Czy AI renderuje JavaScript

#Co test naprawdę udowodnił

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.

#Eksperyment w jednym akapicie

Test, przeprowadzony przez Andre Alpara i opublikowany przez CitationOne, 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. Każdy asystent dostał unikalny, niemożliwy do zgadnięcia URL, 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.

#Kto czytał tylko HTML

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.

#Kto renderował 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

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

#”Przecież Google renderuje JavaScript”

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 to psuje w praktyce

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.

#Nudne rozwiązanie, teraz potwierdzone dla AI

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.

#Jak radzi sobie z tym nasz własny stack

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.

#Słownik

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.

#Uczciwy wniosek

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.