JavaScript SEO 2026 — SPA, SSR, hydration i rendering dla Google i LLM

TL;DR — JavaScript SEO w 2026 roku wymaga jednoczesnej odpowiedzi na trzy pytania — czy Googlebot widzi treść bez pustej powłoki HTML, czy LLM-owe crawlery (GPTBot, ClaudeBot, PerplexityBot) potrafią wyciągnąć fakty przy ograniczonym budżecie renderowania, oraz czy użytkownik dostaje stabilny LCP i INP bez długich okien hydration. Najbezpieczniejszym domyślnym wyborem jest SSR lub SSG jako render path dla wszystkich stron, które mają rankować, a CSR wyłącznie dla warstw wymagających interaktywności (filtry, koszyk, dashboard). Frameworki takie jak Next.js 15, Nuxt 3, Remix i Astro oferują gotowe hybrydy — używaj ich zamiast pisać rendering od zera. W tym pillar'u pokazuję porównanie strategii renderowania, 10-krokowy framework audytu JS SEO, tabelę sygnałów Core Web Vitals w aplikacjach JS, konkretne patterny dla LLM readiness oraz FAQ obejmujące dynamic rendering, lazy loading i route changes — dla zespołów migrujących z WordPress/PHP do nowoczesnego stacku JS oraz dla tych, które walczą z dropem ruchu po przejściu na SPA.

Czym wlasciwie jest JavaScript SEO i dlaczego w 2026 jest trudniejsze niz klasyczne on-page?

JavaScript SEO to zestaw praktyk, ktory zapewnia, ze tresc generowana dynamicznie w przegladarce jest widoczna dla wyszukiwarek i LLM-ow na tym samym poziomie co tresc serwowana w czystym HTML. Wbrew pozorom nie jest to problem nowy — pojawil sie razem z pierwszymi aplikacjami AngularJS okolo 2014 roku. Nowe jest natomiast tempo, w jakim JavaScript wchodzi na strony, na ktorych nikt sie tego nie spodziewal: landingi, blogi, sklepy z mikro-interakcjami, dashboardy z tresciami blokowanymi za loaderem.

Problem ma trzy warstwy. Po pierwsze, Googlebot renderuje strony w dwoch etapach (crawling + rendering) i budzet na drugi etap jest ograniczony. Jesli aplikacja odpala 1,5 MB JS, wykonuje kilkanascie zapytan do API i czeka na hydration, Googlebot czesto indeksuje pusta powloke. Po drugie, LLM crawlery (GPTBot, ClaudeBot, PerplexityBot, CCBot) w 2026 roku nadal w przewazajacej wiekszosci nie wykonuja JavaScriptu lub wykonuja go selektywnie. Oznacza to, ze tresc renderowana klient-side praktycznie nie trafia do trening setow ani do Retrieval-Augmented Generation pipeline'ow AIO. Po trzecie, Core Web Vitals w aplikacjach SPA mierzy sie inaczej — klasyczna LCP na landingu to jedno, a LCP po route change w aplikacji hydrowanej to cos zupelnie innego.

W 2026 roku doszedl jeszcze jeden wymiar — LLM readiness. Nawet jesli Google widzi tresc po renderze, LLM mogą jej nie zobaczyć, bo zatrzymały się na pierwszym fetchu surowego HTML. Redakcje, ktore w ostatnich miesiacach dropnely o 30-50 procent cytowan w AI Overviews i Perplexity, w wiekszosci przypadkow mialy jeden wspolny mianownik: migracja do client-side-heavy stacku bez odpowiedniego fallbacku SSR.

Ktora strategia renderowania — CSR, SSR, SSG czy ISR — daje najlepsze SEO?

Odpowiedz zalezy od tego, jak czesto zmienia sie tresc, jak duzy jest wolumen stron i jakiego rodzaju interaktywnosci wymaga UI. Zadna strategia nie jest uniwersalnie najlepsza — dobrze zaprojektowany serwis w 2026 roku laczy dwa lub trzy tryby renderingu w zaleznosci od typu strony. Uproszczony decyzyjnik wyglada tak: landing marketingowy i artykul bloga → SSG, kategoria z filtrami produktow → SSR lub ISR, koszyk i konto uzytkownika → CSR, strona glowna z personalizacja → SSR z cache na brzegu.

Najwazniejsze, zeby tresc istotna dla SEO — naglowki, paragrafy, linki wewnetrzne, dane strukturalne, obrazki z altami — byla w pierwszym fetchu HTML. Jesli Googlebot, GPTBot i uzytkownik widza ta sama zawartosc juz po initial response, wszystkie pozostale parametry (speed, INP, interaktywnosc) dadza sie zoptymalizowac w drugim kroku. Jesli tresc pojawia sie dopiero po hydration, zadna optymalizacja JS nie odbuduje strat w indeksacji i cytowaniach.

