Sirak Ghroyan - SEO, GEO, AEO
SEO

JavaScript в SEO и AEO: как устроен рендеринг страниц и почему контент пропадает из поиска после релиза

JavaScript в SEO и AEO: как устроен рендеринг страниц и почему контент пропадает из поиска после релиза

Команда выкатывает обновлённый фронтенд на современном JavaScript-фреймворке. Тестировщики открывают сайт в браузере, переходят по разделам, проверяют корзину и закрывают задачу: визуально всё работает. Но через неделю в Google Search Console и Яндекс Вебмастере начинается просадка: карточки товаров переходят в статус Soft 404, часть разделов выпадает из индекса, внутренние ссылки перестают обнаруживаться, а в сниппетах вместо названий статей появляется общий заголовок шаблона.

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

Грамотная работа с JavaScript в SEO — это не отказ от реактивных интерфейсов. Задача решается архитектурно: критические сигналы документа (код ответа сервера, директивы индексации, канонический адрес, заголовки, основной текст и ссылки <a href>) должны быть доступны роботу без имитации действий человека и без противоречий между первичным 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) по умолчанию прописан тег <meta name="robots" content="noindex">, а разработчики рассчитывают, что клиентский скрипт после загрузки данных заменит его на index, follow, схема не сработает. Согласно документации Google, при обнаружении noindex на этапе первичного разбора HTML робот пропускает фазу рендеринга и не запускает JavaScript. Скрипт, который должен был снять запрет, просто не получает управления.

Если страница открыта для сканирования, наступает вторая фаза — рендеринг. Сервис Web Rendering Service (WRS) запускает страницу в безголовом браузере на базе актуального («вечнозелёного», evergreen) движка Chromium, выполняет JavaScript и строит итоговое дерево документа (Rendered DOM). Затем наступает третья фаза: поисковая система анализирует отрендеренный DOM, извлекает текст, заголовки, микроразметку и новые ссылки <a href> для очереди обхода.

При этом 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, о которых важно помнить при проектировании фронтенда:

  1. Только HTTP-запросы без постоянных сокетов. Googlebot получает данные по протоколу HTTP и не поддерживает загрузку основного контента через постоянные соединения вроде WebSockets или WebRTC. Если каталог подтягивает записи только через сокет-соединение без HTTP-фолбэка, для поисковика страница останется пустой.
  2. Агрессивное кеширование и content fingerprinting. Чтобы не перегружать серверы сайтов, WRS активно кеширует статические файлы и может игнорировать заголовки Cache-Control. Если после релиза команда обновила логику внутри app.js, не изменив его URL, робот может долго выполнять старую версию скрипта из кеша вместе с новым HTML. Рекомендация Google — использовать хеширование содержимого в именах файлов (content fingerprinting, например main.2bb85551.js), чтобы каждое изменение кода создавало новый адрес ресурса.
  3. Сплющивание Shadow DOM в Web Components. При обработке веб-компонентов WRS объединяет («сплющивает») Shadow DOM и Light DOM. Если компонент не использует элемент <slot> для вставки содержимого из Light DOM, текст и ссылки внутри него могут пропасть из финального дерева документа.
  4. Отсутствие состояния между запросами. Каждый URL обрабатывается изолированно: WRS не переносит localStorage, sessionStorage и пользовательские cookies между страницами. Если сайт показывает контент только после записи региона или подтверждения возраста в локальное хранилище, робот при каждом заходе будет видеть модальное окно вместо текста статьи или карточки товара. Исправление проблем с JavaScript в поиске Google.

Инструменты Яндекса: рендеринг JavaScript и window.YandexRotorSettings

В Яндексе управление обработкой клиентского кода вынесено в раздел Яндекс Вебмастера «Индексирование → Рендеринг страниц JavaScript (β)». По умолчанию действует режим «На усмотрение робота», когда алгоритмы сами решают, нужно ли выполнять скрипты. Однако в официальной справке Яндекса есть важное правило: если на сайте уже настроен серверный рендеринг (SSR) или пререндеринг и значимый контент отдаётся сразу в исходном HTML, выполнять дополнительный JS-рендеринг на стороне робота не требуется — его рекомендуется отключить в Вебмастере. Рендеринг страниц JavaScript в справке Яндекс Вебмастера.

Если же сайт полагается на клиентский рендеринг и подгружает данные асинхронно с задержкой, робот Яндекса может снять слепок страницы раньше завершения запроса к API. Для таких случаев Яндекс поддерживает глобальный объект конфигурации window.YandexRotorSettings, который размещают в <head> до события 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) означает, что бот увидит только пустой контейнер <div id="app"></div>.
  • Важно сохранять точность и в бизнес-оценках: даже если благодаря серверному рендерингу страница индексируется и цитируется в ИИ-ответе, сам факт появления ссылки в блоке генеративного ответа не равен переходу на сайт, заявке или продаже.

