Czy AI renderuje JavaScript

#Czy AI renderuje JavaScript

Dla inżynierów wyszukiwania to nie nowość, ale dotąd był to argument, nie dowód. Teraz zostało to przetestowane wprost, a dowód jest niewygodny dla całej klasy stron budowanych jako aplikacje JavaScript, które składają treść w przeglądarce.

#Jak przebiegał test renderowania JavaScriptu przez AI

Test, przeprowadzony przez Andre Alpara i opublikowany w czerwcu 2026 w serwisie Search Engine World, był prosty i trudny do oszukania. Strona serwowała numer-wabik w surowym HTML. Prawdziwy numer podstawiał dopiero zewnętrzny JavaScript, pobierając go z drugiego endpointu, i nie występował nigdzie w HTML ani w kodzie skryptu. Każdy z dwunastu asystentów dostał własny, nigdzie nielinkowany, niemożliwy do zgadnięcia URL, więc każde trafienie w serwer dało się przypisać jednemu asystentowi, a serwer logował trzy zdarzenia osobno: pobranie strony, pobranie pliku JavaScript i wywołanie endpointu z numerem. Logika jest szczelna. Zwracasz prawdziwy numer, czyli wykonałeś skrypt. Zwracasz wabik, czyli przeczytałeś tylko HTML.

Pobranie wywoływał użytkownik. Alpar ręcznie wklejał każdy URL do czatu i prosił asystenta o streszczenie strony i podanie wewnętrznego numeru referencyjnego. Test mierzy więc to, co dzieje się, gdy człowiek podaje asystentowi link, a nie to, co robi crawler działający w tle według własnego harmonogramu. Autor sam nazywa granice: to “test jednoprzebiegowy, na żywym pobraniu: jeden prompt na asystenta, uchwycony w jednym momencie”, a crawlery działające w tle, takie jak GPTBot i ClaudeBot, “mogą równie dobrze zachowywać się inaczej” (tłumaczenie własne). Wynik to ostra migawka ścieżki odpowiedzi na żywo z czerwca 2026, a nie trwała cecha każdego produktu.

#Którzy asystenci AI czytają tylko surowy HTML

W teście Alpara ci asystenci zwrócili wabik, czyli oparli grounding na surowym HTML i nigdy nie uruchomili skryptu:

• ChatGPT
• Claude
• Gemini
• Perplexity
• Meta AI
• Microsoft Copilot

Grok wykonał JavaScript na jednym węźle, ale i tak zwrócił wabik, więc nawet tam, gdzie skrypt się uruchomił, wyrenderowana wartość nie trafiła do odpowiedzi.

Trzy szczegóły z logów serwera wyostrzają obraz. Spośród amerykańskich systemów, które nie renderowały, Microsoft Copilot był jedynym, który pobrał plik JavaScript, i zrobił to przez zewnętrzny scraper Diffbot, ale nigdy nie wywołał endpointu z numerem i podał wabik. Gemini, które Alpar nazywa niespodzianką, bo pochodzi od Google, także niczego nie wyrenderowało. Perplexity odpowiedziało, że nie może otworzyć strony, choć jego crawler pobrał ją z kodem HTTP 200. Stąd rada Alpara: ufaj logowi serwera, nigdy relacji chatbota o tym, co zrobił.

Glenn Gabe z GSQi powtórzył pytanie na pięciu platformach i opisał wynik 19 października 2026. ChatGPT, Claude i Perplexity przegrały wszystkie trzy testy. Gemini i Copilot zdały dwa pierwsze: stronę, której cała treść ładuje się JavaScriptem, i stronę ze statycznym nagłówkiem i stopką, ale treścią z JavaScriptu. W trzecim teście, na stronie z paralaksą opartą na WebGL, Gemini odczytało treść, a Copilot nie. Gabe tłumaczy to wprost: “Gemini korzysta z systemów wyszukiwania Google, więc widzi treść renderowaną JavaScriptem” (tłumaczenie własne). Sukces Copilota przypisuje w ten sam sposób wyszukiwarce Bing.

