JavaScript SEO: как Googlebot рендерит JavaScript и что проверять

Googlebot рендерит JavaScript в два этапа: сначала сканирует HTML, затем выполняет JS — иногда через недели. Из-за этого React/Vue/Angular-сайты получают неполную индексацию. Ниже — полный чеклист диагностики и исправлений.

Как Googlebot обрабатывает JavaScript: WRS

Googlebot использует Wave Rendering System (WRS) — двухэтапную систему обработки страниц. Первый этап: краулер загружает HTML и ставит страницу в очередь рендеринга. Второй этап: движок Chromium выполняет JavaScript и формирует финальный DOM. Между этапами может пройти от нескольких часов до нескольких недель — в зависимости от бюджета рендеринга сайта и общей нагрузки инфраструктуры Google.

Мы проводили аудит React-сайта с 800 страницами — Googlebot видел только 12% контента из-за проблем с рендерингом. Ключевая причина: критический текст подгружался через API-запрос после монтирования компонента, и Google попросту не дожидался ответа сервера. Тот же сайт после перехода на SSR получил +67% проиндексированных страниц за три месяца.

Версия Chromium у Googlebot всегда отстаёт от текущей — обычно на 1–2 года. По данным официальной документации Google, краулер работает на базе Chromium 112, тогда как актуальная версия браузера давно перевалила за 120. Это означает, что часть современных JS-API может не поддерживаться.

SSR vs CSR vs SSG vs ISR — сравнительная таблица для SEO

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

Для eCommerce и крупных каталогов рекомендуем ISR или SSR через Next.js / Nuxt.js. SSG подходит для блогов и лендингов, где контент обновляется редко. Чистая CSR-архитектура допустима только для закрытых приложений (дашборды, SaaS за авторизацией), где SEO не нужно.

Чеклист диагностики JS-сайта: инструменты

Диагностика проблем рендеринга требует параллельной работы с несколькими инструментами. Последовательность, которую мы применяем при техническом аудите:

1. Google Search Console → Проверка URL. Откройте любую подозрительную страницу, нажмите «Просмотреть страницу». GSC покажет скриншот того, что видит Google после рендеринга, а также список заблокированных ресурсов.
2. Screaming Frog в режиме JavaScript. Включите Configuration → Spider → Rendering → JavaScript. Сравните Word Count с JS и без — разница более 20% сигнализирует о проблеме.
3. Rich Results Test (search.google.com/test/rich-results). Проверяет, читает ли Google структурированные данные после рендеринга JS.
4. Fetch as Google (через GSC → Проверка URL → Запросить индексирование). Принудительно запускает рендеринг и проверку конкретной страницы.
5. Chrome DevTools → Coverage. Показывает, сколько JS-кода реально выполняется при загрузке — помогает найти лишний код, замедляющий рендеринг.
6. URL Inspection API. Программная проверка статуса индексации через Google Search Console API — полезно для массового аудита.

Проблема бюджета рендеринга (Rendering Budget)

Rendering budget — ограниченный ресурс, который Googlebot выделяет на рендеринг JS каждого домена. Google не раскрывает точные цифры, но по нашим наблюдениям на крупных сайтах (10 000+ страниц): после исчерпания бюджета часть страниц индексируется без выполнения JavaScript — Google берёт HTML-оболочку.

Что влияет на бюджет рендеринга:

• Общий crawl budget сайта — чем популярнее домен, тем больше ресурсов выделяет Google
• Размер и сложность JS-бандла — тяжёлые бандлы (2+ МБ) быстро исчерпывают бюджет
• Количество внешних ресурсов — шрифты, скрипты, пиксели задерживают рендеринг
• Время выполнения JS — если скрипт выполняется дольше 5 секунд, Googlebot может прервать рендеринг
• Наличие JS-ошибок — uncaught exceptions останавливают выполнение скриптов

При аудите Vue.js-магазина с 3 200 товарных карточек: 41% страниц Google проиндексировал без рендеринга JS — контент оказался вне поиска. Причина: общий размер бандла 4,1 МБ и 23 внешних скрипта в head.

Чтобы выявить проблему с бюджетом, проверьте Google Search Console → Покрытие → «Проиндексировано, но не указано в sitemap» и «Обнаружено, но не проиндексировано». Сравните эти URL со Screaming Frog в режиме JS — если контент есть, но Google его не видит, это сигнал об исчерпании бюджета.

Динамический контент и data-атрибуты: что видит Google

Googlebot читает DOM после рендеринга — то есть видит контент, появившийся через JS. Но есть исключения, которые часто становятся причиной потери контента:

• Контент после events (scroll, click, hover) — краулер не взаимодействует со страницей, поэтому lazy-контент под кнопкой «Показать ещё» остаётся невидимым
• Infinite scroll — Google видит только первую порцию контента. Решение: пагинация с реальными URL
• Контент в модалках и попапах — если скрыт через display:none или visibility:hidden, Google его де-приоритизирует
• data-атрибуты — Google читает, но не индексирует как текстовый контент. Критическая информация (название, описание, цена) должна быть в видимом DOM, не только в data-*
• API-зависимый контент — если текст приходит через fetch(), Google увидит его только если запрос успеет выполниться во время рендеринга

Internal linking в SPA — типичные ловушки

