Boty AI takie jak GPTBot, ClaudeBot czy PerplexityBot pobierają surowy HTML i na tym kończą. Nie uruchamiają skryptów, nie czekają na hydratację, nie klikają zakładek. Jeśli kluczowa treść serwisu powstaje dopiero w przeglądarce, dla modeli językowych ta strona jest pusta, choć w Google może rankować bez zarzutu. Temat JavaScript a boty AI (renderowanie) sprowadza się więc do jednego pytania: co zostaje w odpowiedzi serwera, zanim odpali się pierwszy skrypt.
W skrócie:
- Googlebot renderuje JavaScript w drugiej fazie (Web Rendering Service), crawlery AI tej fazy nie mają.
- Analiza ruchu Vercel z końca 2024 roku (setki milionów żądań) nie wykazała ani jednego crawlera AI wykonującego skrypty.
- Test jest prosty:
curlbez nagłówków przeglądarki albo Chrome z wyłączonym JS pokazuje dokładnie to, co widzi GPTBot. - Rozwiązania w kolejności kosztu: prerendering wybranych podstron, SSR dla szablonów treści, pełna migracja frameworka na końcu.
- Zakładki, akordeony i nieskończone przewijanie to trzy miejsca, gdzie treść najczęściej znika.
Czym różni się crawler AI od Googlebota
Googlebot pracuje dwuetapowo: najpierw pobiera HTML i indeksuje to, co w nim jest, a potem trafia z adresem do kolejki renderowania, gdzie bezgłowa wersja Chromium wykonuje skrypty i oddaje pełny DOM. Google opisuje ten proces w dokumentacji Search Central, zaznaczając, że renderowanie może nastąpić z opóźnieniem liczonym w dniach.
GPTBot, opisany w dokumentacji OpenAI, pomija drugi etap. Pobiera dokument, parsuje HTML, wyciąga tekst i linki, po czym idzie dalej. To samo dotyczy ClaudeBota (Anthropic), PerplexityBota i Bytespidera.
Konsekwencja jest brutalna: w Google strona oparta na Reakcie z klientowym pobieraniem danych może wyglądać normalnie, a w cytowaniach ChatGPT czy Perplexity nie pojawi się nigdy. Ten mechanizm opisaliśmy szerzej w przeglądzie SEO technicznego 2026: rendering, hreflang i schema dla LLM, tutaj skupiamy się wyłącznie na warstwie JavaScriptu.
| Cecha | Googlebot | GPTBot / ClaudeBot / PerplexityBot |
|---|---|---|
| Wykonuje JavaScript | Tak, w kolejce renderowania | Nie |
| Czeka na żądania XHR/fetch | Tak, do limitu czasu | Nie |
| Widzi treść po kliknięciu | Nie (bez interakcji) | Nie |
Czyta noscript |
Częściowo | Tak, jako zwykły HTML |
| Respektuje robots.txt | Tak | Tak (deklarowane przez OpenAI i Anthropic) |
Jak sprawdzić treść widzianą bez JavaScriptu
Najszybszy test zajmuje kilkanaście sekund i nie wymaga żadnego narzędzia SEO. W terminalu wystarczy curl -s -A "GPTBot/1.2" https://domena.pl/adres/ | grep -c "słowo z treści". Jeśli wynik to zero, a słowo widać w przeglądarce, treść powstaje po stronie klienta.
Drugi sposób to Chrome: DevTools, polecenie „Disable JavaScript” (Ctrl+Shift+P), odświeżenie strony. To, co zostaje na ekranie, jest dokładnie tym, co odczyta crawler AI. Trzeci, dla osób nietechnicznych, to widok źródła strony (Ctrl+U) i wyszukanie fragmentu akapitu, którego cytowania oczekujemy.
Uwaga na pułapkę: narzędzie Google „Sprawdzenie adresu URL” pokazuje HTML po renderowaniu, więc nie nadaje się do tego audytu. Ono odpowiada na pytanie, co widzi Google, nie GPTBot. Różnica między tymi dwoma zrzutami to w praktyce lista rzeczy do naprawy.
SSR, prerendering i hydratacja w praktyce
Do wyboru są trzy podejścia, każde z innym kosztem wdrożenia i innym efektem ubocznym. Wspólny mianownik: pełny tekst artykułu, nagłówki i linki wewnętrzne mają być w pierwszej odpowiedzi serwera.
| Podejście | Jak działa | Koszt wdrożenia | Kiedy ma sens |
|---|---|---|---|
| Prerendering statyczny | Serwer zapisuje gotowy HTML w czasie budowania lub na żądanie i serwuje go botom | Niski (usługa lub wtyczka) | Serwis treściowy, rzadkie zmiany, szybki efekt |
| SSR (renderowanie po stronie serwera) | Każde żądanie generuje HTML z danymi, klient tylko dokłada interakcje | Średni do wysokiego | Treść dynamiczna, framework z obsługą SSR (Next.js, Nuxt, Astro) |
| Dynamiczne renderowanie | Bot dostaje wersję z bezgłowej przeglądarki, użytkownik zwykłą aplikację | Średni, wymaga utrzymania | Tymczasowo, dla starych aplikacji SPA |
Hydratacja to moment, w którym klientowy JavaScript przejmuje statyczny HTML z serwera i dokłada zdarzenia. Dla bota AI hydratacja nie ma znaczenia, bo on jej nie doczeka. Ma znaczenie to, czy HTML sprzed hydratacji jest kompletny. Częsty błąd: szablon SSR renderuje szkielet strony z komunikatem „Ładowanie…”, a treść dociąga dopiero komponent kliencki. Technicznie to SSR, w praktyce bot widzi trzy słowa.
Google w 2024 roku wycofało dynamiczne renderowanie z listy zalecanych rozwiązań i traktuje je jako obejście. Dla crawlerów AI nadal działa, bo one rozpoznają się po User-Agent. Jeśli wybieracie tę drogę, upewnijcie się, że obie wersje mają identyczną treść, inaczej ryzykujecie zarzut maskowania (cloakingu).
Treści doładowywane po kliknięciu: zakładki i akordeony
Zakładki produktowe („Opis”, „Specyfikacja”, „Opinie”), sekcje FAQ w akordeonie i przyciski „Czytaj więcej” to trzy najczęstsze miejsca, w których znika treść. Jeżeli zawartość zakładki jest w HTML i tylko ukryta przez CSS, bot ją odczyta. Jeżeli pobiera się dopiero po kliknięciu (żądanie fetch do API), dla GPTBota nie istnieje.
Test polega na wyszukaniu w źródle strony tekstu z drugiej zakładki. Rozwiązanie: elementy details i summary zamiast akordeonów sterowanych JavaScriptem. Przeglądarka obsługuje je natywnie, treść jest w HTML od pierwszego bajta, a wygląd da się ostylować bez skryptów. Dokładnie ten wzorzec stosujemy w sekcjach FAQ na tym serwisie.
Osobny problem to dane strukturalne generowane skryptem. Jeśli JSON-LD wstrzykuje Google Tag Manager albo komponent kliencki, crawler AI nie zobaczy schematu Article ani FAQPage. Porównanie form zapisu i argumenty za JSON-LD w kodzie serwera zebraliśmy w tekście o tym, która forma danych strukturalnych działa dla LLM.
Nieskończone przewijanie i paginacja
Nieskończone przewijanie (infinite scroll) dokłada kolejne wpisy w reakcji na zdarzenie przewinięcia. Crawler AI nie przewija, więc widzi tylko pierwszą porcję, zwykle 10–20 elementów. Reszta archiwum, a wraz z nią linki do starszych artykułów, pozostaje niewidoczna.
Poprawka nie wymaga rezygnacji z przewijania dla ludzi. Wystarczy, aby każda porcja miała własny adres (?page=2, /strona/3/) obecny w HTML jako zwykły link a href, a nie przycisk obsługiwany skryptem. Nagłówki link rel="next" Google ignoruje od 2019 roku, ale zwykły link w treści działa dla wszystkich botów bez wyjątku.
Warto też sprawdzić listingi kategorii w sklepach: filtry i sortowanie często przebudowują listę produktów przez JavaScript, a pierwotny HTML zawiera pustą siatkę. W efekcie Perplexity, zapytane o produkty w danej kategorii, cytuje konkurenta z klasycznym listingiem serwerowym.
Szybki audyt na pięciu podstronach
Pełny audyt renderowania dużego serwisu to praca na dni. Wersja wstępna, która wyłapuje 80% problemów, mieści się w godzinie i obejmuje pięć reprezentatywnych adresów: stronę główną, listing kategorii, pojedynczy artykuł lub produkt, stronę z FAQ oraz podstronę z najwyższym ruchem organicznym.
- Pobierzcie każdy adres przez
curlz User-Agentem GPTBot i zapiszcie odpowiedź do pliku. - Policzcie słowa w tekście po usunięciu znaczników i porównajcie z liczbą słów widoczną w przeglądarce. Różnica powyżej 20% oznacza problem.
- Sprawdźcie obecność nagłówków
h1ih2w surowym HTML, bo to na nich modele opierają rozumienie struktury. - Wyszukajcie blok
application/ld+jsonw odpowiedzi serwera, nie w DOM po renderowaniu. - Policzcie linki wewnętrzne
a hrefw surowej odpowiedzi i zestawcie z liczbą w DevTools.
Wynik zapiszcie w prostej tabeli: adres, słowa w HTML, słowa w DOM, nagłówki, schema, linki. Jeśli najwięcej brakuje na artykułach, sprawdźcie, czy nie kwalifikują się do wyświetlania w polach źródeł AI Overviews, co opisujemy w analizie anatomii source boxa Google AI.
Najczęstsze błędy
- Audyt tylko w narzędziach Google. Sprawdzenie adresu URL i Test wyników z elementami rozszerzonymi pokazują wersję po renderowaniu, która dla botów AI jest fikcją.
- SSR szkieletu bez danych. Serwer oddaje układ strony, treść pobiera komponent kliencki. Wykrywa to test na liczbę słów.
- Blokowanie GPTBota w robots.txt „na wszelki wypadek”. Domyślne reguły części wtyczek bezpieczeństwa i CDN odcinają boty AI, zanim ktokolwiek sprawdzi renderowanie.
- Schema przez Tag Managera. JSON-LD wstrzykiwany skryptem nie istnieje dla crawlerów bez silnika JS.
- Lazy loading tekstu. Leniwe ładowanie ma sens dla obrazów, nie dla akapitów i sekcji FAQ.
FAQ: JavaScript a boty AI
Czy GPTBot w ogóle wykonuje JavaScript?
Nie. GPTBot pobiera HTML i pliki statyczne, ale nie uruchamia skryptów ani nie czeka na żądania API wykonywane przez przeglądarkę. Potwierdzają to obserwacje logów serwerowych i analizy ruchu z 2024 i 2025 roku. Treść, która pojawia się dopiero po wykonaniu JavaScriptu, jest dla GPTBota niewidoczna. To samo dotyczy ClaudeBota i PerplexityBota.
Czym różni się SSR od prerenderingu?
SSR generuje HTML przy każdym żądaniu na podstawie aktualnych danych, więc nadaje się do treści zmieniającej się często. Prerendering tworzy gotowe pliki HTML z wyprzedzeniem (podczas budowania lub przy pierwszym wejściu) i serwuje je z pamięci podręcznej. Dla bota AI oba dają ten sam efekt: pełną treść w odpowiedzi serwera. Prerendering jest tańszy we wdrożeniu, SSR elastyczniejszy.
Jak sprawdzić, co widzi crawler AI na mojej stronie?
Najprościej przez terminal: curl -A "GPTBot/1.2" adres zwraca surowy HTML. Alternatywa bez terminala to Chrome DevTools z wyłączonym JavaScriptem albo widok źródła strony (Ctrl+U). W obu przypadkach szukacie konkretnego zdania z artykułu. Jeśli go nie ma, treść powstaje po stronie klienta i wymaga przeniesienia do HTML serwera.
Czy treść w zakładkach i akordeonach jest widoczna dla botów AI?
Zależy od implementacji. Jeśli tekst jest w HTML i tylko ukryty stylem CSS, bot go odczyta. Jeśli dociąga się po kliknięciu przez żądanie do API, bot go nie zobaczy. Bezpieczny wzorzec to natywne elementy details i summary, które zawierają treść w kodzie od pierwszego bajta i nie potrzebują skryptu do działania.
Czy dynamiczne renderowanie dla botów to cloaking?
Nie, o ile wersja dla bota zawiera tę samą treść co wersja dla użytkownika, tylko w innej formie technicznej. Google od 2024 roku nie zaleca tego podejścia, ale go nie karze. Ryzyko pojawia się, gdy wersje zaczynają się różnić zawartością, na przykład bot dostaje dodatkowe akapity lub linki. Traktujcie dynamiczne renderowanie jako rozwiązanie przejściowe przed SSR.
Ile treści z JavaScriptu można stracić bez szkody dla cytowań?
Elementy interaktywne (kalkulatory, filtry, mapy) mogą zostać po stronie klienta bez wpływu na cytowania. Krytyczne są: pełny tekst artykułu, nagłówki, sekcja FAQ, dane strukturalne i linki wewnętrzne. Jeżeli różnica w liczbie słów między surowym HTML a DOM przekracza 20%, strona najprawdopodobniej traci widoczność w odpowiedziach modeli językowych.
Co dalej
Zacznijcie od pięciu adresów z audytu i policzenia rozjazdu słów, bo to w godzinę pokaże, czy problem w ogóle istnieje. Jeśli tak, priorytetem są szablony artykułów i FAQ, a dopiero potem listingi. Szerszy kontekst techniczny, w tym hreflang i schemę dla modeli, znajdziecie w przeglądzie SEO technicznego na 2026 rok.