Oba wyniki mogą być prawdziwe naraz. Alpar dawał każdemu asystentowi świeży, nigdzie nielinkowany URL, którego żadna wyszukiwarka nie miała w indeksie, więc Gemini i Copilot musiały pobrać surowy HTML tak samo jak reszta. Gabe sprawdzał istniejące serwisy, które Google i Bing znały już wcześniej, więc Gemini i Copilot mogły sięgnąć po wersję wyrenderowaną przez wyszukiwarkę. Dla nowej podstrony, zanim wyszukiwarka ją wyrenderuje, liczy się wynik z czerwca. ChatGPT, Claude i Perplexity czytały sam HTML w obu testach.

#Którzy asystenci AI wykonują JavaScript

Pięciu asystentów zwróciło prawdziwy numer, dowodząc, że wykonali skrypt:

• DeepSeek, ERNIE, Qwen i Kimi, wszyscy z Chin
• Mistral, z Europy

DeepSeek na tej liście to czat. Suganthan Mohanadasan sprawdził inną ścieżkę tej samej firmy, Fetch API wyszukiwarki DeepSeek, i opisał test 19 października 2026. W teście renderowania fetcher pobrał CSS, ale nie uruchomił JavaScriptu, nie załadował obrazków i nie wywołał beaconu XHR, więc treść wymagająca skryptu nie pojawiła się w wyniku. Przedstawiał się jako Firefox/149.0 z sieci AS136907 (Huawei Cloud, Hongkong), bez żadnej nazwy DeepSeek, i pobierał adresy zablokowane w robots.txt. Cały test, 110 wywołań, kosztował około 0,08 USD. Czat DeepSeek i jego API do pobierania stron to po prostu dwie różne drogi do Twojego HTML, i w tych testach skrypt wykonał tylko czat.

Renderowanie JS przez AI naprawdę się dzieje. Tyle że dla głównych zachodnich asystentów, na których faktycznie zależy europejskim firmom, to wyjątek przy pobraniu na żywo, a Gemini i Copilot widzą treść z JavaScriptu dopiero przez indeks wyszukiwarki. Podział jest na tyle wyraźny, że warto planować pod niego: buduj pod asystentów, których używają Twoi klienci, a ci dziś czytają HTML.

#Co badanie Vercela mówi o crawlerach AI i JavaScripcie

Test z czerwca 2026 nie jest pierwszym pomiarem, który wskazuje ten kierunek. W grudniu 2024 Vercel razem z firmą MERJ opublikował analizę ruchu crawlerów AI w swojej sieci i stwierdził, że “żaden z głównych crawlerów AI nie renderuje obecnie JavaScriptu” (tłumaczenie własne). ChatGPT i Claude pobierały pliki JavaScript, odpowiednio 11,50% i 23,84% swoich zapytań, ale ich nie wykonywały. W badanym miesiącu GPTBot wykonał 569 milionów pobrań, Claude 370 milionów, a PerplexityBot 24,4 miliona, wobec 4,5 miliarda pobrań Googlebota dla Gemini i wyszukiwarki łącznie. ChatGPT trafiał na strony 404 w 34,82% pobrań, Claude w 34,16%.

Vercel wskazał dwa crawlery, które renderują: AppleBot, działający przez crawler oparty na przeglądarce, podobnie jak Googlebot, oraz Gemini, bo korzysta z infrastruktury Googlebota. Ten drugi punkt kłóci się z wynikiem Alpara z 2026, w którym Gemini podało wabik. Oba pomiary patrzą na różne ścieżki: crawling w tle w sieci Vercela i pobranie na żywo wywołane promptem użytkownika. Sama ta rozbieżność jest lekcją: to, że Google renderuje stronę na potrzeby indeksu, niewiele mówi o tym, co Gemini czyta, gdy odpowiada na pytanie. Zalecenie Vercela zgadza się z resztą tego tekstu: główną treść, metadane i nawigację renderuj na serwerze, a renderowanie po stronie klienta zostaw dla funkcji, które tylko wzbogacają stronę.