Strategia	Jak dziala	Widocznosc dla Google	Widocznosc dla LLM (GPTBot, ClaudeBot)	TTFB i LCP	Koszt infrastruktury	Dla jakich stron
CSR (Client-Side Rendering)	HTML pusty, tresc buduje JS w przegladarce	Slaba — wymaga 2-fazowego renderowania, budzet ograniczony	Prawie zerowa — wiekszosc LLM-botow nie wykonuje JS	Zle LCP (2.5-5s), dobre po hydration	Niski (statyczny hosting)	App internal (dashboard, panel, koszyk)
SSR (Server-Side Rendering)	HTML generowany per-request na serwerze	Bardzo dobra — pelny HTML w first response	Bardzo dobra	Umiarkowane TTFB (200-800ms), dobre LCP	Sredni-wysoki (compute per-request)	Personalizowane strony, search, kategorie
SSG (Static Site Generation)	HTML zbudowany w buildzie, serwowany z CDN	Excellent — najszybsze TTFB, pelny HTML	Excellent	TTFB <100ms, LCP <1.5s	Bardzo niski	Blog, dokumentacja, landing, katalog produktow do kilku tysiecy SKU
ISR (Incremental Static Regeneration)	Statyczne, ale z mechanizmem revalidate (np. co 60s)	Excellent	Excellent	TTFB <100ms (cache hit), 300-800ms (miss)	Niski	Sklepy, serwisy news, duze katalogi z czesto zmienianymi stanami
Edge SSR / Streaming SSR	SSR na brzegu sieci, streaming HTML w kawalkach	Excellent	Bardzo dobra (zalezy od implementacji)	Najlepsze TTFB (50-150ms globalnie)	Sredni (edge functions)	Globalne serwisy, aplikacje z personalizacja bez utraty SEO
Dynamic Rendering	Dla botow SSR, dla uzytkownikow CSR	Akceptowalna (Google oficjalnie deprecated od 2024)	Akceptowalna (jesli user-agent listy obejmuja LLM-boty)	Zalezna od rozwiazania	Sredni	Tylko legacy — nie rekomendowane w nowych projektach

Zauwaz jedna rzecz — Dynamic Rendering, ktore jeszcze w 2021 roku bylo rekomendowanym workaroundem, jest dzis traktowane jako anti-pattern. Google oficjalnie odradza, a LLM-boty czesto nie maja user-agenta zgodnego z Googlebotem, wiec lada na pusty CSR. W 2026 produkcyjnym wyborem powinno byc SSR, SSG lub ISR — nie dynamic rendering. Porownanie szerszych strategii technicznych mozesz zobaczyc w naszym materiale o strategii SEO.

Jak dziala proces renderowania Googlebota w 2026 i gdzie JavaScript wywraca indeksacje?

Googlebot od 2019 korzysta z evergreen Chromium — to dobra wiadomosc. Zla jest taka, ze proces renderowania jest dwuetapowy i nie dzieje sie w czasie rzeczywistym. Etap pierwszy (crawling) to standardowy HTTP request — Googlebot pobiera HTML, wyciaga linki, kolejkuje nowe URL-e. Etap drugi (rendering) trafia do osobnej kolejki WRS (Web Rendering Service), gdzie strona jest wykonywana w headless Chrome i dopiero po hydration indeksowana jest ostateczna tresc. Kolejka WRS w 2026 dziala szybciej niz kilka lat temu — mediana to kilka godzin zamiast dni — ale nadal jest opoznienie.

Komplikacja numer jeden — budzet renderowania. Googlebot ustala limit czasu i zasobow per domena. Jesli strona odpala 60 zapytan HTTP, chargeuje 3 MB JavaScriptu i czeka 8 sekund na hydration, Googlebot moze zrezygnowac w polowie i zaindeksowac niekompletna zawartosc. W praktyce widoczne jest to tak — w Search Console pojawiaja sie strony z meta „przygotowano, nie zaindeksowano” albo indeksuje sie wersja bez glownego contentu.

Komplikacja numer dwa — linki renderowane przez JS. Google <a href> z atrybutem href odczytuje w crawlu (etap 1). Linki dolozone do DOM przez JavaScript (np. lazy-loaded paginacja, infinite scroll, routery SPA bez <a href>) sa widoczne dopiero po etapie 2. Oznacza to, ze cala podstrona moze zostac odkryta z duzym opoznieniem albo w ogole pominieta, jesli hydrayion nie zakonczy sie poprawnie. Zasada — kazdy wazny link musi byc <a href>, serwowany w pierwszym HTML-u.

