«Спросил у ChatGPT про вашу компанию — он назвал трех конкурентов». Если вы работаете с сайтами, такую фразу вы слышали уже не раз. При этом сайт в топе, трафик из поиска идет, конверсии в порядке. А нейросеть либо не знает о вас, либо рассказывает о компании по данным двухлетней давности.

Первая реакция — переписать тексты, добавить экспертизы, оформить FAQ. Мы проходили этот путь: гипотеза про «мало контента» выглядит логично, но почти никогда не подтверждается. Отвечает нейросеть не по вашему тексту, а по тому, что до нее дошло. И вот тут начинается самое интересное.

Когда мы прогнали свой сайт через запросы к разным моделям и посмотрели, что именно получает их инфраструктура, картина оказалась прозаичной. Часть ИИ-краулеров не исполняет JavaScript. Для сайта, который собирается в браузере, это означает одно: до модели вместо статьи доезжает пустой каркас. Пользователь видит прекрасную страницу, а нейросеть — пустой файл.

В этой статье разберем, как устроено чтение сайтов системами ИИ, где контент теряется на пути от сервера к ответу модели и что из этого можно проверить и починить.

❯ Нейросеть не ходит по сайту — она собирает контекст

Чтобы понять, почему сайт может быть невидим для ИИ, полезно разобраться, как модель вообще получает информацию. Многие представляют процесс так: пользователь задает вопрос, нейросеть «заходит» на сайт и читает его, как это сделал бы человек в браузере. Это не так.

Нейросеть работает через retrieval-слой — отдельный поисковый пайплайн, который перед генерацией ответа находит документы по теме, нарезает их на фрагменты и отбирает самые релевантные. Эти фрагменты попадают в контекст модели, и уже на их основе она строит ответ со ссылками на источники.

Из этого следуют два практических вывода. Во-первых, критерий попадания в ответ — не позиция в выдаче, а пригодность страницы к извлечению фрагментов. Робот ищет не «страницу целиком», а абзац, который можно вырезать и вставить в ответ. Во-вторых, чтобы что-то извлечь, это «что-то» должно физически находиться в том, что отдал сервер.

На сайт при этом приходят разные роботы, и ведут они себя по-разному. За OpenAI работают GPTBot и OAI-SearchBot, за Anthropic — ClaudeBot, есть PerplexityBot, есть роботы Яндекса, обслуживающие Алису и режим «Нейро». И вот ключевой момент: не все из них умеют исполнять JavaScript. Часть краулеров забирает HTML в том виде, в котором его вернул сервер, и на этом останавливается.

Для классического сайта на серверном рендеринге это не проблема — текст уже внутри HTML. Для сайта, который собирается в браузере из JavaScript, это приговор: в исходном ответе нет ни заголовков, ни текста, ни цен, ни адресов.

❯ Три слоя, где теряется контент

Когда мы разложили путь от сервера до ответа модели на этапы, стало видно, что сбой возможен на трех уровнях. И чинить их нужно в правильном порядке: сначала доступ, потом рендеринг, потом сигналы. Перепутаете порядок — будете полировать тексты, которые до модели не доезжают.

Доступ: кого пускает сервер

Прежде чем читать страницу, краулер должен ее получить. А сервер может его не пустить. Проверьте три вещи. Первая — robots.txt: не закрыты ли в нем роботы ИИ. Ситуация частая: владельцы сайтов годами не трогали файл, но при обновлении CMS в него попали директивы, блокирующие новых ботов. Вторая — WAF и защита от ботов: они умеют отдавать 403 или капчу не только по частоте запросов, но и по user-agent, и «лишние» роботы отсекаются вместе со спамом. Третья — логи. Если в логах сервера нет визитов от GPTBot или ClaudeBot, значит, до сайта они либо не дошли, либо их отсекли на входе

Отдельно про популярный совет «закройте GPTBot, чтобы модель не училась на вашем контенте». Здесь важно понимать механику. Роботы, которые действуют по прямому запросу пользователя, могут не подчиняться правилам robots.txt: провайдеры сами предупреждают, что в таких случаях файл может не применяться. То есть закрытая дверь не дает той защиты, на которую рассчитывают, зато гарантированно лишает вас попадания в ответы.

Рендеринг: пустой каркас вместо страницы

Второй слой — тот самый, из-за которого сайт «невидим» при живом трафике. Разница между типами рендеринга здесь решает все.

CSR, клиентский рендеринг: сервер отдает скелет страницы и скрипты, а контент подставляет браузер. Это привычная схема для SPA на React, Vue или Angular. Для бота без поддержки JavaScript такая страница выглядит как пустая заготовка. SSR, серверный рендеринг: страница собирается на сервере и приходит уже с текстом. SSG: страницы генерируются заранее при сборке. ISR: статика обновляется по мере необходимости. В любом из этих вариантов в HTML уже лежит готовый к извлечению контент — именно этого и ждут от сайта краулеры ИИ.

