Как сделать JavaScript-сайт читаемым для ChatGPT и ИИ

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

Удобно держать это в голове как порядок действий. Видимость в ИИ сводится к доставке контента, и у неё три слоя, которые должны работать по очереди. Сначала доступ: может ли бот вообще загрузить страницу? Затем осмысленный HTML: есть ли основной контент в этом первом ответе, без запуска JavaScript? И только потом клиентская интерактивность: скрипты, которые улучшают уже читаемую страницу. Пропустите слой, и те, что над ним, перестают иметь значение.

Ключевые выводы

• Многие ИИ-краулеры читают сырой HTML и не выполняют JavaScript. Vercel наблюдала, как GPTBot и OAI-SearchBot от OpenAI, ClaudeBot от Anthropic и PerplexityBot загружают HTML, не рендеря его; Gemini от Google (через Googlebot) и AppleBot — исключения (Vercel).
• Работайте по порядку: доступ → осмысленный HTML → интерактивность. Клиентский JS должен улучшать уже читаемую страницу, а не создавать её.
• «Google это рендерит» — слабый критерий. Googlebot необычно силён, поэтому пройти его рендеринг ещё не значит, что другие ИИ-краулеры увидят ваш контент.
• Боты не взаимозаменяемы: OAI-SearchBot для видимости в поиске ChatGPT, GPTBot для управления обучающим обходом, ChatGPT-User для загрузки по запросу пользователя; настраиваются независимо (OpenAI).
• Что видит бот, можно воспроизвести с помощью curl, View Source, перезагрузки с отключённым JS и снимков в headless-браузере. aiSiteReady автоматизирует те же проверки и оценивает сайт от 0 до 100.

Читает ли ChatGPT JavaScript на вашем сайте?

Честный ответ: не стоит на это рассчитывать. Публичная документация OpenAI описывает идентичность краулеров, семантику их robots.txt и диапазоны IP, но не утверждает, что эти боты выполняют JavaScript вашего сайта (OpenAI). Когда вендор молчит о рендеринге, безопасное инженерное допущение состоит в том, что рендеринга нет.

Независимые измерения указывают туда же. Когда Vercel проанализировала поведение краулеров в своей сети, GPTBot и OAI-SearchBot от OpenAI, ClaudeBot от Anthropic и PerplexityBot загружали HTML, но не рендерили клиентский JavaScript. Vercel даже видела, как краулер ChatGPT запрашивал JavaScript-файлы в 11,5% загрузок, а Claude — в 23,8%. Ни один из этих ботов не выполнял этот код (Vercel). Gemini от Google (через Googlebot) и AppleBot — заметные исключения: они рендерят.

Этот последний момент важнее, чем кажется. Googlebot необычно силён: он запускает свежую версию Chromium. Поэтому «Google это видит» оказывается критерием слабее, чем многие думают. Если контент появляется только после полноценного браузерного рендеринга, он всё равно может быть невидим для ИИ-краулеров, которые всё чаще питают ответы в ChatGPT, Perplexity и Claude. Common Crawl, чей архив обучает и заземляет многие системы, снимает любую двусмысленность: он загружает через HTTP GET, не выполняет JavaScript и не использует cookies (Common Crawl).

Одно различие стоит понять верно, потому что его постоянно путают: боты OpenAI — это не одно и то же. OAI-SearchBot показывает ваши страницы в поиске ChatGPT. GPTBot управляет тем, можно ли использовать ваш контент для обучения моделей. ChatGPT-User загружает страницу, когда человек явно просит ChatGPT её посмотреть (OpenAI). Они настраиваются независимо. Хотите попасть в поиск ChatGPT — разрешите OAI-SearchBot; блокировка GPTBot лишь исключает вас из обучения и не убирает из поиска (OpenAI Help Center). Anthropic и Perplexity публикуют такое же разделение между автоматическими краулерами и загрузчиками по запросу пользователя (Anthropic, Perplexity).

Почему ИИ не может прочитать мой сайт?

Если бот доходит до страницы, но уходит ни с чем, причина почти всегда одна из этих. Каждая по-своему проваливает слой «осмысленного HTML».

• Рендеринг только на клиенте. Первый ответ — это в основном пустой корневой элемент и теги скриптов, а настоящий контент собирается в браузере. Не-рендерящий краулер видит оболочку и останавливается. web.dev прямо противопоставляет это HTML, отданному сервером, и отмечает минусы сборки страниц в браузере для обнаружения контента (web.dev).
• Ленивая загрузка или бесконечная прокрутка для основного контента. Google сообщает, что Поиск не прокручивает и не кликает, чтобы раскрыть контент, и рекомендует постраничные URL для бесконечных списков (Google). Если даже Google не станет прокручивать, чтобы найти ваш основной текст, то менее документированные ИИ-краулеры — куда более рискованное место, чтобы его прятать.
• Заблокированные JS или CSS. Если нужные для рендеринга ресурсы запрещены в robots.txt, движок, который мог бы рендерить, не сможет и может неверно понять страницу (Google).
• Контент за логином, cookies или баннером согласия. Для публичного обнаружения считайте, что краулеры не авторизованы и не несут cookies. Common Crawl буквально без них (Common Crawl).
• Несовпадение при гидратации. React ожидает совпадения серверной и клиентской разметки; типичные причины вроде Date.now(), Math.random(), ветвлений по window или различий локали приводят к несовпадению, после которого React может отбросить серверный HTML и пересобрать дерево на клиенте (React). Ваша история «HTML в первую очередь» настолько же стабильна, насколько стабильна ваша гидратация.

Что CSR, SSR и предрендеринг на самом деле отдают боту?

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

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

Как проверить, что видит бот?

