Аудит JS-рендеринга: исходный и отрендеренный HTML

Проверка рендеринга: исходный HTML и отрендеренный DOM

Когда использовать: Убедитесь, что видит Googlebot после выполнения JavaScript, а не только в первом ответе сервера.

Сравните исходный код с отрендеренным DOM

Google сначала получает исходный HTML, а перед индексацией рендерит страницу в headless-браузере. Рендеринг откладывается и требует ресурсов, поэтому может отставать от сканирования. В итоге для индексации важен именно отрендеренный результат.

Начните с исходного HTML (того, что возвращает сервер) и отметьте, какой контент, ссылки и метаданные есть до выполнения JavaScript. Затем изучите отрендеренный DOM после работы скриптов и сравните две версии.

• [URL страницы] проверен
• Основной контент есть в исходном HTML?
• Заголовки, текст и данные о товаре есть в отрендеренном DOM?
• Навигация и внутренние ссылки есть после рендеринга?
• Title, meta description и canonical есть после рендеринга?

Отмечайте всё, что появляется только после выполнения JavaScript. Такой контент целиком зависит от успешного рендеринга, поэтому риск здесь максимальный. Каждое расхождение между исходным HTML и отрендеренным DOM записывайте как задачу на исправление.

Сканируемый контент и ссылки

Когда использовать: Проверьте, что основной контент и навигация построены на настоящих сканируемых ссылках в DOM.

Настоящие ссылки и контент в DOM

Поисковые системы переходят по ссылкам через стандартные элементы <a> с атрибутом href, который ведёт на реальный URL. Ссылки, работающие только через обработчик onclick, кнопку или span, находятся ненадёжно, и важные страницы могут остаться несканированными.

Пройдитесь по ключевым шаблонам и убедитесь, что каждая навигационная и контекстная ссылка является настоящим якорем со сканируемым href.

• Главная навигация использует ссылки [a href]
• Пагинация и фильтры отдают сканируемые URL
• Похожие и внутренние ссылки являются настоящими якорями, а не onclick
• Основной контент рендерится в DOM, а не прячется за взаимодействиями

Не полагайтесь на события клика, бесконечную прокрутку без URL пагинации или контент, который подгружается только после действий пользователя. Googlebot их не выполняет. Если контент появляется только после тапа или прокрутки, считайте его рискованным и дайте к нему сканируемый путь. Запишите, какие ссылки и блоки прошли проверку, а каким нужен настоящий href или присутствие в DOM.

Индексируемость: метаданные после рендеринга

Когда использовать: Ловите сюрпризы с noindex, canonical или robots, которые добавляет JS и которые блокируют или сбивают индексацию.

Проверяйте метаданные после рендеринга, а не только в исходнике

JavaScript может менять сигналы индексации, но не всегда так, как вы ждёте. Noindex, добавленный через JavaScript, может сработать. А noindex в исходном HTML, который JavaScript потом убирает, может не сработать: Google иногда пропускает рендеринг страниц, где изначально стоит noindex. Canonical, заданный через JavaScript, должен совпадать с canonical в исходном HTML.

Для каждого шаблона изучите отрендеренный DOM и убедитесь, что сигналы индексации соответствуют вашему замыслу.

• Robots meta в отрендеренном DOM: [index/noindex]
• Тег canonical есть один раз и указывает на нужный URL
• JavaScript не подменяет canonical на другой URL
• Title и meta description после рендеринга принимают правильные значения
• Hreflang и структурированные данные есть там, где должны быть

Изменения noindex или canonical через JS рискованны: Google может учесть исходное значение, отрендеренное или вовсе пропустить рендеринг. Особенно осторожно с фреймворками и менеджерами тегов, которые переписывают элементы head. Если директива может отличаться в исходном и отрендеренном состоянии, считайте это дефектом и задавайте её на сервере. Записывайте отрендеренные директивы каждой страницы и все расхождения.

Стратегия рендеринга: CSR, SSR или SSG

Когда использовать: Выберите подход к рендерингу, при котором контент надёжно доступен краулерам.

Выберите стратегию рендеринга в пользу сканируемости

От способа рендеринга зависит, насколько надёжно контент доходит до поисковых систем. Рендеринг у Google отложенный, поэтому стратегии, которые отдают контент в первом HTML, снижают риск.

• Рендеринг на клиенте (CSR): браузер собирает страницу из JavaScript. Контент полностью зависит от успешного рендеринга, поэтому риск для индексации самый высокий.
• Рендеринг на сервере (SSR): сервер на каждый запрос отдаёт готовый HTML. Контент, ссылки и метаданные доступны сразу.
• Генерация статического сайта (SSG) или пререндеринг: HTML собирается заранее или отдаётся через слой пререндеринга. Контент надёжно доступен, а производительность высокая.

Для важных для SEO страниц выбирайте SSR, SSG или пререндеринг, чтобы контент был в первом HTML. Тяжёлый CSR оставьте для разделов за авторизацией или с низкой ценностью для SEO.

Опишите текущий подход для каждого шаблона, проблемы, которые он создаёт, и целевую стратегию.

• Шаблон: [название]
• Текущий и целевой способ рендеринга

Влияние JavaScript на производительность

