JavaScript SEO — co naprawdę widzą Googlebot i crawlery AI bez renderowania

Krótka, uczciwa odpowiedź na 2026 rok brzmi tak: Google potrafi renderować JavaScript, ale robi to z opóźnieniem i na własny koszt — a większość crawlerów AI nie robi tego wcale. Badanie Vercela na próbie setek milionów żądań pokazało, że GPTBot, ClaudeBot i PerplexityBot pobierają pliki JavaScript, ale ich nie wykonują. Jeśli kluczowa treść Twojej strony powstaje dopiero w przeglądarce, to dla ChatGPT, Claude'a i Perplexity ta treść nie istnieje. W erze, w której coraz więcej researchu zaczyna się od pytania do modelu, „pusta skorupa HTML" przestała być problemem czysto technicznym — to problem widoczności biznesu.

Googlebot renderuje JavaScript — z opóźnieniem i na własny koszt. Większość crawlerów AI nie renderuje go wcale: badanie Vercela pokazało, że GPTBot, ClaudeBot i PerplexityBot pobierają pliki JS, ale ich nie wykonują. Jak w 5 minut sprawdzić, co boty naprawdę widzą, czym różni się CSR od SSR/SSG/ISR i jak naprawić SPA bez przepisywania całej aplikacji.

Ten przewodnik pokazuje, jak naprawdę wygląda przetwarzanie JavaScriptu przez boty, jak w 5 minut sprawdzić, co widzą na Twojej stronie, i jak dobrać strategię renderowania (CSR/SSR/SSG/ISR) bez przepisywania całej aplikacji.

Jak Google przetwarza JavaScript — trzy etapy zamiast jednego

Dla zwykłej strony HTML proces jest prosty: Googlebot pobiera dokument i przekazuje go do indeksowania. Dla strony opartej na JavaScripcie dochodzi trzeci, kosztowny etap — renderowanie:

Googlebot najpierw pobiera surowy HTML i indeksuje to, co w nim znajdzie. Strona trafia potem do kolejki renderowania — Web Rendering Service, czyli w praktyce aktualnego Chromium, który wykonuje JavaScript i buduje pełny DOM. Dopiero ten wyrenderowany HTML wraca do indeksowania. Google deklaruje, że mediana czasu oczekiwania jest krótka, ale kolejka jest współdzielona i priorytetyzowana: przy dużych serwisach opóźnienie potrafi rosnąć do godzin, a nawet dni. Renderowanie jest też po prostu drogie — i wlicza się w crawl budget, więc serwis, który każdą podstronę każe renderować od zera, sam sobie dławi indeksację.

Wniosek praktyczny: nawet w „przyjaznym" scenariuszu Google treść zależna od JavaScriptu jest indeksowana później i mniej niezawodnie niż treść obecna w surowym HTML.

Crawlery AI nie wykonują JavaScriptu — i to się szybko nie zmieni

Tu kończy się teoria z dokumentacji Google, a zaczyna nowa rzeczywistość. Vercel przeanalizował ruch botów AI na swojej infrastrukturze (setki milionów żądań miesięcznie) i wnioski są jednoznaczne:

• GPTBot i OAI-SearchBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot — pobierają pliki JS, ale ich nie wykonują. Widzą wyłącznie to, co serwer zwraca w pierwszej odpowiedzi HTML.
• Gemini korzysta z infrastruktury Googlebota (WRS), więc jako jedyny z dużych graczy dostaje wyrenderowaną treść.
• Bingbot (zasilający Copilota) deklaruje ograniczone renderowanie — w praktyce nie należy na nim polegać.

Konsekwencje są brutalne dla klasycznych SPA: aplikacja React/Vue/Angular, która zwraca botom pusty div i buduje treść klientem, jest dla wyszukiwarek AI niewidzialna. To samo dotyczy elementów wstrzykiwanych JavaScriptem: meta tagów, canonicali i danych strukturalnych Schema.org — jeśli dokleja je dopiero przeglądarka, boty AI nigdy ich nie zobaczą. A skoro modele nie widzą treści, nie ma czego cytować — cała strategia obecności w odpowiedziach ChatGPT zaczyna się od renderowania.

CSR, SSR, SSG, ISR — którą strategię wybrać

Cztery strategie renderowania różnią się jednym: kto i kiedy buduje HTML.

Dobra wiadomość: to nie jest wybór „wszystko albo nic". Nowoczesne frameworki (Next.js, Nuxt, Astro, SvelteKit) pozwalają mieszać strategie per szablon: blog jako SSG, karty produktów jako ISR, koszyk jako CSR. Rozsądny domyślny podział na 2026 rok brzmi: każda treść publiczna, na której Ci zależy w wyszukiwaniu — HTML z serwera; interakcje — JavaScript. Hydration (dołączenie interaktywności do gotowego HTML) nie szkodzi SEO, o ile HTML jest kompletny zanim JavaScript wystartuje.

Test w 5 minut: co naprawdę widzi bot

Nie musisz wierzyć na słowo — sprawdź:

1. 1.Wyłącz JavaScript w DevTools (Ctrl+Shift+P → „Disable JavaScript") i odśwież stronę. To, co widzisz, to wersja dla botów AI. Brakuje treści, cen, opisów? Masz problem.
2. 2.Porównaj view-source z DOM. „Pokaż źródło strony" to surowy HTML (widzą go wszyscy), zakładka Elements to DOM po JavaScripcie (widzi go głównie Google — po renderowaniu).
3. 3.Pobierz stronę jak bot. Jedno polecenie w terminalu pokazuje, czy kluczowa fraza jest w pierwszej odpowiedzi serwera:

# Czy tytuł oferty jest w surowym HTML?curl -s -A "GPTBot" https://twojastrona.pl/oferta | grep -i "nazwa uslugi"# Ile znaków treści zwraca serwer bez JS?curl -s https://twojastrona.pl/ | wc -c

1. 1.Inspekcja URL w Google Search Console. Zobacz wyrenderowany HTML i zrzut ekranu oczami Googlebota — różnice między nim a przeglądarką to sygnał ostrzegawczy. Jeśli strona wygląda dobrze w GSC, ale w teście bez JavaScriptu jest pusta, to znaczy: Google sobie poradzi, boty AI nie.

Siedem typowych wpadek SPA

Z audytów wynika, że problemy powtarzają się w kółko — te same siedem grzechów:

1. 1.Treść dopiero po interakcji. Taby, akordeony i sekcje dogrywane po kliknięciu nie istnieją dla botów. Treść ma być w DOM od razu (może być zwinięta wizualnie).
2. 2.Infinite scroll bez paginacji. Bot nie scrolluje. Bez klasycznych linków do kolejnych stron produkty z „dalszych ekranów" są nieosiągalne.
3. 3.Metadane ustawiane klientem. Title, description i canonical wstrzykiwane JavaScriptem — boty AI ich nie zobaczą, a Google może zaindeksować wersję sprzed podmiany.
4. 4.Schema.org doklejana w przeglądarce. Dane strukturalne muszą być w HTML z serwera — inaczej tracisz 3× wyższą cytowalność w AI, którą dają.
5. 5.Zablokowane pliki JS/CSS w robots.txt. Google nie wyrenderuje strony, jeśli zablokowałeś mu zasoby. Audyt dostępów opisuję we wpisie o crawlerach AI i robots.txt.
6. 6.Lazy-loading bez fallbacku. Obrazy i treści ładowane wyłącznie po zdarzeniach scrolla (bez natywnego loading="lazy" albo noscript) dla botów nie istnieją.
7. 7.Soft 404. SPA zwraca status 200 dla nieistniejących adresów i renderuje „nie znaleziono" klientem. Bot indeksuje śmieci albo — gorzej — duplikaty.

Nasz przypadek: Smart SPA Fallback w PozyczkoBanku

Że da się to rozwiązać bez wyrzucania aplikacji do kosza, pokazuje projekt PozyczkoBank: serwis działał jako SPA, więc dla botów był w praktyce pusty. Zamiast kosztownego przepisania całości wdrożyliśmy architekturę Smart SPA Fallback — boty i pierwsze wejścia dostają pełny, wyrenderowany serwerowo HTML, a użytkownik po hydration korzysta z aplikacji jak wcześniej. Efekt: treści (w tym generowane automatycznie przez pipeline z Gemini) są indeksowalne od pierwszego żądania, bez zmiany doświadczenia użytkownika.

Plan naprawczy krok po kroku

1. 1.Zinwentaryzuj szablony, nie pojedyncze strony: strona główna, kategoria, karta produktu/usługi, wpis blogowy, strona statyczna.
2. 2.Przetestuj każdy szablon bez JavaScriptu (metody wyżej) i oznacz: pełna treść / częściowa / pusta skorupa.
3. 3.Ustal priorytety po pieniądzach. Najpierw szablony, które zarabiają: oferta, karty produktów, treści pozyskujące ruch.
4. 4.Dobierz strategię per szablon: treści stabilne → SSG, często zmienne → ISR/SSR, panel klienta → zostaje CSR.
5. 5.Przenieś metadane i schema na serwer — title, description, canonical, JSON-LD w pierwszej odpowiedzi HTML.
6. 6.Zweryfikuj efekt: inspekcja URL w GSC, test curl, a po tygodniach — statystyki indeksowania i logi serwera.
7. 7.Pilnuj wydajności. SSR zwykle poprawia LCP, ale hydration potrafi zepsuć INP — po wdrożeniu sprawdź Core Web Vitals.

---

Projektuję architektury renderowania stron i aplikacji, które są szybkie dla ludzi i czytelne dla botów, a audyt renderowania robię w ramach technicznego SEO. Napisz do mnie — w pierwszym kroku sprawdzę, co z Twojej strony naprawdę widzą Google i crawlery AI.

Warto przeczytać dalej:

• Crawlery AI — kto skanuje Twoją stronę i jak tym zarządzać
• Core Web Vitals — jak poprawić LCP, INP i CLS
• Crawl budget — jak Google indeksuje dużą stronę
• Dane strukturalne Schema.org — kompletny przewodnik