#Czy Google renderuje JavaScript inaczej niż asystenci AI

To zarzut, który wykoleja całą rozmowę, więc zmierz się z nim wprost. Tak, Googlebot renderuje JavaScript na potrzeby klasycznego indeksu. To osobny proces od groundingu odpowiedzi AI, a test dotyczy tego drugiego. Strona może świetnie rankować w klasycznym wyszukiwaniu na treści, która istnieje dopiero po JS, i nadal być niewidoczna, gdy ChatGPT albo Perplexity pobierze ją do złożenia odpowiedzi. Traktowanie “Google renderuje JS” jako dowodu, że “AI renderuje JS”, to błąd. Te dwa systemy zachowują się inaczej, i właśnie w tej luce po cichu wycieka widoczność w AI.

#Co dokumentacja Google o SEO dla JavaScriptu mówi o renderowaniu

Google opisuje swój proces w podstawach SEO dla JavaScriptu: aplikacje JavaScript przechodzą przez trzy fazy, crawling, renderowanie i indeksowanie. Strony czekają w kolejce do renderowania, zanim bezgłowy Chromium uruchomi ich JavaScript, a według Google strona “może zostać w tej kolejce kilka sekund, ale może to trwać dłużej” (tłumaczenie własne). Ta sama strona dokumentacji nadal zaleca renderowanie po stronie serwera albo prerendering, bo jest szybsze dla użytkowników i crawlerów, i dlatego, że “nie wszystkie boty potrafią uruchamiać JavaScript” (tłumaczenie własne).

To zdanie jest pomostem do asystentów AI. Google pisze, że JSON-LD można wygenerować JavaScriptem i wstrzyknąć do strony, i Googlebot go odczyta po etapie renderowania. Alpar testował numer w widocznym tekście, nie dane strukturalne, ale schema wstrzyknięta skryptem dociera do asystenta tym samym mechanizmem, więc asystent, który nie uruchamia skryptu, nigdy jej nie zobaczy. Dokumentacja Google jest pisana dla Googlebota. Warstwa odpowiedzi AI to właśnie przypadek “nie wszystkich botów”.

Osobna strona Google o renderowaniu dynamicznym, zaktualizowana 10 grudnia 2025, zamyka skrót polegający na rozpoznawaniu botów i podawaniu im kopii wyrenderowanej na serwerze, podczas gdy użytkownicy dostają wersję renderowaną w przeglądarce. Google nazywa to obejściem i go nie zaleca, bo dokłada złożoności i wymaga dodatkowych zasobów, a w zamian wskazuje renderowanie po stronie serwera, renderowanie statyczne albo hydratację. Prerendering w czasie budowania, opisany niżej, mieści się w renderowaniu statycznym, więc każdy klient, bot czy przeglądarka, dostaje ten sam HTML.

#Jakie wzorce JavaScript ukrywają treść przed asystentami AI

Ryzyko skupia się w rozpoznawalnym zestawie wzorców:

• Aplikacje jednostronicowe, które wysyłają niemal pustą skorupę HTML i składają stronę w przeglądarce.
• Ceny, stany magazynowe albo specyfikacje wstrzykiwane przez JavaScript z API po załadowaniu.
• Treść schowana za zakładkami, akordeonami albo przyciskiem “pokaż więcej”, która dociąga się dopiero przy interakcji.
• Opisy produktów lub usług renderowane przez framework kliencki bez wersji z serwera.
• Opinie, oceny i widżety FAQ osadzone jako zewnętrzny JavaScript.

Jeśli którekolwiek z nich niosą fakty, które chcesz, by AI powtarzało, stawiasz swoją widoczność w AI na zachowaniu renderowania, które właśnie zawiodło u sześciu z siedmiu zachodnich asystentów.

#Jak pokazać AI treść ładowaną przez JavaScript

