Twoja strona rankuje w Google, ale ChatGPT jej nie widzi – czym jest Rendering Gap w SEO?

Twoja strona może mieć dobre pozycje w Google, poprawny content, schema markup i sensowny profil linkowy. A mimo to część crawlerów AI może nie widzieć jej najważniejszej treści.

Problem szczególnie często dotyczy stron opartych o JavaScript: React, Vue, Angular, SPA albo Next.js bez prawidłowego SSR/SSG. W przeglądarce wszystko wygląda dobrze, ale w surowej odpowiedzi HTML może nie być głównego tekstu, oferty, FAQ, cen, opisów produktów ani danych strukturalnych.

Temat jest ważny dla widoczności w narzędziach AI, bo część crawlerów AI nie wykonuje JavaScriptu. Googlebot potrafi renderować JS, ale crawlery takie jak GPTBot, ClaudeBot czy PerplexityBot według analizy Vercel/MERJ nie renderują JavaScriptu, dlatego najważniejszy content powinien być dostępny już w raw HTML.

Rendering Gap to różnica między tym, co użytkownik widzi po załadowaniu strony w przeglądarce, a tym, co crawler widzi w surowej odpowiedzi HTML. W klasycznej stronie HTML główny content znajduje się od razu w kodzie źródłowym. Crawler pobiera adres URL i widzi treść: H1, akapity, nagłówki, linki, FAQ, ceny, opisy produktów i dane strukturalne.

W nowoczesnych aplikacjach JavaScript często wygląda to inaczej. Serwer może wysłać tylko pusty szkielet strony, na przykład:

<div id="root"></div>
<script src="/app.js"></script>

Dopiero przeglądarka użytkownika pobiera pliki JavaScript, wykonuje kod, odpytuje API i buduje finalny widok strony. Człowiek widzi gotową stronę. Crawler, który nie wykonuje JavaScriptu, widzi tylko pustą powłokę.

To właśnie Rendering Gap.

Dlaczego Google widzi stronę, a ChatGPT może jej nie widzieć?

Googlebot działa inaczej niż wiele crawlerów AI. Google Search przetwarza strony JavaScriptowe w trzech etapach: crawling, rendering i indexing. Google oficjalnie informuje, że Google Search uruchamia JavaScript przy użyciu evergreen Chromium.

Przeczytaj: jak działa wyszukiwarka Google?

W 2019 roku Googlebot przeszedł na evergreen Chromium, czyli najnowszą stabilną wersję silnika Chromium do renderowania stron. Dzięki temu Googlebot może przetwarzać wiele nowoczesnych aplikacji JavaScriptowych znacznie lepiej niż klasyczne crawlery tekstowe.

Crawlery AI mogą działać inaczej. Analiza Vercel/MERJ wskazuje, że crawlery OpenAI, Anthropic i Perplexity nie wykonują JavaScriptu. Mogą pobierać pliki JS, ale nie oznacza to, że uruchamiają kod i widzą finalny DOM tak jak przeglądarka.

Dlatego strona może być dobrze zaindeksowana w Google, ale jednocześnie mieć słabą widoczność dla systemów, które bazują głównie na raw HTML.

Które crawlery AI renderują JavaScript?

System / asystent	Background crawling / crawler	Live grounding według Search Engine World	Wniosek praktyczny
ChatGPT / OpenAI	Vercel/MERJ: brak JS rendering dla crawlerów OpenAI	raw HTML	Kluczowa treść w HTML
Claude	Vercel/MERJ: brak JS rendering	raw HTML	Kluczowa treść w HTML
Perplexity	Vercel/MERJ: brak JS rendering	raw HTML / deklaracje mogą się mylić	Testować logami
Gemini	Googlebot renderuje JS; Vercel/MERJ wskazuje infrastrukturę Googlebota	raw HTML w teście live URL	Nie zakładać renderowania w czacie
Microsoft Copilot	Bingbot może renderować JS z ograniczeniami	pobrał JS przez Diffbot, ale nie wykonał	Raw HTML nadal kluczowy
Meta AI	brak mocnej oficjalnej deklaracji JS rendering	raw HTML	Raw HTML
Grok	przypadek pośredni	JS wykonany na jednym nodzie, ale odpowiedź z raw HTML	Log ≠ odpowiedź modelu
Mistral	zależy od trybu	wykonał JS w teście	Nadal warto mieć HTML
DeepSeek / ERNIE / Qwen / Kimi	zależy od systemu	wykonały JS w teście	Mniej ryzykowne, ale nie gwarancja