Полностью переезжать на другой стек при этом не обязательно. Практика показывает, что решает задачу точечный подход: пререндерить критичные данные. Цены, контакты, состав услуг, ключевые абзацы описаний — все, что нейросеть должна уметь процитировать, должно находиться в исходном HTML. Остальное может подгружаться скриптами, как раньше.

Проверить это просто: откройте исходный код страницы в браузере (не инспектор, а именно исходник ответа сервера) и поищите там текст, который хотите видеть в ответах моделей. Нет текста в исходнике — нет текста и у нейросети.

Формат: llms.txt, разметка и скорость ответа

Начнем с llms.txt — файла, о котором в последний год говорят много и часто путают его с robots.txt и sitemap.xml. Разница принципиальная: robots.txt управляет доступом, sitemap перечисляет URL для индексации, а llms.txt объясняет смысл сайта — что это за проект, какие разделы главные, что цитировать в первую очередь. Это markdown-файл в корне сайта с краткой картой ключевых страниц. Есть и расширенная версия — llms-full.txt, куда выносят более полное содержание.

Стандарт появился в сентябре 2024 года, а 10 августа 2026-го получил вторую версию спецификации — первую ревизию за все время. Файл перенимают и крупные игроки: свои llms.txt публикуют Anthropic, OpenAI, Perplexity, Cloudflare, Stripe. Google добавил его в собственную документацию для разработчиков. Обязательным требованием файл при этом не стал: проверка в Lighthouse не срабатывает, если сервер честно отвечает 404.

Но есть нюанс, который стоит держать в голове: наличие файла не равно его работоспособности. Формат легко сломать — неправильной структурой, битыми ссылками, отсутствием обязательных секций. Проблема настолько массовая, что мы разбирали ее отдельно: три llms.txt из десяти оказываются сломаны, и владельцы об этом не знают.

Кроме llms.txt работает и классическая машиночитаемая разметка: Schema.org помогает системам аккуратно извлекать факты о компании, товарах и услугах. А еще — скорость ответа сервера и аптайм. Если страница отдается медленно или периодически недоступна, шансов попасть в ответ становится меньше: retrieval-слою проще взять соседний источник, который отдает то же самое быстро и стабильно.

❯ Проверяем сайт глазами нейросети

Теория полезна, когда ее можно проверить на своем проекте. Собрали набор простых проверок, которые мы прогнали на своих страницах. Никакого специального софта не нужно — хватит терминала и браузера.

Проверка первая: запрос от имени бота. Возьмите адрес важной страницы и запросите его с user-agent, под которым ходит ИИ-краулер:

curl -A "GPTBot" https://example.com/page | head -c 2000

Посмотрите, что попало в ответ. Если в первых двух килобайтах есть заголовок, текст и ключевые данные — сервер отдает контент. Если вы видите каркас из тегов и подключенные скрипты, а текста нет — вы нашли причину. Повторите это для адресов, под которыми ходят другие роботы: набор user-agent у каждого провайдера свой и опубликован в его документации.

Проверка вторая: исходник против DOM. Откройте страницу и сравните две вещи: исходный код ответа сервера и финальную структуру страницы в инспекторе, после выполнения скриптов. Разница между ними — это ровно тот контент, который доступен браузеру и недоступен части краулеров. Полезно оценить не только факт расхождения, но и объем: если в исходнике пусто, а в интерфейсе — статья на десять тысяч знаков, у вас проблема первого порядка. 

Проверка третья: логи. Загляните в журналы веб-сервера и поищите визиты роботов по user-agent. Так вы увидите, кто реально до вас доходит, как часто и какие страницы запрашивает. Если ИИ-боты не появляются в логах вообще — возвращайтесь к слою доступа. 

Проверка четвертая: валидатор llms.txt. Если файл уже есть, прогоните его через валидатор: он проверяет структуру (заголовок, описание, секции), размер и корректность ссылок. Файл, который существует, но не проходит валидацию, работает не лучше отсутствующего.

Проверка пятая: тест в самой модели. Задайте нейросети несколько вопросов по вашей теме и посмотрите, какие источники она называет и использует. Учтите два нюанса: у каждой модели свой набор источников, а ответы от прогона к прогону различаются — один запрос ничего не доказывает. Спрашивайте одинаково минимум три раза и фиксируйте, что меняется. 

❯ Что чинить в инфраструктуре

Когда причина найдена, исправления выстраиваются в понятную последовательность от простого к сложному.

Доступ. Приведите robots.txt в порядок: уберите случайные запреты, проверьте, что нужные роботы допущены. Настройте правила безопасности так, чтобы они не отсекали ИИ-краулеров заодно со спамом. Если сайт за прокси или CDN, проверьте фильтрацию и на этом уровне.

