Почему ChatGPT не видит ваш сайт: разбор причин

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

По обычным метрикам ничего не заметно. Позиции в Google держатся, органика идет, Search Console показывает зеленые графики. Робот Google научился выполнять скрипты много лет назад и забирает собранный документ целиком. Краулер ChatGPT приходит на тот же адрес и получает пустую оболочку. Разрыв между двумя картинами и есть та зона, где пропадают упоминания в ответах моделей. О том, чем оптимизация под генеративную выдачу отличается от классического поиска, есть отдельный разбор.

Чем краулер модели отличается от поискового

Оба обходят сайты по ссылкам, и на этом сходство заканчивается.

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

Главное расхождение - в моменте обращения. Поисковый робот обходит сайт заранее и складывает копию в индекс. Пользователь задает вопрос, ответ достают из готового хранилища. Модель поступает иначе: она запрашивает адрес в тот момент, когда человек спросил, разбирает полученный документ и делит его на фрагменты сразу же. Каждое следующее цитирование - новый запрос к серверу, а не обращение к сохраненной копии. Отсюда требования к скорости, которых у классического поиска не было.

Ведут себя модели по-разному. Gemini и Copilot скрипты выполняют. У ChatGPT такой способности нет: он забирает то, что сервер отдал в первом ответе, и на этом останавливается. Ориентироваться приходится на самого требовательного участника, иначе сайт будет доступен одной платформе и невидим для другой.

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

Отдельное условие, без которого остальное не имеет смысла. Если краулер закрыт директивой в robots.txt или отбивается защитой от нагрузки, диагностика содержимого бесполезна - до содержимого дело не доходит. Начинать стоит с проверки доступа: какие AI-боты существуют и как открыть им сайт, разобрано отдельно. Файл llms.txt тут тоже не спасает: он описывает структуру, но не заменяет собой текст, которого на странице нет.

Скрипты: что читается, а что нет

Одностраничное приложение на распространенных библиотеках вроде React или Angular собирает содержимое в браузере пользователя. Сервер отдает каркас, дальше работает код. Человек видит наполненный экран, краулер ChatGPT получает оболочку с шапкой и меню, где на месте текста пусто.

Пропадает при этом почти всегда одно и то же:

• цены, которые подгружаются отдельным запросом после открытия страницы
• отзывы и рейтинги из внешних виджетов
• списки товаров в каталоге, если карточки рисуются скриптом
• содержимое вкладок и раскрывающихся блоков
• текст под кнопкой «показать полностью»
• характеристики и описания в аккордеонах на карточке товара

Чаще встречается половинчатый случай, а он опаснее полного. Сайт собран на обычной системе управления, текст статей и описания услуг приходят с сервера, но каталог, калькулятор и блок с ценами дорисовываются скриптом. Владелец проверяет главную, видит текст в коде и успокаивается. Модель при этом отвечает по общим страницам и молчит по товарам - то есть по тем адресам, которые и должны приводить заявки. Отсюда правило: проверять надо не сайт целиком, а каждый шаблон по отдельности.

Требование к устройству документа простое: важное содержимое лежит в разметке текстом. Не появляется после действия пользователя, не спрятано внутри изображения и не существует только в ролике. Отсюда же требования к подписям картинок и расшифровкам видео - для модели это части текста, а без них смысл кадра пропадает.

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

Формулировка задачи для разработчика в одно предложение: «Нужен серверный рендеринг или предварительная генерация страниц, чтобы текст, заголовки и цены приходили в HTML первым ответом сервера, без выполнения JavaScript». Этого достаточно, чтобы человек с доступом к коду понял объем работ. Если сайт на Next.js или Nuxt, режим уже встроен и включается настройкой. Если фронтенд писали с нуля на чистом клиентском рендеринге, речь пойдет о переработке, и сроки будут другими.

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

Когда текст стал доступен, начинается второй вопрос: как он написан и почему одни абзацы берут в ответ, а другие нет. Про это - разбор структуры текста под цитирование.

Проверка через исходный код за две минуты

Способов три, любой доступен без разработчика.

Исходный код. Откройте страницу, вызовите просмотр исходного кода браузера и поищите в нем предложение, которое видно на экране - например, первую строку описания услуги. Нашли - текст приходит с сервера. Не нашли - краулер тоже не найдет, потому что он смотрит ровно в этот документ.

Отключение скриптов. В настройках браузера запретите выполнение JavaScript для своего домена и обновите вкладку. Исчезнувшее и есть та часть, которую модели не получают. Способ нагляднее первого: результат виден сразу и его можно показать заказчику или коллеге без объяснений.

Запрос от имени бота. Через консоль вызывается загрузка адреса с подстановкой имени краулера: `curl -A GPTBot https://example.com/`. В ответ приходит документ, с которым работает модель. Если ответ пустой или в нем нет текста со страницы - вопрос закрыт. Эта же команда стоит в общей процедуре аудита AI-видимости среди других шагов.

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