Komplikacja numer trzy — metadane i canonical ustawiane przez JS. Title, meta description, canonical, hreflang, OG tags generowane dynamicznie po hydration dzialaja w Google (etap 2) z duzym opoznieniem i praktycznie nie dzialaja dla LLM-ow (ktorzy zatrzymuja sie na etapie 1). Jesli framework generuje title client-side, najprawdopodobniej LLM nie zobacza Twojej strony w ogole.

Co z LLM-owymi crawlerami — GPTBot, ClaudeBot, PerplexityBot?

LLM-owe crawlery dzialaja inaczej niz Googlebot i nalezy je traktowac jako osobna klase agentow. W 2026 roku wyglada to tak — GPTBot, ClaudeBot, PerplexityBot, CCBot, Applebot-Extended oraz Google-Extended (dla Gemini) w przewazajacej wiekszosci pobieraja surowy HTML i nie wykonuja pelnego renderowania JavaScriptu. Powod jest prozaiczny — koszt. Wykonywanie JS dla milionow stron dziennie jest o 2-3 rzedy wielkosci drozsze niz pobieranie surowego HTML. Przy budzetach trening setow mierzalnych w tysiacach petabajtow, to nie wchodzi w gre.

Implikacja jest konkretna — jesli Twoja tresc jest renderowana tylko client-side, LLM-y jej nie widza. Nie trafi do GPT-5, nie zostanie zcytowana przez Perplexity, nie pojawi sie w odpowiedziach ChatGPT z enabled web search. To prawdopodobnie najwieksza przyczyna dropow ruchu cytowanego w AIO u serwisow, ktore w 2024-2025 migrowaly z WordPressa do heavy React SPA.

Druga implikacja — robots.txt i allow/disallow dla LLM-botow. Jesli w robots.txt masz User-agent: GPTBot Disallow: /, blokujesz samego siebie przed cytowaniami w ChatGPT. W 2026 domyslnie rekomendujemy otwarcie dla wszystkich LLM-botow (OAI-SearchBot, ChatGPT-User, GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Applebot-Extended) i traktowanie cytowan AIO jako formy organicznej widocznosci. Wyjatkiem sa serwisy premium z platnym contentem — tam odwrotna strategia (block + dedicated paid API access).

Trzecia implikacja — LLM-y lubia strukturyzowane dane. Schema Article, FAQPage, HowTo, Product w JSON-LD, jezeli generowane serwer-side, sa dla LLM-ow bardzo wartosciowym sygnalem. Pomagaja ekstraktowac encje (osoby, firmy, produkty, daty) bez konczenia renderowania. Schema generowane przez JS po hydration — ponownie — nie jest widoczne dla wiekszosci LLM-botow. Wiecej o formatach LLM-friendly zebralismy w tekscie o AIO.

Jak hydration psuje Core Web Vitals i co z tym zrobic w 2026?

Hydration to proces, w ktorym serwer-side HTML zostaje „ozywiony” przez JavaScript klient-side — React, Vue, Svelte przypina event listenery, state i reaktywnosc. Problem — hydration jest kosztowna. W duzych aplikacjach potrafi zajac 1-3 sekundy na mobile CPU. W tym czasie uzytkownik widzi juz UI (bo HTML jest z SSR), ale klikniecie w guzik nic nie robi — to powoduje dwa zjawiska w Core Web Vitals.

Pierwsze — INP (Interaction to Next Paint). Kazda interakcja uzytkownika przed koncem hydration wpada do dlugiego taska, ktory blokuje renderowanie. INP rosnie do 400-800 ms, gdzie prog „Good” to 200 ms. Google od Q4 2024 uzywa INP jako glowny metric interaktywnosci (zastapilo FID), wiec wysokie INP przeklada sie na gorszy ranking.

Drugie — LCP przy route changes w SPA. LCP mierzone jest tylko dla pierwszego loadu strony. Ale kiedy uzytkownik klika link w aplikacji SPA i nastepuje route change bez page reload, Google Search Console dalej widzi tylko LCP dla inital page. Z punktu widzenia uzytkownika natomiast moze on oczekiwac 2-3 sekundy na renderze nowego widoku. W 2026 Google eksperymentuje z soft navigation measurement — w najblizszych miesiacach mozna spodziewac sie oficjalnego pomiaru dla SPA. Warto przygotowac sie wczesniej.