Lekarstwo to reguła, którą klasyczne SEO powtarza od dekady: kluczowe fakty umieść w HTML renderowanym po stronie serwera. Generowanie statyczne i renderowanie po stronie serwera oba ją spełniają. Framework nie ma znaczenia, znaczenie ma to, gdzie składany jest HTML. Renderuj treść na serwerze, wyślij ją w pierwszej odpowiedzi, a JavaScript niech ją wzbogaca, a nie dostarcza.

Własną stronę sprawdzisz w minutę. Pobierz stronę bez przeglądarki i przeczytaj, co wróci:

curl -s https://twoja-strona.example/twoja-podstrona/ | less

Jeśli nagłówki, treść, ceny, specyfikacje i Schema.org JSON-LD są w tej surowej odpowiedzi, asystenci AI je przeczytają. Jeśli strona to cienka skorupa, która wypełnia się po skrypcie, to jest Twój problem, i teraz go widzisz.

#Jakich user agentów używają asystenci AI do pobierania stron

Dostawcy dokumentują osobne agenty do trenowania modeli, indeksowania na potrzeby wyszukiwania i pobrań wywołanych przez użytkownika, a reguły robots.txt różnią się między nimi:

• OpenAI: GPTBot zbiera treści, które mogą posłużyć do trenowania modeli bazowych, OAI-SearchBot decyduje, czy strona może pojawić się w odpowiedziach wyszukiwania ChatGPT, a ChatGPT-User pobiera strony na potrzeby działań użytkownika. ChatGPT-User nie służy do automatycznego crawlingu, a ponieważ jego działania inicjuje użytkownik, reguły robots.txt mogą go nie dotyczyć. Każde ustawienie jest niezależne, a według OpenAI zmiana w robots.txt potrzebuje około 24 godzin, żeby dotrzeć do wyników wyszukiwania.
• Anthropic: ClaudeBot zbiera dane treningowe, Claude-SearchBot indeksuje na potrzeby jakości wyszukiwania, a Claude-User pobiera strony, gdy człowiek zadaje Claude pytanie. Anthropic deklaruje, że jego boty respektują robots.txt, i publikuje listę adresów IP swoich crawlerów.
• Perplexity: PerplexityBot pokazuje strony w wyszukiwarce Perplexity i nie służy do trenowania modeli. Perplexity-User obsługuje działania użytkownika i, ponieważ pobranie zlecił użytkownik, zasadniczo ignoruje robots.txt.
• Google: Google-Extended to token produktu w robots.txt, a nie osobny crawler. Steruje użyciem treści do trenowania Gemini i do groundingu, nie ma własnego user agenta HTTP i nie wpływa na obecność ani pozycje w wyszukiwarce Google.

Żadna z tych stron nie obiecuje renderowania JavaScriptu. W drugim eksperymencie, dotyczącym robots.txt, Alpar ustalił, że tylko 3 z 12 asystentów zostawiły w spokoju zablokowany URL: ChatGPT jako ChatGPT-User, Claude jako Claude-User i Perplexity jako Perplexity-User. Gemini przyszło z gołym user agentem “Google”, Copilot przez Diffbot ze zwykłym ciągiem Chrome, a Grok, DeepSeek, Qwen i Kimi z podrobionymi user agentami przeglądarek. Praktyczny wniosek dla renderowania: nie da się niezawodnie podsunąć asystentom AI specjalnej, wyrenderowanej wersji po rozpoznaniu user agenta, więc fakty musi nieść HTML, który dostają wszyscy.

#Jak WordPress serwuje treść dla AI bez JavaScriptu

Klasyczny motyw WordPressa jest domyślnie po bezpiecznej stronie: PHP składa stronę na serwerze, więc wpisy, opisy produktów i ceny z bazy danych są w HTML, zanim uruchomi się jakikolwiek skrypt. Ryzyko pojawia się, gdy treść trafia do widżetów po stronie klienta, do bloków pobierających dane przez REST API po załadowaniu albo do headlessowego frontendu, który renderuje się tylko w przeglądarce.