Смотреть стоит не только на абзацы текста. В исходном коде должны быть видны заголовки разделов, подписи изображений, цена и условия, контакты и адрес, структурированные данные в конце документа. Если заголовки на месте, а цены нет - значит цена подгружается отдельным запросом, и в ответе модели ее не будет.

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

Итог укладывается в два варианта. Первый: содержимое лежит в разметке, тогда причину невидимости надо искать дальше - в доступе для OAI-SearchBot, внешнем обнаружении, скорости или структуре. Второй: содержимое собирается скриптами, и тогда все остальное подождет, потому что до него дело не дойдет.

Bing как дополнительный канал обнаружения

Официальная документация OpenAI не называет Bing единственным обязательным индексом. Для включения содержимого в summaries и snippets критично не блокировать OAI-SearchBot. При этом OpenAI может обнаруживать адреса через сторонних поисковых провайдеров, поэтому присутствие в Bing остается полезным дополнительным каналом, а не условием допуска.

Частные замеры показывали заметное пересечение между ссылками в ответах ChatGPT и результатами Bing, но корреляция не доказывает техническую зависимость. Проверять Bing Webmaster Tools полезно вместе с доступом OAI-SearchBot, качеством содержимого и упоминаниями на других площадках.

Порядок действий короткий:

• подключить сайт в Bing Webmaster Tools и подтвердить права на домен, настройки там близки к Google Search Console
• отправить карту сайта и убедиться, что главные адреса попали в индекс, через инструмент проверки адреса
• при переезде, смене структуры или добавлении разделов отправить карту сайта заново
• посмотреть отчет по цитированию в AI-режимах: он показывает, какие страницы берут в ответы Copilot, и доступен подтвержденным сайтам
• для ускорения обхода подключить IndexNow - протокол мгновенного уведомления поисковых систем об изменениях, после публикации адрес уходит на переобход сразу

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

У остальных платформ свои источники. Алиса опирается на индекс Яндекса, Gemini - на индекс Google. Вывод из этого следует неудобный, но честный: работать приходится с тремя вебмастерскими панелями вместо одной, и запись в каждой стоит примерно пятнадцати минут.

Скорость ответа и почему она стала условием

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

В логах сервера это видно как код 499. Формально его нет в спецификации HTTP, его пишет NGINX, когда клиент оборвал соединение до получения ответа. Всплеск таких записей от краулеров - сигнал, что сайт отсекают по времени. Стоит попросить разработчика или администратора выгрузить обращения GPTBot, ClaudeBot и Google-Extended за месяц с кодами ответов: там же видны отказы 403 и ограничения 429.

Ориентиры берутся из показателей загрузки, которые публикует Google. Отрисовка основного содержимого - меньше 2,5 секунды. Смещение верстки при загрузке - ниже 0,1. Отклик на действие пользователя - меньше 200 миллисекунд. Пороги задавались для поиска и удобства людей, но модели работают с тем же сервером и тем же ответом, поэтому цифры годятся как рабочая планка. Страница, которая открывается пять-шесть секунд, теряет и посетителей, и краулеров.

Что дает результат быстрее прочего:

• сжать изображения и перевести их в современные форматы вроде WebP или AVIF
• главное изображение экрана отдавать сразу, без отложенной загрузки и с высоким приоритетом
• второстепенные скрипты отложить: чаты, виджеты отзывов, счетчики
• убрать цепочки переадресаций, когда один адрес ведет на второй, а тот на третий
• сократить число шрифтов и начертаний

Формулировка для разработчика: «Нужно уложить отрисовку основного содержимого на главной, странице услуги и в статье блога в 2,5 секунды на мобильном соединении, сжать изображения и отложить сторонние скрипты».

Мерить стоит по двум источникам сразу. Лабораторный замер в PageSpeed Insights показывает, как страница ведет себя на эталонном соединении, и годится для поиска узких мест. Полевые данные в Search Console собираются с посетителей и показывают картину на их устройствах - на рынках вроде Узбекистана или Кыргызстана, где велика доля мобильного интернета, разрыв между двумя цифрами доходит до нескольких секунд. Ориентироваться надо на полевые: краулер приходит по тем же каналам связи.

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

Структура документа и границы блоков

Модель делит полученный документ на фрагменты и дальше работает с ними по отдельности. Границы фрагментов она проводит по структуре: заголовкам и разделам. Когда структуры нет, деление получается случайным, и в отбор попадает обрывок без начала и конца. Такой обрывок не выбирают в ответ, даже если текст написан хорошо.

Разбору помогает такое устройство документа:

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

Структурированные данные читаются из исходного кода и добавляют определенности: они прямо сообщают, что перед моделью статья, товар или организация. Как их собирать под генеративную выдачу - в разборе разметки сущностей.

Здесь речь о технической стороне: теги, уровни, границы. Что писать внутри этих границ, чтобы фрагмент годился в ответ целиком, разобрано в материале про структуру текста.

Конструкции, которые прячут содержимое от краулера

Скрипты, скорость и структура разобраны выше. Осталось устройство самого сайта, и оно держится на трех требованиях.

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