Когда использовать: Уменьшите вес JS и стоимость его выполнения, чтобы страницы быстро рендерились и для людей, и для краулеров.

Сократите стоимость JavaScript

Тяжёлый JavaScript замедляет рендеринг для пользователей и добавляет работы поисковым системам. Рендеринг требует ресурсов, поэтому лёгкие страницы рендерятся надёжнее и грузятся быстрее. Это хорошо и для пользовательского опыта, и для индексации.

Проверьте, сколько скриптов отдаёт каждый ключевой шаблон и что они блокируют.

• Найдены большие или неиспользуемые JavaScript-бандлы
• Блокирующие рендеринг скрипты отложены или разбиты, где возможно
• Важный контент не ждёт медленного выполнения скриптов
• Сторонние скрипты проверены на вес и необходимость
• Core Web Vitals проверены на ключевых шаблонах

Используйте разделение кода, удаляйте неиспользуемый код и загружайте второстепенные скрипты позже, чтобы основной контент появлялся быстро. Никогда не блокируйте JavaScript- и CSS-файлы в robots.txt: тогда Google не сможет отрендерить страницу так, как её видят пользователи. Запишите размеры бандлов, блокирующие ресурсы и запланированные исправления для каждого проверенного шаблона.

Тестирование и мониторинг

Когда использовать: Проверяйте рендеринг реальными инструментами и следите за ситуацией в Search Console.

Протестируйте отрендеренную страницу и наблюдайте за ней

Сверяйте исправления с тем, что Google рендерит на самом деле. Инструмент проверки URL (URL Inspection) в Search Console показывает отрендеренный HTML и скриншот просканированной страницы. Так можно убедиться, что контент, ссылки и метаданные есть после рендеринга.

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

• Отрендеренный HTML в проверке URL содержит основной контент
• Скриншот рендеринга показывает ожидаемый макет
• Навигация и внутренние ссылки есть в отрендеренном HTML
• Директивы индексации в отрендеренном результате верны
• Ошибок при рендеринге нет

Затем переходите от разовых проверок к постоянному мониторингу.

• Следите за отчётами об охвате и индексации в Search Console
• Проверяйте заново после крупных изменений фреймворка или шаблонов
• Следите, не выпадают ли страницы из индекса

Записывайте каждый протестированный URL [URL], его статус рендеринга и нужные доработки, чтобы ловить проблемы рано, а не после просадки позиций.

Таблица аудита: исходный и отрендеренный HTML (для заполнения)

Когда использовать: Одна строка на шаблон страницы: исходные и отрендеренные значения контента, ссылок, title, canonical, robots и статуса, плюс ошибки консоли и гидратации.

Аудит исходного и отрендеренного HTML

Проверьте по одному типичному URL на шаблон (главная, категория, товар, статья). Исходный = HTML, который возвращает сервер. Отрендеренный = то, что показывает проверка URL или проверка расширенных результатов (Rich Results Test) после выполнения JavaScript.

Какие ошибки записывать

• Ошибки консоли при рендеринге: [сообщение, файл скрипта]
• Ошибки гидратации: [предупреждение фреймворка, компонент, что изменилось между серверным и клиентским HTML]
• Заблокированные ресурсы: [JS- или CSS-файлы, заблокированные в robots.txt]

Правило: если контент или ссылки есть только в отрендеренной колонке, шаблон зависит от рендеринга. Для страниц, которые должны ранжироваться, надёжнее перейти на рендеринг на сервере или пререндеринг.

Проверка статусов и soft 404

Когда использовать: Убедитесь, что страницы ошибок в одностраничном приложении отдают настоящие ошибки, а маршрутизация использует сканируемые URL.

Проверка статусов

Одностраничные приложения часто показывают сообщение "страница не найдена" со статусом 200. Google называет такие страницы soft 404. В его руководстве по JavaScript есть два решения: редирект на URL, который отдаёт настоящий 404, или добавление robots-тега noindex через JavaScript.

Критерий готовности: строки каждого шаблона совпадают или у исправления есть ответственный; дата повторной проверки [дата].

Разобранный пример (вымышленное приложение рецептов)

Когда использовать: Заполненный аудит придуманного сайта рецептов на React с тремя расхождениями между исходным и отрендеренным HTML.

Разобранный пример: Pantry & Plate

Только пример. Компания, люди, URL и цифры придуманы, чтобы показать, как выглядит рабочая заполненная версия.

Почему строка 3 оказалась главной

Шаблон по умолчанию отдавал noindex, а JavaScript после загрузки менял его на index. В браузере всё выглядело нормально. Но Google может не рендерить страницу, если в исходном HTML стоит noindex, и тогда замену он просто не увидит. Удаление значения по умолчанию решило проблему.

Что дальше

Откройте Получить исходный код страницы, чтобы увидеть исходный HTML, который получает краулер, и сравните его с отрендеренным HTML из проверки URL. Запустите аудит сайта, чтобы найти проблемы со статусами и метаданными во всех шаблонах, и проверяйте страницы прямо при просмотре с помощью SEO-расширения seotools.pro. Если команде нужна помощь с переводом ключевых шаблонов на рендеринг на сервере, загляните в наши услуги SEO и GEO.