JavaScript SEO 2026 — pełny przewodnik (CSR vs SSR vs SSG)

JavaScript SEO to subdyscyplina technical SEO skupiona na optymalizacji stron napędzanych JavaScript (React, Vue, Angular, Svelte) tak by wyszukiwarki (Google, Bing, Yandex) ORAZ AI crawlery (GPTBot, ClaudeBot, PerplexityBot) mogły je poprawnie crawlować, renderować i indexować. Powstał ~2015 wraz z mass adoption frameworków SPA (Single Page Application). KRYTYCZNY problem: tradycyjne crawlery widziały tylko HTML w server response — strony CSR (Client-Side Rendering) zwracały tylko "<div id=root></div>" + JS bundle. Crawler nie wiedział co render. Rozwiązanie: SSR/SSG/Hybrid rendering. W 2026 Googlebot renderuje JavaScript (Web Rendering Service oparty na Chromium 131+), ale: (a) z opóźnieniem (median 9 sek vs <1s dla HTML), (b) limit budgetu rendering, (c) AI crawlery NIE renderują JS w 2026 (GPTBot, ClaudeBot, PerplexityBot widzą tylko HTML response). Konsekwencja: SSR/SSG = MANDATORY dla SEO + AI SEO 2026.

CSR (Client-Side Rendering) — server zwraca pusty HTML + JS bundle. Browser pobiera JS, wykonuje, generuje DOM. Przykłady: Create React App (deprecated), stary Angular SPA, ręczny SPA. SEO: SŁABE — Googlebot renderuje z opóźnieniem 9-30 sek, AI crawlery widzą pusty HTML = ZERO citability. NIE polecane od 2020. SSR (Server-Side Rendering) — server wykonuje React/Vue dla każdego requesta, zwraca pełny HTML. Hydration na browserze. Przykłady: Next.js getServerSideProps (legacy), Remix, Nuxt SSR. SEO: BARDZO DOBRE — full HTML w response, low TTFB. Koszt: server CPU per request. SSG (Static Site Generation) — strony budowane raz w build time, zwracane jako static HTML. Przykłady: Next.js generateStaticParams + force-static, Astro, Gatsby, Hugo, Jekyll. SEO: NAJLEPSZE — instant TTFB <100ms, perfect dla CDN, zero server cost. Wadę: re-build przy zmianach. ISR (Incremental Static Regeneration) — kombinacja SSG + on-demand revalidation. Strony pre-rendered, ale revalidate co N sek lub on webhook. Przykłady: Next.js 13+ App Router default. SEO: NAJLEPSZE — combinacja zalet SSG + freshness SSR. REKOMENDACJA: 95% stron 2026 = SSG/ISR. SSR tylko gdy wymaga personalizacji per user.

Googlebot Rendering Process (Two-Wave Indexing, od 2018): WAVE 1 (FAST INDEX) — crawler pobiera HTML (initial response). Indexuje to co widzi BEZ JS. Czas: instant. WAVE 2 (RENDER QUEUE) — strona ląduje w "render queue". Web Rendering Service (WRS, oparty na Chromium 131+ od 2025) renderuje JS. Median delay 9 sek (od kilku sekund do 1-2 tygodni dla starych domen z low crawl budget). Po renderowaniu re-index z full DOM. KONSEKWENCJE PRACTICAL: (1) jeśli content krytyczny (H1, primary keyword, CTA) jest w initial HTML = INDEXED FAST, dobre dla SEO. (2) jeśli content tylko po JS execution (np. async fetch z API + render) = INDEXED LATE, gorzej. (3) dla nowych domen + low authority Wave 2 może NIGDY nie nastąpić = pages NOT indexed. (4) AI crawlery NIE robią Wave 2 — widzą tylko Wave 1 HTML. KRYTYCZNE: ważne content MUSI być w initial HTML (SSR/SSG) lub renderable przez Googlebot Chromium (no fetch from blocked CDN, no infinite loops, no timeout >30s). DEBUG: GSC URL Inspection → "Test Live URL" → "View tested page" → "More info" → "JavaScript console messages" + "Page resources". Pokazuje co Googlebot widzi po renderze.

Hydration to proces "ożywiania" statycznego HTML przez JavaScript po stronie clienta. Po SSR/SSG, browser otrzymuje pełny HTML (instant render = dobrze dla LCP), POTEM JS bundle pobiera, parsuje, "hydrates" interactive elements (event handlers, state). PROBLEM HYDRATION: CPU-heavy operation, blokuje main thread = wysoki INP (Interaction to Next Paint), słaby Core Web Vitals = niższy ranking Google. SOLUTIONS 2026: (1) PARTIAL HYDRATION (Astro, Qwik) — hydrate tylko interactive components ("islands architecture"). Static parts = no JS. Astro 4+ default. (2) PROGRESSIVE HYDRATION (Vue 3.5+, React 18 Suspense) — hydrate priority components first (above-the-fold), reszta lazy. (3) RESUMABILITY (Qwik) — zero hydration, JS lazy-loaded only on user interaction. Najlepsze dla performance ale niche. (4) REACT SERVER COMPONENTS (RSC, Next.js 13+ App Router) — komponenty renderowane na serwerze, ZERO JS shipped do clienta dla static parts. Hydration tylko Client Components ("use client"). Best of both worlds. NEXT.JS 16 (GMWEB stack): RSC + ISR + Edge runtime = LCP <1s, INP <100ms, full SEO + AI SEO ready. Hydration cost dla typical landing page <50ms.

