ChatGPT i Claude mogą nie widzieć treści z JavaScriptu: co pokazał test po roku

Krótka odpowiedź: część asystentów widzi tylko to, co jest w HTML

Jeśli opis oferty, cena albo dane kontaktowe pojawiają się na stronie dopiero po uruchomieniu JavaScriptu, ChatGPT, Claude i Perplexity mogą ich w ogóle nie zobaczyć. W teście Glenna Gabe’a opisanym 19 października 2026 roku te trzy platformy odczytały z takich stron tylko menu, stopkę, baner cookies albo komunikat o błędzie. Gemini odczytał treść we wszystkich trzech testach, a Copilot w dwóch: nie poradził sobie ze stroną z grafiką WebGL.

Google radzi sobie z JavaScriptem od lat, więc strona może dobrze stać w wyszukiwarce i jednocześnie być pusta dla asystenta AI. Sprawdzisz to sam w kwadrans, a naprawa polega na tym, żeby serwer wysyłał gotowy tekst w kodzie HTML.

Test Glenna Gabe’a: ten sam wynik po 434 dniach

Glenn Gabe, amerykański konsultant SEO znany z analiz aktualizacji Google, pierwszy raz sprawdził to w sierpniu 2025 roku. Po 434 dniach powtórzył test tą samą metodą: podawał platformie adres strony i prosił o pierwszy i ostatni akapit tekstu. Wybrał trzy rodzaje stron:

1. cała treść główna ładowana JavaScriptem;
2. nagłówek i stopka w zwykłym HTML, treść główna ze skryptu;
3. strona z efektami graficznymi (parallax, WebGL), która wymaga przeglądarki z grafiką.

Odpowiedzi są pouczające. ChatGPT napisał wprost, że nie może potwierdzić pierwszego i ostatniego akapitu, bo dostał tylko elementy nawigacji i stopki. Perplexity na pierwszej stronie widziała głównie treść banera zgody na cookies, a na trzeciej podała jako akapit komunikat o błędzie. Claude sam rozpoznał przyczynę: taki obraz zwykle oznacza stronę w Next.js, której treść renderuje się w przeglądarce. Zaproponował też otwarcie strony we wbudowanej przeglądarce, ale domyślnie tego nie zrobił.

Gabe tłumaczy przewagę Gemini i Copilota tym, że korzystają z systemów wyszukiwarek Google i Bing, które uruchamiają JavaScript. Sam dodaje, że na części sprawdzanych stron nawet Gemini i Copilot nie widziały treści, i zapowiada kolejne testy. Jego rada dla firm: uważaj, jeśli treść wymaga JavaScriptu. Już we wpisie z sierpnia 2025 roku radził sprawdzić stronę i pokazać wyniki programistom.

Drugi test: fikcyjna firma i logi serwera

Trzy dni później na forum r/TechSEO pojawił się test zrobiony inaczej. Autor zbudował stronę nieistniejącej firmy z czterema podstronami. Na każdej umieścił zmyślone fakty, których nie ma nigdzie indziej w internecie: maskotkę, miasto, cenę. Każda podstrona podawała je w inny sposób. Potem dał adresy ChatGPT, Claude i Gemini, w aplikacjach i przez API, łącznie pięciu narzędziom, i patrzył w logi serwera.

• Fakty w HTML (strona renderowana na serwerze albo statyczna): odczytało je wszystkie 5 narzędzi.
• Fakty tylko w pliku JavaScript: odczytała je wyłącznie aplikacja ChatGPT.
• Fakty w pliku JavaScript, celowo zamaskowane: też tylko aplikacja ChatGPT.
• Fakty tylko w bloku danych JSON w kodzie strony: znowu tylko aplikacja ChatGPT.

Pozostałe cztery narzędzia widziały pustą stronę ze stopką. Według autora logi pokazały, że ich roboty pobrały sam HTML i w ogóle nie poprosiły o plik JavaScript. Pominęły też, jak pisze, wszystko, co stało w znacznikach <script>, razem z danymi JSON. Aplikacja ChatGPT wróciła po 12 sekundach, pobrała plik skryptu i odczytała nawet zamaskowane fakty. Żadne narzędzie niczego nie zmyśliło.

Dwie uwagi do tego testu. Autor sam pisze, że buduje narzędzie do SEO i widoczności w AI, więc ma interes w temacie. Poprawił też swój wpis: czwarta podstrona nie pokazuje, jak działa Next.js, bo w trybie Pages Router framework wysyła gotowy HTML, a JSON dokłada tylko do uruchomienia interakcji. Wyniki testu strony w App Routerze autor podał w komentarzach. Test dotyczy strony, na której JSON jest jedyną kopią treści.