Честные служебные данные. Канонические адреса, дата изменения в разметке, указания по сниппетам. Без них краулер достраивает картину сам и ошибается.

Уважение к нагрузке. Задержку между обращениями объявляют в robots.txt. Отбитый защитой бот уходит молча и возвращается нескоро.

Дальше - типовые конструкции, которые эти требования нарушают.

Каталог с подгрузкой по прокрутке. Товары ниже первой партии не существуют для модели: она не прокручивает экран. Решение - постраничная навигация со ссылками на каждую страницу. Виды такой навигации различаются последствиями: нумерация страниц дает краулеру набор адресов, кнопка «показать еще» дает один адрес, бесконечная прокрутка не дает ничего. Отдельный вариант - страница со всем каталогом сразу, но она проигрывает по скорости.

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

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

Языковые версии. Языки и регионы разносятся по подкаталогам вида `/uz/`, `/kz/`, `/en/`. Поддомен для такой задачи хуже: он набирает вес самостоятельно, и усилия расходятся по разным адресам. Служебные указания на языковые варианты страницы обязательны, иначе система выберет наугад. На практике это два действия: языковой атрибут в разметке документа для каждой версии и перекрестные указания между ними. Переводы нужны человеческие - машинный текст модели читают, но в ответ берут неохотно. И главное: язык материала должен совпадать с языком вопроса. Человек, спросивший по-узбекски, получит подборку из источников на своем языке, и русская версия той же страницы в нее не войдет. Что писать на каждом языке и как это работает на локальных рынках - отдельная тема, ей занимается HITZ Agency, GEO-агентство в Центральной Азии.

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

Сайты на конструкторах вроде Tilda или Wix ведут себя лучше одностраничных приложений: текст они отдают сервером. Ограничения там другие - служебные файлы, разметка, скорость шаблонов. Как обходить эти ограничения, разобрано отдельно. Проверить доступ ботам к сайту на конструкторе стоит через настройки robots.txt, они есть не во всех тарифах.

Чек-лист технической доступности

Список для одного прохода по сайту. Слева - что смотрим, справа - что считать провалом.

• Содержимое в разметке. Исходный код, поиск фразы с экрана. Провал: фразы в коде нет
• Работа без скриптов. Отключить выполнение JavaScript и обновить вкладку. Провал: текст исчез
• Ответ краулеру. Запрос адреса от имени бота. Провал: ответ пустой
• Индекс Bing. Проверка адреса в Bing Webmaster Tools. Провал: главные адреса не проиндексированы
• Скорость. Измерение отрисовки основного содержимого. Провал: больше 2,5 секунды
• Коды в логах. Поиск обращений краулеров за месяц. Провал: 403, 429, 499
• Навигация. Обход каталога по ссылкам без прокрутки. Провал: часть карточек недостижима
• Заголовки. Структура документа. Провал: пропуски уровней или несколько первых заголовков
• Изображения и ролики. Подписи и расшифровки. Провал: пусто
• Языковые версии. Подкаталоги и служебные указания. Провал: поддомены или машинный перевод
• Переадресации. Четыре варианта адреса. Провал: работают несколько версий одной страницы

Чинить стоит по порядку, а не по удобству. Сначала то, что делает содержимое недоступным целиком: запреты для ботов и сборку текста скриптами. Затем скорость - без нее содержимое не успевают забрать. Затем структуру и разметку, которые определяют, каким куском сайт попадет в ответ. Порядок важен, потому что первый пункт обесценивает все остальные: вылизанная иерархия заголовков на странице с пустой оболочкой не даст ничего.

Самый короткий срок до результата в моей работе выглядел так. Сайт переделали под серверную отдачу текста, дописали служебные страницы - «О компании», контакты, условия работы, - привели в порядок структурированные данные. Через месяц модели начали приводить его в ответах. Такая скорость получается, когда закрывают все части сразу: доступ, содержимое, разметку. Когда пункты чинят по одному за квартал, счет идет на полгода и больше.

Коротко

• Модели забирают документ в момент вопроса пользователя, а не заранее, и скрипты при этом не выполняют.
• Сайт, который собирает текст в браузере, отдает ChatGPT пустую оболочку: заголовки, цены и отзывы в ответ не попадут.
• Диагностика занимает две минуты: найти фразу с экрана в исходном коде, обновить вкладку с выключенным JavaScript, запросить документ под именем GPTBot.
• Для ChatGPT в первую очередь нужен доступ OAI-SearchBot; Bing остается дополнительным каналом обнаружения. Для Алисы важны индекс Яндекса и YandexAdditionalBot, для AI-функций Google — Googlebot.
• Скорость ответа решает, успеют ли забрать текст: при долгом ожидании модель уходит к другому источнику, в логах остается код 499.
• Чинить по порядку: доступ, доставка содержимого, скорость, структура. Верхнее не работает без нижнего.

Если проблема начинается с поискового обхода, проверьте по шагам, почему страниц нет в индексе.

Частые вопросы