Rozwiazania — Selective Hydration (React 18+, Next.js 15), ktore hydroje tylko interaktywne czesci strony, zostawiajac statyczne komponenty bez JS. Islands Architecture (Astro, Fresh) — paradygmat, w ktorym 95 procent strony to czysty HTML/CSS, a tylko „wyspy” interaktywne dostaja JS. Dla blogow i dokumentacji to najlepsza architektura w 2026. React Server Components — komponenty, ktore renderuja sie wylacznie na serwerze i w ogole nie wysylaja JS do klienta. Razem z Next.js App Router pozwalaja zredukowac JS bundle o 60-80 procent przy utrzymaniu pelnej interaktywnosci tam, gdzie jest potrzebna.

Konkretne cele metryczne dla SPA w 2026 — LCP < 2,5s (p75 mobile), INP < 200ms (p75), CLS < 0,1, TBT < 200ms. Jesli twoja aplikacja nie miesci sie w tych progach, nie ma sensu martwic sie o optymalizacje niszowe — najpierw redukcja JS payloadu, lazy loading komponentow interaktywnych i odlozenie hydration dla non-critical islands.

Jak przeprowadzic 10-krokowy audyt JavaScript SEO?

Framework ponizej stosujemy w agencji od 2023 roku, zaktualizowany na rok 2026 o warstwe LLM readiness i nowe metryki. Kazdy krok ma input, output i narzedzia — potraktuj to jako checkliste, ktora mozesz przejsc w ciagu jednego dnia dla sredniego serwisu (do 50 tys. URL-i) lub w tydzien dla duzego.

1. Krok 1 — Render parity check. Pobierz 20 reprezentatywnych URL-i (home, kategoria, produkt, artykul, landing). Zrob curl z user-agentem Googlebot i porownaj z render w Chrome DevTools „View Page Source” vs „Inspect”. Szukasz roznic — jesli treść glowna, linki lub schema sa tylko w „Inspect”, masz problem. Narzedzia — curl, Screaming Frog JS render mode, Google Search Console URL Inspection.
2. Krok 2 — Raw HTML content check dla LLM-ow. Ten sam test co krok 1, ale z user-agentami GPTBot, ClaudeBot, PerplexityBot. Jesli otrzymujesz pusty HTML z divem root i bundle.js w src, LLM-y nie widza Twoich tresci. Naprawa — SSR lub SSG dla wszystkich stron indeksowanych.
3. Krok 3 — Internal linking discovery. Crawl pelen Screaming Frog z wylaczonym JS render (tryb Text Only) i porownaj liczbe znalezionych URL-i z crawlem z wlaczonym JS render. Duza roznica (>15 procent) to sygnal, ze sporo linkow renderuje sie client-side. Ekstrakcja <a href> i pagination do prerenderu.
4. Krok 4 — Metadata in initial HTML. Sprawdz, czy title, meta description, canonical, OG tags, hreflang i JSON-LD sa obecne w pierwszym fetchu HTML dla kazdego typu strony. Jesli sa injected po hydration — migruj na rendering serwerowy meta tagow (Next.js Metadata API, Nuxt useHead).
5. Krok 5 — Core Web Vitals dla p75 mobile. CrUX, PageSpeed Insights, WebPageTest. Mierz p75 dla LCP, INP, CLS, TBT. Interesujace sa rozbicia per template — home, kategoria, produkt, artykul. Jesli ktorykolwiek template ma INP > 300ms, masz problem z hydration — priorytet naprawy.
6. Krok 6 — JS bundle analysis. Webpack Bundle Analyzer, Lighthouse Treemap albo Next.js @next/bundle-analyzer. Szukasz duplikatow bibliotek, niepotrzebnych polifillow, lib jak lodash/moment importowanych w calosci. Cel — glowny bundle < 180 KB (gzip) dla stron publicznych.
7. Krok 7 — Hydration measurement. Performance.measure() w DevTools albo React Profiler / Vue Devtools. Dla kazdego typu strony mierz Time to Interactive (TTI) i hydration duration. Jesli hydration zajmuje > 500 ms na mid-range mobile, szukaj miejsc do selective hydration lub islands.
8. Krok 8 — robots.txt i LLM-bot policy. Sprawdz, ktore crawlery masz allow/disallow dla LLM-ow. Dla publicznych serwisow marketingowych — otwieraj GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, Google-Extended. Zablokowanie == brak cytowan AIO. Dodaj tez explicitne Allow dla folderu /assets/ — obrazki i CSS musza sie loadowac.
9. Krok 9 — Structured data coverage. Schema.org markup per template w JSON-LD serwowanym serwer-side. Sprawdz Rich Results Test dla home, artykulu, kategorii i produktu. Dla bloga obowiazkowe — Article, BreadcrumbList, Organization. Dla sklepu — Product, Offer, AggregateRating. Dla FAQ sekcji — FAQPage. Schema generowane client-side trafia do indeksu z duzym opoznieniem albo wcale.
10. Krok 10 — Soft navigation i SPA route changes. Jesli aplikacja jest SPA, sprawdz, czy route changes aktualizuja title, meta description, canonical i scroll position. Uzyj window.history API, monitoruj pushState events. W 2026 Google testuje soft navigation jako osobny page load — zle zaprojektowane SPA moze niedlugo ucierpiec w CWV.

