2. Оптимизация JavaScript-сайтов под AI: критическая проблема

JavaScript-рендеринг — не прихоть, а барьер первой необходимости. Пока AI-краулеры не эволюционировали до полноценных браузеров с бесконечными ресурсами, отдавать контент в статическом виде — обязанность владельца сайта. Выберите подходящий метод (SSR, пре-рендеринг, hydration) и внедряйте его в приоритетном порядке — особенно для страниц, нацеленных на AI-цитирование.

В первой статье блока мы разобрали, что одиночные файлы вроде llms.txt не сделают сайт видимым для нейросетей — нужна комплексная стратегия. Но есть проблема ещё более фундаментальная, которая способна обнулить все усилия разом. Речь о сайтах, чей контент существует только после выполнения JavaScript. Таких проектов с каждым годом всё больше: React, Vue, Angular, Svelte — фреймворки, подарившие вебу плавность и интерактивность, одновременно возвели невидимую стену для AI-краулеров.

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

2.1 В чём проблема? AI-боты не умеют жать на кнопки

Классический браузер получает HTML, загружает JS-бандл, выполняет код, и только затем DOM наполняется текстом, заголовками, списками. AI-краулеры — это не браузеры. Они работают как упрощённые текстовые экстракторы, нацеленные на быстрое извлечение контента без затрат на полную отрисовку.

Как ведут себя популярные AI-краулеры:

• ChatGPT-User и GPTBot — согласно документации OpenAI, их инструмент просмотра использует облегчённый процесс: загружается исходный HTML, извлекается текст, и на этом всё. JavaScript не исполняется, DOM не строится. Если ваш контент появляется только после ReactDOM.render() или createApp().mount(), бот получит пустой <div id="root"></div>.
• Claude-Web (Anthropic) — аналогично, заявляет о поддержке только статического HTML. Никаких признаков исполнения JS в логах.
• PerplexityBot и Google-Extended — чуть более продвинуты, но крайне ограничены по тайм-аутам: если скрипт грузится дольше 1–2 секунд, краулер забирает то, что успел, и уходит.
• Googlebot — да, он умеет рендерить JS, но очередь на рендеринг (render queue) может длиться днями и неделями. Для AI-индексации, где свежесть критична, это непозволительная роскошь. Более того, даже Google признаёт, что приоритет отдаёт быстрому статическому контенту.

Реальный пример:
Возьмём типичный SPA-интернет-магазин на Vue. При загрузке страницы товара сервер отдаёт минимальный HTML с <div id="app">. Карточка товара — название, цена, описание, характеристики — всё это рендерится клиентским JavaScript после запроса к API. Результат для AI-краулера: страница с нулевым текстовым содержанием. Модель не узнает ни о товаре, ни о бренде.

Проверить свой сайт легко: откройте DevTools (F12), перейдите в Settings → Preferences → Debugger, включите Disable JavaScript. Обновите страницу. Если вы видите белый экран, скелетную загрузку без текста или сообщение «Включите JavaScript» — у вас проблема. Именно так ваш контент выглядит для ChatGPT.

2.2 Что ищут AI-боты? Структура, а не анимация

Языковые модели не смотрят на страницу глазами. Их интересует семантический скелет:

• Заголовки H1–H3 — по ним модель определяет структуру и иерархию ответа.
• Списки <ul>/<ol> — легко парсятся, часто цитируются дословно.
• Параграфы <p> с фактической информацией, особенно первые 100–150 слов.
• Таблицы — при запросах на сравнение модели обожают табличные данные.
• Микроразметка schema.org (JSON-LD) — структурированные данные о продукте, статье, FAQ. Они считываются даже без JavaScript, но только если жёстко прописаны в <head>.

Если всё это генерируется на клиенте, AI-экстрактор получает лишь <script> и пустые контейнеры. Даже Google порой показывает в сниппете «Loading...» или пустой текст — AI-боты ещё менее терпеливы.

Показательный кейс:
Форум на React, где список тем и посты загружаются через AJAX. Мы провели аудит для клиента: после отключения JS страница обсуждения содержала только шапку и футер. AI-трафик был нулевым, хотя органический держался за счёт рендеринга Googlebot. После внедрения SSR (см. ниже) первые цитирования в Perplexity появились через 2 недели.

2.3 Методы решения: три пути к статическому контенту

Все решения требуют участия разработчиков, но они окупаются не только AI-видимостью, но и общим улучшением Core Web Vitals и индексации поисковиками.

Метод 1: Рендеринг на стороне сервера (SSR)

Как работает: сервер выполняет JavaScript, собирает готовый HTML и отправляет его браузеру или краулеру. Пользователь получает контент мгновенно, а затем JS «оживляет» интерактивные элементы.

Плюсы:

