Ekspert JavaScript SEO

Ekspert JavaScript SEO – renderowanie, indeksacja i widoczność dla botów AI

Diagnozuję, co roboty Google i crawlery AI naprawdę widzą na Twoim serwisie opartym o React, Vue, Next.js czy Nuxt – i co jest dla nich niewidzialne.
Nie zgaduję: prowadzę własne laboratorium badawcze JavaScript SEO i pracuję na zmierzonych danych, nie na poradnikach.

  • Prowadzę jsseo.dev – laboratorium mierzące zachowanie ponad 27 klas botów (Googlebot, Bingbot, crawlery AI) na treściach renderowanych w JavaScript. Pre-rejestrowane hipotezy, otwarte dane.
  • Audytowałem serwisy JS liczone w milionach podstron (Nuxt + Varnish + Cloudflare, 3M+ URL-i), łącznie z analizą logów serwera i porównaniem raw vs rendered HTML w skali całego serwisu.
  • Prowadzę wymagania SEO przy migracjach headless (m.in. Magento → Nuxt 3): routing, architektura URL-i filtrów, dynamiczny routing, dane strukturalne.
  • 25+ lat w SEO, w tym jako Head of SEO w Onet (RASP) i Wyborcza.pl – wiem, jak rozmawiać z zespołami dev, żeby rekomendacje weszły do sprintu, a nie do szuflady.
  • Badam widoczność treści JS dla crawlerów AI (ChatGPT, Perplexity, Claude, NotebookLM) – obszar, w którym większość serwisów SPA jest dziś niewidzialna i nawet o tym nie wie.

Zgłoś swój serwis do analizy

Napisz, jakiego frameworka używasz i co Cię boli. Skontaktuję się w ciągu 24 godzin.

W czym pomagam

  • Diagnoza renderowania: porównanie raw HTML vs rendered DOM w skali serwisu – co Googlebot widzi od razu, co po renderowaniu, a czego nie widzi wcale.
  • Widoczność dla crawlerów AI: audyt tego, co z Twoich treści JS widzą boty ChatGPT, Perplexity i innych asystentów – na podstawie zmierzonych zachowań z jsseo.dev, nie deklaracji vendorów.
  • Strategia renderowania: SSR, SSG, ISR czy hydracja częściowa – dobór do typu podstron (produkty, kategorie, content) zamiast jednej religii dla całego serwisu.
  • Migracje headless: formalna specyfikacja wymagań SEO dla zespołu dev – routing, canonicale i metadane w initial HTML, linkowanie na elementach <a href>, architektura URL-i filtrów.
  • Crawl budget i logi serwera: jak Googlebot faktycznie chodzi po Twoim serwisie JS – częstotliwości, ślepe zaułki, koszt renderowania.
  • Wsparcie zespołu dev: rekomendacje jako backlog gotowy do sprintu, z kryteriami akceptacji i weryfikacją po wdrożeniu.

Dla kogo i kiedy to ma sens?

  • Serwis na React / Vue / Angular / Next.js / Nuxt ma problemy z indeksacją: podstrony nie wchodzą do indeksu albo wypadają.
  • Planujesz migrację headless i chcesz specyfikacji wymagań SEO zanim dev zacznie kodować, a nie audytu strat po wdrożeniu.
  • Ruch z ChatGPT, Perplexity i AI Overviews rośnie w Twojej branży, a Twój serwis SPA jest dla tych systemów niewidoczny.
  • Dev mówi „Google renderuje JavaScript, nie ma problemu”, a dane z GSC mówią co innego – potrzebujesz rozstrzygnięcia na dowodach.
  • E-commerce z nawigacją fasetową na froncie JS: chaos w parametrach, kanonikalizacji i crawl budget.
  • Software house / agencja buduje serwisy JS dla klientów i chce mieć wytyczne SEO w standardzie projektowym zamiast gaszenia pożarów.

Czym jest JavaScript SEO?

JavaScript SEO to dziedzina technicznego SEO zajmująca się tym, aby treści renderowane przez JavaScript – w frameworkach takich jak React, Vue, Angular, Next.js czy Nuxt – były widoczne, renderowalne i indeksowalne dla robotów wyszukiwarek oraz crawlerów AI. Różnica względem klasycznego SEO sprowadza się do jednego pytania: czy treść istnieje w initial HTML, czy powstaje dopiero po wykonaniu kodu w przeglądarce.

Googlebot potrafi renderować JavaScript, ale robi to z opóźnieniem i kosztem, który rośnie ze skalą serwisu. Crawlery AI to inna liga: większość botów zbierających treści dla ChatGPT, Perplexity czy podobnych systemów nie wykonuje JavaScriptu w ogóle – widzą wyłącznie surowy HTML. Serwis SPA, który „jakoś działa” w Google, bywa całkowicie pusty dla systemów odpowiedzi AI. Dokładnie te różnice mierzę w jsseo.dev: osiem wzorców osadzania treści, ponad 27 klas botów, pre-rejestrowane hipotezy i otwarte dane.

