Чат с ИИ против классического сайта
Почему я больше не мыслю интерфейс как набор страниц
Я — разработчик и архитектор, который последние годы живёт на стыке веб‑фреймворков, SEO и инструментов искусственного интеллекта. Осознанно остаюсь в полутени: в этой истории важнее не моё имя, а паттерн, который вырастает из практики и, кажется, скоро станет нормой.
Если коротко, мы влетели в ситуацию, где пользователь всё чаще спрашивает ИИ вместо того, чтобы ходить по сайту. При этом маркетинг по‑прежнему инвестирует в SEO и дизайн, продукт — в новые фичи, разработчики — в очередной рефакторинг фронтенда. Воронка, вроде бы, та же. Но поведение людей — уже другое.
Возникает неприятный вопрос: если клиент идёт сначала в ChatGPT или Perplexity, а уже потом, возможно, доходит до нашего сайта, то кто на самом деле контролирует интерфейс общения с ним? И не превратится ли бизнес в просто «поставщика данных» для чужих голосов и чужих интерфейсов?
В этом тексте хочу поделиться тем, как я отвечаю для себя на этот вопрос. Почему, на мой взгляд, чат с ИИ не убьёт сайты, но вынудит нас переизобрести саму модель интерфейса. И как архитектура слотов и параллельных маршрутов помогает превратить ИИ‑слой в часть продукта, а не в внешний придаток.
Как ИИ ломает привычный маршрут «поисковик → сайт»
Давайте честно. Годы мы жили в одном и том же паттерне:
- Пользователь формулирует короткий запрос в поисковике.
- Открывает несколько ссылок.
- Блуждает по сайту, пока не находит ответ или не выгорает.
Сайты под эту модель проектировались годами: меню, хлебные крошки, фильтры, внутренняя поисковая строка, «похожие материалы». Контент‑стратегии, SEO, UI/UX — всё было подчинено задаче «помочь человеку быстрее найти нужную страницу».
ИИ‑чаты разрушили эту картинку одним простым действием: они убрали из цепочки «страницу» как обязательный шаг.
Вместо «купить кроссовки спб» люди пишут: «нужны чёрные кроссовки для города, не для бега, до 8 тысяч, чтобы не было огромного логотипа на боку». Вместо «документация next js parallel routes» — длинный вопрос с контекстом своего проекта. Вместо «как подать 3‑НДФЛ» — описание ситуации.
Ключевая перемена:
- раньше пользователь подстраивал мысли под алгоритм поиска;
- теперь система подстраивается под естественный язык пользователя.
И самое неприятное для владельца сайта в том, что в этой новой цепочке сайт может вообще не появиться. Чату не нужно показывать страницу, чтобы дать ответ. Он может прочитать её сам, переварить, объединить с другими источниками и выдать аккуратный пересказ.
Я несколько раз ловил себя на том, что решаю вопрос с продуктом конкурента, даже не зайдя к нему на сайт. Просто потому, что диалог с ИИ оказался быстрее, чем разбор чужой навигации. Уверен, это не только мой опыт.
Если ИИ такой умный, зачем нам сайты?
Логичный радикальный вопрос: если ИИ и так всё расскажет, зачем вообще сайты, интерфейсы, сложные UX‑сценарии? Может, всё будем делать через один универсальный чат?
Технически — да, довольно много задач можно уместить внутрь диалога:
- подобрать товар;
- заполнить форму по голосовым ответам;
- помочь с онбордингом в сложную систему;
- объяснить контракт простым языком.
Но есть несколько «но», которые делают полную замену сайта чатом плохой идеей.
1. Бренд нельзя уместить в пузырь чата
Бизнесу мало «чтобы это работало». Нужен характер, атмосфера, отличимость. Это достигается не только текстом, но и формой — визуальным языком, типографикой, анимацией, тем, как продукт «чувствуется» в интерфейсе.
Чат, особенно стандартизированный, радикально сужает выразительные средства. Все бренды становятся одинаковыми: текст, аватар, несколько кнопок. Уходит ощущение «я в особом пространстве конкретного продукта».
2. Не все задачи удобны в чистом диалоге
Есть сценарии, где диалог — идеален. Но есть и такие, где человеку проще принять решение, увидев таблицу, карту, график, структуру страницы. Попробуйте заменить полноценный отчёт с сотней показателей на диалог: либо вы утонете в текстах, либо интерфейс всё равно начнёт показывать визуальные блоки.
Чистый чат — это крайность. Так же как чистый «страничный» интерфейс без умного слоя — другая крайность.
3. Потеря контроля и доверия
Когда всё, что видит пользователь, — это ответы внешнего ИИ, бизнес теряет:
- контроль над тем, как именно объясняется продукт;
- возможность выстроить свою историю;
- часть доверия: «мне ответил не сервис X, а некая абстрактная нейросеть».
В какой‑то момент бренд может целиком раствориться в чужих алгоритмах.
Что это значит для бизнеса: деньги, SEO и влияние
С позиции бизнеса здесь две большие угрозы и одна большая возможность.
Угроза №1. Вы становитесь «сырьём» для чужого интерфейса
Если ваш продукт существует только как набор страниц, доступных ИИ, вы уже сегодня рискуете стать поставщиком сырья. Модели берут ваш контент, агрегируют, миксуют с конкурентами и подают пользователю в собственном интерфейсе.
Кто в этой конструкции владеет отношениями с клиентом? Не вы.
Угроза №2. Классический SEO‑подход начинает буксовать
SEO по‑прежнему важно: люди всё ещё ищут через Google/Яндекс, а поисковики всё ещё выдают страницы. Но параллельно развивается слой ИИ‑ответов, который может «перехватить» пользователя до того, как он доедет до вашего сайта.
Если продукт не умеет сам разговаривать с пользователем (через встроенный ИИ‑слой), он с каждым годом будет всё больше зависеть от чужих интерфейсов.
Возможность. Гибридный интерфейс как точка роста
Если встроить ИИ в свою архитектуру, бизнес получает интересную комбинацию:
- SEO и статический контент продолжают приводить трафик и работать на доверие;
- ИИ‑диалог внутри вашего интерфейса сокращает путь пользователя от «интереса» до «действия»;
- архитектура с несколькими «потоками» позволяет развивать новый функционал без постоянного перелопачивания фронтенда.
Это уже не про «поставить чатик на сайт». Это про то, чтобы интерфейс умел:
- говорить с пользователем;
- понимать его контекст;
- управлять визуальными слоями (открывать нужные экраны, подбирать данные);
- при этом оставаться устойчивым и индексируемым.
Новый интерфейс: не «страницы против чата», а параллельные потоки
Момент, когда у меня «щелкнуло» в голове, был связан с очень конкретной задачей.
Нужно было построить систему, где:
- слева живёт ИИ‑чат, который знает всё о продукте, доках, внешних сервисах;
- справа живут и статические страницы, и динамические интерфейсы для авторизованных пользователей;
- падение правой части (ошибка, сбой API) не убивает чат и не сбрасывает диалог;
- статические страницы остаются SEO‑дружелюбными HTML‑документами, которые работают даже без JavaScript.
Когда начинаешь это декомпозировать, быстро понимаешь: одной страницы и одного потока интерфейса мало. Нужны параллельные потоки опыта.
- Диалоговый поток — голос ИИ, который понимает язык задач и может инициировать действия.
- Визуальный поток — страницы, дашборды, формы, таблицы.
- Бизнес‑логика и данные — то, что решает, что можно, а что нельзя, какие сценарии допустимы.
Ключевое слово — «параллельные». Они не обязаны идти один за другим: сначала чат, потом страница, потом обратно. Они могут жить одновременно:
- вы задаёте вопрос ИИ;
- он отвечает;
- одновременно открывает справа нужный экран;
- справа вы что‑то кликаете — чат это «видит» и предлагает следующее действие.
Чтобы так работало, нужна архитектура, которая умеет держать несколько независимых областей интерфейса в рамках одного приложения.
Немного архитектуры без кода: слоты и параллельные маршруты
Я пришёл к решению через архитектуру, которую назвал AIFA. В ней интерфейс устроен как набор слотов (окон), каждый из которых живёт своей жизнью, но все они разделяют общую сцену.
Упрощённо:
- левый слот — чат, авторизация, ассистент;
- правый статический слот — страницы, которые должны грузиться быстро и работать даже без JS (SEO, доверие, документация);
- правый динамический слот — сложные интерфейсы для авторизованных пользователей (дашборды, настройки, web3‑инструменты и т.п.).
Важно не то, какой именно фреймворк вы используете, а сам принцип:
- у каждого слота свой жизненный цикл;
- ошибка в одном не должна валить остальные;
- навигация в одном слоте не должна сбрасывать состояние другого (например, чата);
- рендеринг можно подбирать отдельно: статический, динамический, гибридный.
В мире Next.js это естественным образом ложится на параллельные маршруты (parallel routes). Но даже если вы используете другой стек, сама идея остаётся: вы перестаёте мыслить «один URL = один поток», начинаете мыслить «один экран = несколько потоков, живущих параллельно».
Примеры сценариев, где новый интерфейс оправдан
1. Сложная документация и обучающие продукты
Пользователь не знает структуру доки и не хочет учить её. Он хочет ответ на свою задачу.
- Он пишет в чат: «как правильно обновить токен, если у меня мульти‑тенантная архитектура и два клиента на одном аккаунте?»
- ИИ вытягивает нужные фрагменты из документации, собирает ответ.
- Одновременно открывает справа страницу, где это подробно расписано, чтобы пользователь мог углубиться.
Вместо того чтобы «знать сайт», человек просто рассказывает ситуацию.
2. E‑commerce с большой номенклатурой
Тысячи товаров, десятки фильтров. Пользователь не хочет ставить 18 галочек.
- Слева он формулирует «живой» запрос: «нужен ноутбук для дизайна, 16+ ГБ ОЗУ, хороший экран, не тяжелее 1.5 кг, бюджет до 150k».
- ИИ понимает задачу и подбирает диапазон моделей, открывает их справа.
- Если надо — включает классический фильтр, но уже как уточнение, а не точку входа.
3. B2B‑сервисы и админки
Вместо «запомни 15 отчётов и 30 фильтров»:
- менеджер пишет: «покажи клиентов, у которых за последние 3 месяца упала активность, но чек остался высоким»;
- справа открывается отчёт с нужным срезом;
- чат объясняет, почему выбрал такие критерии.
Когда новый интерфейс не нужен
Важно не впасть в противоположную крайность — видеть в этом паттерне серебряную пулю.
Не нужен новый интерфейс:
- простым лендингам и одностраничным промо;
- микропроектам, где ценность — в скорости вывода гипотез, а не в сложной архитектуре;
- ситуациям, где у пользователя одна‑две простые задачи, легко решаемые статичной формой.
Там будет достаточно сделать хороший, быстрый сайт и, возможно, добавить минимальный чат‑слой как эксперимента.
Нужен — там, где:
- много страниц, разделов, сущностей;
- значимая доля трафика идёт из поисковиков (SEO важен);
- есть сценарии для авторизованных пользователей (личный кабинет, дашборды, кабинеты партнёров);
- команда готова думать в категориях архитектуры, а не только компонентов.
Личный вывод: я больше не вижу интерфейс как «только страницы»
Я не верю, что завтра весь веб исчезнет и мы останемся один на один с абстрактными чатами. Но я точно уже не могу проектировать интерфейсы так, как делал это до появления массовых ИИ‑чатов.
- Игнорировать диалоговый слой — значит, заставлять пользователя играть по старым правилам, тогда как он уже привык говорить по‑своему.
- Уходить полностью в чат — значит, отказаться от бренда, визуального языка, прозрачности и части контроля.
Поэтому для себя я выбираю третий путь — архитектуру, где интерфейс состоит из нескольких параллельных потоков: чат понимает задачи, страницы дают форму и контекст, бизнес‑логика расставляет границы. ИИ становится не внешним сервисом, а внутренним слоем продукта.
И, честно говоря, меня меньше волнует, как это называется — AIFA, «новый UI/UX» или ещё как‑то. Важно другое: начнём ли мы, как индустрия, осознанно проектировать интерфейсы под новую реальность, или продолжим спорить «кто кого убьёт — чат или сайты».
Лично я в этот спор уже не верю. Чат и сайт не враги. Враги — устаревшие модели мышления.