Oba testy się częściowo wykluczają. U Gabe’a ChatGPT treści ze skryptu nie widział, a Gemini widział. Na Reddicie było odwrotnie. Możliwe wyjaśnienie, którego żaden z autorów nie potwierdził: wynik zależy od tego, którą drogą narzędzie pobiera stronę (aplikacja czy API, wizyta na żywo czy indeks wyszukiwarki), a to zmienia się bez ogłoszeń. Na szczęście nie musisz zgadywać, która ścieżka zadziała u Twojego klienta, jeśli tekst jest w HTML.

Dlaczego boty AI nie uruchamiają JavaScriptu

Googlebot pobiera stronę, a potem, gdy pozwalają na to zasoby Google, uruchamia ją w przeglądarce Chromium bez okna i dopiero z tego wyniku indeksuje treść. To kosztowny krok. Jak Googlebot renderuje stronę i co może go zatrzymać, opisujemy osobno. Większość robotów firm od AI tego kroku nie robi: pobiera surowy kod HTML i wyciąga z niego tekst.

Vercel i firma MERJ opisali to w grudniu 2024 roku na podstawie kilku miesięcy ruchu w sieci Vercel i na nextjs.org. Wniosek: żaden z dużych robotów AI nie renderował wtedy JavaScriptu. Dotyczyło to botów OpenAI, Anthropic, Meta, ByteDance i Perplexity. Na nextjs.org pliki JavaScript stanowiły 11,5% pobrań robotów ChatGPT i 23,84% pobrań Claude’a, ale roboty ich nie wykonywały. Wyjątki to Gemini, który korzysta z infrastruktury Googlebota, i AppleBot, który używa przeglądarki.

OpenAI i Anthropic w dokumentacji swoich robotów (OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User i inne) nie piszą nic o JavaScripcie, ani że go obsługują, ani że nie. Stan na 29 października 2026 roku. Jakie zadania mają poszczególne boty i których nie blokować, opisaliśmy w tekście o botach AI w robots.txt. Google w dokumentacji o JavaScripcie przypomina z kolei, że renderowanie po stronie serwera to nadal dobry pomysł, bo nie wszystkie boty potrafią uruchomić JavaScript.

Jak sprawdzić swoją stronę w 15 minut

Wybierz jedną ważną stronę, na przykład główną usługę albo popularny produkt. Skopiuj z niej zdanie, które ma znaczenie dla klienta: cenę, czas realizacji, nazwę usługi z opisu.

1. Kod źródłowy kontra to, co widzisz

Otwórz stronę w Chrome i naciśnij Ctrl+U (na Macu Cmd+Option+U). Otworzy się kod HTML, który serwer wysłał Twojej przeglądarce. Bot bez JavaScriptu dostaje zwykle to samo, chyba że serwer rozpoznaje roboty i podaje im inną wersję. Wyszukaj w nim skopiowane zdanie (Ctrl+F). Jeśli go nie ma, a na stronie je widzisz, poszukaj jeszcze krótszego fragmentu, bo znaczniki i encje HTML potrafią rozdzielić tekst. Gdy i fragmentu brak, ta treść najpewniej powstaje w przeglądarce. Dla porównania kliknij prawym przyciskiem na tekst i wybierz Zbadaj: tam zobaczysz kod już po uruchomieniu skryptów.

2. Pobranie strony bez przeglądarki

Programista albo Ty w terminalu możecie pobrać stronę tak, jak robi to prosty robot:

curl -sL https://twojadomena.pl/uslugi/ | grep -cF "Twoje zdanie z oferty"

Wynik 0 oznacza, że w pobranym kodzie nie ma dokładnie tego ciągu znaków (opcja -F każe szukać dosłownego tekstu). Opcja -s ukrywa jednak błędy połączenia, a znaczniki i encje mogą rozdzielać zdanie, więc obejrzyj też cały pobrany kod: jeśli w środku jest prawie tylko pusty element w rodzaju <div id="root"></div> i lista skryptów, cała strona powstaje w przeglądarce.

3. Pytanie do asystenta

Wklej adres strony do ChatGPT, Claude, Perplexity i Gemini i poproś o to samo, o co prosił Gabe: „Podaj pierwszy i ostatni akapit tekstu z tej strony”. Możesz też zapytać o konkretny fakt, który jest tylko na tej stronie, na przykład cenę pakietu. Jeśli asystent podaje menu, stopkę, treść banera cookies albo pisze, że nie może odczytać strony, w tej próbie nie dotarł do właściwej treści. Gdy tego zdania nie ma też w kodzie źródłowym, przyczyną jest najpewniej JavaScript. Powtórz pytanie kilka razy, bo jak widać po dwóch testach, wynik potrafi się różnić. Stały sposób na takie sprawdzanie opisujemy w tekście jak sprawdzić, czy ChatGPT poleca Twoją firmę.

Co zrobić, gdy treść jest tylko w skrypcie

Cel jest jeden: najważniejszy tekst strony ma przychodzić z serwera w kodzie HTML. Skrypty mogą potem dokładać interakcje, na przykład koszyk, filtry czy kalkulator.