Raport z audytu zbieramy w tabeli — kolumny: krok, status (pass/fail/warning), priorytet (P0/P1/P2), rekomendacja. P0 to blockery indeksacji (render parity, internal linking). P1 to straty CWV i LLM readiness. P2 to drobne optymalizacje. Audyt typu enterprise (> 500 tys. URL-i) zwykle ma 15-30 issue'ow, z czego 3-5 na poziomie P0. Naprawa P0 to priorytet numer jeden — reszta moze poczekac miesiac lub dwa.

Czy Next.js 15 i Nuxt 3 rzeczywiscie rozwiazuja problemy JS SEO w 2026?

W duzej mierze tak — ale pod warunkiem, ze uzyjesz ich domyslnych konwencji. Next.js 15 z App Router domyslnie renderuje komponenty serwer-side (React Server Components), laduje JS tylko dla interaktywnych client components, generuje metadata przez Metadata API i wspiera ISR z revalidate. Nuxt 3 oferuje podobny model — universal rendering, useHead, lazy hydration, hybrid rendering per route. Astro idzie jeszcze dalej — w zerowym JS domyslnie, JavaScript dolaczasz tylko tam, gdzie naprawde potrzebujesz (islands).

Problem zaczyna sie, kiedy zespol uzywa frameworka w trybie „client-first” — wszystko jest <ClientComponent>, useEffect do fetchu danych, dynamic imports z ssr: false. Taki projekt Next.js jest funkcjonalnie gorszy SEO niz czysty Create React App, bo zatraca wszystkie zalety, ktore framework daje out-of-the-box. W audytach widzimy to regularnie — zespoly technologicznie migrujace do Next.js, ktore nie zmienialy mental modelu i po prostu przepisywaly CRA na Next z minimalnym refactorem.

Rekomendacja w 2026 — dla nowych projektow Astro dla content-heavy (blog, docs, magazyn, landing), Next.js App Router dla aplikacji z mieszana interaktywnoscia (sklep, SaaS marketing site z dashboardem), Remix/React Router 7 dla form-heavy apps, Nuxt 3 dla zespolow Vue. Najwazniejsza decyzja — default na SSR/SSG, a CSR tylko tam, gdzie konieczny. Dokumentacja Next.js jest tu wyjatkowo wyczerpujaca, zaczac warto od ich Learn SEO course, a dla warstwy Google-side od Google Search Central: JavaScript SEO basics — to dwa zrodla, do ktorych wracam najczesciej.

Jak przygotowac tresc, zeby LLM-y mogly ja zcytowac?

LLM readiness to nowa warstwa JS SEO, ktorej w 2020 roku w ogole nie bylo. W 2026 to jedna z najwazniejszych metryk organicznej widocznosci — cytowanie w ChatGPT Search, Perplexity, Claude i Gemini daje ruch porownywalny (lub wyzszy) niz pozycja w top 3 SERP-a, zwlaszcza dla zapytan informacyjnych. Zeby LLM zacytowal, musi najpierw zobaczyc tekst — a to wraca do punktu startowego, czyli serwer-side renderingu. Zakladamy, ze ten warunek jest spelniony. Co dalej?

Po pierwsze, answer-first paragraphs. Pierwsze zdanie kazdej sekcji H2 powinno odpowiadac na pytanie w naglowku, nawet jesli rozwiniecie ciagnie sie jeszcze przez trzy akapity. LLM-y ekstraktuja zdanie po zdaniu i szukaja tych, ktore daja konkretna odpowiedz. „W tym artykule omowimy…” jest bezwartosciowe. „Hydration psuje Core Web Vitals, poniewaz blokuje INP przez 1-3 sekundy po load na mobile” — to jest zdanie, ktore moze pojawic sie w cytowaniu.

Po drugie, entity density. LLM-y rozpoznaja encje (osoby, firmy, produkty, technologie, protokoly, standardy) i budowa graf wiedzy oparty na ich wspolwystepowaniu. Tekst o JavaScript SEO, ktory wymienia Next.js, Nuxt, Remix, Astro, Googlebot, GPTBot, Core Web Vitals, INP, LCP, hydration, React Server Components — jest duzo silniej powiazany z klastrami tematycznymi niz tekst, ktory uzywa generycznych okreslen typu „nowoczesne frameworki” albo „metryki wydajnosci”.

