Renderowanie JavaScript a AI: dlaczego model nie widzi treści

Strona może wyglądać świetnie w przeglądarce, mieć komplet opisów produktów i rozbudowane FAQ, a mimo to dla ChatGPT czy Perplexity być prawie pusta. Powód jest prozaiczny: Google renderuje JavaScript, większość crawlerów AI tego nie robi. Jeśli kluczowa treść pojawia się w dokumencie dopiero po wykonaniu skryptów, model jej po prostu nie dostaje. Poniżej wyjaśniamy, skąd bierze się ta różnica, jak ją zmierzyć na własnym serwisie i które rozwiązania mają sens przy różnych budżetach.

Czym różni się crawl Google od botów AI

Googlebot działa w dwóch etapach. Najpierw pobiera surowy HTML, a potem kolejkuje stronę do renderowania w usłudze opartej na aktualnym Chromium. Dopiero po wykonaniu JavaScriptu Google widzi pełny DOM, czyli to, co widzi użytkownik. Proces opisuje dokumentacja Google Search Central o podstawach SEO dla JavaScriptu. Renderowanie bywa opóźnione, ale co do zasady następuje.

Crawlery modeli językowych działają inaczej. GPTBot, OAI-SearchBot, ClaudeBot czy PerplexityBot pobierają HTML i na tym zwykle kończą. Analiza ruchu botów opublikowana przez Vercel w raporcie o crawlerach AI pokazała, że główne boty AI ściągają pliki JavaScript, ale ich nie wykonują. Renderowanie milionów stron w przeglądarce jest kosztowne, a firmy AI optymalizują przede wszystkim skalę pobierania. Wyjątkiem są narzędzia, które korzystają z indeksu Google lub Bing (na przykład Gemini czy Copilot), bo dziedziczą wyrenderowaną wersję z wyszukiwarki.

Efekt praktyczny: ta sama strona ma dwie wersje. Jedną widzi Google i użytkownik, drugą widzi model. Dobra pozycja w wynikach wyszukiwania niczego tu nie gwarantuje. Więcej o tym, jak Google ocenia strony w ostatnich aktualizacjach, piszemy w tekście o tym, jak zrozumieć algorytmy Google w 2026 roku.

Jak sprawdzić treść bez JavaScriptu

Najszybszy test zajmuje dwie minuty i nie wymaga płatnych narzędzi. Chodzi o porównanie surowego HTML z wyrenderowanym DOM.

1. Pobranie strony z linii poleceń. Komenda curl -A "GPTBot" https://twojadomena.pl/adres zwraca dokładnie to, co dostaje bot bez renderowania. Wystarczy wyszukać w wyniku charakterystyczne zdanie z opisu produktu lub nagłówek sekcji.
2. Wyłączenie JavaScriptu w przeglądarce. W Chrome DevTools: Ctrl+Shift+P, wpisać „Disable JavaScript”, przeładować stronę. Jeśli widzisz pusty szkielet i spinner, model widzi to samo.
3. Podgląd źródła. Ctrl+U pokazuje HTML z serwera, a nie aktualny DOM. Jeśli treść jest w zakładce Elements, ale nie ma jej w źródle, generuje ją skrypt.
4. Porównanie objętości. Policz słowa w surowym HTML i w wyrenderowanej wersji. Narzędzia typu Screaming Frog w trybie renderowania pokazują obie wartości obok siebie dla całego serwisu.

Ten test warto potraktować jako jeden z elementów szerszej diagnostyki. Pełny zestaw kontroli, od logów serwera po cytowania, opisujemy w poradniku jak sprawdzić, czy AI widzi Twoją stronę. Tutaj skupiamy się na tym, co zrobić, gdy test bez JavaScriptu wypadnie źle.

Typowe elementy, które znikają

Rzadko zdarza się, że znika cała strona. Częściej giną konkretne bloki, i to zwykle te najcenniejsze dla odpowiedzi AI:

• Opisy i specyfikacje produktów ładowane przez API po wejściu na kartę produktu.
• Ceny i dostępność pobierane dynamicznie z systemu magazynowego.
• Zakładki i akordeony, w których treść wstrzykiwana jest dopiero po kliknięciu, a nie tylko ukrywana stylami CSS.
• Opinie klientów z widgetów zewnętrznych dostawców.
• FAQ i dane strukturalne dodawane przez menedżera tagów lub skrypt po załadowaniu strony.
• Linki wewnętrzne w menu i paginacji generowanych przez framework, przez co bot nie dociera do kolejnych podstron.