• Renderowanie po stronie serwera (SSR): serwer składa stronę w odpowiedzi na żądanie i wysyła gotowy HTML. Gotowy wynik może też przechować w pamięci podręcznej. Tak działają klasyczne systemy, w których szablon tworzy HTML na serwerze, na przykład WordPress w PHP albo motywy Shopify w języku Liquid.
• Generowanie statyczne (SSG): strony powstają jako gotowe pliki HTML przy publikacji. Dobre dla stron firmowych i blogów, które nie zmieniają się co minutę.
• Prerendering dla botów (renderowanie dynamiczne): dodatkowa usługa rozpoznaje roboty i wysyła im wcześniej wyrenderowaną kopię strony, a użytkownikom wersję ze skryptami. To łatka dla gotowych aplikacji, których nie da się szybko przebudować. Google nazywa takie rozwiązanie obejściem, którego nie zaleca, i radzi renderowanie po stronie serwera, statyczne albo z hydracją.

Next.js, React i kreatory stron z AI

W Next.js z App Routerem strony i układy są domyślnie komponentami serwerowymi, więc tekst trafia do HTML. Problem pojawia się, gdy treść jest pobierana dopiero w przeglądarce, na przykład przez skrypt po załadowaniu strony, albo gdy renderowanie na serwerze jest wyłączone. Wtedy w HTML zostaje szkielet. Samo oznaczenie komponentu jako klienckiego tego nie powoduje, bo Next.js i tak składa jego HTML na serwerze przy pierwszym wejściu. Klasyczna aplikacja w React lub Vue bez renderowania na serwerze ma ten problem z założenia, chyba że korzysta z prerenderingu.

Dobry przykład to Lovable, popularny kreator stron z AI. Według jego dokumentacji aplikacje utworzone od 13 maja 2026 roku (w kontach Enterprise od 22 czerwca) renderują strony na serwerze. Starsze, oparte na React i Vite, renderują się w przeglądarce, a Lovable wysyła zweryfikowanym wyszukiwarkom i robotom AI wyrenderowane kopie. Jeśli Twoja strona powstała wcześniej, sprawdź ją testem z poprzedniej części i rozważ przejście na nową wersję, które Lovable udostępnia dla części projektów.

WordPress i sklepy

Na WordPressie i Shopify główna treść zwykle jest w HTML. Kłopot robią dodatki: zakładki opisu produktu doczytywane skryptem, widżety opinii, konfiguratory, cenniki w kalkulatorach, FAQ ładowane z zewnętrznej usługi. Sprawdź testem właśnie te elementy, jeśli zawierają informacje, o które pytają Twoi klienci.

Dane strukturalne też umieszczaj w HTML wysyłanym przez serwer. Blok JSON-LD dopisywany skryptem w przeglądarce Google odczyta po wyrenderowaniu strony, ale bot, który nie uruchamia JavaScriptu, go nie zobaczy. Test z Reddita pokazał też, że część narzędzi pomija nawet blok JSON, który w HTML jest.

Czego jeszcze nie wiadomo (stan na 29.10.2026)

• OpenAI, Anthropic ani Perplexity nie piszą w opisach swoich robotów, jak traktują one JavaScript. Anthropic podaje jedynie w dokumentacji API, że narzędzie web fetch nie obsługuje stron renderowanych dynamicznie JavaScriptem. Poza tym wszystko, co wiemy, pochodzi z testów praktyków i z pomiaru Vercel opisanego w grudniu 2024 roku.
• Nie wiadomo, czy roboty budujące indeks wyszukiwania (OAI-SearchBot, Claude-SearchBot) zachowują się tak samo jak pobranie na żywo w czasie rozmowy. Autor testu z Reddita zapowiedział 22 października drugi test na ten temat. Do dnia publikacji nie znaleźliśmy pełnego opisu jego wyników, a komentarzy pod wpisem nie udało nam się odczytać.
• Nie wiadomo, dlaczego aplikacja ChatGPT w jednym teście pobrała skrypt, a w drugim nie.
• Nie wiadomo, czy wyrenderowane kopie, które wysyłają usługi prerenderingu, trafiają też do botów pobierających stronę na prośbę użytkownika.

Jedna obserwacja z testu z Reddita dotyczy czegoś innego, ale warto ją znać. Przegląd od AI w Google, zapytany o fikcyjną markę, zanim Google zaindeksował choć jedną jej stronę, i tak wymyślił jej historię. Brak treści nie chroni więc przed tym, że AI coś o firmie powie. Jak łatwo trafiają do odpowiedzi AI zmyślenia, opisujemy w tekście o fałszywych faktach w odpowiedziach AI.

Kiedy poprosić o pomoc

Jeśli test pokazał, że asystenci widzą tylko menu i stopkę, i nie wiesz, czy przebudowa to tydzień pracy, czy nowa strona, sprawdzimy to w ramach pracy nad widocznością w AI i powiemy, co trzeba zmienić najpierw.