Nie wszystkie crawlery AI działają tak samo. Dlatego nie warto pisać ogólnie, że „AI nie renderuje JavaScriptu”. Bezpieczniej rozdzielić systemy.

Live grounding a background crawling – ważna różnica

W widoczności AI trzeba rozróżnić dwa scenariusze:

• Background Crawling – sytuacja, w której crawler, taki jak GPTBot, ClaudeBot, PerplexityBot, Googlebot czy Bingbot, samodzielnie pobiera strony do indeksu, systemu wyszukiwania, treningu lub warstwy retrieval.
• Live Grounding – sytuacja, w której użytkownik wkleja konkretny URL do asystenta AI i prosi: „streść tę stronę”, „sprawdź ten produkt”, „podaj cenę z tej podstrony”.

To rozróżnienie jest kluczowe, bo asystent może zachowywać się inaczej w trybie indeksowania, a inaczej w trybie jednorazowego odczytu linku w czacie.

W teście Search Engine World sprawdzono właśnie live grounding. Autorzy przygotowali strony testowe, w których raw HTML zawierał wartość-fałszywkę, a prawdziwa wartość pojawiała się dopiero po wykonaniu JavaScriptu. Następnie wkleili unikalne URL-e do 12 asystentów AI i sprawdzili logi serwera: czy asystent pobrał HTML, czy pobrał plik JS i czy faktycznie wykonał kod.

Wynik testu był ważny praktycznie: ChatGPT, Claude, Gemini, Perplexity, Meta AI i Microsoft Copilot odpowiedziały na podstawie raw HTML, bez użycia wartości dostępnej dopiero po wykonaniu JavaScriptu. Z kolei DeepSeek, ERNIE, Qwen, Kimi i Mistral zwróciły wartość po wykonaniu JS. Grok miał przypadek pośredni: jeden z jego nodów wykonał JavaScript, ale odpowiedź nadal bazowała na wartości z raw HTML.

Skala problemu: czego uczy badanie „A Third Of Fintech Is Invisible To AI Agents„?

W maju 2026 roku przeanalizowano 274 homepage’y firm fintech z listy CNBC World’s Top Fintech Companies 2025. Pomiar porównywał surową odpowiedź HTTP bez JavaScriptu z pełnym renderowaniem w przeglądarce przez Playwright.

Wyniki badania:

• 36% badanych homepage’y zwracało mniej niż 80% finalnej treści w raw HTML,
• 55 stron zwracało mniej niż 30% treści bez JavaScriptu,
• 47 stron zwracało zero czytelnej treści w raw HTML,
• 273 z 274 stron osiągały ponad 80% widoczności po renderowaniu w przeglądarce.

To nie znaczy, że „36% badanych stron było niewidoczne dla każdego AI”. Badanie dotyczyło homepage’y, jednego dnia, jednej grupy stron i konkretnej metodologii. Sam autor badania zaznacza ograniczenia: pomiar obejmował tylko strony główne, jeden region i nie obejmował podstron wewnętrznych.

Wniosek jest jednak ważny: strona może działać poprawnie dla użytkownika, a jednocześnie zwracać bardzo mało treści w raw HTML.

Jak sprawdzić, czy strona jest widoczna dla crawlerów AI?

