neuropushПочему JavaScript делает сайт невидимым для ИИ-краулеров
Представьте себе библиотеку, в которой все книги стоят на полках, но написаны невидимыми чернилами. Посетитель библиотеки (человек) берёт специальную лампу (браузер с JavaScript), подсвечивает страницу и читает текст. Но библиотекарь (ИИ-краулер, такой как GPTBot, ClaudeBot или PerplexityBot), который пришёл составить каталог, не имеет такой лампы. Он видит только пустые обложки, а иногда и просто корешки без единой надписи. Это не метафора — это буквальное описание того, что происходит, когда современный сайт, построенный на клиентском рендеринге, пытается проанализировать искусственный интеллект.
Когда вы открываете сайт в браузере, вы видите результат сложного процесса: сервер прислал HTML-код, браузер загрузил JavaScript-файлы, выполнил их, и только потом на экране появились текст, картинки и кнопки. Но подавляющее большинство AI-краулеров не выполняют JavaScript. Они приходят на сервер, получают исходный HTML-документ ровно в том виде, в котором он отдаётся без единой строчки исполненного кода, и анализируют именно этот «сырой» ответ. Если ваш сайт использует подход Client-Side Rendering (CSR), то в этом «сыром» ответе не будет ни одного слова вашего контента. Для ИИ ваш сайт — это пустой лист бумаги.
SSR, SSG и CSR: три мира, три судьбы для контента
Чтобы понять глубину проблемы, нужно разобраться в трёх принципиально разных архитектурах веб-приложений. От выбора одной из них зависит, увидит ли ИИ ваш текст или нет.
CSR — Client-Side Rendering: контент как призрак
Client-Side Rendering — это подход, при котором сервер отдаёт браузеру минимальный HTML-каркас. Обычно это выглядит так: внутри <body> есть один пустой контейнер <div id="root"></div> и подключённые скрипты. Весь интерфейс, все тексты, все заголовки, все описания товаров — всё это создаётся динамически на стороне клиента. Браузер человека получает пустую страницу, выполняет JavaScript, и только тогда происходит «магия»: React, Vue или Angular монтируют приложение, подтягивают данные с API и отрисовывают интерфейс.
Плюсы CSR очевидны для пользователя: сайт после первой загрузки работает как нативное приложение — переходы между страницами мгновенные, без перезагрузок, интерфейс плавный и интерактивный. Но для поисковых роботов и, что критически важно, для ИИ-краулеров, этот подход превращает сайт в пустую оболочку. Когда GPTBot запрашивает страницу, он получает именно тот самый HTML с пустым <div>. Внутри нет ни одного слова контента. Нет заголовков. Нет текста. Только ссылки на скрипты, которые бот исполнять не будет.
SSR — Server-Side Rendering: сервер делает всю работу
Server-Side Rendering — это подход, при котором сервер перед отправкой ответа самостоятельно выполняет весь необходимый код и формирует полностью готовый HTML-документ. Представьте, что вместо того, чтобы отправлять клиенту рецепт блюда и набор продуктов, ресторан присылает уже готовое, сервированное блюдо. Браузер получает HTML, в котором уже есть все тексты, все заголовки, вся структура страницы. JavaScript в этом случае нужен только для добавления интерактивности (например, для обработки кликов или отправки форм), но он не является обязательным условием для чтения контента.
Когда AI-краулер запрашивает SSR-страницу, он получает полноценный документ с тегами <h1>, <p>, <article> и так далее. ИИ может спокойно проанализировать текст, понять структуру и извлечь смысл. Именно поэтому SSR считается «золотым стандартом» для SEO и GEO — контент доступен без каких-либо дополнительных условий.
SSG — Static Site Generation: контент, приготовленный заранее
Static Site Generation — это гибридный вариант, который во многом повторяет SSR, но с одним важным отличием: HTML-страницы генерируются не в момент запроса, а заранее, на этапе сборки проекта. Вы один раз запускаете процесс сборки, и он создаёт сотни или тысячи статических HTML-файлов. Когда приходит запрос (от человека или бота), сервер просто отдаёт готовый файл без какой-либо обработки.
SSG сочетает преимущества производительности (статический файл отдаётся мгновенно) и полной доступности контента. ИИ-краулер видит готовый HTML с полным текстом. Для блогов, документации, корпоративных сайтов и лендингов SSG — это идеальный выбор. Но есть нюанс: если на сайте есть динамические данные (например, личный кабинет или лента новостей, обновляющаяся каждый час), SSG потребует пересборки при каждом обновлении.
Как выглядит «пустой» сайт для ИИ: практический пример
Давайте посмотрим на реальную разницу. Вот как выглядит исходный HTML-код типичной SPA-страницы (CSR-подход), которую запрашивает AI-краулер:
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title>Интернет-магазин example.ru</title>
<link rel="stylesheet" href="/static/css/main.css">
</head>
<body>
<div id="root"></div>
<script src="/static/js/vendor.bundle.js"></script>
<script src="/static/js/main.bundle.js"></script>
</body>
</html>Что видит GPTBot или PerplexityBot, когда получает этот документ? Пустой <div>. Ни одного слова о товарах, ни одного заголовка, ни одного описания. Весь контент, который вы так старательно писали для пользователей, находится внутри JavaScript-файлов, которые бот не исполняет. Для ИИ этот сайт не просто «невидим» — он не существует как источник информации.
А вот как выглядит HTML той же страницы, но с серверным рендерингом (SSR) или статической генерацией (SSG):
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title>Купить смартфон XPhone 15 Pro в Москве — example.ru</title>
</head>
<body>
<header>
<h1>Интернет-магазин example.ru</h1>
<nav>
<a href="/catalog">Каталог</a>
<a href="/delivery">Доставка</a>
</nav>
</header>
<main>
<h2>Смартфон XPhone 15 Pro</h2>
<p>Флагманский смартфон с камерой 48 Мп и батареей на 5000 мАч. Доступен в чёрном и белом цветах. Цена: 79 990 рублей.</p>
<h3>Характеристики</h3>
<ul>
<li>Экран: 6.7 дюймов OLED</li>
<li>Процессор: X-Chip A17 Pro</li>
<li>Память: 8/256 ГБ</li>
</ul>
</main>
</body>
</html>Второй вариант — это полноценный документ, который ИИ может прочитать, проанализировать и использовать для ответа пользователю. Разница колоссальная. В первом случае — «пустышка», во втором — содержательный сайт.
Почему Googlebot — не показатель для ИИ-краулеров
Многие владельцы сайтов задают закономерный вопрос: «Но Google же индексирует мой сайт на React! Я вижу его в поиске». Это правда. Googlebot действительно умеет исполнять JavaScript. Компания Google использует headless-браузер Chromium для рендеринга страниц перед индексацией. Но есть три важных «но».
Первое — это задержка. Googlebot сначала запрашивает HTML-код, видит пустую оболочку, ставит страницу в очередь на повторный рендеринг. Очередь может растянуться на дни или даже недели. Для обычного SEO это приемлемо, но для GEO (Generative Engine Optimization), где важна скорость попадания контента в базы знаний ИИ, такая задержка может быть критичной.
Второе — это неполнота обработки. Googlebot исполняет JavaScript, но не всегда ждёт завершения всех асинхронных запросов. Если ваш контент подгружается через API после того, как основной скрипт отработал, Google может проиндексировать страницу без этого контента. Результат — потерянные позиции по ключевым запросам.
Третье и самое важное — большинство ИИ-краулеров не являются Googlebot. GPTBot от OpenAI, ClaudeBot от Anthropic, PerplexityBot — все они работают по принципу «получил HTML — проанализировал». Они не запускают headless-браузеры, не ждут выполнения скриптов и не тратят вычислительные ресурсы на рендеринг. Их задача — максимально быстро и экономно собрать текстовую информацию. Если информация не приходит в первом ответе сервера, они просто переходят к следующему сайту.
Когда вы оптимизируете сайт под GEO, вы должны думать не о Googlebot, а о том, что ваш HTML-код должен быть самодостаточным. ИИ-краулеры — это гости, которые не будут ждать, пока ваша «тяжёлая» страница загрузит все скрипты. Они прочитают то, что есть в исходном HTML, и уйдут.
Как проверить, видит ли ИИ ваш контент
Существует простой способ узнать, что видит AI-краулер, когда приходит на ваш сайт. Нужно открыть страницу в браузере и нажать Ctrl+U (или Cmd+U на Mac). Это откроет «Исходный код страницы» (View Source). Обратите внимание: это не то же самое, что «Просмотреть код» через DevTools (F12). DevTools показывает отрендеренный DOM — то есть то, что браузер построил после выполнения JavaScript. А View Source показывает именно то, что сервер отдал в ответ на запрос. Это и есть «вид» краулера без JavaScript.
Посмотрите внимательно на исходный код. Есть ли там ваши тексты? Заголовки <h1>, <h2>? Описания товаров или статей? Или вы видите пустой <div id="root">? Если последнее — у вас серьёзная проблема с видимостью для ИИ.
Второй способ — воспользоваться нашим инструментом «Проверка контента без JavaScript». Он работает по тому же принципу: загружает исходный HTML страницы без выполнения скриптов, после чего считает объём текста и количество заголовков в документе. Результаты интерпретируются следующим образом:
- FAIL — в исходном HTML 0 слов. Это означает, что весь контент подгружается через JavaScript. ИИ-краулеры видят полностью пустую страницу.
- WARN — в исходном HTML меньше 100 слов. Технически контент есть, но его очень мало. Возможно, часть текста подгружается динамически.
- PASS — в исходном HTML более 100 слов. Контент полностью доступен без JavaScript. ИИ-краулеры смогут прочитать страницу.
Дополнительно инструмент проверяет наличие заголовков <h1>–<h6> в исходном HTML. Заголовки — это структурные элементы, по которым ИИ понимает иерархию информации. Если заголовков нет, даже при наличии текста страница будет восприниматься хуже.
Готовы проверить свой сайт?
19-пунктный GEO-чек-лист — тот же набор рычагов, которым мы пользуемся в работе.
Смотреть чек-листКак исправить ситуацию: стратегии для разных случаев
Хорошая новость в том, что проблема решаема. Плохая новость — универсального решения нет. Выбор стратегии зависит от типа вашего сайта, ресурсов команды и специфики бизнеса.
Полный переход на SSR или SSG
Это самое радикальное, но и самое надёжное решение. Если вы используете React, Vue или Angular, есть фреймворки, которые поддерживают серверный рендеринг из коробки. Например, Next.js для React, Nuxt для Vue, Angular Universal для Angular. Они позволяют настроить рендеринг каждой страницы на сервере перед отправкой клиенту.
Для статического контента (блоги, документация, корпоративные сайты) идеально подходит SSG. Вы один раз генерируете все HTML-файлы, и ваш хостинг отдаёт их как статику. Это максимально быстрый и экономичный вариант. ИИ-краулеры получают полностью готовый HTML с первого запроса.
Для интернет-магазинов и сайтов с часто обновляющимся контентом больше подходит SSR. Сервер будет каждый раз формировать HTML заново, но этот процесс не такой затратный, как кажется, особенно если использовать кэширование.
Гибридный рендеринг
Не всегда нужно переписывать весь сайт. Иногда достаточно выделить ключевые страницы (лендинги, статьи, карточки товаров) и перевести их на SSR или SSG, оставив остальные разделы на CSR. Например, личный кабинет пользователя не обязан быть доступен ИИ-краулерам — это приватная зона. А вот страницы со статьями, каталогом и описаниями должны быть полностью доступны.
Гибридный подход позволяет сохранить удобство SPA для интерактивных разделов и обеспечить видимость для ИИ на коммерчески важных страницах. Это требует более сложной архитектуры, но часто является оптимальным компромиссом.
Прогрессивное улучшение
Третий подход — это паттерн прогрессивного улучшения (progressive enhancement). Суть его в том, что базовый контент (тексты, заголовки, основные ссылки) доступны в HTML сразу, без выполнения JavaScript. А уже поверх этого «базового слоя» добавляется интерактивность: анимации, динамическая подгрузка дополнительных блоков, сложные формы.
На практике это означает, что даже если JavaScript не выполнится (или бот не будет его исполнять), пользователь и ИИ увидят основное содержимое страницы. Это не такой простой путь, как полный SSR, но он более гибкий. Вы пишете HTML вручную или генерируете его на сервере, а React/Vue/Angular подключаете только для «улучшения» интерфейса, а не для его создания.
Частые заблуждения о видимости для ИИ
Вокруг темы взаимодействия ИИ и сайтов существует множество мифов. Разберём самые распространённые из них.
«У меня высокий Lighthouse Score, значит всё в порядке»
Lighthouse — это инструмент Google для аудита качества веб-страниц. Он измеряет производительность, доступность, SEO-факторы и другие метрики. Но Lighthouse работает в браузере, то есть выполняет JavaScript. Когда он оценивает вашу страницу, он видит полностью отрендеренный DOM. Это отлично для оценки пользовательского опыта, но совершенно бесполезно для понимания того, что видит ИИ-краулер. Вы можете получить 100 баллов в Lighthouse и при этом иметь пустой исходный HTML. Поэтому высокий Lighthouse Score — это хорошо для пользователей, но не гарантия видимости для ИИ.
«Мы используем prerender.io или аналогичный сервис»
Существуют сервисы, которые выполняют JavaScript на своей стороне и отдают готовый HTML ботам. Они могут работать для Googlebot, который отправляет запрос с определённым User-Agent. Но большинство ИИ-краулеров маскируются под обычных пользователей или используют стандартные User-Agent без специальных маркеров. Если сервис prerender не настроен на перехват запросов от GPTBot или PerplexityBot, они получат исходный пустой HTML. Надёжнее не полагаться на сторонние сервисы, а сделать контент доступным на уровне сервера.
«Если сайт работает у людей, значит, он работает и у ботов»
Это самое опасное заблуждение. Человек использует браузер с включённым JavaScript, поэтому видит полноценную страницу. Бот — это не человек. Он не видит, не понимает и не исполняет JavaScript. Он работает только с текстом HTML-ответа. Ваша страница может быть восхитительно красивой для человека и абсолютно пустой для ИИ. Это две разные реальности, которые никак не пересекаются.
«Я добавил JSON-LD разметку, теперь ИИ найдёт контент»
Структурированные данные (Schema.org, JSON-LD) — это замечательно. Они помогают ИИ понять тип контента (товар, статья, организация). Но если сам контент (текст, описание) находится в JavaScript и не доступен в HTML, то разметка окажется бесполезной. JSON-LD может указывать на данные, которых нет в исходном документе. ИИ получит «пустышку» с метаданными, но без самого наполнения.
Часто задаваемые вопросы
1. Влияет ли невидимость для ИИ-краулеров на обычный поиск Google?
Влияет, но в меньшей степени. Googlebot умеет исполнять JavaScript, поэтому ваш сайт всё равно попадёт в индекс, хотя и с задержкой. При этом есть риск неполной индексации контента, который подгружается асинхронно после выполнения основного скрипта. Для обычного SEO лучше иметь серверный рендеринг хотя бы ключевых страниц.
2. Все ли ИИ-краулеры не поддерживают JavaScript?
Подавляющее большинство — да. GPTBot, ClaudeBot, PerplexityBot, Google-Extended (отдельный краулер для ИИ от Google) работают с исходным HTML. Некоторые экспериментальные ИИ-системы могут запускать браузер, но это скорее исключение, чем правило. Не стоит рассчитывать на то, что ИИ «подождёт», пока ваш скрипт отработает. Бюджет времени и ресурсов у краулеров ограничен.
3. Мой сайт на WordPress. Есть ли у меня проблема?
Обычный WordPress (без использования конструкторов, которые рендерят контент на клиенте) — это классический пример SSR. PHP генерирует полноценный HTML на сервере, и боты видят весь контент. Проблемы возникают, если вы используете темы или плагины на базе React/Vue, которые выводят контент через JavaScript. Проверьте ваш сайт через View Source — если тексты есть в исходном коде, всё в порядке.
4. Как быстро перейти с CSR на SSR?
Скорость зависит от используемого фреймворка. Если вы используете React, переход на Next.js может занять от нескольких дней (для небольших сайтов) до нескольких месяцев (для сложных SPA). Аналогичная ситуация с Vue и Nuxt. Если проект слишком сложен для полного перехода, начните с гибридного подхода: вынесите на SSR/SSG самые важные страницы для бизнеса.
5. Может ли использование CDN с edge-рендерингом решить проблему?
Да, современные CDN и платформы (например, Vercel, Netlify, Cloudflare Workers) поддерживают edge-рендеринг. Это означает, что HTML генерируется на сервере в точке присутствия CDN, максимально близкой к пользователю. Для ИИ-краулеров это работает так же, как обычный SSR: они получают готовый HTML. Это хороший вариант, если вы хотите сохранить удобство разработки на JavaScript, но обеспечить серверный рендеринг.
6. Стоит ли полностью отказаться от JavaScript на сайте?
Нет, это не нужно и вредно для пользовательского опыта. JavaScript необходим для интерактивности, анимаций, отправки форм, реализации сложных интерфейсов. Проблема не в самом JavaScript, а в том, что контент становится недоступен без его исполнения. Используйте принцип прогрессивного улучшения: базовый HTML с контентом + JavaScript для улучшения. Так вы получите лучшее из обоих миров.
Заключение
Эра GEO (Generative Engine Optimization) ставит перед владельцами сайтов новые вызовы. Если раньше достаточно было оптимизировать сайт под Google, который мог «дождаться» выполнения JavaScript, то теперь ИИ-краулеры работают по принципу «что вижу в HTML, то и использую». Пустой <div id="root"> — это приговор для вашего контента в глазах искусственного интеллекта.
Решение проблемы лежит на поверхности: убедитесь, что ваш контент доступен в исходном HTML без необходимости выполнения скриптов. Используйте SSR или SSG для ключевых страниц, применяйте гибридные подходы и прогрессивное улучшение. Регулярно проверяйте свои страницы через View Source или наш инструмент «Проверка контента без JavaScript».
ИИ-краулеры не будут адаптироваться под ваш сайт. Адаптироваться должны вы. Сделайте свой контент видимым — и тогда ответы нейросетей будут содержать ссылки на ваши материалы, а не на пустые оболочки конкурентов.
Нужна помощь с внедрением?
Берём на себя аудит, robots.txt, llms.txt и Schema.org — под ключ.
Смотреть услугу