Пять типовых ошибок фронтенда, из-за которых страницы выпадают из индекса

Разберём пять сбоев, которые чаще всего возникают при обновлении клиентской части сайта.

1. Конфликт канонических и индексных сигналов между сырым HTML и DOM

В одностраничных приложениях базовый HTML-файл часто содержит шаблонные метатеги главной страницы, а реальные <title>, <meta name="description"> и <link rel="canonical"> подставляются клиентским роутером после инициализации JavaScript.

Если в исходном HTML-шаблоне прописан rel="canonical" на главную страницу, а клиентский скрипт добавляет второй тег rel="canonical" с адресом текущей карточки товара (или перезаписывает его с задержкой), в документе возникают противоречивые сигналы. О том, как поисковик взвешивает конфликтующие подсказки и почему он может выбрать не тот адрес, который задумал владелец сайта, я подробно писал в материале о работе canonical в SEO. В первичном HTML-ответе конкретной страницы не должно быть чужого canonical или временного noindex.

2. Псевдоссылки и потеря внутреннего графа перелинковки

Разработчики нередко оформляют карточки товаров, пагинацию или ссылки на подразделы через элементы <div onClick="...">, <button> или <a onClick="router.push('/product/123')"> без атрибута href. Для пользователя в браузере переход срабатывает мгновенно через History API.

Для поискового робота такой элемент ссылкой не является. В руководстве Google по сканируемым ссылкам прямо указано: робот гарантированно извлекает и ставит в очередь обхода только те адреса, которые размечены тегом <a> с валидным атрибутом href, содержащим разрешаемый URL документа. Конструкции с javascript:void(0), href="#" или атрибутами data-url разрывают внутреннюю перелинковку: робот заходит в категорию, но не видит переходов в карточки товаров. Требования Google к сканируемым ссылкам.

При этом реальные ссылки <a href> нужны именно для тех страниц, которые должны индексироваться (категории, карточки, посадочные срезы со спросом и последовательная пагинация). Служебные переключатели сортировки и технические комбинации параметров, наоборот, не стоит выводить как открытые ссылки в DOM — эту грань я разбирал в статье про фильтры каталога в SEO и AEO.

3. Клиентский Soft 404 на несуществующих адресах

В классической серверной архитектуре обращение к удалённому товару или несуществующему URL возвращает HTTP-статус 404 Not Found или 410 Gone. В клиентском SPA веб-сервер часто настроен так, чтобы на любой маршрут отдавать один и тот же файл index.html с кодом 200 OK. Затем в браузере запускается JavaScript, обращается к API, получает ответ «товар не найден» и рисует заглушку «Страница не существует».

Для поисковой системы комбинация кода 200 OK при пустом или сообщающем об ошибке документе является классической ошибкой Soft 404. Робот тратит краулинговый бюджет на обход несуществующих адресов, а в Search Console копится список проблемных страниц. В документации Google описаны два решения: при серверном рендеринге отдавать честный HTTP-код 404/410 на уровне сервера, а при чисто клиентской маршрутизации — немедленно добавлять в <head> тег <meta name="robots" content="noindex"> или перенаправлять маршрут на страницу, отдающую серверный статус 404. Ошибки Soft 404 и способы их устранения в Google.

4. Отложенная загрузка (lazy-loading), завязанная на действия пользователя

Отложенная подгрузка блоков ниже первого экрана ускоряет работу сайта, но при неправильной реализации скрывает контент от индексации. В руководстве по lazy-loading Google предупреждает: во время рендеринга робот не прокручивает страницу и не кликает по элементам интерфейса. Настройка отложенной загрузки контента в Google Search Central.

Если описание товара, таблица характеристик или отзывы подгружаются в DOM только после события window.onscroll или нажатия на вкладку «Характеристики», в отрендеренном DOM этих данных не окажется. Как сделать правильно:

  • Для изображений и iframe ниже первого экрана используйте нативный атрибут loading="lazy" или API IntersectionObserver — при рендеринге WRS автоматически увеличивает высоту виртуального окна просмотра (viewport), чтобы сработали стандартные наблюдатели видимости.
  • Не применяйте lazy-loading к контенту первого экрана (заголовку, главному фото и основному описанию).
  • Для вкладок и аккордеонов загружайте текст в HTML-разметку сразу и управляйте его видимостью через CSS, вместо того чтобы запрашивать текст с сервера только по клику мыши.

5. Обрыв рендеринга из-за неперехваченных ошибок в скриптах

Ошибка второстепенного виджета (онлайн-чата, геотаргетинга или рекомендательного блока) может остаться незамеченной в браузере тестировщика, если она возникает только в окружении без cookies. Но если неперехваченное исключение (Uncaught TypeError) прерывает выполнение основного бандла до отрисовки центрального блока страницы, робот получит пустой экран. Проверка логов консоли внутри инструмента проверки URL в Search Console помогает заметить ошибки выполнения скриптов, если они воспроизводятся во время прохода WRS.

