Команда выкатывает обновлённый фронтенд на современном JavaScript-фреймворке. Тестировщики открывают сайт в браузере, переходят по разделам, проверяют корзину и закрывают задачу: визуально всё работает. Но через неделю в Google Search Console и Яндекс Вебмастере начинается просадка: карточки товаров переходят в статус Soft 404, часть разделов выпадает из индекса, внутренние ссылки перестают обнаруживаться, а в сниппетах вместо названий статей появляется общий заголовок шаблона.
Содержание:
Причина почти всегда одна: человек в браузере и поисковый робот видят страницу в разных состояниях. Браузер пользователя выполняет клиентский код, ждёт ответа сервисов, реагирует на прокрутку и клики. Поисковый робот работает по жёсткому конвейеру: сначала он оценивает сырой HTTP-ответ сервера, затем в неинтерактивном режиме пропускает страницу через сервис рендеринга и отсекает всё, что требует действий пользователя или заблокировано правилами обхода.
Грамотная работа с JavaScript в SEO — это не отказ от реактивных интерфейсов. Задача решается архитектурно: критические сигналы документа (код ответа сервера, директивы индексации, канонический адрес, заголовки, основной текст и ссылки ) должны быть доступны роботу без имитации действий человека и без противоречий между первичным HTML и финальным DOM.
Ниже — разбор рендеринга JavaScript в Google и Яндексе, типовых ошибок фронтенда и чек-листа приёмки релизов для поиска и ответных ИИ-систем (AEO и GEO). Официальная документация поисковых систем сверена 27 октября 2026 года. Регламент приёмки и архитектурная матрица — мои авторские рекомендации; фрагменты кода и сценарии релизов приведены как условные примеры, а не данные клиентских проектов.
Как поисковые системы обрабатывают JavaScript: три фазы и ловушка первичного HTML
В документации Google Search Central обработка сайтов на JavaScript разделена на три этапа: сканирование (Crawling), рендеринг (Rendering) и индексирование (Indexing). Основы JavaScript SEO в Google Search Central.
На первом этапе Googlebot отправляет HTTP-запрос к адресу страницы и скачивает исходный HTML-файл. Ещё до попадания страницы в очередь на выполнение скриптов робот проверяет HTTP-заголовки, файл robots.txt и базовые метатеги в первичном ответе сервера. Именно здесь срабатывает первая ловушка.
Если в исходном HTML-шаблоне одностраничного приложения (SPA) по умолчанию прописан тег , а разработчики рассчитывают, что клиентский скрипт после загрузки данных заменит его на index, follow, схема не сработает. Согласно документации Google, при обнаружении noindex на этапе первичного разбора HTML робот пропускает фазу рендеринга и не запускает JavaScript. Скрипт, который должен был снять запрет, просто не получает управления.
Если страница открыта для сканирования, наступает вторая фаза — рендеринг. Сервис Web Rendering Service (WRS) запускает страницу в безголовом браузере на базе актуального («вечнозелёного», evergreen) движка Chromium, выполняет JavaScript и строит итоговое дерево документа (Rendered DOM). Затем наступает третья фаза: поисковая система анализирует отрендеренный DOM, извлекает текст, заголовки, микроразметку и новые ссылки для очереди обхода.
При этом WRS работает только с ресурсами, к которым разрешён доступ. Если в robots.txt закрыты директории со скриптами (/assets/*.js, /static/) или внутренние API-эндпоинты (/api/v1/products), через которые фронтенд запрашивает название, цену и описание товара, браузер посетителя загрузит страницу без проблем (пользователи не читают robots.txt). Но поисковый робот соблюдает запрет: он не скачает заблокированный скрипт или JSON-ответ, получит пустой шаблон и исключит страницу из индекса. Исправление проблем с JavaScript в поиске Google.
Где расходятся Google, Яндекс и боты ответных ИИ-систем (AEO и GEO)
У Google, Яндекса и краулеров генеративных систем разные настройки ожидания, правила кеширования и требования к серверному ответу.
Особенности Web Rendering Service в Google
В документации по отладке JavaScript инженеры Google выделяют четыре технических ограничения WRS, о которых важно помнить при проектировании фронтенда:
- Только HTTP-запросы без постоянных сокетов. Googlebot получает данные по протоколу HTTP и не поддерживает загрузку основного контента через постоянные соединения вроде WebSockets или WebRTC. Если каталог подтягивает записи только через сокет-соединение без HTTP-фолбэка, для поисковика страница останется пустой.
- Агрессивное кеширование и content fingerprinting. Чтобы не перегружать серверы сайтов, WRS активно кеширует статические файлы и может игнорировать заголовки Cache-Control. Если после релиза команда обновила логику внутри app.js, не изменив его URL, робот может долго выполнять старую версию скрипта из кеша вместе с новым HTML. Рекомендация Google — использовать хеширование содержимого в именах файлов (content fingerprinting, например main.2bb85551.js), чтобы каждое изменение кода создавало новый адрес ресурса.
- Сплющивание Shadow DOM в Web Components. При обработке веб-компонентов WRS объединяет («сплющивает») Shadow DOM и Light DOM. Если компонент не использует элемент для вставки содержимого из Light DOM, текст и ссылки внутри него могут пропасть из финального дерева документа.
- Отсутствие состояния между запросами. Каждый URL обрабатывается изолированно: WRS не переносит localStorage, sessionStorage и пользовательские cookies между страницами. Если сайт показывает контент только после записи региона или подтверждения возраста в локальное хранилище, робот при каждом заходе будет видеть модальное окно вместо текста статьи или карточки товара. Исправление проблем с JavaScript в поиске Google.
Инструменты Яндекса: рендеринг JavaScript и window.YandexRotorSettings
В Яндексе управление обработкой клиентского кода вынесено в раздел Яндекс Вебмастера «Индексирование → Рендеринг страниц JavaScript (β)». По умолчанию действует режим «На усмотрение робота», когда алгоритмы сами решают, нужно ли выполнять скрипты. Однако в официальной справке Яндекса есть важное правило: если на сайте уже настроен серверный рендеринг (SSR) или пререндеринг и значимый контент отдаётся сразу в исходном HTML, выполнять дополнительный JS-рендеринг на стороне робота не требуется — его рекомендуется отключить в Вебмастере. Рендеринг страниц JavaScript в справке Яндекс Вебмастера.
Если же сайт полагается на клиентский рендеринг и подгружает данные асинхронно с задержкой, робот Яндекса может снять слепок страницы раньше завершения запроса к API. Для таких случаев Яндекс поддерживает глобальный объект конфигурации window.YandexRotorSettings, который размещают в до события DOMContentLoaded:
- Параметр WaiterEnabled: true сообщает роботу Яндекса, что нужно дождаться явного сигнала готовности от приложения.
- Когда скрипт получил данные и отрисовал основной контент в DOM, он выставляет флаг window.YandexRotorSettings.IsLoaded = true, после чего робот забирает готовую разметку.
- Если при запросе к API произошёл сбой, приложение передаёт window.YandexRotorSettings.IsError = true, чтобы робот не зафиксировал в индексе пустую оболочку. Параметры FailOnTimeout и NoJsRedirectsToMain дополнительно управляют поведением при превышении лимита ожидания и перенаправлениях. Рендеринг страниц JavaScript в справке Яндекс Вебмастера.
Как рендеринг влияет на AEO и GEO
В обсуждениях оптимизации под ответные системы (AEO) и генеративный поиск (GEO) — терминов, не имеющих единого отраслевого стандарта, — техническую доставку контента часто упускают из виду. Между тем в документации Google Search Central по функциям ИИ (AI Overviews и AI Mode) зафиксировано: для попадания страницы в генеративные сводки не существует специальных ИИ-тегов или отдельной схемы индексации. Базовое требование одно — страница должна быть просканирована, проиндексирована в основном поиске Google и иметь право на показ со сниппетом. Функции ИИ и ваш сайт в Google Search Central.
На практике это создаёт двойной фильтр для сайтов с тяжёлым клиентским JavaScript:
- В поисковых системах с собственным рендерером (таких как Google с AI Overviews) контент, скрытый за кликом по вкладке, бесконечным скроллом или заблокированным скриптом, не попадёт в отрендеренный DOM и не станет подтверждающим источником при развёртывании веера подзапросов (query fan-out).
- Во внешних ИИ-ассистентах и retrieval-ботах, которые запрашивают страницы напрямую по HTTP и зачастую не поднимают браузерный движок Chromium на каждый запрос, чисто клиентский рендеринг (CSR) означает, что бот увидит только пустой контейнер
.
- Важно сохранять точность и в бизнес-оценках: даже если благодаря серверному рендерингу страница индексируется и цитируется в ИИ-ответе, сам факт появления ссылки в блоке генеративного ответа не равен переходу на сайт, заявке или продаже.
Пять типовых ошибок фронтенда, из-за которых страницы выпадают из индекса
Разберём пять сбоев, которые чаще всего возникают при обновлении клиентской части сайта.
1. Конфликт канонических и индексных сигналов между сырым HTML и DOM
В одностраничных приложениях базовый HTML-файл часто содержит шаблонные метатеги главной страницы, а реальные
Если в исходном HTML-шаблоне прописан на главную страницу, а клиентский скрипт добавляет второй тег с адресом текущей карточки товара (или перезаписывает его с задержкой), в документе возникают противоречивые сигналы. О том, как поисковик взвешивает конфликтующие подсказки и почему он может выбрать не тот адрес, который задумал владелец сайта, я подробно писал в материале о работе canonical в SEO. В первичном HTML-ответе конкретной страницы не должно быть чужого canonical или временного noindex.
2. Псевдоссылки и потеря внутреннего графа перелинковки
Разработчики нередко оформляют карточки товаров, пагинацию или ссылки на подразделы через элементы