Расхожая фраза «Google не понимает JavaScript» устарела много лет назад. Google выполняет JavaScript и видит отрисованные страницы. Но рендеринг идёт отдельным этапом со своими ограничениями, и ошибки на нём выглядят иначе, чем на обычных сайтах. Страница в браузере работает, а робот получает пустой шаблон, код 200 на несуществующем товаре или ссылки, по которым нельзя перейти.
Этот материал для маркетолога и руководителя разработки, которые готовят новый сайт или меняют шаблон. Чек-лист переезда мы собрали отдельно. Здесь только про рендеринг и проверки.
Коротко
- Сравнивайте исходный HTTP-ответ и DOM после выполнения JavaScript: расхождения между ними и есть зона риска.
- SSR и статическая генерация снимают большую часть рисков, но не лечат медленный сервер, противоречивый canonical или пустой контент.
- Отдельно проверяйте контент за кликом, выбором города, согласием, авторизацией и бесконечной прокруткой.
- Несуществующая страница должна отдавать 404, а не шаблон с ответом 200.
Исходный ответ и DOM после JavaScript
Когда браузер запрашивает страницу, сервер отдаёт HTML. Это исходный ответ. Потом выполняются скрипты: загружают данные, строят разметку, меняют заголовки. Результат называется DOM, и именно его видит посетитель. Если сайт построен на клиентском рендеринге, исходный ответ может содержать только пустой контейнер и ссылки на скрипты.
Google обрабатывает такие страницы в три этапа: обход, рендеринг и индексирование. Рендеринг может происходить не сразу после обхода. Всё, что зависит от него, попадает в индекс позже и только если рендеринг прошёл успешно.
CSR, SSR и статическая генерация
| Подход | Что в исходном ответе | Плюсы | Ограничения |
|---|---|---|---|
| CSR (клиентский рендеринг) | Пустой шаблон, контент строится в браузере | Простая инфраструктура, быстрые переходы внутри приложения | Контент зависит от рендеринга, ошибки API дают пустую страницу |
| SSR (серверный рендеринг) | Готовый HTML на каждый запрос | Контент и метаданные сразу в ответе | Нагрузка на сервер, медленный бэкенд замедляет каждую страницу |
| SSG (статическая генерация) | Готовый HTML, собранный заранее | Быстро и надёжно, легко кэшировать | Нужна пересборка или ревалидация при изменении данных |
Современные фреймворки позволяют смешивать подходы: каталог генерировать статически, корзину рендерить на клиенте. Выбор зависит от того, как часто меняются данные и сколько стоит поддержка. SSR сам по себе позиции не повышает. Он убирает зависимость от этапа рендеринга. Но если сервер отвечает три секунды, canonical указывает на другую страницу, а контент бесполезен, SSR этого не исправит.
Что проверять в шаблоне
Для каждого типа страниц сравните исходный ответ и отрисованную версию по списку: основной текст, список товаров или материалов, ссылки на другие страницы, title, meta description, canonical, meta robots, структурированные данные. Идеально, когда всё это есть уже в исходном ответе. Допустимо, когда появляется после рендеринга и проверка URL в Search Console это подтверждает.
Опасная ситуация: в исходном HTML одно значение, после рендеринга другое. Например, canonical на главную в исходном ответе и правильный после работы скрипта. Или noindex, который скрипт снимает. Увидев noindex в исходном ответе, Google может вообще не выполнять рендеринг. И не отдавайте роботу контент, отличный по смыслу от того, что видит человек: это клоакинг.
Контент за действием пользователя
Робот не нажимает кнопки, не выбирает город, не принимает cookies и не прокручивает страницу бесконечно. К тому же рендерер Google не сохраняет состояние между загрузками страниц. Поэтому отдельно проверьте:
- вкладки и аккордеоны, содержимое которых загружается только по клику;
- окно выбора города, без которого каталог не показывается;
- баннер согласия на cookies, перекрывающий контент или блокирующий загрузку данных;
- контент только для авторизованных пользователей;
- бесконечную прокрутку и кнопку «Показать ещё» без страниц пагинации.
Если контент в DOM есть, но скрыт до клика, обычно всё в порядке. Если он загружается с сервера только по клику, робот его не получит.
Коды ответа, 404 и ошибки API
Классическая ошибка одностраничных приложений: на любой URL сервер отдаёт 200 и пустой шаблон, а сообщение «Товар не найден» рисует скрипт. Для поисковика это мягкая 404 или, хуже, тысячи одинаковых страниц в индексе. Несуществующий адрес должен отдавать 404 на уровне сервера. Если это невозможно, для SPA есть два обходных пути: редирект на URL, который отдаёт 404, или noindex через JavaScript.
Второй риск: ошибка API в момент рендеринга. Каталог временно не получил данные, и робот увидел пустую страницу с кодом 200. При SSR такая ситуация должна давать 5xx, а не пустой HTML с 200: тогда поисковик поймёт, что это временный сбой, и вернётся позже.
Яндекс: настройки отдельно
У Яндекса рендеринг JavaScript управляется настройкой «Рендеринг страниц JavaScript» в разделе «Индексирование» Вебмастера. Функция помечена как бета-версия. По умолчанию робот сам решает, выполнять ли скрипты. Если на сайте есть SSR или пререндеринг, рендеринг лучше запретить: выполнение JavaScript роботом нагружает сервер, а нового робот уже не увидит.
Для сайтов, где контент появляется с задержкой, у Яндекса есть объект window.YandexRotorSettings: через него можно сообщить роботу, когда страница загружена. Есть и неочевидная деталь: вызов window.history.back() робот воспринимает как переход на главную. Если ваш роутер так обрабатывает ошибки, проверьте это отдельно.
Как проверять выборку шаблонов
Возьмите по 3-5 адресов каждого шаблона: главная, категория, карточка товара или услуги, статья, страница фильтра, несуществующий адрес. Для каждого:
- посмотрите исходный ответ: curl или «Просмотр кода страницы» в браузере, не инспектор элементов;
- откройте страницу с отключённым JavaScript и посмотрите, что осталось;
- сделайте живую проверку URL в Search Console и сравните отрисованный HTML со скриншотом;
- проверьте ответ сервера в Вебмастере;
- краулером с рендерингом и без сравните title, canonical, ссылки и объём текста по всем шаблонам.
| Наблюдение | Как проверить | Возможная причина | Задача |
|---|---|---|---|
| Одинаковый title у многих страниц в индексе | Исходный HTML карточек | title подставляется скриптом после загрузки | Отдавать title в исходном ответе |
| В индексе нет товаров дальше первой порции | Ссылки на страницы пагинации в HTML | Только кнопка «Показать ещё» | Добавить пагинацию с адресами ?page=n |
| Тысячи страниц «не найдено» в индексе | Код ответа несуществующего URL | 200 на любой адрес | Отдавать 404 с сервера |
| Пустые страницы в проверке URL | Скриншот и логи API в момент проверки | Ошибка или таймаут API | SSR с кодом 5xx при сбое, надёжный API |
| Ссылки не обходятся | Наличие a href в отрисованном HTML | Переходы через onclick | Перевести навигацию на ссылки с href |
| Канонический адрес выбран неверно | canonical в исходном HTML и после рендеринга | Разные значения | Одно значение в исходном ответе |
Условный пример: каталог с кнопкой «Показать ещё»
Пример учебный. Магазин переехал на новый фронтенд. В категории 400 товаров, по 24 на экране, остальные подгружаются кнопкой. Через месяц в индексе карточки только из первых экранов категорий. Проверка показывает: в HTML нет ссылок на следующие порции, кнопка делает запрос к API без смены адреса.
Решение без потери удобства: кнопка остаётся, но каждая порция получает свой адрес вида ?page=2, страницы пагинации отдаются сервером с собственным canonical, а в HTML есть обычные ссылки на них. Посетитель видит ту же кнопку, робот видит цепочку страниц.
Чек-лист QA перед релизом
- Для каждого шаблона title, description, canonical и robots есть в исходном ответе и совпадают с отрисованной версией.
- Основной текст и ссылки на другие страницы видны при отключённом JavaScript или подтверждены проверкой URL.
- Несуществующий адрес отдаёт 404, удалённый товар отдаёт свой код по правилам каталога.
- При ошибке API страница отдаёт 5xx, а не пустой шаблон с 200.
- Навигация построена на a href, без переходов только через onclick.
- Списки с «Показать ещё» дублируются страницами пагинации.
- Контент не скрыт за выбором города, согласием или авторизацией.
- Настройка рендеринга в Яндекс Вебмастере соответствует архитектуре сайта.
После релиза
Первые недели после выкладки смотрите на отчёты об индексировании в обеих панелях, статистику обхода, ошибки сервера в логах и число страниц с одинаковыми title. Если резко выросло число исключённых страниц или страниц «просканирована, не проиндексирована», вернитесь к выборке шаблонов. Сроки рендеринга и индексации никто не гарантирует, поэтому сравнивайте с данными до релиза, а не с ожиданиями. Если сайт уже в работе и что-то пошло не так, начните с технического аудита.
Вывод
JavaScript-сайт может индексироваться не хуже классического. Для этого нужно не доверять тому, что видно в браузере, а проверять исходный ответ, коды и ссылки на выборке шаблонов. Лучше всего делать это до релиза, пока исправление стоит часы, а не месяцы потерянного трафика.
Частые вопросы
Не обязательно, но он снимает зависимость индексации от рендеринга и ошибок в браузере робота. Для сайтов, где важен органический трафик, SSR или статическая генерация основных шаблонов обычно надёжнее чистого клиентского рендеринга.
Сам по себе нет. SSR помогает поисковику получить контент без рендеринга. Если проблема была в том, что контент не индексировался, это заметно поможет. Если в медленном сервере или слабом контенте, не поможет.
Живая проверка URL в Search Console показывает отрисованный HTML и скриншот страницы. Сравните его с исходным ответом сервера: если основной текст, ссылки или canonical есть только после рендеринга, страница зависит от этого этапа.
Зависит от архитектуры. Если на сайте есть SSR или пререндеринг, рендеринг лучше запретить. Если контент строится только в браузере, рендеринг нужен. Функция в бета-версии, поэтому результат стоит проверять по статусам страниц.
