Googlebot potrafi uruchamiać JavaScript — to fakt potwierdzony przez sam Google w 2019 roku. Problem w tym, że „potrafi" nie znaczy „robi to natychmiast i bezbłędnie". Między pierwszym crawlem a pełnym renderowaniem strony opartej na JS może minąć od kilku godzin do kilku dni. W tym czasie Google widzi pustą stronę lub szczątkowy HTML, co oznacza jedno: treść nie trafia do indeksu wtedy, gdy powinna. Z własnego doświadczenia przy audytach stron SPA widzimy, że opóźnienie renderowania potrafi przesunąć indeksację nowych podstron nawet o 7-10 dni w porównaniu z klasycznymi stronami HTML. Ten artykuł pokazuje, jak rozwiązać ten problem i sprawić, by dynamiczne strony rankingowały tak samo dobrze jak statyczne.
Z naszego artykułu dowiesz się:
Jak Googlebot przetwarza strony oparte na JavaScript
Proces indeksowania stron z JavaScript składa się z dwóch odrębnych faz. Pierwsza to crawl — Googlebot pobiera surowy HTML zwrócony przez serwer. Druga to rendering — Chromium-based renderer (Web Rendering Service, WRS) uruchamia JavaScript i generuje pełny DOM. Między tymi fazami istnieje kolejka renderowania, której długość zależy od zasobów Google.
Kolejka renderowania i jej wpływ na indeksację
W przypadku klasycznych stron HTML obie fazy zachodzą praktycznie jednocześnie — crawler pobiera gotową treść i od razu ją indeksuje. Przy stronach SPA zbudowanych w React, Vue czy Angular sytuacja wygląda inaczej. Surowy HTML często zawiera tylko pusty div z identyfikatorem „root" i odniesienie do bundla JS. Cała treść powstaje dopiero po wykonaniu skryptów.
Google przyznaje, że WRS działa na Chromium w wersji evergreen (aktualnej), ale nie udostępnia publicznie danych o średnim czasie oczekiwania w kolejce. Z testów przeprowadzanych przez specjalistów SEO w 2024 roku wynika, że opóźnienie wynosi od kilku sekund do kilku dni — zależnie od wielkości witryny i jej crawl budgetu. Dla serwisu z 50 podstronami różnica może być niezauważalna. Przy 50 000 stron produktowych opóźnienie staje się realnym problemem biznesowym.
Czego WRS nie obsługuje podczas renderowania
Mimo że Web Rendering Service bazuje na aktualnym Chromium, ma istotne ograniczenia. Nie obsługuje interakcji użytkownika — nie klika przycisków „Pokaż więcej", nie scrolluje strony, nie wypełnia formularzy. Treści ładowane dopiero po interakcji (lazy loading wyzwalany scrollem, infinite scroll, treść za tabami) pozostają niewidoczne dla Google.
Czas na wykonanie JS jest ograniczony. Jeśli skrypty potrzebują więcej niż kilka sekund na wyrenderowanie treści, WRS może przerwać rendering i zaindeksować niekompletną wersję strony. Przy audytach spotykamy się z sytuacjami, gdzie ciężkie biblioteki analityczne lub widgety third-party wydłużają czas renderowania o 3-4 sekundy, blokując zaindeksowanie właściwej treści.
Server-Side Rendering kontra Client-Side Rendering w kontekście SEO
Wybór strategii renderowania to najważniejsza decyzja architektoniczna wpływająca na js seo. Każde podejście ma konkretne konsekwencje dla widoczności w wyszukiwarce.
| Strategia | Opis | Czas do indeksacji | Złożoność wdrożenia | |
| CSR (Client-Side Rendering) | JS generuje HTML w przeglądarce | Zależny od kolejki WRS | Niska | |
| SSR (Server-Side Rendering) | Serwer zwraca gotowy HTML | Natychmiastowa | Średnia-wysoka | |
| SSG (Static Site Generation) | HTML generowany w build time | Natychmiastowa | Średnia | |
| ISR (Incremental Static Regeneration) | Hybrydowe SSG z odświeżaniem | Natychmiastowa | Średnia |
Dla stron, gdzie SEO jest priorytetem — a w e-commerce, wydawnictwach i serwisach ogłoszeniowych zawsze jest — rekomendujemy SSR lub SSG jako bazową strategię. CSR sprawdza się w panelach administracyjnych, dashboardach i aplikacjach za logowaniem, gdzie indeksacja nie ma znaczenia.
Przy react seo popularnym rozwiązaniem jest Next.js, który oferuje SSR, SSG i ISR w jednym frameworku. Vue.js ma analogiczny Nuxt.js, Angular — Angular Universal. Te narzędzia rozwiązują problem renderowania javascript google na poziomie architektury, eliminując zależność od WRS.
Dynamic rendering jako rozwiązanie przejściowe dla istniejących aplikacji SPA
Nie każdy projekt może sobie pozwolić na migrację z CSR na SSR. Przebudowa dużej aplikacji SPA to miesiące pracy i setki tysięcy złotych. W takich przypadkach dynamic rendering oferuje pragmatyczne rozwiązanie, które Google oficjalnie uznaje za akceptowalne (choć nie zalecane jako docelowe).
Mechanizm działa następująco: serwer wykrywa, czy request pochodzi od bota (na podstawie user-agenta), i zwraca mu wstępnie wyrenderowany HTML. Zwykli użytkownicy otrzymują standardową wersję CSR. To nie jest cloaking — Google wyraźnie odróżnia dynamic rendering od ukrywania treści, pod warunkiem że bot i użytkownik widzą tę samą zawartość, tylko w innej formie technicznej.
Do implementacji dynamic rendering służą narzędzia takie jak Rendertron (open-source od Google) czy Prerender.io (komercyjne SaaS). Konfiguracja sprowadza się do dodania middleware na serwerze, który przekierowuje requesty botów do usługi prerenderującej.
Warto pamiętać, że Google traktuje dynamic rendering jako rozwiązanie tymczasowe. W dokumentacji Search Central pojawiło się w 2023 roku sformułowanie sugerujące, że długoterminowo rekomendowaną ścieżką jest SSR. Przy planowaniu roadmapy warto traktować dynamic rendering jako most do pełnej migracji, nie jako cel sam w sobie.
Audyt spa seo — jak sprawdzić, czy Google widzi treść Twojej strony
Zanim zdecydujesz się na konkretne rozwiązanie, musisz zdiagnozować aktualny stan. Wiele zespołów deweloperskich zakłada, że skoro strona działa w przeglądarce, to Google też ją widzi. To błędne założenie — testowaliśmy dziesiątki aplikacji SPA, gdzie indeks Google zawierał mniej niż 30% rzeczywistej treści.
Narzędzie „Sprawdź URL" w Google Search Console
Najszybszy test to wpisanie adresu w Search Console i porównanie dwóch widoków: „Wyświetlony kod HTML" oraz zrzut ekranu renderowanej strony. Jeśli w wyrenderowanym HTML brakuje treści widocznej w przeglądarce, masz problem z renderowaniem javascript google. Zwracaj uwagę na elementy ładowane dynamicznie — recenzje produktów, opisy kategorii, filtry z treścią.
Test z wyłączonym JavaScript
Otwórz stronę w Chrome z wyłączonym JS (DevTools → Settings → Disable JavaScript). To, co widzisz, to z grubsza odpowiednik tego, co Googlebot pobiera w pierwszej fazie crawlu. Jeśli strona jest pusta lub wyświetla tylko loader — treść jest całkowicie zależna od renderowania po stronie klienta.
Innym cennym narzędziem jest Mobile-Friendly Test od Google, który pokazuje wyrenderowany HTML po przetworzeniu JS. Porównaj wynik z kodem źródłowym (Ctrl+U w przeglądarce). Różnice między tymi dwoma wersjami wskazują dokładnie, które elementy wymagają przeniesienia do SSR lub objęcia dynamic renderingiem.
Optymalizacja JavaScript pod crawl budget i szybkość renderowania
Nawet przy wdrożonym SSR nadmiarowy lub źle zoptymalizowany JavaScript potrafi obniżyć efektywność indeksowania. Googlebot ma ograniczony crawl budget dla każdej witryny — im więcej zasobów musi pobrać i przetworzyć, tym mniej stron zaindeksuje w jednostce czasu.
Redukcja rozmiaru bundla JS to pierwszy krok. Przy audytach react seo regularnie spotykamy bundle przekraczające 500 KB po gzipie, gdzie po analizie tree-shakingu i usunięciu nieużywanych zależności udaje się zejść do 180-220 KB. Narzędzia takie jak Webpack Bundle Analyzer czy Lighthouse pozwalają zidentyfikować największe moduły.
Canonical tagi, meta roboty i dane strukturalne (schema.org) powinny znajdować się w początkowym HTML zwracanym przez serwer, nie być wstrzykiwane przez JavaScript. Googlebot przetwarza te elementy w pierwszej fazie crawlu, przed renderowaniem. Jeśli zależą od JS, mogą zostać pominięte.
Osobną kwestią są mapy witryn XML. Przy dużych aplikacjach SPA sitemap to jedyny pewny sposób, by poinformować Google o wszystkich URL-ach. Generuj ją automatycznie z bazy danych lub CMS-a, aktualizuj co najmniej raz dziennie i zgłoś w Search Console. Dla serwisów z ponad 10 000 URL-i zalecamy podział na mniejsze pliki sitemap po maksymalnie 10 000 adresów każdy, połączone indeksem sitemap.
Renderowanie dynamicznych stron dla Google to problem, który ma jasne rozwiązania techniczne. SSR eliminuje go u źródła, dynamic rendering łagodzi skutki przy istniejących aplikacjach, a systematyczny audyt pozwala wychwycić luki zanim wpłyną na pozycje. Niezależnie od wybranej ścieżki, regularne sprawdzanie stanu indeksacji w Search Console powinno stać się stałym elementem procesu — algorytmy Google i możliwości WRS ewoluują, a to co działało w 2024 roku, może wymagać korekty w 2026.
