Renderowanie JavaScriptu a crawlery AI: luka w widoczności

Dlaczego renderowanie JavaScriptu stało się kwestią widoczności

Przez lata renderowanie JavaScriptu uchodziło za kwestię czysto wydajnościową. Kto renderował po stronie klienta, ryzykował wolniejsze ładowanie, ale raczej nie utratę widoczności, bo Googlebot wykonuje JavaScript. W erze wyszukiwania AI to założenie już nie wystarcza. Nowa klasa crawlerów czyta strony internetowe bez wykonania choćby jednej linii JavaScriptu: to crawlery stojące za ChatGPT, Claude, Perplexity i innymi systemami AI.

Wspólna analiza Vercel i MERJ dotycząca zachowania crawlerów w sieci Vercel po raz pierwszy szeroko udokumentowała tę lukę. Według analizy z grudnia 2024 r. żaden duży crawler AI nie renderuje JavaScriptu, w tym crawlery OpenAI (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic (ClaudeBot), ByteDance (Bytespider), Meta i Perplexity (PerplexityBot). Zmienia to całą logikę: Server-Side Rendering nie jest już optymalizacją pod szybsze dostarczanie, lecz podstawowym warunkiem tego, by treści w ogóle istniały dla rosnącej części ruchu crawlerów.

Skala tego ruchu ma znaczenie. Już same GPTBot i ClaudeBot wygenerowały w ciągu miesiąca w sieci Vercel odpowiednio 569 mln i 370 mln żądań, łącznie około 20% wolumenu Googlebota wynoszącego 4,5 mld żądań. Dla cytowań w ChatGPT czy Perplexity liczą się ich crawlery wyszukujące OAI-SearchBot i PerplexityBot. Według tej samej analizy one również nie renderują JavaScriptu. Treść renderowana po stronie klienta pozostaje dla nich niewidoczna.

Techniczna przyczyna luki w widoczności

Crawler przechodzi zasadniczo przez dwa etapy: pobiera dokument HTML (crawling), a następnie przetwarza jego zawartość. Kluczowa różnica polega na tym, czy między tymi etapami występuje proces renderowania, w którym silnik przeglądarki wykonuje JavaScript, buduje DOM i wstawia doładowywane treści.

Googlebot renderuje, crawlery AI nie: Googlebot, Google Gemini i AppleBot korzystają z etapu renderowania opartego na przeglądarce, dzięki czemu widzą także treści powstające dopiero za sprawą JavaScriptu. Crawlery AI z tego rezygnują. Przetwarzają wyłącznie surowy HTML dostarczony przez serwer. Co ciekawe, JavaScript jak najbardziej pobierają: crawlery ChatGPT ładują pliki JS w 11,50% swoich żądań, ClaudeBot w 23,84%, ale tych plików nie wykonują. Pobieranie bez wykonania oznacza, że wszystko, co składa się dopiero w przeglądarce, pozostaje niewidoczne.

Ile technicznie kosztuje renderowanie: renderowanie jest zasobożerne. Wymaga środowiska przeglądarki dla każdej strony, czasu obliczeniowego i pamięci operacyjnej. Dla crawlera przetwarzającego miliardy stron to istotny czynnik kosztowy. Crawlery AI są nastawione przede wszystkim na budowę zbiorów danych do trenowania i retrievalu. W czasie analizy Vercel rezygnowały z tego etapu, prawdopodobnie ze względu na koszty. Czy to się zmieni, pozostaje sprawą otwartą.

Praktyczna konsekwencja: w udokumentowanym teście w realnych warunkach ChatGPT, Perplexity i Claude nie były w stanie odczytać treści strony renderowanej po stronie klienta, ponieważ zależała ona od renderowania JavaScriptu. Co więcej, dotknięte strony pojawiały się tylko w podrzędnych miejscach, takich jak sekcja „More” w ChatGPT, zamiast jako główne źródło cytowań. O widoczności w wyszukiwaniu AI decyduje więc już to, czy główna treść znajduje się w HTML dostarczonym przez serwer.

Porównanie strategii renderowania

Wybór strategii renderowania to główna dźwignia. Dominują cztery podejścia o wyraźnie różnych skutkach dla widoczności w AI i dla crawlerów.

Client-Side Rendering (CSR): serwer dostarcza minimalny szkielet HTML, a cała treść powstaje dopiero w przeglądarce za pomocą JavaScriptu. Dla crawlerów AI ta treść nie istnieje. Czyste architektury CSR to najbardziej problematyczny wariant z punktu widzenia widoczności w AI.

Server-Side Rendering (SSR): serwer generuje kompletny HTML przy każdym żądaniu i dostarcza go w gotowej postaci. Główna treść, metadane i dane strukturalne są od razu w kodzie źródłowym i każdy crawler może je odczytać. SSR to najpewniejsze podejście, jeśli chodzi o maksymalną widoczność dla crawlerów i AI.

Static Site Generation (SSG) i prerendering: strony są wstępnie renderowane w czasie builda i dostarczane jako statyczny HTML. Łączy to pełną widoczność z bardzo szybkim dostarczaniem. Dla treści, które rzadko się zmieniają, na przykład artykułów z bazy wiedzy czy stron usług, to często idealne rozwiązanie.

Incremental Static Regeneration (ISR): forma pośrednia, która w tle generuje statyczne strony na nowo w określonych odstępach czasu. Łączy zalety SSG z aktualnością treści dynamicznych i także dostarcza gotowy HTML.

W Next.js te strategie realizuje App Router. React Server Components renderują się domyślnie na serwerze, więc ich wynik trafia bezpośrednio do HTML. Streaming dostarcza treści progresywnie, nie zagrażając czytelności głównej treści dla crawlerów, o ile kluczowa zawartość nie jest ukryta za komponentem działającym wyłącznie po stronie klienta. Decydująca pozostaje prosta zasada: to, co jest w początkowej odpowiedzi HTML, jest widoczne. To, co składa dopiero przeglądarka, już nie.

Trend w stronę renderowania po stronie serwera widać także w danych. Porównanie liczby słów po wyrenderowaniu i w surowym HTML na stronach głównych pokazuje medianę różnicy na poziomie 13,6% (mobile) i 17,5% (desktop), przy czym różnica maleje przy dłuższych tekstach, co wskazuje na relatywnie większe rozpowszechnienie technologii serwerowych w przypadku dłuższych treści. Na 10. percentylu różnica na desktopie sięga jednak nawet 32%, co wyraźnie pokazuje, że znaczna część stron nadal doładowuje treści, które umykają crawlerom AI.

Dobre praktyki: architektura przyjazna crawlerom

Dostarczanie głównej treści po stronie serwera: główna treść tekstowa, title i meta description, dane strukturalne Schema.org, linkowanie wewnętrzne, atrybuty hreflang oraz tag canonical muszą znaleźć się w początkowej odpowiedzi HTML. Te elementy sterują indeksacją, przypisaniem języka i regionu oraz analizą przez systemy AI. Jeśli są tylko w wyrenderowanym DOM, przepadają dla crawlerów czytających surowy HTML.

Osadzanie danych strukturalnych po stronie serwera: JSON-LD powinien znajdować się bezpośrednio w HTML dostarczanym przez serwer, a nie być wstrzykiwany przez JavaScript. W przeciwnym razie crawlerom AI brakuje kontekstu czytelnego dla maszyn, który jest cenny dla rozpoznawania encji i cytowalności.

Linkowanie wewnętrzne jako prawdziwe linki HTML: nawigacja i linki wewnętrzne muszą występować w kodzie źródłowym jako zwykłe elementy kotwic. Linków generowanych przez JavaScript crawlery AI nie śledzą, a nawet Googlebot potrzebuje na nie znacznie więcej czasu. Możliwość crawlowania struktury linków to podstawa, by podstrony w ogóle zostały znalezione.

Szybkie dostarczanie przez edge i CDN: HTTP/3, edge caching i CDN skracają czas odpowiedzi i zmniejszają obciążenie przy częstym crawlingu. To szczególnie ważne, bo crawlery AI działają nieefektywnie. W przypadku ChatGPT 34,82% pobrań trafia na strony 404, w przypadku Claude 34,16%, a w przypadku Googlebota tylko 8,22%. Uporządkowane mapy witryn XML i IndexNow pomagają celowo sygnalizować nowe i zmienione adresy URL oraz ograniczać marnowanie zasobów crawlingu na martwe ścieżki.

Oddzielenie zarządzania zgodami od crawlerów: banery cookies i obszary wymagające zgody nie mogą ukrywać właściwej treści przed crawlerami. Jeśli główna treść ładuje się przez JavaScript dopiero po wyrażeniu zgody, crawlery AI widzą tylko baner. Rozwiązanie zgodne z RODO polega na dostarczaniu treści niezawierających danych osobowych po stronie serwera i ograniczeniu zarządzania zgodami do tego, czego faktycznie dotyczy: trackingu i niekoniecznych plików cookie. Blokowanie treści za zgodą szkodzi widoczności, choć przepisy o ochronie danych tego nie wymagają.

Częste błędy

Traktowanie Dynamic Renderingu jako rozwiązania: Google uznał serwowanie różnych treści botom i użytkownikom za przestarzałe obejście. Zwiększa ono złożoność, sprzyja błędom i nie zastępuje czystej architektury serwerowej. Kto dziś buduje od nowa, powinien od razu postawić na SSR, SSG lub ISR.

Używanie frameworków CSR bez renderowania po stronie serwera: aplikacja typu Single Page Application bez renderowania po stronie serwera generuje niemal pusty dokument HTML. Dla użytkowników to działa, dla crawlerów AI strona nie ma treści. W codziennej pracy błąd często umyka, bo w przeglądarce strona wygląda bez zarzutu.

Założenie, że widoczność dla Googlebota wystarczy: nawet jeśli Googlebot wyrenderuje stronę JavaScript, nie dotyczy to crawlerów AI. Kto optymalizuje wyłącznie pod zachowanie Googlebota, ignoruje rosnący udział ruchu z ChatGPT, Perplexity i podobnych systemów.

Hurtowe blokowanie crawlerów bez rozważenia skutków: w pliku robots.txt można pojedynczo dopuszczać lub blokować GPTBota, ClaudeBota, PerplexityBota, Google-Extended i inne crawlery AI. Kluczowa jest różnica między crawlerami treningowymi a wyszukującymi. Zablokowanie GPTBota lub ClaudeBota sygnalizuje przede wszystkim, że treści nie powinny być używane do trenowania modeli. Google-Extended steruje trenowaniem i groundingiem dla Gemini, a nie wyszukiwarką Google. Dla widoczności w wyszukiwarce ChatGPT liczy się OAI-SearchBot, w Claude Claude-SearchBot, a w Perplexity PerplexityBot. ChatGPT-User i Claude-User pobierają strony tylko na żądanie użytkownika; w przypadku ChatGPT-User robots.txt według OpenAI może nie obowiązywać. Google AI Overviews wymagają, aby strona była w indeksie Google i mogła być wyświetlana ze snippetem; steruje się tym przez dostęp Googlebota w pliku robots.txt oraz przez noindex, nosnippet, data-nosnippet i max-snippet. Kto chce być cytowany w odpowiedziach AI, dopuszcza co najmniej crawlery wyszukujące. Ten wybór między kontrolą a widocznością warto podjąć świadomie, a nie przypadkiem, przez zbyt restrykcyjną konfigurację.

Niedocenianie obciążenia JavaScriptem: duże bundle po stronie klienta pogarszają widoczność w AI i wydajność. Mediana payloadu JavaScript wynosi 558 kilobajtów na urządzeniach mobilnych i 613 kilobajtów na desktopie, przy czym około 44% (206 kilobajtów) dostarczonych bajtów pozostaje niewykorzystanych podczas ładowania. Ten niewykorzystany balast obciąża przede wszystkim Largest Contentful Paint i Interaction to Next Paint.

Metryki i pomiar

Porównanie samego HTML z wyrenderowanym DOM: najszybszy test polega na porównaniu surowego HTML z wyrenderowanym DOM. W źródle strony lub przez proste pobranie HTML można sprawdzić, czy główna treść jest obecna już bez JavaScriptu. Jeśli tekstu brakuje w źródle, ale pojawia się w wersji wyrenderowanej, mamy do czynienia z problemem CSR. Test wyników z elementami rozszerzonymi Google i raport sprawdzania adresu URL w Search Console pokazują, co Google widzi po wyrenderowaniu. Crawler taki jak Screaming Frog z włączonym renderowaniem JavaScriptu potrafi systematycznie pokazać różnicę między wersją surową a wyrenderowaną.

Analiza botów AI w logach serwera: analiza logów serwera pokazuje, które crawlery AI faktycznie pobierają stronę, jakie adresy URL odwiedzają i jaki mają odsetek błędów 404. Wysokie wskaźniki błędów wskazują na nieaktualne linki w mapach witryn lub nieefektywną strukturę. Te dane są najbardziej bezpośrednim dowodem na to, jak systemy AI postrzegają Twoją domenę.

Uwzględnienie opóźnienia indeksacji: nawet w przypadku Google JavaScript powoduje mierzalną stratę czasu. W jednym z eksperymentów Googlebot potrzebował około dziewięć razy więcej czasu na crawling stron JavaScript niż czystych stron HTML, konkretnie 313 godzin wobec 36 godzin dla tej samej liczby stron. Również link wewnętrzny wstawiony przez JavaScript Googlebot odwiedził wyraźnie wolniej: po 52 godzinach wobec 25 godzin w przypadku linku HTML. To opóźnienie w modelu dwóch fal wydłuża czas do indeksacji i przy aktualnych treściach kosztuje zasięg.

Monitorowanie Core Web Vitals: wydajność pozostaje samodzielnym sygnałem jakości. Obecnie 48% stron mobilnych i 56% stron desktopowych przechodzi wszystkie trzy Core Web Vitals, przy czym dobry Largest Contentful Paint osiąga tylko 62% stron mobilnych wobec 74% na desktopie. Code splitting, odraczanie niekrytycznego JavaScriptu i oszczędna strategia hydratacji zmniejszają obciążenie po stronie klienta i jednocześnie poprawiają LCP oraz INP.

Konsekwencje GEO dla rynku austriackiego

Dla austriackiego rynku B2B luka w widoczności ma konkretne znaczenie. Zasięg kanałów cyfrowych jest wysoki: w styczniu 2025 r. w Austrii było około 8,69 mln internautów przy penetracji na poziomie 95,3%. Jednocześnie klasyczne wyszukiwanie pozostaje dominujące. W maju 2026 r. Google ma w Austrii około 82% udziału w rynku, a za nim plasuje się Bing z około 9%. Ponieważ Bing zasila odpowiedzi AI w Microsoft Copilot, a Google wyświetla AI Overviews, treść dostarczana po stronie serwera i dobrze ustrukturyzowana trafia do obu światów: klasycznego wyszukiwania i generatywnych systemów odpowiedzi.

Kto optymalizuje pod widoczność w ChatGPT, Perplexity, Gemini i Google AI Overviews, ten jednocześnie uprawia solidne techniczne SEO. Wymagania się pokrywają: czytelny HTML, osadzone dane strukturalne, szybkie dostarczanie i struktura linków dostępna dla crawlerów. Server-Side Rendering jest wspólnym mianownikiem. Gwarantuje, że treść istnieje zarówno dla renderującego Googlebota, jak i dla nierenderujących crawlerów AI, które coraz częściej współdecydują o tym, jakie marki pojawiają się w odpowiedziach AI.

Dalsza lektura

Renderowanie JavaScriptu nie jest więc odizolowanym tematem frontendowym, lecz kluczową dźwignią wyszukiwalności. Warto zgłębić architekturę SEO w Next.js z App Routerem i Server Components, celowe zarządzanie crawlerami AI przez robots.txt oraz IndexNow i mapy witryn XML jako akceleratory efektywnego crawlingu. Kto oprze te elementy na fundamencie renderowania po stronie serwera, zamknie lukę w widoczności, zamiast ją pogłębiać.