Nie trzeba zaczynać od dużego audytu technicznego. Pierwszy test zajmuje kilka minut.

Metoda 1 – curl

W terminalu wpisz:

curl -s "https://twoja-strona.pl/kluczowa-podstrona" | grep -i "kluczowa fraza"

Interpretacja:

• jeśli fraza pojawia się w odpowiedzi, prawdopodobnie jest dostępna w raw HTML;
• jeśli frazy nie ma, istnieje ryzyko, że treść jest ładowana dopiero przez JavaScript;
• wynik negatywny nie jest jeszcze ostatecznym dowodem, bo treść może znajdować się w JSON-ie, danych RSC albo innym fragmencie odpowiedzi HTML.

Dla dokładniejszej analizy warto zapisać cały HTML:

curl -s "https://twoja-strona.pl/kluczowa-podstrona" > raw-html.txt

Następnie sprawdź, czy w pliku są:

• H1,
• główny opis usługi,
• sekcje ofertowe,
• FAQ,
• linki wewnętrzne,
• dane strukturalne JSON-LD,
• treść, którą chcesz pokazać crawlerom.

Metoda 2 – canary test dla AI assistantów

Jeśli chcesz sprawdzić, czy asystent AI faktycznie pobrał Twoją stronę, możesz użyć prostego testu typu canary.

Dodaj na testowej podstronie unikalny ciąg znaków, którego nie ma nigdzie indziej w internecie, na przykład:

adspectra-canary-rendering-gap-2026-x9k27

Następnie wklej URL do asystenta AI i poproś go o streszczenie strony albo odnalezienie konkretnej informacji. Jeśli asystent zwróci canary, oznacza to, że faktycznie pobrał treść strony. Jeśli nie zwróci canary albo opisze stronę ogólnie, nie masz dowodu, że ją przeczytał.

Jeszcze lepszy test polega na umieszczeniu jednej wartości w raw HTML i innej wartości dopiero po wykonaniu JavaScriptu. Jeśli asystent zwraca wartość z raw HTML, nie użył wyrenderowanej wersji strony.

Metoda 3 – View Source

Otwórz stronę w przeglądarce, kliknij prawym przyciskiem i wybierz „Wyświetl źródło strony” albo użyj skrótu:

Ctrl + U

Jeśli w źródle widzisz tylko pusty kontener aplikacji i skrypty, a nie widzisz głównego contentu, to sygnał ostrzegawczy.

Metoda 4 – wyłącz JavaScript

W Chrome możesz zablokować JavaScript w ustawieniach witryny, odświeżyć stronę i sprawdzić, co zostaje widoczne. To nie jest idealna symulacja każdego crawlera AI, ale bardzo dobrze pokazuje, czy strona ma podstawową niezależność od renderowania.

Metoda 5 – porównaj raw HTML i rendered HTML

Najdokładniejsza metoda to porównanie:

• HTML z curl,
• HTML po wyrenderowaniu w przeglądarce, np. przez Playwright, Puppeteer albo narzędzia SEO obsługujące JavaScript rendering.

Jeśli różnica jest duża, masz Rendering Gap.

Nie ufaj temu, co chatbot mówi o własnym dostępie do strony

W testach widoczności AI nie wystarczy zapytać asystenta: „czy widzisz tę stronę?” albo „czy wykonałeś JavaScript?”.

Search Engine World pokazało, że odpowiedź asystenta może nie zgadzać się z logami serwera. W jednym przypadku Perplexity twierdziło, że nie mogło uzyskać dostępu do strony, mimo że serwer odnotował rzeczywiste pobranie URL-a. W innym przypadku Grok wykonał JavaScript na jednym z nodów, ale końcowa odpowiedź i tak bazowała na raw HTML.

Dlatego w audycie GEO i AI visibility najważniejsze są:

• raw HTML,
• logi serwera,
• testy canary,
• porównanie HTML przed i po renderowaniu,
• nie deklaracje samego asystenta.