Гадать не нужно. Эта последовательность идёт от самого грубого инструмента к подтверждению со стороны поисковика, и разработчик может прогнать всё это на ноутбуке.

1. Начните с сырого ответа. curl и wget показывают тело первого HTML без выполнения JavaScript. Это ровно то, что получает не-рендерящий краулер.

# Сохранить сырой HTML, который получает базовый загрузчик
curl -L -s https://example.com/page > raw.html

# Действительно ли осмысленный контент там есть?
grep -n "<title>" raw.html
grep -n "<h1"     raw.html
grep -n "<main"   raw.html
grep -n "ожидаемая вами фраза" raw.html

Если тело статьи, описание товара, заголовки или навигационные ссылки здесь отсутствуют, это уже свидетельство того, что не-рендерящим краулерам придётся тяжело.

2. Сравните View Source с живым DOM. View Source показывает HTML в том виде, в каком его отдал сервер; панель Elements в DevTools показывает живой DOM после выполнения скриптов (Chrome). Если ваш настоящий текст появляется только в Elements, но не в View Source, он зависит от JavaScript.

3. Отключите JavaScript и перезагрузите. В Chrome DevTools для этого есть встроенная команда (Chrome). Откройте DevTools, нажмите Cmd+Shift+P (или Ctrl+Shift+P), выполните Disable JavaScript и перезагрузите. Если страница схлопывается в пустую оболочку или спиннер, это и видит краулер без JS.

4. Снимайте воспроизводимо. Для проверки в CI Playwright поддерживает javaScriptEnabled: false на уровне контекста браузера (Playwright). Отрендерьте страницу один раз с выключенным JS и один раз с включённым, затем сравните длину текста:

const ctx = await browser.newContext({ javaScriptEnabled: false });
const page = await ctx.newPage();
await page.goto(url, { waitUntil: "networkidle" });
const text = await page.locator("body").innerText();
// Если здесь почти пусто, а в прогоне с JS — полно, ваш контент зависит от скриптов.

5. Подтвердите инструментами поисковиков. Инструмент проверки URL / Rich Results Test от Google показывает отрендеренный DOM, загруженные ресурсы и вывод консоли, а у Bing есть свой URL Inspection. Они подтверждают, что видят индексирующие движки. Это полезно, но помните: они отражают рендереры, а не более простые ИИ-краулеры.

Как это исправить, и что лишь временный мост?

Долговечное решение концептуально простое: сделайте страницу осмысленной до запуска клиентского JavaScript. Отдавайте контент через серверный рендеринг, статическую генерацию, инкрементальную регенерацию или схему островов/гибрида. А затем позвольте гидратации навесить интерактивность сверху. Собственное руководство Google теперь называет динамический рендеринг обходным решением и рекомендует вместо него серверный рендеринг, статический рендеринг или гидратацию (Google). Современные фреймворки делают это по умолчанию: Nuxt, например, по умолчанию рендерит на сервере и позволяет предрендерить или включить гибрид для каждого маршрута (Nuxt).

Практическое правило выбора:

• Публичные, в основном стабильные страницы (документация, маркетинг, статьи): склоняйтесь к SSG или ISR.
• Публичные страницы, которые должны быть свежими на каждый запрос: используйте SSR.
• Сильно интерактивные контентные страницы: держите контент серверно-отрендеренным и гидратируйте только интерактивные виджеты (подход островов).
• Поверхности приложения за авторизацией: CSR обычно подходит, ведь эти страницы и не предназначены для публичного обнаружения.
• Большое legacy-SPA: используйте предрендеринг или динамический рендеринг как мост, а не пункт назначения, пока переводите шаблоны на SSR/SSG/острова. Единственное жёсткое правило: версия, которую вы отдаёте ботам, должна быть по сути тем же контентом, что и у пользователей, иначе рискуете клоакингом.

Держите и no-JS-фолбэк честным. Начинайте с нативного семантического HTML, добавляйте ARIA лишь чтобы улучшить семантику взаимодействия, а <noscript> используйте для необходимого сообщения-фолбэка, а не как замену реальному серверному HTML (MDN). Цель — страница, у которой тема, текст, ссылки и метаданные существуют в ответе, а JavaScript наслаивается сверху как улучшение.

Как проверить весь сайт сразу?

Проверить один шаблон вручную реально; проверять каждый шаблон на каждом релизе — нет. Эту работу делает aiSiteReady. Он загружает ваш сайт так, как это сделал бы агент: запрашивает сырой HTML, соблюдает robots.txt и читает то, что на самом деле получает клиент без JavaScript. А затем сообщает, где ваш контент исчезает.

Это напрямую относится к категории доступности контента в оценке: может ли агент прочитать вашу страницу без браузера? Это одна из примерно 15–20 проверок по обнаружимости, доступности контента, управлению ботами, протоколам и коммерции, объединённых в оценку Agent Readiness Score от 0 до 100. Точные проверки и веса описаны на странице методологии, а этот гайд — подробный разбор за тем самым шлюзом доступности контента из материала о том, что значит готовность к ИИ-агентам. Если же вы хотите дать ассистентам курируемую карту чтения после того, как ваши страницы станут читаемыми, посмотрите, что такое llms.txt и как его добавить.

Запустите бесплатное сканирование, чтобы сравнить ваш сырой HTML с отрендеренным DOM, найти контент, который существует только после запуска JavaScript, и получить приоритизированный список исправлений по каждому шаблону, на английском, украинском или русском.

У IMozz 20 лет в разработке ПО, а последний год он строит продукты с помощью LLM. Он развивает aiSiteReady, сканер только для чтения, который проверяет, может ли ИИ-агент прочитать сайт. Сканер серверно рендерит собственный контент как рабочий пример.