Владельцы сайтов всё чаще сталкиваются с ситуацией, когда ChatGPT или другая языковая модель не знает о компании либо рассказывает о ней по устаревшим данным, хотя сам сайт находится в топе выдачи и показывает хорошие конверсии. Первая реакция в таких случаях обычно сводится к переписыванию текстов, добавлению экспертизы и оформлению FAQ. Однако, как показывает практика, гипотеза о недостатке контента почти никогда не подтверждается, поскольку нейросеть отвечает не по тексту страницы, а по тому, что реально дошло до её инфраструктуры. Когда сайт прогоняется через запросы к разным моделям, выясняется, что часть ИИ-краулеров не исполняет JavaScript, и для сайта, который собирается в браузере, это означает передачу пустого каркаса вместо статьи.

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

Когда путь от сервера до ответа модели раскладывается на этапы, становится видно, что сбой возможен на трёх уровнях, и чинить их нужно в правильном порядке: сначала доступ, потом рендеринг, потом сигналы. На уровне доступа краулер должен получить страницу, но сервер может его не пустить. Проверить стоит три вещи: не закрыты ли роботы ИИ в robots.txt, не отсекают ли их WAF и защита от ботов по user-agent, и есть ли в логах сервера визиты от GPTBot или ClaudeBot. Отдельно стоит упомянуть популярный совет закрыть GPTBot, чтобы модель не училась на контенте: роботы, действующие по прямому запросу пользователя, могут не подчиняться правилам robots.txt, поэтому закрытая дверь не даёт ожидаемой защиты, зато гарантированно лишает попадания в ответы. На уровне рендеринга разница между типами отдачи страницы решает всё: CSR отдаёт скелет и скрипты, а контент подставляет браузер, тогда как SSR, SSG и ISR формируют HTML уже с готовым к извлечению текстом. Полностью переезжать на другой стек не обязательно — практика показывает, что задачу решает точечный подход: пререндерить критичные данные, такие как цены, контакты, состав услуг и ключевые абзацы описаний. Проверить это просто: нужно открыть исходный код страницы в браузере и поискать там текст, который хочется видеть в ответах моделей; нет текста в исходнике — нет текста и у нейросети.

Третий уровень связан с форматом и сигналами, и здесь центральное место занимает файл 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 и другие компании. Помимо этого, значение имеют разметка и скорость ответа сервера, поскольку медленная отдача или отсутствие структурированных данных усложняют извлечение фрагментов.

Для российского рынка описанная проблема особенно актуальна, поскольку всё больше компаний используют нейросети для анализа конкурентов, подбора подрядчиков и формирования рекомендаций. Если сайт собирается на JavaScript и не отдаёт контент в исходном HTML, он рискует выпасть из ответов не только зарубежных моделей, но и российских решений, включая сервисы Яндекса с Алисой и режимом «Нейро». Отраслевые специалисты отмечают, что запросы на аудит «видимости для ИИ» растут, но многие команды по-прежнему начинают с контента, а не с технической доступности. В результате ресурсы тратятся на тексты, которые физически не доезжают до модели, тогда как исправление доступа и рендеринга могло бы дать быстрый эффект. Показательно, что даже в смежных разработках, таких как ИИ-сметчик или ИИ-секретарь, авторы подчёркивают важность инфраструктурных ограничений: без ключа доступа или при неверной маршрутизации запросов даже хорошая модель не выдаёт результат.

Если сравнивать подходы к решению проблемы, то полный переезд на серверный рендеринг или статическую генерацию выглядит радикальным и затратным, особенно для крупных проектов на React, Vue или Angular. Точечный пререндеринг критичных данных оказывается более гибкой альтернативой, позволяющей сохранить текущий стек и при этом обеспечить попадание ключевой информации в исходный HTML. Альтернативой также может стать использование динамического рендеринга, когда для ботов с определёнными user-agent отдаётся заранее подготовленная версия страницы, хотя такой подход требует аккуратной настройки, чтобы не нарушать правила поисковых систем. Наконец, публикация llms.txt и llms-full.txt становится дополнительным сигналом, который помогает моделям понять структуру сайта и приоритеты цитирования, но не заменяет техническую доступность контента.

В перспективе можно ожидать, что требования к «ИИ-дружелюбности» сайтов будут только расти, а стандарты вроде llms.txt получат более широкое признание и, возможно, новые версии спецификации. Открытыми остаются вопросы о том, как будут развиваться краулеры с поддержкой JavaScript, начнут ли они массово исполнять скрипты, и как это повлияет на нагрузку серверов. Также неясно, станут ли поисковые системы учитывать наличие llms.txt при ранжировании или это останется исключительно вспомогательным сигналом. Пока же владельцам сайтов стоит проверить доступ, рендеринг и формат, поскольку именно эти три слоя определяют, увидит ли нейросеть компанию или расскажет о ней по данным двухлетней давности.