• Полноценный статический HTML для всех: и для Googlebot, и для AI-краулеров.
• Лучшие показатели FCP/LCP — прямой сигнал для AI (помните, FCP < 0,4 с утраивает шансы на цитирование, Часть 1.6).
• Единый код для поисковых и реальных пользователей.

Минусы:

• Сложность внедрения в существующий SPA. Часто требует перехода на мета-фреймворки (Next.js для React, Nuxt для Vue, SvelteKit для Svelte).
• Повышенная нагрузка на сервер — каждый запрос требует рендеринга.

Идеально для: новых проектов или крупных сайтов, готовых к рефакторингу.

Пример: если у вас интернет-магазин на React, миграция на Next.js с getServerSideProps позволит отдавать карточки товаров, категории и блог в виде готового HTML. После этого AI-боты увидят и заголовки, и цены, и описания.

Метод 2: Статический предварительный рендеринг (Static Pre-Rendering)

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

Плюсы:

• Молниеносная отдача — сервер отдаёт файл как есть.
• Максимальная доступность для любых ботов.
• Простота деплоя (можно хостить на CDN).

Минусы:

• Не подходит для страниц с персонализированным или часто меняющимся контентом (корзина, личный кабинет, результаты поиска).
• Требует пересборки при каждом изменении контента (автоматизируется через CI/CD).

Инструменты:

• Next.js — Static Generation (getStaticProps).
• Nuxt — режим nuxt generate.
• Gatsby — целиком построен на пре-рендеринге.
• Puppeteer / Prerender.io — для не-SPA сайтов, где можно сгенерировать статические копии динамических страниц и отдавать их ботам.

Пример: корпоративный блог на VuePress или Nuxt Content. При деплое генерируются HTML-версии всех статей с полным текстом. AI-краулер видит их сразу, без ожидания клиентского рендеринга.

Метод 3: Технология Hydration (и динамический рендеринг)

Как работает: сервер сначала отдаёт статический HTML (результат SSR или пре-рендеринга), а затем на клиенте JavaScript «навешивается» на существующую разметку, добавляя интерактивность. Это компромисс: боты получают контент, пользователи — удобство.

Частный случай — динамический рендеринг (Dynamic Rendering): для обычных пользователей отдаётся SPA, а для ботов (по User-Agent) сервер проксирует запрос через headless-браузер и возвращает готовый HTML. Раньше рекомендовался Google, но сейчас считается временным решением из-за дополнительной нагрузки и риска расхождения контента.

Плюсы hydration:

• Не нужно полностью переписывать приложение.
• Плавное внедрение: можно начать с критических страниц (карточки товаров, статьи).

Минусы:

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

Инструменты: для Vue — vue-server-renderer, для React — ReactDOM.hydrate, или готовые решения вроде Nuxt/Next с автоматической гидратацией.

Сравнительная таблица методов

Практический совет: срочная диагностика и чек-лист

Если ваш сайт работает на JavaScript-фреймворках, выполните три шага прямо сейчас:

1. Отключите JavaScript в браузере (DevTools → Settings → Debugger → Disable JavaScript). Пройдите по ключевым страницам: главная, категория, товар, статья. Видите ли вы основной текстовый контент, заголовки, списки? Если нет — переходите к шагу 2.
2. Проверьте логи сервера (см. Часть 3 первого блока «Проверка доступности сайта для AI-ботов»). Выгрузите access-логи и найдите запросы с User-Agent ChatGPT-User, GPTBot, PerplexityBot. Если они получают коды 200, но страницы пустые, это ложный успех — боты не видят контент.
3. Запустите тестовый запрос в ChatGPT с прямым упоминанием URL вашей страницы: «Что написано на странице  https://mysite.com/product/123?». Если модель отвечает «я не могу прочитать страницу» или пересказывает неполные данные — подтверждение проблемы.

Экстренное решение (до полноценной миграции):

• Для небольших сайтов (до 100–200 страниц) можно быстро развернуть статический пре-рендеринг через Prerender.io (облачный сервис) или Puppeteer на своём сервере. Создайте статические HTML-версии и настройте Nginx отдавать их для User-Agent ботов.
• Для WordPress-сайтов с тяжёлыми JS-темами — используйте плагины кеширования с функцией «отдавать статический HTML» (WP Rocket, Flying Pages). Они не решают проблему коренным образом, но часто восстанавливают видимость контента.

В следующей статье технического блока мы продолжим расчищать дорогу ботам: разберём, как правильно настраивать пагинацию, бесконечный скролл и фильтры, чтобы нейросети не теряли важные страницы и не уходили в тупик. Оставайтесь с нами на форуме «Белое SEO».

Есть опыт борьбы с JS для AI? Поделитесь в комментариях — обсудим кейсы и инструменты