Какую архитектуру выбрать: SSR, SSG, гидратация или динамический рендеринг

При запуске сайта или перестройке фронтенда выбор способа рендеринга определяет, насколько стабильно страницы будут входить в индекс.

  1. Статическая генерация (SSG, Static Site Generation) — HTML-код каждой страницы собирается заранее на этапе сборки или по расписанию. Это самый надёжный вариант для разделов со стабильным контентом: статей блога, справочников, посадочных страниц услуг и документации. Поисковый робот и ИИ-краулер сразу получают готовый HTML без ожидания скриптов.
  2. Серверный рендеринг с гидратацией (SSR + Hydration) — при запросе адреса сервер собирает полный HTML с актуальными данными (ценами, остатками, заголовками и метатегами), отправляет его клиенту, а затем в браузере «оживляет» интерактивные элементы через JavaScript. Это рабочий стандарт для интернет-магазинов, маркетплейсов и крупных порталов.
  3. Чистый клиентский рендеринг (CSR, Client-Side Rendering) — сервер отдаёт только минимальный HTML-каркас, а весь контент строится в браузере. Такую схему разумно оставлять для закрытых личных кабинетов, панелей управления и внутренних инструментов, которым не нужно ранжироваться по информационным или товарным запросам.

Отдельно стоит сказать о динамическом рендеринге (Dynamic Rendering) — схеме, при которой сервер определяет поискового робота по заголовку User-Agent и отдаёт ему предрендеренный статический слепок, а обычным посетителям отправляет клиентский SPA. В документации Google прямо подчёркнуто: динамический рендеринг является временным обходным путём (workaround), а не рекомендуемым долгосрочным решением. Он усложняет инфраструктуру и создаёт риск: если предрендеренный для бота HTML из-за сбоя кеша начнёт существенно отличаться от пользовательской версии, поисковая система может расценить расхождение как клоакинг. Инвестировать ресурсы лучше в полноценный SSR, SSG или гидратацию. Позиция Google по динамическому рендерингу.

Регламент приёмки фронтенд-релиза: 6 проверок до и после выкатки

Перед выкаткой и сразу после релиза я рекомендую проходить чек-лист из шести проверок.

  1. Сверка первичного HTML и отрендеренного DOM. На тестовом стенде запросите страницу HTTP-клиентом без выполнения скриптов (curl) и сравните ответ с итоговым DOM после выполнения JavaScript. В сыром HTML не должно быть шаблонного noindex и чужого rel="canonical", а после рендеринга в DOM должны присутствовать уникальный <h1>, основной текст и внутренние ссылки <a href="...">.
  2. Проверка навигации без событий клика и скролла. Убедитесь, что ссылки на категории, карточки и страницы пагинации (?page=2) присутствуют в DOM как теги <a href>, а характеристики товара не требуют нажатия на вкладку для появления в разметке.
  3. Тест несуществующего URL на Soft 404. Обратитесь к несуществующему адресу (/catalog/non-existent-item-999). При SSR сервер обязан вернуть HTTP-статус 404 или 410. При CSR проверьте, что роутер сразу выставляет noindex или перенаправляет на страницу со статусом 404, а не оставляет код 200 OK с индексируемой заглушкой.
  4. Проверка доступности ресурсов в robots.txt и хеширования бандлов. Убедитесь, что файлы .js, .css и публичные API-маршруты, формирующие контент страницы, открыты для обхода, а имена скриптов содержат хеш содержимого (content fingerprinting).
  5. Согласование настроек рендеринга в Яндекс Вебмастере. Если проект переехал с CSR на полноценный SSR, отключите лишний рендеринг на стороне робота в разделе «Индексирование → Рендеринг страниц JavaScript» Яндекс Вебмастера. Если проект остаётся на асинхронном CSR, проверьте корректность работы window.YandexRotorSettings и сигнала IsLoaded = true.
  6. Пострелизный контроль через URL Inspection и Rich Results Test. В первый день после выкатки проверьте по одному типовому URL каждого шаблона через инструмент проверки URL в Google Search Console («Проверить опубликованный URL → Просмотреть просканированную страницу»), сверяя итоговый HTML, скриншот и лог ошибок консоли JS.

С чего начать на своём сайте

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

Сначала откройте инструмент проверки URL в Google Search Console для живой страницы и проверьте код отрендеренного DOM: найдите поиском по коду текст со второго экрана, характеристики из вкладок и ссылки на соседние товары. Затем проверьте настройки рендеринга JavaScript и отчёт «Диагностика сайта» в Яндекс Вебмастере, а также отчёт индексирования на предмет ошибок Soft 404. Сопоставление этих данных помогает сузить круг гипотез — от блокировки ресурсов в robots.txt до клиентской маршрутизации или отложенной загрузки — и сформулировать предметное техническое задание для разработчиков по подтверждённым расхождениям.

33