Po trzecie, konkretne liczby i daty. LLM-y preferuja odpowiedzi z atrybucja liczbowa — „80 procent LLM-botow nie wykonuje JS”, „INP prog to 200 ms p75″, „Google od Q4 2024 zastapil FID przez INP”. Vague claims („duzo”, „wiekszosc”) sa ignorowane, bo nie mozna ich cytowac wiarygodnie.

Po czwarte, strukturyzowane dane FAQ. FAQPage schema w JSON-LD serwowana serwer-side jest dla LLM-ow jak gotowy data source — pytanie, odpowiedz, atrybucja. Redakcje z dobra sekcja FAQ zcytowana w HTML widza az 3-5 razy wyzszy udzial w AI Overviews niz podobne serwisy bez FAQ. Dla JS SEO oznacza to, ze dobry blog lub dokumentacja musi mieć FAQ schema w HTML (nie inject client-side) i minimum 5-8 pytan per artykul pillarowy.

Najczestsze bledy w JavaScript SEO w 2026 — i jak je naprawic

Lista ponizej to bledy powtarzajace sie niemal we wszystkich audytach serwisow migrujacych do JS stacku. Kazdy z nich potrafi samodzielnie scinac ruch organiczny o 20-40 procent. Razem — moga zrujnowac pozycje calej domeny w kilka miesiecy.

Blad 1 — tresc renderowana tylko client-side. Domyslnie wszystko w Next.js App Router powinno byc Server Component, chyba ze masz konkretny powod zeby go „use client”'owac. Bledem jest traktowanie 'use client' jako default. Naprawa — audit wszystkich use client, przenies fetch do serwera, zostaw client tylko tam gdzie naprawde trzeba (formularze, animacje, state zaleznie od usera).