Co znika ze strony, gdy crawler nie wykonuje JavaScriptu?

Najczęściej niewidoczne są elementy ładowane komponentowo albo po stronie klienta.

Dotyczy to szczególnie:

• H1 i tekstu hero,
• opisów usług,
• opisów produktów,
• cen,
• specyfikacji,
• opinii klientów,
• FAQ,
• treści w tabach i akordeonach,
• CTA,
• linków wewnętrznych,
• danych z API,
• breadcrumbs,
• danych strukturalnych JSON-LD wstrzykiwanych przez JavaScript.

Ostatni punkt jest szczególnie ważny. Schema Markup powinien być dostępny w HTML, najlepiej w <head> albo w stabilnym fragmencie dokumentu. Jeśli JSON-LD pojawia się dopiero po wykonaniu JavaScriptu, część crawlerów może go nie zobaczyć.

Jak naprawić Rendering Gap?

Celem nie jest rezygnacja z Reacta, Vue, Angulara czy Next.js. Celem jest to, żeby najważniejsza treść była dostępna już w odpowiedzi HTML.

1. SSR – Server-Side Rendering

SSR oznacza, że strona jest renderowana po stronie serwera, a crawler otrzymuje gotowy HTML.

To najlepsze rozwiązanie dla stron, które mają dynamiczną treść, ale muszą być widoczne dla crawlerów:

• strony usług,
• landing pages,
• e-commerce,
• katalogi produktów,
• marketplace’y,
• strony z ofertą,
• artykuły i poradniki z dynamicznymi elementami.

W Next.js oznacza to prawidłowe wykorzystanie renderowania po stronie serwera albo server components, zależnie od wersji i architektury projektu.

2. SSG – Static Site Generation

SSG generuje gotowy HTML w czasie buildu. To bardzo dobre rozwiązanie dla treści, które nie zmieniają się co minutę:

• blogi,
• poradniki,
• dokumentacje,
• strony kategorii,
• strony usług,
• strony edukacyjne.

Przykłady narzędzi i frameworków:

• Next.js,
• Astro,
• Gatsby,
• Nuxt,
• Hugo,
• Eleventy.

3. Pre-rendering

Pre-rendering tworzy statyczną wersję HTML dla crawlerów i użytkowników, którzy trafiają na stronę bez pełnego środowiska JS. To może być praktyczne rozwiązanie dla istniejących aplikacji SPA, gdzie pełna migracja na SSR nie jest możliwa od razu.

4. Quickwin: kluczowe treści bezpośrednio w HTML

Jeżeli pełna przebudowa nie jest teraz możliwa, zacznij od najważniejszych elementów:

• H1,
• główny opis usługi,
• 2–3 akapity opisujące ofertę,
• najważniejsze USP,
• linki wewnętrzne,
• FAQ,
• JSON-LD,
• dane kontaktowe,
• CTA.

W prostych projektach taki quickwin może zająć 1–2 dni. W większych aplikacjach wymaga pracy deweloperskiej, testów i kontroli regresji.

Rendering Gap a SEO, AIO i GEO

Rendering Gap jest problemem technicznym, ale jego skutki są strategiczne.

W klasycznym SEO można było częściowo polegać na tym, że Googlebot wyrenderuje JavaScript. Google sam opisuje proces renderowania i indeksowania stron JS.

W AIO i GEO sytuacja jest szersza. ChatGPT, Claude, Perplexity, Common Crawl, narzędzia agentowe i inne systemy mogą korzystać z różnych crawlerów, datasetów i warstw pobierania treści. Nie można zakładać, że każdy z nich będzie działał jak Googlebot.

To dotyczy szczególnie:

• stron B2B,
• fintech,
• SaaS,
• e-commerce,
• stron usług lokalnych,
• stron opartych o React/Next.js,
• portali z dynamicznymi listingami,
• stron z contentem ładowanym z API,
• marek, które chcą być cytowane przez AI Search.