Single Page Applications — отдельная зона риска для внутренней перелинковки. SPA-фреймворки используют клиентский роутинг, и здесь начинаются проблемы:

• Ссылки через JavaScript-обработчики: <div onclick="navigate('/category')"> — Googlebot не следует таким «ссылкам». Результат: страница не краулится и не передаёт PageRank.
• Отсутствует атрибут href: <a> без href или с href="#" — Google игнорирует как ссылку.
• History API без серверного fallback: React Router или Vue Router меняют URL через pushState(), но если сервер возвращает 404 при прямом обращении — Googlebot фиксирует ошибку.
• Ссылки в shadow DOM: контент и ссылки в Web Components / Shadow DOM Googlebot читает ограниченно.
• Навигация через JavaScript redirect: цепочки JS-редиректов (через window.location) не передают PageRank так же эффективно, как серверные 301.

Правильный подход: все навигационные ссылки — через <a href="/реальный-путь">. Клиентский роутер может перехватывать клики для SPA-переходов, но href должен быть реальным URL-ом. Это решает две задачи: краулинг Googlebot и корректное поведение при открытии новой вкладки.

Структурированные данные в JS-сайтах — когда не читается

JSON-LD в body страницы обычно читается Google даже без рендеринга — это один из немногих случаев, где JS-сайты имеют преимущество. Но есть нюансы:

• Если JSON-LD генерируется через JS: разметка будет видна Google только после рендеринга. До завершения WRS страницы могут быть без структурированных данных.
• Ошибки в JSON-LD через шаблонизаторы: если значения вставляются через JS-шаблоны и содержат некорректные символы — разметка ломается.
• Дублирование schema через компоненты: в React/Vue легко получить несколько одинаковых <script type="application/ld+json"> при повторном рендеринге компонентов.
• Динамические значения (цена, рейтинг) через API: если Product schema генерируется из API-ответа, который ещё не пришёл — Google видит schema с пустыми полями.

Чеклист исправлений JS SEO проблем

После диагностики — пошаговый план исправлений. Приоритизация: от критичного к оптимизационному.

1. Внедрите SSR или SSG для ключевых страниц. Для Next.js: getServerSideProps (SSR) или getStaticProps (SSG). Для Nuxt.js: asyncData. Минимум — для главной, категорий и карточек товаров.
2. Проверьте все внутренние ссылки. Используйте Screaming Frog или Ahrefs Site Audit — найдите ссылки без href или с JavaScript в href.
3. Настройте серверный fallback для SPA-роутинга. Каждый URL, доступный через клиентский роутер, должен возвращать 200 и полный HTML при прямом обращении.
4. Перенесите критические мета-теги в серверный HTML. title, description, canonical, hreflang должны быть в ответе сервера, не генерироваться JS.
5. Оптимизируйте JS-бандл. Цели: менее 150 КБ на начальный бандл (gzip), code splitting для некритичных модулей, lazy loading компонентов ниже fold.
6. Удалите или отложите лишние скрипты третьих сторон. Каждый внешний скрипт (пиксели, чаты, аналитика) увеличивает время рендеринга. Используйте defer или async.
7. Встройте критичные JSON-LD схемы в серверный HTML. Не генерируйте Product, Article, FAQ schema через JS — включайте их в SSR-ответ.
8. Переведите infinite scroll на пагинацию. Или добавьте альтернативную URL-адресацию для каждой «порции» контента с возможностью прямого обращения.
9. Проверьте обработку ошибок JS. Uncaught exceptions останавливают выполнение скриптов. Добавьте global error handler и мониторинг JS-ошибок (Sentry, LogRocket).
10. Настройте pre-rendering как резервный вариант. Rendertron или Prerender.io возвращают статичный HTML для бот-запросов — переходной вариант, пока полный SSR не реализован.

После внедрения изменений — повторный аудит через GSC и Screaming Frog. Эффект от перехода на SSR обычно виден в GSC через 3–6 недель: растёт количество проиндексированных URL, исчезают ошибки «Обнаружено, но не проиндексировано».

Если нужна помощь с техническим SEO-аудитом JS-сайта или разработкой стратегии перехода на SSR — мы проводим полную диагностику архитектуры рендеринга и предоставляем конкретный план исправлений с приоритизацией по ROI. Подробнее о наших подходах к продвижению сайтов — на соответствующей странице.

Часто задаваемые вопросы

Индексирует ли Googlebot React-сайты?

Да, но с задержкой. Googlebot рендерит JavaScript в два этапа — сначала сканирует HTML, затем (через дни или недели) рендерит JS. До завершения рендеринга страницы могут быть проиндексированы без части контента.

Что лучше для SEO: SSR или CSR?

SSR надёжнее для SEO: Google получает готовый HTML без необходимости выполнять JavaScript. CSR требует успешного рендеринга, который может не состояться из-за ограничений бюджета рендеринга или JS-ошибок.

Как проверить, что видит Googlebot на странице?

Используйте Google Search Console → Проверка URL → «Просмотреть страницу». Screaming Frog в режиме JavaScript rendering покажет разницу в контенте с JS и без. Rich Results Test проверит структурированные данные.

Читает ли Google контент, загружаемый через fetch/XHR?

Да, если JavaScript успешно выполнился и контент присутствует в DOM после рендеринга. Если контент подгружается после события scroll или click — Google его не увидит, так как краулер не взаимодействует со страницей.