Навчання
JavaScript SEO debugging: rendered HTML, hydration і crawlable links
Гайд з дебагу SEO для React, Vue, Nuxt і Next.js: як Google рендерить JavaScript, чому зникають контент і посилання і як зробити їх crawlable.
Запусти свіжий аудит DomainLens і використовуй звіт як список пріоритетів.
Як Google насправді рендерить JavaScript
Google обробляє JavaScript-сторінку у дві хвилі. Спершу сканує сирий HTML-відповідь; потім, коли зʼявляються ресурси для рендера, запускає сторінку в headless Chromium і індексує rendered DOM. Проміжок між цими хвилями — причина, чому проблеми JavaScript SEO такі непомітні: сторінка ідеально працює у твоєму браузері, але crawler проіндексував щось інше — або відрендерив із запізненням, або взагалі ні.
Найважливіша звичка — перестати довіряти «View Source». Значення має rendered HTML: те, що існує в DOM після виконання JavaScript, бо саме це індексує Google. Більшість JS SEO-багів — це просто розбіжність між цими двома.
Помилки, що ховають контент від crawlers
- Контент, що монтується лише після клієнтського запиту даних, тож початковий і rendered HTML порожні, а рендер може вичерпати час, перш ніж контент прийде.
- Посилання як <span> чи <div> з onclick-обробниками або javascript:-URL — Google переходить лише за <a href>, тож такі сторінки неможливо знайти.
- Метадані (title, canonical, robots, hreflang), задані клієнтським JavaScript, які можуть бути пропущені або прийти після першої хвилі сканування.
- Роутинг на History API без серверних URL, тож у глибоких сторінок немає crawlable точки входу.
- Блокування Googlebot від JS- або CSS-бандлів у robots.txt, тож він взагалі не може відрендерити сторінку.
Як перевірити rendered HTML
Дебаг JS SEO — це переважно про порівняння того, що ти віддаєш, із тим, що бачить crawler.
- Скористайся URL Inspection у Search Console → «Test live URL» → View rendered HTML і скріншот; це власний рендер Google, а не твого браузера.
- Порівняй сиру відповідь (curl або «View Source») із rendered DOM (DevTools Elements) — контент, що є в DOM, але немає у відповіді, залежить від JS.
- Вимкни JavaScript у DevTools і перезавантаж: усе, що зникає, невидиме для першої хвилі й під ризиком, якщо рендер відкладено.
- Перевір, що title, canonical і robots meta існують у rendered HTML і відповідають задуму.
- Підтверди, що внутрішні посилання — це справжні <a href> у DOM, а не click-обробники.
Як зробити JavaScript-сайт crawlable
- Роби server-render або pre-render контенту й метаданих, щоб вони існували в початковому HTML — SSR (Next.js, Nuxt), статична генерація або hydration поверх серверного виводу.
- Віддавай справжні <a href> посилання для кожного маршруту, який хочеш просканувати й проіндексувати.
- Задавай критичні SEO-теги (title, canonical, robots, hreflang) на сервері, а не після hydration.
- Ніколи не блокуй JS/CSS ресурси в robots.txt; вони потрібні Google для рендера.
- Тримай rendered output стабільним і швидким — рендер, що вичерпує час, трактується так, ніби контенту немає.
Помилки, що погіршують JS SEO
- Вважати, що «Google тепер рендерить JavaScript» означає, що будь-який JS-патерн безпечний — рендер відкладений, лімітований і може провалитися.
- Перевіряти SEO-теги в DevTools браузера замість rendered HTML від Google.
- Використовувати soft 404 (статус 200 із порожньою оболонкою SPA) для маршрутів, яких не існує.
- Віддавати Googlebot інший контент, ніж користувачам, щоб «допомогти» рендеру — це клоакінг.
Як перевірити виправлення
Перезапусти URL Inspection і переконайся, що rendered HTML тепер містить контент, правильні canonical і robots теги та crawlable посилання. Потім перевіряй звіт Page Indexing наступні дні, щоб підтвердити, що потрібні URL заходять в індекс.
У DomainLens сприймай rendered HTML як джерело істини: він завантажує й читає сторінку так, як crawler, тож title, canonical чи посилання, що існують лише після hydration, показуються як відсутні — саме так їх може бачити Google.