Blad 2 — linki jako <div onClick> zamiast <a href>. Klasyka wsrod developerow przyzwyczajonych do React Router. Googlebot nie wykonuje onClick, LLM-y nie wykonuja onClick — twoja paginacja, menu i breadcrumbs znikaja z crawlu. Naprawa — kazda nawigacja jako <a href> (Next/Link, Nuxt's NuxtLink) renderuje HTML, a onClick dokladasz opcjonalnie dla client-side navigation.

Blad 3 — metadata injected client-side. Czesty w legacy CRA i Vue apps — useEffect + document.title. Google w etapie 2 to podchwyci, ale LLM-y nie, a Core Web Vitals liczy opoznienie. Naprawa — framework's metadata API serwerowa (Next.js generateMetadata, Nuxt useHead).

Blad 4 — lazy loading zbyt agresywne. Lazy load obrazu powyzej fold, IntersectionObserver dla content blocka z H2 — Googlebot i LLM widza puste miejsce. Naprawa — lazy tylko below fold, obrazki above fold z loading=eager lub fetchpriority=high.

Blad 5 — duplicate content przez query params i routing. SPA generuje URL-e typu /produkt/butelka?color=red i /produkt/butelka#red, kazdy z tym samym contentem bez canonical. Naprawa — strict canonical per URL, rel canonical serwer-side, wyczyszczenie nieistotnych query params.

Blad 6 — 404 i soft-404 w SPA. SPA domyslnie zwraca 200 dla kazdego URL-a, nawet dla nieistniejacego, bo router klient-side pokazuje komponent NotFound. Naprawa — SSR musi zwracac HTTP 404 dla nieistniejacych stron, Next.js notFound() i Nuxt createError z statusCode: 404 to robia poprawnie.

Blad 7 — robots.txt blokujacy zasoby JS i CSS. Jesli zablokujesz /_next/static/ albo /assets/, Googlebot nie moze wykonac renderingu — indeksacja lezy. Sprawdz robots.txt w Search Console Coverage Report. Naprawa — Allow: /assets/, Allow: /_next/static/.

Blad 8 — brak sitemap.xml albo sitemap z linkow, ktorych nie ma w menu. SPA czasem ma rute w kodzie, ale linku nie ma nigdzie na stronie. Sitemap.xml serwer-side musi obejmowac wszystkie kanoniczne URL-e. Dla duzych katalogow — sitemap index podzielony na <50 tys. URL-i per plik.

Blad 9 — fonty i CSS blokujace render. Import fontow z Google Fonts bez font-display: swap, CSS-in-JS wywalajacy 300 KB do runtime — powoduje CLS i slaby LCP. Naprawa — font-display: swap, self-host fontow, CSS krytyczne inline, reszta async.

Blad 10 — ignoracja Accept-Language i geo dla multi-region. SPA z personalizacja renderuje inna tresc dla US i PL pod tym samym URL-em, a canonical i hreflang sa nieustawione. Naprawa — osobne URL-e per locale (nextjs /en/ /pl/), hreflang w SSR, geo personalizacja tylko tam, gdzie naprawde potrzebna, z canonical na default locale.

Jak monitorowac JavaScript SEO na biezaco?

Jednorazowy audyt to za malo. SPA i aplikacje z CI/CD deployowane codziennie moga wprowadzic regresje SEO w ciagu jednego sprintu. W 2026 rekomendowany stack monitoringu to cztery warstwy, dzialajace synchronicznie.

Warstwa 1 — CI/CD gates. Kazdy pull request odpala Lighthouse CI z budzetami (JS bundle < 180 KB, LCP < 2,5s, INP < 200ms) oraz render parity check (czy kluczowe selektory H1, H2, main content sa w raw HTML bez JS). Fail = merge blocked. Narzedzia — Lighthouse CI, Puppeteer scripts, Playwright testy renderu.

Warstwa 2 — daily crawl. Screaming Frog cloud albo Sitebulb codzienny crawl 500-5000 URL-i ze sprawdzeniem statusu, canonical, title, meta, schema, liczby linkow, render parity. Report trafia do Slack/Teams. Idealne do wylapania regresji po deploy'ach.

Warstwa 3 — Real User Monitoring. Chrome UX Report API, Google Search Console Core Web Vitals, wlasne RUM (Cloudflare, Vercel Analytics, SpeedCurve). Mierz p75 CWV per template codziennie. Alert przy wzroscie LCP lub INP o > 20 procent w tygodniu.

Warstwa 4 — AIO citations monitoring. To nowa warstwa, ktorej nie bylo 2 lata temu. Tygodniowe testy topicow w ChatGPT Search, Perplexity, Gemini — czy twoja domena jest cytowana dla kluczowych zapytan. Narzedzia — Otterly.ai, AIO monitors, wlasne skrypty z API Perplexity. Drop cytowan to sygnal, ze cos sie popsulo w LLM readiness (crawling, raw HTML, schema).

FAQ — najczestsze pytania o JavaScript SEO w 2026

1. Czy Googlebot rzeczywiscie wykonuje JavaScript w 2026?

Tak — od 2019 roku Googlebot uzywa evergreen Chromium i wykonuje JS w pelni. Problem nie lezy w zdolnosci, tylko w budzecie i opoznieniu. Rendering to drugi etap po crawlingu, w osobnej kolejce WRS, z mediana kilku godzin. Budzet per domena jest ograniczony, wiec ciezkie aplikacje z dlugim hydration moga miec indeksacje niepelna lub opoznioną.

2. Czy LLM-y (ChatGPT, Claude, Perplexity) wykonuja JavaScript?

W 2026 w przewazajacej wiekszosci nie. GPTBot, ClaudeBot, CCBot pobieraja surowy HTML. Wyjatki to OAI-SearchBot i ChatGPT-User (fetch live przez browser) oraz PerplexityBot w trybie browse — ale to dotyczy tylko podzbioru cytowan live, a nie training setow. Glowna zasada — jesli chcesz byc cytowany w LLM-ach, tresc musi byc w raw HTML.

3. Czy Dynamic Rendering jeszcze ma sens?

Nie. Google oficjalnie deprecate'owal rekomendacje w 2024, a LLM-y nie maja user-agenta zgodnego z Googlebotem — landuja na pusty CSR. W 2026 domyslnym wyborem jest SSR, SSG lub ISR. Dynamic Rendering jest akceptowalny tylko jako tymczasowy workaround przy migracji, z planem na 2-3 miesiace wyjscia.

4. Jakie sa optymalne progi Core Web Vitals dla aplikacji JS w 2026?

LCP < 2,5s (p75 mobile), INP < 200ms (p75), CLS < 0,1, TBT < 200ms. Dla aplikacji mobilnych z duza interaktywnoscia INP jest najtrudniejszy — wymaga selective hydration albo islands architecture. Monitoruj p75 per template, nie caly serwis — bo agregat ukrywa problemowe sekcje.

5. Czy Islands Architecture (Astro) nadaje sie do kazdego typu serwisu?

Nie. Astro jest swietny dla content-heavy stron z malą interaktywnoscia — blogi, dokumentacja, magazyny, landingi. Dla aplikacji z intensywna interaktywnoscia (SaaS dashboard, e-commerce z koszykiem i filtrami, portal spolecznosciowy) bardziej odpowiednie sa Next.js, Nuxt albo Remix. Zasada — jesli strona to 95 procent tresc i 5 procent interakcji, Astro. Jesli 50/50 albo interaktywnosc dominuje, framework z pelnym SSR + hydration.

6. Jak najszybciej sprawdzic, czy moja strona jest widoczna dla LLM-ow?

Najprostszy test — curl z user-agentem GPTBot do glownych URL-i i ogladniecie odpowiedzi. Jesli dostajesz <div id=”root”></div> bez content, LLM-y nie widza Twojej strony. Drugi test — pytanie ChatGPT lub Perplexity o konkretny fakt z Twojej strony i sprawdzenie, czy moga go zacytowac. Trzeci test — Google Search Console > URL Inspection > View Crawled Page — porownanie raw HTML vs rendered HTML.

7. Czy warto blokowac LLM-boty w robots.txt?

Dla wiekszosci serwisow — nie. Zablokowanie oznacza zero cytowan w AI Overviews, Perplexity i ChatGPT Search, co w 2026 jest istotnym zrodlem ruchu (5-15 procent dla serwisow informacyjnych). Wyjatek — serwisy z premium content za paywallem, gdzie blokada chroni przed free cytowaniem. Druga strategia — allowlist selektywny (np. otwieramy ChatGPT-User live, blokujemy GPTBot trening).

8. Ile realnie kosztuje migracja z CSR na SSR/SSG dla sredniego serwisu?

Dla serwisu z 10-50 tys. URL-i, migracja Next.js Pages Router na App Router z Server Components to zwykle 6-12 tygodni pracy zespolu 2-3 developerow. Koszt — 60-150 tys. PLN. Zwrot — zwykle w 3-6 miesiacy przez wzrost ruchu organicznego i cytowan AIO. Dla serwisu zaczynajacego od CRA lub Vue SPA, migracja do Astro albo Nuxt 3 bywa szybsza, bo framework wymusza correct patterns.

Co dalej — jak rozwijac JavaScript SEO w 2027 i kolejnych latach?

Trzy kierunki beda ksztaltowaly JS SEO w najblizszych dwoch latach — i zespoly, ktore zaczna je adresowac teraz, beda mialy przewage w 2027 roku.

Kierunek 1 — Soft navigation measurement przez Google. Google od 2024 pracuje nad oficjalnym sposobem mierzenia Core Web Vitals dla route changes w SPA. Oznacza to, ze niedlugo strony, ktore maja slabe LCP/INP po route change (nie tylko na initial load), beda traciły w rankingu. Przygotuj sie — mierz teraz te metryki przez RUM, optymalizuj prefetch, code splitting i route-level data fetching.

Kierunek 2 — LLM-specific markup i schema. W 2026 schema.org dopiero startuje z nowymi typami dedykowanymi AI — LearningResource, SoftwareSourceCode z detailed metadata, DataFeed. Obserwuj Google Search Central blog i schema.org changelog. Wdrazaj wczesniej — konkurencja zwykle wdraza miesiace pozniej, a pierwsza fala implementacji ma wieksze szanse na premium citations w AIO.

Kierunek 3 — Server-first JavaScript frameworks. Trend jest wyrazny od 2023 — od React Server Components, przez Remix/React Router 7, po Astro islands. Wszystkie nowe frameworki startuja server-first, client-as-enhancement. W 2027 client-first aplikacje beda tak archaiczne jak dzisiaj jQuery — nadal dziala, ale w nowoczesnych zespolach nikt jej nie wybiera na greenfield. Jesli zaczynasz nowy projekt w Q1 2026, domyslne pytanie to „jakim server-first framework'iem to robie”, a nie „czy SSR”.

Trzy zasady, ktorych warto trzymac sie niezaleznie od kierunku. Po pierwsze — raw HTML zawsze, JS jako enhancement. Po drugie — mierzona jakosc ponad deklarowana. Po trzecie — LLM readiness to nowy SEO, nie opcjonalny dodatek. Reszta to detale implementacyjne, ktore rozwiaza sie z czasem.

JavaScript SEO w 2026 nie jest juz problemem tehnicznej ciekawostki dla enterprise'u — to warunek przetrwania organicznego dla kazdego serwisu zbudowanego na nowoczesnym stacku. Granica miedzy serwisami, ktore rozumieja server-first rendering i LLM readiness, a tymi, ktore nadal probuja CSR-a z dynamic rendering'iem jako backupem, bedzie w 2027 widoczna w ruchu, cytowaniach i pozycjach. Dobra wiadomosc — naprawa nie wymaga przepisywania calego serwisu od zera. Wystarczy audyt 10-krokowy, ustalenie P0 (render parity, internal linking, metadata), iteracyjna naprawa przez 3-6 miesiecy i monitoring cztero-warstwowy. Reszta dobuduje sie przez dobor odpowiedniego framework'a i dyscypline w code review. Start dzisiaj — koszt opoznienia rosnie kazdym kwartalem.