Етапи обробки Google
Google описує JavaScript processing як crawling, rendering та indexing — це не один синхронний fetch.
JavaScript SEO · Rendering · Діагностика індексації
JavaScript SEO: діагностика rendering та індексації для SPA, SSR і hybrid-сайтів
Я рекомендую спочатку визначити та переконатися на якому рівні / етапі контент сторінки розходиться з очікуваним контентом. Порівняйте HTTP response, browser-rendered DOM і Google-rendered evidence; виправляйте найперший шар, де губиться критичний контент, посилання або індексаційний сигнал.
Коротка відповідь
Не варто починати з питання чи вміє Google виконувати код вашого framework. Візьміть один репрезентативний URL і порівняйте три артефакти: raw HTTP response, DOM після виконання JavaScript у браузері та Google-rendered evidence з URL Inspection або Rich Results Test. Перший шар, де зникає критичний контент, links, canonical/robots або коректна status behavior, визначає наступний тест.
Типовий статус для render queue
За документацією Google, сторінки з HTTP 200 потрапляють у rendering queue, якщо robots directive не блокує indexing; для non-200 rendering може бути пропущений.
Надійний crawlable-link primitive
Google зазвичай парсить посилання як anchor element з href; script-only псевдопосилання не є надійною заміною.
Default limit crawling infrastructure
Crawling infrastructure Google за замовчуванням обробляє перші 15 MB файлу, але окремі краулери та типи файлів можуть мати інші ліміти. Це інфраструктурна межа, а не універсальний Googlebot HTML threshold.
01 · Локалізуйте проблему
Почніть із трьох станів сторінки, а не з діагнозу framework
JavaScript SEO проблему простіше локалізувати, якщо зберегти три артефакти одного URL: server HTML, browser-rendered DOM і Google-rendered output.
Порожній view-source: сам по собі не доводить, що сторінка не може бути проіндексована. Так само ідеальна сторінка у вашому браузері не доводить, що Google отримав той самий контент. Моя базова модель — порівняння трьох станів. Стан 1 — HTTP response до client JavaScript. Стан 2 — DOM після виконання scripts та data fetch у браузері. Стан 3 — HTML і resource evidence з Google rendering tools. Виправляйте найраніший стан, де зникає потрібний сигнал: наступні симптоми часто є лише наслідком.
02 · Побудуйте модель pipeline
Розділіть crawling, rendering та indexing до того, як інтерпретувати симптом
У JavaScript pipeline Google є окремі етапи та черги. Discovery failure — не те саме, що render failure, а успішний render не гарантує indexing.
Google Search описує три основні фази для JavaScript pages: crawling → rendering → indexing. Googlebot спочатку отримує URL, якщо robots.txt дозволяє crawl, і витягує links із response. Сторінки з HTTP 200 потім потрапляють у rendering queue, якщо robots directive не забороняє indexing; очікування може тривати секунди або довше. Headless evergreen Chromium виконує JavaScript, після чого Google ще раз аналізує rendered HTML для links і використовує цей output під час indexing. Тому «Google fetched URL» і «Google indexed rendered content» — різні твердження.
Кастомна схема
Evidence pipeline для JavaScript SEO
Один URL створює різні докази на crawl, render та index stages. Кожен етап може мати окрему failure mode і потребує свого артефакту.
Спочатку класифікуйте симптом
- Discovery/crawl: URL або потрібні ресурси не завантажуються, internal links не є crawlable або robots.txt блокує доступ.
- Rendering: HTTP response є, але JavaScript, API data, hydration чи resource loading завершується помилкою до появи critical DOM content.
- Indexation: rendered content присутній, але canonical, robots, duplicate/quality або інші сигнали не дають обрати потрібний URL для індексації.
03 · Зафіксуйте baseline
Перевірте HTTP response до того, як JavaScript змінить сторінку
Server response — це контрольний зразок. Зафіксуйте status, directives, canonical, ключовий контент і crawlable links до аналізу client-side app.
Baseline server response
- 1
Зафіксуйте status і headers
Запитайте точний canonical URL без залежності від browser state. Збережіть фінальний status після redirects і перевірте robots-related HTTP headers.
Шлях
Terminal → curl -I https://example.com/pathКритерійПотрібний indexable URL приходить на очікуваний final URL із коректним HTTP status; немає неочікуваного X-Robots-Tag, що блокує indexing.
- 2
Збережіть raw HTML body
Збережіть response body, щоб пізніше порівняти його з rendered output. Перевірте title, canonical, robots meta, H1/primary content і кілька representative internal links.
Шлях
Terminal → curl -sS https://example.com/path -o server.htmlКритерійSEO-сигнали, які архітектура має віддати через server rendering, дійсно присутні та коректні в server.html.
- 3
Звірте main document у DevTools
Відкрийте сторінку з уже активним DevTools, щоб cache не приховав first-load behavior. Виберіть main document і перегляньте Headers та Response.
Шлях
Chrome DevTools → Network → reload → [main document] → Headers / ResponseКритерійDevTools показує той самий final status та очікуваний initial HTML, що й незалежний curl capture.
- 4
За потреби повторіть із cold cache
Для intermittent hydration/bundle issues форсуйте first-load request замість діагностики кешованого успіху.
Шлях
Chrome DevTools → Network → long-press Reload → Empty Cache And Hard ReloadКритерійDocument, scripts і data успішно завантажуються на cold load без нового critical blocking failure.
Мінімальний capture server response
URL='https://example.com/products/42'
curl -sS -L -D response-headers.txt "$URL" -o server.html
printf '\nStatus chain and headers saved to response-headers.txt\n'
printf 'Raw response HTML saved to server.html\n'
# Spot checks; вони не замінюють повний аналіз HTML.
grep -i -m1 '<title' server.html || true
grep -i -m1 'rel="canonical"' server.html || true
grep -i -m1 'name="robots"' server.html || trueПотрібні curl і стандартні shell tools. Це capture evidence, а не DOM parser: client-generated content тут не з'явиться. Висновки треба звірити з rendered DOM і Google-rendered output.
04 · Відтворіть у браузері
Простежте, що саме було потрібно браузеру для побудови фінального DOM
Rendered DOM може виглядати коректно, але залежати від крихких API calls, state, blocked resources або script-only navigation. Зберігайте dependency chain разом із DOM evidence.
Browser-render checklist
- 1
Перевірте final DOM, а не тільки View Source
Знайдіть distinctive phrase з primary content, canonical link і кілька representative internal links після завершення роботи app.
Шлях
Chrome DevTools → Elements → Ctrl/Cmd+FКритерійCritical content і SEO elements існують у rendered DOM та не приховані за наступною user action.
- 2
Знайдіть request, що приніс відсутній контент
Якщо контенту немає в server HTML, але він з'являється пізніше, визначте API/data request та його Initiator. Перевірте status, response payload і залежність від auth, cookies чи client state.
Шлях
Chrome DevTools → Network → Fetch/XHR → [request] → Headers / Response / InitiatorКритерійRequired data request успішний на clean load і не потребує state, недоступного crawler-у.
- 3
Прочитайте runtime errors до зміни rendering architecture
Hydration mismatch, uncaught exception або blocked module можуть зупинити app до створення critical subtree.
Шлях
Chrome DevTools → ConsoleКритерійНемає uncaught error або failed critical dependency, що блокує main content, metadata чи links.
- 4
Відкрийте deep route як перший request
Не тестуйте тільки переходом із home. Завантажте deep URL напряму, адже краулери відкривають URL незалежно один від одного.
Шлях
New Incognito window → paste deep URL → open DevTools → reloadКритерійDeep route повертає коректний content/status без залежності від попереднього SPA state, localStorage чи cookies.
WRS не зберігає localStorage, sessionStorage та HTTP cookies між page loads. Якщо route стає повним лише після попереднього in-app переходу, звичайна browser session може приховувати crawler-visible bug. Representative routes потрібно тестувати як незалежні entry points.
05 · Звірте Google evidence
Перевірте Google-rendered output через URL Inspection і Rich Results Test
Browser parity необхідна, але недостатня. Google's rendering tools дають rendered HTML, resource evidence та JavaScript failures.
Перевірка Google render
- 1
Спочатку зафіксуйте indexed state
URL Inspection допомагає зрозуміти збережений/indexed стан і canonical/indexability signals для точного URL у вашій Search Console property.
Шлях
Search Console → URL Inspection → inspect URLКритерійЗафіксовані indexed state, last crawl evidence та canonical/indexability result до запуску fresh test.
- 2
Запустіть current live render
Запустіть live test і відкрийте tested-page evidence. Порівняйте distinctive content phrase, link targets, canonical/robots, screenshot та failed resources із browser baseline.
Шлях
Search Console → URL Inspection → Test Live URL → View tested page → HTML / ScreenshotКритерійGoogle live render містить critical content і crawlable links, а required first-party resources завантажуються без помилок.
- 3
Якщо немає property access — використайте Rich Results Test
Google у JavaScript troubleshooting guide рекомендує Rich Results Test як інший спосіб перевірити loaded resources, console output і rendered DOM. Structured data — не єдина причина застосовувати його під час rendering diagnosis.
Шлях
Rich Results Test → URL → Test URL → rendered-page detailsКритерійPublic Google render відтворює expected critical DOM або показує resource/console failure для подальшої перевірки.
06 · Локалізуйте root cause
Зіставте перше розходження з конкретною JavaScript SEO failure mode
Кожна причина має бути falsifiable hypothesis. Корисне питання не «JavaScript поганий для SEO?», а «який сигнал відсутній, на якому шарі і чому?».
Кастомна схема
Three-layer diff: де саме зник сигнал?
Порівняйте один critical signal у server HTML, browser DOM і Google-rendered HTML. Перший missing layer звужує набір можливих причин і визначає наступний тест.
| Симптом | Ймовірна причина | Тест | Рекомендований fix | Валідація |
|---|---|---|---|---|
| У server HTML лише app shell; у browser content є | CSR залежить від JavaScript + data fetch | Порівняти server.html, Elements і Google-rendered HTML | Зробити critical content надійно renderable; якщо dependency крихка — SSR/prerender/hybrid | Critical content є у Google-rendered HTML на representative routes |
| Links працюють по click, але crawler не знаходить destinations | Script-only navigation або anchor без href | Перевірити rendered DOM на <a href> | Віддавати реальні crawlable anchors; client routing — enhancement | Destination URLs присутні як href у rendered HTML |
| Browser page indexable; Google render показує noindex | Initial robots meta або X-Robots-Tag відрізняється | Перевірити raw response + headers до JS | Віддавати потрібний robots directive у initial response | Server і Google-rendered directives збігаються |
| Після hydration неправильний або multiple canonical | Client code мутує/додає conflicting canonical | Порівняти source head і rendered head | Prefer stable HTML canonical; якщо потрібен JS — лише одне стабільне значення | У rendered HTML рівно один intended canonical |
| Missing product повертає 200 app shell | Client-side soft 404 | Direct request до missing route + URL Inspection | Meaningful server status або real 404/noindex error state | Missing URL більше не виглядає як звичайна 200 content page |
| Below-fold content відсутній у Google render | Lazy loading чекає scroll/click | Google-rendered HTML + browser test без interaction | Завантажувати relevant content, коли він visible; не вимагати explicit user action | Content з'являється без click/scroll dependency |
| Deep route працює після навігації, але не direct load | App залежить від попередніх cookies/storage/session | Відкрити deep URL у fresh Incognito | Public crawlable content має бути self-contained для кожного URL | Fresh direct load рендерить той самий critical content |
| Google render ніби використовує старий JS | Aggressive crawler/WRS caching + assets без fingerprint | Порівняти requested asset URLs і deployed hashes | Content fingerprinting для versioned JS/CSS | Google test завантажує current asset version |
07 · Оберіть architecture свідомо
Оберіть CSR, SSR, prerendering або hybrid rendering із моделі failure
Rendering strategy — trade-off, а не ranking switch. Для SEO потрібен стабільний crawlable/indexable output; продукт також має latency, cacheability, server cost та interactivity constraints.
Google і далі радить server-side або pre-rendering, оскільки це швидше для users/crawlers і не всі bots виконують JavaScript. У документації dynamic rendering bot-specific rendering уже названий workaround, а не long-term solution; замість нього рекомендовані SSR, static rendering або hydration. Для hybrid app я б віддавав search-critical route state через SSR або prerendering, де це можливо, а client-side залишав hydration та enhancement.
Кастомна схема
Decision model для rendering strategy
Почніть із search-critical content та freshness requirements, а потім оберіть найпростішу модель, що робить initial route надійним і не ламає product constraints.
Практична модель trade-offs
- CSR: прийнятний, коли critical routes/content надійно рендеряться й indexation постійно перевіряється; server-side частина може бути простішою, але більше роботи переноситься у browser.
- SSR: доречний для public content, що часто змінюється або формується request-time, якщо server може повернути повний route state.
- Prerender/SSG: сильний варіант для public routes, які можна згенерувати build-time або revalidate за контрольованим cadence.
- Hybrid route-level rendering: high-value search routes можуть мати SSR/prerender, а app-only/authenticated zones залишатися client-rendered.
- Hydration: має коректно повторно використовувати server DOM; framework hydration mismatch — engineering problem і потенційний ризик availability content.
08 · Зафіксуйте implementation contract
Зробіть links, routes, status codes і hydration стійкими до direct crawl
Надійна реалізація — це коли кожен important URL є справжнім entry point із crawlable navigation, meaningful status та deterministic critical content.
Залиште SPA navigation crawlable через real anchors
<nav>
<a href="/products" data-route>Products</a>
<a href="/services" data-route>Services</a>
</nav>
<script type="module">
document.addEventListener('click', (event) => {
const link = event.target.closest('a[data-route]');
if (!link || event.metaKey || event.ctrlKey) return;
event.preventDefault();
const url = new URL(link.href);
window.history.pushState({}, '', url.pathname);
renderRoute(url.pathname);
});
</script>Illustrative framework-neutral pattern. Ключова SEO-вимога — real <a href>; History API enhancement не має скасовувати direct server handling для destination URL.
Приклад route-level rendering в Angular
import { RenderMode, ServerRoute } from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{ path: 'products/**', renderMode: RenderMode.Server },
{ path: 'guides/**', renderMode: RenderMode.Prerender },
{ path: 'account/**', renderMode: RenderMode.Client },
];Illustrative configuration за актуальною Angular SSR documentation. Реальний вибір залежить від data freshness, auth, deployment і caching. Перед production-copy перевірте exact API для вашої встановленої Angular version.
Implementation checks проти повторних regressions
- Повертайте meaningful HTTP status. Missing SPA route, який завжди отримує нормальний 200 shell, може створити soft-404 problem.
- Тримайте один consistent canonical. Краще в server HTML; hydration не має створювати conflicting second canonical.
- Не віддавайте indexable routes з initial noindex, який JavaScript потім намагається прибрати.
- Використовуйте content-hashed JS/CSS filenames, щоб новий release мав нову asset URL і не залежав від stale crawler cache.
- Не вимагайте localStorage, sessionStorage чи cookies із попереднього page load для public crawlable content.
- Для Angular hydration зберігайте expected server/client DOM structure; current Angular docs прямо вимагають matching DOM structure.
09 · Закрийте validation loop
Перевірте fix на representative routes і перетворіть його на release regression test
One-URL live test недостатній для template-level change. Валідуйте різні route types, зберігайте artifacts і контролюйте ті самі invariants після releases.
Release acceptance sequence
- 1
Повторіть тест на URL, де був failure
Запустіть той самий server capture, browser DOM check і Google live render, якими було доведено initial failure. За можливості змінюйте одну hypothesis за раз.
Шлях
curl + Chrome DevTools + Search Console URL InspectionКритерійРаніше missing critical signal присутній на всіх required layers і не з'явився новий directive/status mismatch.
- 2
Візьміть sample кожного rendering/template class
Перевірте хоча б один fresh direct URL для кожного суттєво іншого route mode/template: SSR, prerendered, CSR-only, parameterized та error routes, якщо вони є.
Шлях
Release QA matrix → route class → representative URLsКритерійКожен route class проходить однакові content, link, status, canonical і robots acceptance rules.
- 3
Моніторте crawl/indexation після release
Використовуйте Search Console crawl/indexation reporting і, якщо доступно, verified server/edge logs. Client analytics сам по собі не є повним журналом Googlebot/WRS activity.
Шлях
Search Console → Settings → Crawl stats; Page indexing; server/edge logsКритерійУ monitored segment немає release-linked spike у fetch errors, unintended exclusions або втрати discovery priority routes.
Практичний принцип: rendering вважається перевіреним, коли один search-critical contract витримує independent HTTP fetch, clean browser render і Google render — а не коли framework demo виглядає правильно. Якщо три стани збігаються, переходьте до indexation та quality signals. Якщо ні — збережіть diff і виправляйте найраніший failing layer.
Першоджерела та документація
Джерела
Кожне змінне твердження про пошукову систему, браузер, інтерфейс або технічну поведінку в матеріалі прив’язане до актуального першоджерела.
- Google Search Central Основи JavaScript SEO (відкриється в новій вкладці)Актуальна документація Google; оновлено 4 березня 2026 року.
- Google Search Central Діагностика JavaScript-проблем у Google Search (відкриється в новій вкладці)
- Google Search Central Вимоги Google до crawlable links (відкриється в новій вкладці)
- Google Search Central Коректне lazy-loading для Google Search (відкриється в новій вкладці)
- Google Search Central Dynamic rendering як workaround (відкриється в новій вкладці)
- Google Search Console Help URL Inspection tool (відкриється в новій вкладці)Назви елементів інтерфейсу варто повторно перевіряти перед майбутніми оновленнями статті.
- Google Crawling Infrastructure Огляд crawler/fetcher інфраструктури Google (відкриється в новій вкладці)Актуальна документація crawling infrastructure; оновлено 12 червня 2026 року.
- Chrome for Developers Inspect network activity (відкриється в новій вкладці)
- Chrome for Developers Get started with viewing and changing the DOM (відкриється в новій вкладці)
- Chrome for Developers Console overview (відкриється в новій вкладці)
- Angular Server-side and hybrid-rendering (відкриється в новій вкладці)
- Angular Hydration (відкриється в новій вкладці)
Потрібна допомога з діагностикою та впровадженням?
Перетворіть rendering symptom на відтворюваний engineering backlog
Metricum Lab може простежити crawl, server-response, rendering та indexation evidence для representative route types і перетворити findings на пріоритизовані fixes з acceptance criteria та post-release verification.
Переглянути Technical SEO services