Rendering Gap – co warto wiedzieć:

Potwierdzone w źródłach:

• Googlebot renderuje JavaScript przy użyciu evergreen Chromium i Google opisuje proces crawling → rendering → indexing dla aplikacji JavaScriptowych.
• Vercel/MERJ wskazują, że crawlery OpenAI, Anthropic i Perplexity nie renderują JavaScriptu, a Gemini korzysta z infrastruktury Googlebota.
• Badanie 274 homepage’y fintech pokazało istotną różnicę między raw HTML a pełnym renderowaniem dla części badanych stron.
• Bingbot według Microsoftu generalnie potrafi renderować JavaScript, ale Microsoft wskazuje ograniczenia skali i wsparcia dla frameworków.

Nasze wnioski:

• Rendering gap będzie coraz ważniejszym elementem audytu SEO, AIO i GEO.
• Strony oparte o client-side rendering powinny być audytowane nie tylko pod Googlebota, ale też pod raw HTML, AI crawlery i widoczność treści bez JS.
• SSR, SSG i pre-rendering są bezpieczniejsze dla AI visibility niż aplikacje, w których główny content pojawia się dopiero po stronie klienta.
• Nawet gdy dany ekosystem potrafi renderować JavaScript w trybie indeksowania, jego asystent może w trybie live grounding nadal odpowiedzieć na podstawie raw HTML. Dlatego dla GEO ważniejsze od samego pytania „czy crawler renderuje JS?” jest pytanie: „czy najważniejszy content istnieje w HTML zanim uruchomi się JavaScript?”.

Podsumowanie

Rendering Gap to problem, który może sprawić, że strona wygląda świetnie dla użytkownika i rankuje w Google, ale jest słabo czytelna dla części crawlerów AI.

Nie wszystkie systemy działają tak samo. Googlebot renderuje JavaScript, Gemini według Vercel/MERJ korzysta z infrastruktury Googlebota, a AppleBot również renderuje strony. Ale crawlery OpenAI, Anthropic i Perplexity w analizie Vercel/MERJ nie wykonywały JavaScriptu. Dlatego bezpieczna strategia techniczna jest prosta: najważniejszy content powinien być dostępny w raw HTML.

W erze AI Search widoczność nie zaczyna się od promptów, schema ani narzędzi GEO. Zaczyna się od pytania: czy crawler może przeczytać stronę bez uruchamiania JavaScriptu?

Jako agencja SEO sprawdzamy Rendering Gap jako część audytu technicznego. Jeśli chcesz wiedzieć, czy Twoja strona jest widoczna dla AI — skontaktuj się z nami.

Źródła wiedzy

• Gradient Group – badanie 274 homepage’y fintech porównujące raw HTTP fetch z pełnym renderowaniem w przeglądarce.
• Search Engine World – test 12 asystentów AI w scenariuszu live grounding po ręcznym wklejeniu URL-a, z porównaniem raw HTML, pobrania pliku JavaScript i faktycznego wykonania kodu w logach serwera.
  https://www.searchengineworld.com/do-ai-assistants-actually-render-your-javascript-when-grounding-we-put-it-to-the-test
• Google Search Central – dokumentacja JavaScript SEO, opis procesu crawling, rendering i indexing oraz informacja, że Google Search uruchamia JavaScript przy użyciu evergreen Chromium.
• Google Search Central Blog – informacja o przejściu Googlebota na evergreen Chromium i używaniu najnowszej stabilnej wersji Chromium do renderowania stron.
• Vercel / MERJ – analiza zachowania crawlerów AI, w tym OpenAI, Anthropic, Perplexity, Gemini, AppleBot i Common Crawl, oraz ich podejścia do JavaScript rendering.
• Bing Webmaster Blog – informacja, że Bingbot generalnie potrafi renderować JavaScript, ale ma ograniczenia dotyczące skali i obsługi niektórych frameworków.