Ostatni punkt łatwo przeoczyć. Jeśli nawigacja istnieje wyłącznie w JavaScripcie, crawler AI nie tylko nie widzi treści, ale nie znajduje też adresów, które mógłby pobrać. Podobny mechanizm marnowania zasobów crawlera opisujemy w artykule o tym, kiedy crawl budget faktycznie krzywdzi serwis.

Renderowanie po stronie serwera

Docelowym rozwiązaniem jest SSR (server-side rendering) albo generowanie statyczne. Serwer wysyła gotowy HTML z treścią, a JavaScript w przeglądarce tylko „ożywia” stronę (proces nazywany hydracją). Wszystkie popularne frameworki mają taki tryb: Next.js i Nuxt renderują po stronie serwera domyślnie, Angular oferuje Angular SSR, a w React bez frameworka trzeba go skonfigurować samodzielnie.

Zalety są oczywiste: jedna wersja strony dla wszystkich botów i użytkowników, brak ryzyka cloakingu, szybszy pierwszy render. Koszt to praca deweloperska i czasem większe obciążenie serwera. Przy migracji istniejącej aplikacji SPA trzeba liczyć tygodnie, nie dni, bo kod korzystający z obiektów przeglądarki (window, localStorage) wymaga przepisania.

Warto też pamiętać, że SSR wspiera sygnały wiarygodności. Autor, data publikacji, źródła i bio eksperta muszą być w HTML, żeby model mógł je powiązać z treścią. Szerzej o tych sygnałach piszemy w tekście o praktycznych sygnałach EEAT dla agencji.

Prerendering jako rozwiązanie doraźne

Jeśli przebudowa aplikacji nie wchodzi w grę w najbliższym kwartale, można sięgnąć po prerendering. Usługa (komercyjna lub własna, oparta na przeglądarce headless) generuje statyczne kopie stron i serwuje je botom rozpoznanym po user-agencie. Użytkownicy dalej dostają wersję kliencką.

To rozwiązanie działa, ale ma ograniczenia, o których trzeba wiedzieć przed wdrożeniem:

• lista user-agentów musi obejmować boty AI, nie tylko Googlebota i Bingbota; nowe crawlery pojawiają się co kilka miesięcy;
• kopie trzeba odświeżać, inaczej bot zobaczy nieaktualne ceny lub wycofane produkty;
• treść dla bota i dla użytkownika musi być identyczna; różnice to klasyczny cloaking;
• Google oficjalnie traktuje dynamiczne renderowanie jako obejście, a nie zalecaną architekturę.

Prerendering ma sens jako most na kilka miesięcy, a nie jako stan docelowy.

Kiedy wystarczy przenieść kluczową treść

Nie każdy serwis potrzebuje pełnego SSR. Na stronach, gdzie JavaScript odpowiada głównie za interakcje (konfigurator, filtry, koszyk), często wystarczy przenieść do statycznego HTML kilka elementów:

Kryterium jest proste: wszystko, co ma szansę trafić do odpowiedzi modelu (definicje, parametry, ceny, odpowiedzi na pytania), powinno być w surowym HTML. Interaktywne dodatki mogą zostać po stronie klienta. Jeśli serwis stoi na WordPressie z klasycznym motywem, problem zwykle dotyczy tylko wtyczek i widgetów, a nie samej treści wpisów.

Weryfikacja po wdrożeniu

Po zmianach trzeba sprawdzić efekt na trzech poziomach. Pierwszy to sam HTML: ponowny test curl z user-agentem GPTBot i porównanie liczby słów przed i po. Drugi to logi serwera: czy boty AI pobierają teraz więcej podstron i czy docierają do adresów, które wcześniej były osiągalne tylko przez JavaScript. Trzeci to widoczność w odpowiedziach: zestaw kilkunastu stałych zapytań do ChatGPT i Perplexity, powtarzany co dwa tygodnie.

Efekty w odpowiedziach AI nie pojawiają się od razu. Crawlery wracają na strony nieregularnie, a modele bez dostępu do wyszukiwarki aktualizują wiedzę dopiero przy kolejnym treningu. Realny horyzont oceny to cztery do ośmiu tygodni. Kontrolę renderowania warto dopisać na stałe do przeglądów technicznych; punkt po punkcie pomoże w tym lista kontrolna technicznego SEO.

FAQ