Audyt JavaScript SEO – renderowanie, indeksacja, widoczność dla botów AI
Sprawdzę, co roboty Google i crawlery AI naprawdę widzą na Twoim serwisie opartym o React, Vue, Next.js czy Nuxt – porównanie raw HTML vs rendered DOM w skali serwisu, nie na pojedynczym URL-u. Otrzymasz raport z priorytetami P0–P2, backlog gotowy dla zespołu dev oraz jednorazową kontrolę wdrożeń w cenie.
Prowadzę jsseo.dev – laboratorium mierzące zachowanie ponad 27 klas botów na treściach JavaScript. Rekomendacje opieram na zmierzonych zachowaniach botów, nie na deklaracjach z dokumentacji.
Audytowałem serwisy JS liczone w milionach podstron (Nuxt, 3M+ URL-i), z analizą logów serwera i porównaniem raw vs rendered HTML na poziomie szablonów.
Badam widoczność treści JS dla crawlerów AI (ChatGPT, Perplexity i inne) – większość z nich nie wykonuje JavaScriptu, a to znaczy, że część serwisów SPA jest dla systemów odpowiedzi niewidzialna.
Prowadziłem wymagania SEO przy migracjach headless (m.in. Magento → Nuxt 3) – wiem, jak wygląda styk SEO z realnym sprintem zespołu dev.
25+ lat w SEO, w tym jako Head of SEO w Onet (RASP) i Wyborcza.pl. Audyt robię osobiście, bez podwykonawców.
Zgłoś Twój serwis do audytu
Skontaktuję się w ciągu 24 godzin.
Co dokładnie dostaniesz
Raport audytowy (PDF/Slides) z priorytetyzacją P0–P2. Każde ustalenie: co znalazłem, dowód (zrzut raw vs rendered, dane GSC), co z tym zrobić.
Macierz widoczności: szablon × bot – które typy podstron są widoczne dla Googlebota, a które dla crawlerów AI, i gdzie treść ginie.
Backlog dla dev: zadania z priorytetami, kryteriami akceptacji i uzasadnieniem – copy-paste do Jiry, bez tłumaczenia „co poeta miał na myśli”.
Rekomendacja strategii renderowania per typ podstrony: SSR / SSG / ISR / hydracja – z uzasadnieniem kosztowym, nie ideologicznym.
Quick Wins 14–30 dni: poprawki bez przebudowy architektury (metadane i canonicale w initial HTML, linki na <a href>, błędy JS blokujące render).
Jednorazowa kontrola wdrożeń + krótki raport po poprawkach.
Dla kogo i kiedy to ma sens?
Serwis na React / Vue / Angular / Next.js / Nuxt: podstrony nie wchodzą do indeksu, wypadają albo indeksują się z opóźnieniem.
Przed migracją headless: audyt jako preflight, żeby wymagania SEO weszły do specyfikacji, a nie do listy strat po wdrożeniu.
Po migracji na framework JS ruch spadł i nikt nie potrafi wskazać, która warstwa (render, routing, metadane) za to odpowiada.
Zależy Ci na widoczności w AI Overviews, ChatGPT, Perplexity – a nie wiesz, czy Twoje treści JS w ogóle do nich docierają.
E-commerce z nawigacją fasetową na froncie JS: filtry, parametry i kanonikalizacja pożerają crawl budget.
Dev i SEO spierają się o renderowanie – potrzebujecie rozstrzygnięcia na dowodach, nie na opiniach.
Zakres audytu (co analizuję)
Raw HTML vs rendered DOM: crawl porównawczy na wszystkich typach szablonów – co istnieje w initial HTML, co powstaje po renderze, czego nie ma nigdzie.
Metadane i canonicale: czy title, description, canonical i dane strukturalne istnieją w initial HTML, czy są wstrzykiwane asynchronicznie.
Linkowanie i routing: linki jako elementy <a href> vs zdarzenia onClick, obsługa historii, dostępność ścieżek dla crawlera.
Widoczność dla crawlerów AI: co z Twoich treści widzą boty niewykonujące JavaScriptu – zestawienie per szablon, na bazie zmierzonych zachowań botów z jsseo.dev.
Błędy JS i wydajność renderu: skrypty wywalające render, zasoby blokowane w robots.txt, timeouty, koszt renderowania w skali serwisu.
Logi serwera (jeśli dostępne): jak Googlebot faktycznie chodzi po serwisie JS – częstotliwości, ślepe zaułki, marnowany crawl budget na parametrach.
Proces w 5 krokach
Kick-off & dostępy → GSC (odczyt), lista szablonów, opcjonalnie logi serwera i staging.
Crawl porównawczy → raw vs rendered na próbie szablonów + weryfikacja w URL Inspection i danych GSC.
Omówienie z dev/SEO → przegląd backlogu z zespołem, kryteria akceptacji, pytania.
Kontrola wdrożeń → weryfikacja renderowania i indeksacji po poprawkach + krótkie podsumowanie.
Czas realizacji: zwykle 1–4 tygodnie (zależnie od wielkości serwisu i dostępów).
Wymagane dostępy (żeby zrobić to porządnie)
Google Search Console (odczyt).
Lista typów szablonów i priorytetów biznesowych (które podstrony zarabiają).
Logi serwera (opcjonalnie, mocno wskazane przy dużych serwisach).
Kontakt do zespołu dev (do omówienia backlogu; staging mile widziany).
Cennik i współpraca
Wycena indywidualna po krótkiej rozmowie (scope zależy od skali serwisu i liczby szablonów).
Audyt obejmuje jednorazową kontrolę wdrożeń po poprawkach.
Nie jesteś pewien, czy problem leży w JavaScript? Zacznij od konsultacji SEO – godzina rozmowy często wystarcza, żeby to ustalić.
Najczęściej zadawane pytania (FAQ)
Czym audyt JavaScript SEO różni się od audytu technicznego SEO?
Audyt techniczny SEO obejmuje pełną higienę serwisu: indeksację, architekturę, Core Web Vitals, dane strukturalne. Audyt JavaScript SEO schodzi głęboko w jedną warstwę: renderowanie – co istnieje w initial HTML, co powstaje po wykonaniu JS i co widzą boty, które JS nie wykonują. Jeśli serwis stoi na frameworku JS i objawy wskazują na render, ten audyt trafia prosto w problem. Jeśli nie wiesz, gdzie leży problem – zacznij od audytu technicznego.
Ile trwa audyt?
Najczęściej 1–2 tygodnie od przekazania dostępów. Przy dużych serwisach z wieloma szablonami do 4 tygodni.
Czy sprawdzasz też widoczność dla botów AI?
Tak, to stały element zakresu. Większość crawlerów zbierających treści dla systemów AI nie wykonuje JavaScriptu – widzą wyłącznie surowy HTML. W raporcie dostajesz macierz: który szablon jest widoczny dla Googlebota, a który dla botów AI. Zachowania botów znam z pomiarów we własnym laboratorium jsseo.dev, nie z dokumentacji vendorów.
Mamy dopiero plan migracji na headless. Czy audyt ma sens przed startem?
To najlepszy moment. Audyt działa wtedy jako preflight: zamiast diagnozować straty po wdrożeniu, dostarczam wymagania SEO do specyfikacji projektu – routing, metadane w initial HTML, architektura URL-i, strategia renderowania per typ podstrony. Prowadziłem takie specyfikacje przy migracjach klasy Magento → Nuxt.
Czy naprawiacie znalezione problemy?
Kod produkcyjny pisze Twój zespół dev – ja dostarczam backlog z priorytetami, kryteriami akceptacji i uzasadnieniem, potem weryfikuję wdrożenia. Rekomendacje piszę tak, żeby dev nie musiał zgadywać, o co chodzi.
Jak wygląda raport?
PDF/Slides + backlog zadań (P0–P2) gotowy do przeniesienia do Jiry. Każde ustalenie ma dowód: zrzut raw vs rendered, dane z GSC albo wpisy z logów – żadnych rekomendacji „bo tak się robi”.
Nasz serwis jest na Next.js z SSR – czy audyt w ogóle coś znajdzie?
SSR to strategia, nie gwarancja. W praktyce znajduję hydration mismatch nadpisujący treść, metadane wstrzykiwane client-side mimo SSR, fragmenty szablonów renderowane wyłącznie w przeglądarce i zasoby blokowane w robots.txt. Audyt weryfikuje stan faktyczny, nie deklarowany.
Czy gwarantujesz wzrost ruchu po audycie?
Nie – gwarantuję rzetelną diagnozę z dowodami i backlog, który da się wdrożyć. Efekt zależy od wdrożenia i od tego, czy problem faktycznie leżał w renderowaniu; to ustalamy uczciwie na etapie diagnozy, a nie po fakcie.
Kto przeprowadza audyt: 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. 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ż: ekspert JavaScript SEO i audyt techniczny SEO.