Dla interaktywności WordPress ma rozwiązanie, które zostawia treść na serwerze. Interactivity API, wprowadzone w WordPressie 6.5, używa dyrektyw w znacznikach bloku, a jego przetwarzanie dyrektyw po stronie serwera pozwala WordPressowi wygenerować początkowy HTML z poprawnym stanem. Funkcja wp_interactivity_process_directives odnajduje dyrektywy i za pomocą HTML API przepisuje znaczniki na podstawie stanu początkowego i kontekstu. W przykładzie z dokumentacji lista zbudowana z data-wp-each i data-wp-text opuszcza serwer jako zwykłe elementy listy z wpisanymi już nazwami owoców i bez dyrektyw. Strona przychodzi kompletna, JavaScript dokłada zachowanie później, a asystent czytający surowy HTML widzi tę samą listę co odwiedzający. Dokumentacja podaje powód wprost: takie podejście zachowuje “korzyści dla SEO i wydajności, jakie daje tradycyjne renderowanie WordPressa po stronie serwera” (tłumaczenie własne).

#Statyczny HTML w Astro a widoczność w AI

Nie jesteśmy tu bezstronni, bo zrobiliśmy ten zakład świadomie. wppoland.com działa na Astro, które renderuje strony do statycznego HTML w czasie budowania i serwuje je z brzegu sieci. Wszystko, co istotne, jest w surowej odpowiedzi: treść, każdy nagłówek, FAQ i dane Schema.org JSON-LD. Sprawdziliśmy to tak samo jak test, czytając surowy HTML zamiast wyrenderowanej strony, i treść jest cała na miejscu, zanim uruchomi się choć jedna linia naszego JavaScriptu. JavaScript na naszych stronach to wzbogacenie, nigdy źródło treści.

To ten sam wniosek, do którego doszliśmy okrężną drogą w serwowaniu treści agentom AI: czysty, renderowany po stronie serwera, semantyczny HTML plus Schema to jedyny sygnał, który konsumują i klasyczne crawlery, i systemy AI. Ten test to najczystszy jak dotąd dowód na tę pozycję. To także powód, dla którego program GEO i LLMO musi zaczynać się od tego, jak strona jest renderowana, a nie od sprytnych metadanych, bo metadanych, których asystent nie wykona, nigdy nie przeczyta.

#Czym różni się renderowanie po stronie serwera i klienta

Dla czytelników, którzy prowadzą firmę, a nie potok budowania:

• Renderowanie po stronie serwera / generowanie statyczne - HTML strony jest składany na serwerze (albo w czasie budowania) i przychodzi kompletny w pierwszej odpowiedzi.
• Renderowanie po stronie klienta - serwer wysyła niemal pustą skorupę, a JavaScript przeglądarki buduje stronę później.
• Grounding - gdy asystent AI pobiera realne strony, żeby oprzeć odpowiedź na faktach, a nie na pamięci.
• Hydracja - JavaScript dokładający interaktywność do już wyrenderowanego HTML; bezpieczny, bo treść była tam wcześniej.
• Prerendering - uruchomienie aplikacji klienckiej w czasie budowania, żeby zapisać jej stan początkowy jako statyczny HTML, według definicji z przewodnika web.dev Rendering on the Web. Ten sam przewodnik zauważa, że crawlery rozumieją JavaScript, “ale często mają ograniczenia w tym, jak renderują” (tłumaczenie własne).

#Czy warto czekać, aż AI zacznie renderować JavaScript

Renderowanie JavaScriptu przez asystentów AI z czasem zapewne się poprawi, a chińscy asystenci plus Mistral pokazują, że technicznie to rutyna. Ale nie publikujesz dla asystentów, których chciałbyś, żeby istnieli. Publikujesz dla tych, których używają Twoi klienci, a w czerwcu 2026 najwięksi zachodni asystenci czytają surowy HTML i na tym kończą. Bezpieczna, nudna, dekadę stara odpowiedź okazuje się słuszna także dla AI: serwuj fakty w HTML, który serwer już wyrenderował, a wszystko, co pojawia się dopiero po JavaScripcie, traktuj jak treść, której AI nie zobaczy.