Рендеринг. Выберите стратегию под свой стек. Если сайт на серверном рендеринге — вы уже в выигрыше, проверьте только, что критические блоки действительно попадают в HTML, а не подгружаются отложено. Если на клиентском — двигайтесь к серверному рендерингу постепенно: начните с самых важных страниц. Для этого хватает небольшого сервера: тестовый стенд поднимается за пару минут, и на нем можно спокойно прогонять проверки, не трогая продакшен.

Скорость и стабильность. Быстрый ответ сервера и стабильный аптайм — недооцененный фактор видимости. Тут помогают кэш и CDN перед сайтом, а также мониторинг: важно знать о недоступности раньше, чем о ней сообщат пользователи. Статику, тот же llms.txt и llms-full.txt, удобно отдавать из объектного хранилища — например, из S3-хранилища в Timeweb Cloud, которое снимает с сервера раздачу файлов.

Файлы и разметка. Добавьте llms.txt с честной структурой, при необходимости — расширенную версию. Проверьте разметку Schema.org. Обновите даты и авторов на страницах, чтобы у систем были свежие сигналы о контенте.

Если коротко, весь блок исправлений сводится к одной мысли: между вашим контентом и нейросетью не должно быть технического посредника, который молча ломает передачу. Для команд, которые держат инфраструктуру на своей стороне, это привычная логика: то, что видно в мониторинге, контролируется; то, что не видно, ломается тихо. Кстати, VDS в Timeweb Cloud удобен тем, что весь стек проверок можно собрать на одном сервере и наблюдать за ним целиком: сервер, ответы, боты, скорость.

❯ Как измерять результат

Починили — теперь нужно понять, стало ли лучше. Здесь работают три метрики, которые уже прижились в практике продвижения под нейросети. Citation Rate — доля ваших запросов, в ответах на которые вас цитируют. Share of Voice — соотношение ваших упоминаний с упоминаниями конкурентов по выбранной группе запросов. Brand Mention Rate — как часто бренд вообще называется в ответах, даже без ссылки на сайт. Замерять их стоит вручную или полуавтоматизированно, но регулярно: по пяти-десяти значимым для бизнеса формулировкам, с несколькими прогонами на каждую.

Отдельно про трафик. OpenAI добавляет к ссылкам в поисковых цитированиях метку utm_source=chatgpt.com — такие переходы можно отфильтровать в аналитике. Обратите внимание: во встроенных ссылках внутри диалога метки может не быть, поэтому «нулевой» результат в отчете еще не значит, что переходов нет. 

И главное — не обманывайте себя на малой выборке. Модели недетерминированы: один и тот же запрос в разные моменты дает разные ответы. Если вас упомянули один раз из одного — это не результат, а случайность. Три прогона по десять запросов — уже разговор.

❯ Чек-лист

Проверьте свой сайт по пунктам — от простого к сложному. Полный проход занимает один вечер.

• Проверьте robots.txt: не блокирует ли он роботов ИИ

• Посмотрите логи веб-сервера: приходят ли ИИ-краулеры

• Выполните запрос с user-agent бота и изучите ответ

• Сравните исходный HTML с DOM после рендеринга

• Убедитесь, что цены, контакты и описания есть в исходном HTML

• Определите стратегию рендеринга для ключевых страниц

• Проверьте TTFB и настройте мониторинг доступности

• Добавьте llms.txt, при необходимости — llms-full.txt

• Прогоните файлы через валидатор

• Проверьте разметку Schema.org на важных страницах

• Обновите даты публикации и авторов материалов

• Настройте отслеживание AI-трафика по utm-меткам

• Замерьте Citation Rate по пяти-десяти запросам, минимум три прогона

• Повторите замеры через месяц и сравните

❯ Итоги

Нейросеть не «видит» сайт. Она получает то, что ей отдала инфраструктура, — и работает только с этим. Поэтому оптимизация под нейросети начинается не с текстов, а со слоя, где контент может потеряться: доступа, рендеринга и скорости ответа. Тексты подключаются потом, когда фрагмент уже доезжает до модели.

Хорошая новость в том, что почти все из этого проверяется своими руками и за понятное время: один запрос в терминале, одна прогулка по логам, один файл в корне сайта. Плохая — в том, что проблема не видна снаружи: страница выглядит прекрасно и для вас, и для пользователей, и для классического поиска. Просто кто-то третий раз за разом получает пустой каркас и уходит к конкурентам.

Начните с одной страницы. Прогоните ее по чек-листу и посмотрите, что вернется на запрос от имени бота. Дальше будет проще: вы уже будете знать, что именно чинить.

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram‑канале ↩