JavaScript SEO - co Googlebot i crawlery AI widzą na stronie bez renderowania

Google renderuje JavaScript od blisko dekady i robi to na tyle sprawnie, że temat zdążył zniknąć z listy priorytetów większości zespołów. Wraca teraz z innej strony. Vercel przeanalizował ruch botów AI na własnej infrastrukturze - setki milionów żądań - i okazało się, że GPTBot, ClaudeBot i PerplexityBot pobierają pliki JavaScript, ale ich nie wykonują. Treść, która powstaje dopiero w przeglądarce, dla ChatGPT, Claude'a i Perplexity nie istnieje. Serwis oparty na React czy Vue może mieć bardzo dobre pozycje w Google i jednocześnie być zupełnie nieobecny w odpowiedziach modeli - bo jedyne, co silniki AI z niego widzą, to pusty kontener i loader.

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.

Poniżej opisuję, jak Google faktycznie przetwarza JavaScript, jak sprawdzić, co boty widzą na konkretnej stronie, i według jakiego klucza 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ę.

W praktyce: nawet u Google, które renderować potrafi, treść zależna od JavaScriptu indeksuje się później i mniej niezawodnie niż ta obecna w surowym HTML.

Crawlery AI nie wykonują JavaScriptu

O ile Google zbudowało pod renderowanie całą infrastrukturę, o tyle dostawcy AI poszli na skróty. Dane Vercela nie zostawiają tu pola do interpretacji:

• 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) potrafi renderować JavaScript, ale nie robi tego przy każdym pobraniu ani tak niezawodnie jak Google - w praktyce nie należy na tym polegać.

Dla klasycznego SPA rachunek jest prosty: aplikacja React/Vue/Angular, która zwraca botom pusty div i buduje treść po stronie klienta, 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.

Nie jest to przy tym 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. Sensowny podział domyślny: 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

Zamiast polegać na zapewnieniach dokumentacji frameworka, sprawdź na własnej stronie:

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. 4.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

W audytach wracają wciąż te same błędy - na tyle regularnie, że można je spisać z pamięci:

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. Od grudnia 2025 dokumentacja Google mówi to wprost: do renderowania trafiają strony ze statusem 200, a strony z innym kodem mogą je pominąć. SPA musi więc zwracać prawdziwy status HTTP z serwera, a nie „udawać" 404 w JavaScripcie.

Nasz przypadek: Smart SPA Fallback w PozyczkoBanku

Z dokładnie takim problemem mierzyliśmy się w projekcie 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ć
• Przeglądarki AI i Agent Experience (AX) - czy agent poradzi sobie na Twojej stronie?
• Core Web Vitals - jak poprawić LCP, INP i CLS
• Crawl budget - jak Google indeksuje dużą stronę
• Dane strukturalne Schema.org - kompletny przewodnik