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 роки. Це означає, що частина сучасних JS-API може не підтримуватися. За даними офіційної документації Google, краулер на базі Chromium 112 станом на 2024 рік, тоді як поточна версія браузера вже перевищила 120.

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 або rel="next"/rel="prev"
• Контент у модалках і попапах — якщо він прихований через 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 на пряме звернення до URL — 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 → «Переглянути сторінку». Також допоможе Rich Results Test для перевірки структурованих даних і Screaming Frog у режимі JavaScript rendering.

Чи читає Google контент, що завантажується через fetch/XHR?

Так, якщо JavaScript успішно виконався і контент присутній у DOM після рендерингу. Але якщо контент підвантажується після події scroll або click — Google його не побачить, адже краулер не взаємодіє зі сторінкою.