Proces w 5 krokach

  • Brief techniczny → framework, sposób renderowania, skala serwisu, objawy (indeksacja, spadki, migracja).
  • Crawl porównawczy → raw HTML vs rendered DOM na próbie szablonów + dane GSC i logi (jeśli dostępne).
  • Diagnoza + backlog → co jest niewidoczne, dla których botów i dlaczego; zadania z priorytetami P0–P2 dla dev.
  • Omówienie z dev → wspólny przegląd backlogu, kryteria akceptacji, odpowiedzi na pytania zespołu.
  • Weryfikacja po wdrożeniu → kontrola renderowania i indeksacji po poprawkach + krótkie podsumowanie.

Najczęściej zadawane pytania (FAQ)

Czy Google renderuje JavaScript?

Tak, Googlebot renderuje JavaScript w oparciu o aktualną wersję Chromium. Ale renderowanie ma koszt i kolejkę – przy dużych serwisach opóźnienia i budżet renderowania robią realną różnicę, a każdy błąd JS może zostawić bota z pustym szablonem. „Google renderuje JS” i „Google widzi wszystko na moim serwisie” to dwa różne zdania – to drugie trzeba zmierzyć, nie założyć.

Czy crawlery AI (ChatGPT, Perplexity) wykonują JavaScript?

W większości nie. Boty zbierające treści dla systemów AI zwykle pobierają wyłącznie surowy HTML, bez wykonywania skryptów – treść dostarczana client-side jest dla nich niewidoczna. To mierzalne zachowanie, które badam w laboratorium jsseo.dev na ponad 27 klasach botów. Praktyczny wniosek: serwis SPA bez SSR/SSG może być obecny w Google i jednocześnie nie istnieć dla AI Overviews, ChatGPT czy Perplexity.

SSR, SSG czy CSR – co wybrać?

Zależy od typu podstrony, nie od mody. Treści, które mają rankować i być cytowane przez AI (produkty, kategorie, artykuły), powinny istnieć w initial HTML – przez SSR, SSG albo ISR. Elementy interaktywne bez wartości SEO mogą zostać client-side. Najdroższy błąd to jedna strategia renderowania dla całego serwisu, wybrana bez sprawdzenia, które podstrony na tym tracą.

Czy „dwuetapowe indeksowanie” (two-wave indexing) nadal obowiązuje?

Model dwóch fal opisywał stan sprzed lat i Google od dawna komunikuje, że mediana czasu do renderowania to sekundy, nie tygodnie. Problem nie zniknął, ale zmienił postać: dziś chodzi o koszt renderowania w skali, błędy JS zostawiające pusty DOM i o boty, które nie renderują wcale (crawlery AI). Diagnoza „macie problem z two-wave indexing” w 2026 roku to zwykle sygnał przestarzałej wiedzy.

Jak sprawdzić, co Googlebot widzi na mojej stronie?

Podstawa: URL Inspection w Google Search Console i porównanie surowego HTML z wyrenderowanym widokiem. W skali serwisu: crawl z renderowaniem (Screaming Frog / Sitebulb) i zestawienie raw vs rendered dla każdego szablonu. Do tego logi serwera – pokazują, jak bot faktycznie chodzi po serwisie, a nie jak powinien.

Czy prerendering (np. dynamic rendering) to dobre rozwiązanie?

To obejście, nie rozwiązanie – Google oficjalnie odradza dynamic rendering jako podejście długoterminowe. Bywa sensownym mostem na czas migracji, ale docelowo treść powinna istnieć w initial HTML dla wszystkich botów jednakowo, bez rozpoznawania user-agentów.

Pracujesz z naszym zespołem dev czy zamiast niego?

Z zespołem. Dostarczam diagnozę, backlog z priorytetami i kryteria akceptacji, potem weryfikuję wdrożenia. Nie piszę kodu produkcyjnego za dev – piszę wymagania tak, żeby dev nie musiał zgadywać, o co chodzi.

Ile to kosztuje?

Wycena zależy od skali serwisu i zakresu (diagnoza jednorazowa vs wsparcie migracji). Punktem wejścia mogą być też konsultacje SEO – godzina rozmowy często wystarcza, żeby ustalić, czy problem w ogóle leży w JavaScript.

Kto stoi za tą stroną: Jakub Sawa

Jakub Sawa to konsultant SEO specjalizujący się w JavaScript SEO, Google Discover i technicznych audytach dużych serwisów. Prowadzi jsseo.dev – laboratorium badawcze mierzące zachowanie botów Google i crawlerów AI na treściach renderowanych w JavaScript, z pre-rejestrowanymi hipotezami i otwartymi danymi. Były Head of SEO w Ringier Axel Springer Polska (Onet, Newsweek, Fakt) i dyrektor ds. wzrostu w Agorze (Wyborcza.pl). W SEO od 1997 roku. Zobacz też: audyt techniczny SEO i konsultacje SEO.