LAZY LOADING + DYNAMIC IMPORTS = patterns oszczędzające bundle size przez ładowanie JS/komponentów na żądanie. SEO IMPACT: BARDZO POZYTYWNY przy poprawnej implementacji. (1) LAZY LOADING IMAGES (loading="lazy" attribute) — natywne wsparcie wszystkich browserów od 2020. Obrazy poniżej viewport ładują się dopiero gdy user scrolluje. SEO: poprawia LCP (mniej requestów initial), nie psuje crawlowania. Google indexuje lazy images (od 2019). (2) DYNAMIC IMPORTS (import() lub Next.js dynamic()) — komponenty ładowane on-demand. SEO: dla content critical (above-the-fold) = ZŁE bo Googlebot nie czeka. Dla components below fold = OK. Reguła: nie lazy loaduj content w viewport. (3) ROUTE-BASED CODE SPLITTING — Next.js automatycznie code-splituje per route. Każda strona = własny JS bundle. SEO: pozytywne (mniejsze bundles = szybciej). (4) THIRD-PARTY SCRIPTS (Google Analytics, GTM, chat widgets) — używaj Next.js Script z strategy="afterInteractive" lub "lazyOnload" — nie blokują main thread = lepszy INP. CRITICAL: NIE lazy load żadnego content który Googlebot powinien indexować jako primary content (H1, opis produktu, FAQ).

AI crawlery 2026 NIE renderują JavaScript (z wyjątkiem Google-Extended który dziedziczy WRS od Googlebota). Konsekwencje: (1) GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, FacebookBot, Bytespider — wszystkie widzą TYLKO HTML w server response. (2) CSR pages = invisible dla AI = ZERO citation w ChatGPT/Claude/Perplexity. (3) SSR/SSG pages = full visibility = high citation potential. WYMAGANIA dla AI SEO: (a) full content w initial HTML response, (b) Schema.org JSON-LD inline w HEAD lub body, (c) clean semantic HTML (proper H1/H2/H3 hierarchy), (d) brak "client-only" komponentów dla critical content. NEXT.JS 13+ APP ROUTER: domyślnie RSC = full SSR = AI-friendly. Jeśli "use client" component wraps content critical, zmień na Server Component lub przenieś content do parent SSR. ALTERNATYWA dla legacy CSR (jeśli migracja niemożliwa): prerender.io / Rendertron — service który renderuje JS bot-side i serwuje statyczne HTML do crawlerów (~$15/mo). Wskaż przez User-Agent detection w server. NIE polecane dla nowych projektów.

8 najczęstszych błędów JS SEO (audit GMWEB 50+ stron): (1) CONTENT W "useEffect" — primary content (H1, opis) ładowany w React useEffect po mount = Googlebot widzi puste, AI crawlery widzą puste. Fix: SSR/SSG dla critical content. (2) ASYNC FETCH BEZ SUSPENSE — komponent fetchuje data, pokazuje "loading...", potem renderuje. Googlebot indexuje "loading..." jako content. Fix: Server Components z await fetch. (3) ROUTING CLIENT-ONLY (react-router) — internal links nie są crawlowane (no href attribute). Fix: Next.js Link / native <a href>. (4) BLOCKED CDN/JS — robots.txt lub server config blokuje JS files (Googlebot Chromium nie może ich załadować = render fail). Fix: allow ALL static assets dla Googlebot. (5) INFINITE LOOPS / TIMEOUT — page nie kończy renderingu w 30s = Googlebot abandon, indexuje pre-render state. (6) CLOAKING (różny content dla bot vs user) — Google penalty. Fix: ten sam HTML dla wszystkich. (7) HASH ROUTING (#section) — Google nie indexuje fragmentów. Fix: real URL paths. (8) JS-ONLY META TAGS — title/description ustawiane przez useEffect = Googlebot Wave 1 widzi default. Fix: Next.js Metadata API w Server Components.

15-punkt checklist JS SEO 2026: TECHNICAL: (1) SSR/SSG/ISR — NIE CSR (chyba że internal tools). (2) Next.js 13+ App Router z RSC default. (3) generateMetadata() per page (nie client-side). (4) Schema.org JSON-LD inline w HEAD. (5) Internal links jako Next.js <Link> (nie router.push w onClick). (6) Hreflang per page przez Metadata.alternates.languages. (7) sitemap.xml dynamic via app/sitemap.ts. PERFORMANCE: (8) LCP <2.5s (force-static + ISR + CDN edge). (9) INP <200ms (RSC = mniej JS hydration). (10) CLS <0.1 (reserve space dla images, lazy load tylko below fold). (11) Bundle size <100KB initial (dynamic imports dla heavy components). (12) Lazy load images z native loading="lazy". RENDERING: (13) Test w Googlebot User Agent (DevTools → Sensors → Custom UA "Googlebot Smartphone"). (14) GSC URL Inspection → "Test Live URL" → verify rendered HTML matches expected. (15) Dla AI SEO: curl page from User-Agent: "GPTBot" — verify HTML zawiera primary content. GMWEB STACK: Next.js 16 + RSC + force-static + Cloudflare Workers OpenNext = 100/100 Lighthouse default + AI-ready.