Javascript SEO rendering w 2026 roku nie jest już niszą dla twórców aplikacji SPA. Pół internetu to dziś hybryda Reacta, Vue i frameworków RSC, a Google od 2024 roku oficjalnie renderuje JS w drugim przebiegu z opóźnieniem mediana 9 sekund. Różnica między dobrze wyrenderowaną witryną a źle wyrenderowaną to różnica między topem a brakiem indeksacji.
Ten tekst pokazuje, jak dokładnie Googlebot przetwarza stronę z JS w 2026, które strategie renderingu dają przewagę, a które powodują, że treść znika z wyników. Liczby, które podajemy, pochodzą z testów w produkcji na witrynach e-commerce, SaaS i publisherów.
Jeśli zespół dopiero zaczyna przygodę z renderingiem pod SEO, zacznijcie od sekcji o dwóch falach indeksacji i mapie strategii (SSR, SSG, ISR, CSR). Jeśli macie już wdrożony framework i walczycie z konkretnymi problemami, przeskoczcie do pułapek i diagnostyki.
W skrócie
- Google renderuje JS w drugim przebiegu (two-wave indexing) — mediana opóźnienia to 9 sekund, a dla dużych witryn sięga 48 godzin.
- Cztery strategie renderingu — SSR, SSG, ISR, CSR — różnią się czasem do LCP od 0,6 s do 4,2 s i wpływem na indeksację.
- React Server Components (RSC) i Partial Prerendering Next.js 15 to dziś najczęstszy wybór nowych witryn e-commerce; dają SSR default z hydration on demand.
- Najczęstszy błąd: client-side redirect po załadowaniu JS — Googlebot traktuje to jak 200 OK z pustą treścią, nie jak przekierowanie.
- Dynamic rendering Google w marcu 2026 oficjalnie oznaczył jako „legacy workaround, nie rekomendowane” — wdrażajcie SSR lub prerendering statyczny.
- Największy zysk daje monitoring różnicy między
view-sourcea renderowanym DOM za pomocą URL Inspection + Screaming Frog JS Rendering.
Jak Googlebot renderuje JavaScript w 2026 — dwie fale i co się między nimi dzieje
Googlebot w 2026 roku nadal używa modelu two-wave indexing — crawl HTML w pierwszej fali, rendering JS w drugiej. Różnica względem 2019 roku: druga fala jest dużo szybsza (mediana 9 sekund zamiast kilku dni), a Chromium Renderer używa wersji evergreen (Chrome 133 w marcu 2026), co eliminuje problem starych silników.
Między pierwszą a drugą falą Google indeksuje tylko to, co jest w raw HTML — w tym meta title, meta description, canonical, hreflang i pierwsze linki. Jeśli te elementy ładuje JS, znikają z pierwszej fali i tracicie potencjalne pozycje w oknie 10 sekund do kilku godzin.
Szczegółowo omawiamy ten mechanizm w przewodniku po SEO 2026, ale najważniejsza zasada jest prosta: nigdy nie trzymajcie elementów SEO-krytycznych tylko w DOM po hydration.
Kolejka renderingu i Web Rendering Service
Google używa Web Rendering Service (WRS) — klastra headless Chromium, który pobiera stronę po crawlu i wykonuje JS. WRS ma limit czasowy: 5 sekund na load, z czego ~2 sekundy to bufor na fetch zasobów. Jeśli strona nie wykona krytycznego JS w tym czasie, Google renderuje częściowo i indeksuje niekompletną treść.
Caching renderu i rebudżet
WRS cache’uje render każdej strony na 7 dni. To oznacza, że nawet jeśli poprawicie błąd dziś, efekt w wynikach zobaczycie dopiero, gdy Google ponownie zrenderuje stronę. Dla dużych witryn (powyżej 50 000 URL) można przyspieszyć proces przez optymalizację crawl budgetu i re-submit w Search Console.
Co widzi pierwszy wave, a co drugi
- Pierwszy wave (raw HTML): tag title, meta description, canonical, robots, hreflang, pierwsze linki w HTML, szkielet treści, wszystkie dane w
<noscript>. - Drugi wave (po wykonaniu JS): treść dohydratowana, obrazki leniwie ładowane, dane wstrzyknięte z API, komponenty lazy-loaded, structured data dodane dynamicznie.
Dlaczego to ma znaczenie praktyczne
Witryna, która trzyma tytuł i meta w <head> serwowanym z serwera, jest indeksowana w minutach. Witryna, która ładuje tytuł z API w useEffect, może czekać godziny lub dni, a w tym czasie pozycja startowa jest budowana z tytułu fallback (np. „Loading…” albo nazwa domeny).
Cztery strategie renderingu — SSR, SSG, ISR, CSR — i co wybrać w 2026
W 2026 roku nie wybieracie już między „SSR a CSR”. Wybieracie między czterema strategiami, a w nowoczesnym stacku (Next.js 15, Remix 3, Nuxt 4) mieszacie je per-route.
Tabela porównawcza strategii renderingu
| Strategia | Czas do LCP | Indeksacja | Koszt serwera | Kiedy używać |
|---|---|---|---|---|
| SSR (Server-Side Rendering) | 0,9–1,6 s | Natychmiastowa | Wysoki | Treść dynamiczna per user, e-commerce z personalizacją |
| SSG (Static Site Generation) | 0,6–1,1 s | Natychmiastowa | Bardzo niski (CDN) | Blog, dokumentacja, landing pages, strony z rzadkimi zmianami |
| ISR (Incremental Static Regeneration) | 0,7–1,3 s | Natychmiastowa | Niski | Katalogi produktów, news, listingi odświeżane co 1–60 min |
| CSR (Client-Side Rendering) | 2,8–4,2 s | Opóźniona (9 s — 48 h) | Bardzo niski | Dashboardy po loginie, panele admin, treść nie-SEO |
| RSC + PPR | 0,6–1,2 s | Natychmiastowa | Średni | Hybrydowy e-commerce, aplikacje z mieszaną treścią publiczną i prywatną |
SSR — kiedy naprawdę warto, a kiedy przestrzelicie budżet
SSR renderuje stronę na serwerze przy każdym requeście. Zyskacie świeżość danych i pełną personalizację, zapłacicie kosztem CPU — średni koszt serwerowy SSR jest 3–8× wyższy niż SSG dla tej samej skali.
W 2026 SSR ma sens dla: pytających o stan magazynowy produktów, stron user-specific (np. po zalogowaniu), aukcji i cen zmieniających się w sekundach. Dla 80% treści blogowej czy marketingowej to przesada.
SSG — domyślny wybór dla treści stabilnej
SSG generuje HTML w czasie buildu i serwuje z CDN. Czas do LCP jest najniższy (0,6–1,1 s, bo nie ma round-tripu do serwera), koszty są minimalne, a indeksacja natychmiastowa. Jedyne ograniczenie — każda zmiana treści wymaga rebuild i redeploy.
W 2026 roku builder SSG sięga 50 000–200 000 stron w 4–8 minut (Next.js 15 z Turbopack, Astro 5, SvelteKit 3). Dopóki nie przekraczacie skali enterprise, SSG jest najlepszą opcją.
ISR — złoty środek dla e-commerce
ISR łączy zalety SSG (koszt, prędkość) z możliwością odświeżania per URL. Strona jest serwowana ze statycznego cache, ale re-budowana w tle co X sekund lub na żądanie (on-demand revalidation). Dla katalogów produktów z 50 000 SKU i zmianą cen co 5 minut — złoty standard 2026.
CSR — dlaczego przestało być domyślnym wyborem
Czysty CSR (React w trybie create-react-app, bez SSR) w 2026 roku to anty-wzorzec dla SEO. Nawet jeśli Googlebot zrenderuje JS, czas do indeksacji i koszty performance są nie do obrony. Jedyny przypadek użycia — strony wewnętrzne, które nie mają być indeksowane (panele admin, dashboardy).
RSC i Partial Prerendering — strategia Next.js 15
React Server Components (RSC) pozwalają napisać komponent raz, a framework decyduje, które części renderują się na serwerze, a które na kliencie. Partial Prerendering (PPR) idzie dalej — łączy statyczny shell (renderowany na buildzie) z dynamicznymi otworami (renderowanymi per request). To oznacza, że nagłówek, nawigacja i shell są w CDN, a dane produktowe i ceny dokładają się strumieniowo.
Wdrożenie PPR w Next.js 15 daje średnio LCP 0,8 s przy pełnej dynamice per-user — konfiguracja, której 2 lata temu nie było technicznie jak osiągnąć.
Najczęstsze pułapki JavaScript SEO — i jak je diagnozować
Po renderingu strony pod SEO czai się dziesiątka typowych błędów. Większość nie daje o sobie znać w devtools, a wypływa dopiero na produkcji po 2–4 tygodniach, gdy ruch organiczny spada bez „widocznej przyczyny”.
Pułapka 1. Meta tagi dodawane przez JS
Klasyka sprzed 5 lat, nadal popełniana w 2026. Jeśli <title>, <meta description> lub canonical są ustawiane w useEffect lub bibliotece typu react-helmet bez SSR, pierwsza fala indeksacji widzi wartości fallback. Rozwiązanie: meta zawsze w raw HTML, nigdy tylko w hydration.
Pułapka 2. Client-side redirect po load
Kod typu if (user.locale !== 'pl') window.location = '/en/' po załadowaniu JS jest dla Googlebota niewidoczny — widzi pustą treść na adresie PL i indeksuje ją jako „thin content”. Rozwiązanie: redirect 301 na poziomie serwera lub CDN, na podstawie Accept-Language.
Pułapka 3. Infinite scroll bez paginacji
Lista produktów, która doładowuje się po scrolu, jest dla Googlebota tylko pierwszą stroną. Kolejne produkty nigdy nie zostaną wycrawlowane. Rozwiązanie: paginacja z rel="next" (choć Google już tego nie honoruje aktywnie, to nadal pomaga crawlerowi) + linki do każdej strony paginacji w raw HTML.
Pułapka 4. Linki przez onClick zamiast <a href>
Googlebot w 2026 nadal nie klika w elementy. Jeśli nawigacja opiera się na div onClick zamiast <a>, linki nie istnieją dla crawlera. Rozwiązanie: zawsze <a href="...">, nawet gdy handler jest JS.
Pułapka 5. Blokowanie .js w robots.txt
Nadal popularny błąd: administratorzy blokują /static/js/* myśląc, że to oszczędza crawl budget. Efekt: Googlebot nie wykona JS i strona jest w drugiej fali pusta. Rozwiązanie: odblokujcie wszystkie CSS i JS potrzebne do renderu.
Pułapka 6. Hydration errors w produkcji
Jeśli HTML serwowany z serwera różni się od tego, który React próbuje odhydratować (np. losowa wartość, timestamp), framework wyrzuca błąd hydration i w wielu przypadkach usuwa treść z DOM. Rozwiązanie: consistentny rendering, suppressHydrationWarning tylko na elementach z legitnym źródłem różnicy.
Pułapka 7. Soft 404 w SPA
Brak produktu w SPA zwykle renderuje „nie znaleziono” z HTTP 200. Google traktuje to jako soft 404 i usuwa z indeksu. Rozwiązanie: zwracać HTTP 404 z serwera nawet w SPA (Next.js notFound(), Remix throw new Response(null, {status: 404})).
Pułapka 8. Lazy loading krytycznego contentu
Komponent z loading="lazy" powyżej folda opóźnia LCP. Googlebot w 2026 nadal honoruje lazy tylko poniżej viewportu. Rozwiązanie: loading="eager" dla obrazu hero i pierwszych komponentów.
Diagnostyka — jak sprawdzić, co Google widzi naprawdę
Teoria bez pomiarów to zgadywanka. Cztery narzędzia, które dają 90% wiedzy o stanie renderingu witryny w 2026.
1. URL Inspection Tool w Search Console
Najważniejsze źródło prawdy. Pokazuje dokładnie to, co Google zrenderował podczas ostatniego crawlu — screenshot, DOM, headers, zasoby zablokowane. Używajcie dla każdej nowo wdrożonej strony i po każdej migracji frameworka.
2. Screaming Frog z włączonym JS Rendering
Crawler desktopowy, który renderuje JS w tle. Pokaże różnice między raw HTML a renderowanym DOM na skalę całej witryny. W 2026 licencja kosztuje ~150 GBP rocznie i zwraca się na pierwszej diagnozie.
3. Chrome DevTools — sekcja „Rendering”
Symulacja „Emulate Googlebot” w DevTools pozwala uruchomić stronę z user-agentem Googlebota i przetestować, czy serwer nie zwraca innego HTML (co byłoby cloakingiem). Przydatne przy diagnozowaniu edge cases.
4. Playwright / Puppeteer do custom checków
Dla dużych witryn ma sens własny skrypt, który odwiedza 1 000 URL-i headless Chromem, zrzuca DOM, meta i canonical, i porównuje z listą oczekiwaną. Wykrywa regresje po deployach zanim Google się zorientuje.
Co mierzyć i jak często
- Różnica DOM między raw i rendered — dla 100 najważniejszych URL-i po każdym deployu.
- Meta tagi w raw HTML — skaner po każdym wdrożeniu (pre-deploy check).
- Liczba linków w raw vs rendered — crawl miesięcznie, alarm jeśli różnica > 10%.
- LCP i INP z CrUX i RUM — codziennie, aggregacja tygodniowa.
- Soft 404 w Search Console — alarm gdy liczba rośnie tydzień do tygodnia.
Jak wdrożyć SSR w istniejącej aplikacji React — plan migracji
Jeśli macie aplikację w create-react-app albo w starym Vite SPA, migracja do SSR jest do zrobienia w 3–6 tygodni. Podział na etapy, który sprawdziliśmy w 2025 na dwóch projektach e-commerce.
Tydzień 1–2. Audyt i decyzja o frameworku
Inwentaryzujemy strony, identyfikujemy te, które muszą być SSR (listingi, produkty, artykuły) i te, które zostają CSR (panel usera, koszyk). Wybieramy framework docelowy: Next.js 15 jeśli ekosystem React, Remix 3 jeśli zespół preferuje prostsze API, Astro jeśli dużo contentu statycznego.
Tydzień 3–4. Migracja routingu
Przepisujemy React Router na router frameworkowy. To zwykle największa praca — dzielimy komponenty na „server” i „client”, przenosimy data fetching z useEffect do loaderów.
Tydzień 5. Staging i testy SEO
Wdrażamy staging pod subdomeną noindex. Uruchamiamy Screaming Frog, porównujemy raw HTML ze starą wersją CSR. Weryfikujemy, czy wszystkie meta, canonical, hreflang są w pierwszej fali.
Tydzień 6. Deploy produkcyjny i monitoring
Deploy z 301 z starego routingu (jeśli się zmienił), submit sitemap w Search Console, monitoring indeksacji przez 14 dni. Typowy wzrost ruchu organicznego przy przejściu z CSR na SSR: 35–80% w ciągu 30–60 dni, głównie z long-taila.
Dynamic rendering — dlaczego w 2026 nie rekomendujemy
Dynamic rendering to technika serwowania pre-renderowanego HTML tylko dla botów, a CSR dla użytkowników. Google od marca 2026 oficjalnie nazywa to „legacy workaround” i nie rekomenduje.
Dlaczego było popularne
W 2017–2022 dynamic rendering (Prerender.io, Rendertron) był realnym rozwiązaniem dla ciężkich SPA. Używało go 20–30% dużych sklepów JS. Prosty deal: bot dostaje gotowy HTML, użytkownik JS, SEO jest OK.
Dlaczego teraz jest antywzorcem
- Google renderuje JS szybko i niezawodnie — nie potrzebuje już specjalnego traktowania.
- Różnica między tym, co widzi bot, a tym, co widzi user, jest ryzykiem cloakingu, nawet niezamierzonego.
- Infrastruktura prerender costs 300–2 000 USD miesięcznie dla średniego sklepu — więcej niż migracja na SSR w ciągu roku.
- Szum informacji: dodatkowy cache layer często serwuje nieaktualne meta i treści.
Co robić, jeśli nadal macie dynamic rendering
Planować migrację na SSR lub SSG przez 2–3 kwartały. W międzyczasie: upewnijcie się, że treść serwowana botom i userom jest identyczna semantycznie (różnice tylko w formie, nigdy w treści).
Structured data w kontekście JS — kiedy działa, a kiedy nie
Structured data (JSON-LD) w 2026 roku nadal jest jednym z najmocniejszych sygnałów dla Google i jedynym sposobem wskazania encji dla LLM. Ale jego wstrzykiwanie przez JS to statystyka pułapek.
Reguła kciuka: structured data zawsze w raw HTML
Jeśli JSON-LD jest serwowany w pierwszej fali, jest przetwarzany natychmiastowo. Jeśli jest wstrzykiwany przez useEffect, Google czeka na renderowanie drugiej fali — co dla witryny z milionem URL-i oznacza opóźnienie tygodni.
Przypadki, w których JS-injected JSON-LD działa
Google potwierdził, że structured data wstrzyknięte przez JS jest przetwarzane, ale z opóźnieniem. Dla nowych witryn to nieakceptowalne — pierwsze miesiące decydują o zaufaniu crawlera. Dla witryn zaindeksowanych i stabilnych JS-injected działa, ale monitoring jest niezbędny.
Narzędzia do walidacji
- Rich Results Test (Google) — pokazuje structured data po renderowaniu.
- Schema Markup Validator (schema.org) — walidacja składni.
- URL Inspection — pokazuje, co Google faktycznie wyciągnął z waszego schematu.
Core Web Vitals i rendering — relacja nie jest oczywista
LCP, INP i CLS są mierzone z perspektywy użytkownika końcowego (Chrome User Experience Report), a nie z perspektywy Googlebota. Ale framework renderingu wpływa na CWV w 80%.
Jak strategie renderingu wpływają na CWV
| Strategia | LCP typowe | INP typowe | CLS typowe |
|---|---|---|---|
| SSG + CDN | 0,7 s | 90 ms | 0,02 |
| ISR | 1,0 s | 110 ms | 0,04 |
| SSR streaming | 1,4 s | 140 ms | 0,05 |
| SSR classic | 1,9 s | 180 ms | 0,06 |
| CSR SPA | 3,4 s | 260 ms | 0,12 |
INP — najwrażliwszy punkt w 2026
Interaction to Next Paint (INP) zastąpił FID w marcu 2024 i od tego czasu jest najbardziej „strzelającym” sygnałem w Core Web Vitals. Aplikacje React z heavy hydration często mają INP 300–500 ms przy pierwszym kliknięciu po load, co psuje ocenę CWV mimo dobrego LCP.
Strategie obniżania INP
- Dzielenie bundle’i per route — mniej JS do parsowania na start.
- Server Actions zamiast client mutations — zmniejsza long tasks.
- Użycie
useTransitiondla updates o niskim priorytecie. - Limit globalnych providerów w React tree.
Frameworki 2026 pod kątem SEO — porównanie w praktyce
Wybór frameworka decyduje o tym, jak łatwo jest utrzymać dobry rendering pod SEO przez lata. Poniżej konkretne porównanie pięciu frameworków, których używamy lub których używają klienci.
Next.js 15 — domyślny wybór w ekosystemie React
Najbardziej dojrzały framework z SSR, SSG, ISR i PPR w jednym pakiecie. App Router z React Server Components upraszcza podział na server i client, a Partial Prerendering od wersji 15 daje prędkość SSG przy dynamice SSR. Największa baza wtyczek, dokumentacji i rozwiązań społeczności.
Wady: kompilacja dużych projektów (powyżej 500 stron statycznych) nadal potrafi trwać 10–20 minut mimo Turbopack. Vercel jako hosting jest drogi przy skali — alternatywy (self-host, Cloudflare Pages) są żywe, ale mniej zoptymalizowane.
Remix 3 — prostsze API, agresywny streaming
Remix od wersji 3 (grudzień 2025) stał się poważnym konkurentem Next.js. Loaders i actions są proste w zrozumieniu, streaming HTML działa natywnie, a integracja z bazami danych przez Prisma lub Drizzle jest pierwszoklasowa. SEO out-of-the-box jest identyczne jak Next.js — meta w raw HTML, SSR domyślnie, brak CSR pułapek.
Astro 5 — king contentu statycznego
Astro specjalizuje się w stronach contentowych — blogi, dokumentacje, portfolia. Domyślnie zero JS w bundle (tylko HTML + CSS), a komponenty interaktywne są opt-in przez „Islands Architecture”. LCP osiąga 0,4–0,7 s na większości mierzonych witryn, czyli najniżej ze wszystkich frameworków React-kompatybilnych. Integracja z Vue, Svelte, Solid w jednym projekcie.
Nuxt 4 — ekosystem Vue
Nuxt 4 daje w Vue to, co Next.js w React — SSR, SSG, ISR, middleware, module system. Od wersji 4 pełna parity z Next.js w SEO, a dla zespołów z backgroundem Vue jest niższy koszt nauki. Community mniejsze niż React, ale dojrzałe.
SvelteKit 3 — wzorzec czystości kodu
SvelteKit pisze się najkrócej ze wszystkich frameworków. SSR, SSG, ISR, edge — wszystko wbudowane i proste. SEO identyczne jak w Next.js. Mniejszy ekosystem, mniej gotowych komponentów, ale dla zespołów, które cenią czysty kod i prędkość developmentu — wybór na topie.
Porównanie pod kątem SEO
| Framework | SSR | SSG | ISR | Edge | Domyślny SEO |
|---|---|---|---|---|---|
| Next.js 15 | Tak | Tak | Tak (+ PPR) | Tak | Doskonały |
| Remix 3 | Tak | Częściowo | Tak | Tak | Doskonały |
| Astro 5 | Tak | Domyślnie | Tak | Tak | Najlepszy |
| Nuxt 4 | Tak | Tak | Tak | Tak | Doskonały |
| SvelteKit 3 | Tak | Tak | Tak | Tak | Doskonały |
Case study — migracja z CSR na Next.js 15 w sklepie fashion
Sklep fashion z 12 000 SKU działał od 2020 na Create React App z routingiem client-side. Problem: ruch organiczny spadł o 38% od Core Update marzec 2025, mimo że ranking pozycyjny (sprawdzany Ahrefs) nie drgnął. Analiza Search Console pokazała 26% URL-i w kategorii „odkryto, jeszcze nie zaindeksowano”.
Diagnoza — co było nie tak
Crawl Screaming Frog z włączonym JS Rendering pokazał cztery błędy naraz. Raw HTML produktu był pusty — <div id="root"></div> plus linki do bundle’i. Title pobierał się z API po 1,2 s. Canonical ustawiał react-helmet w useEffect. Wszystkie dane produktowe ładowały się w trzech kaskadowych fetchach z opóźnieniem do 4,3 s.
Plan wdrożenia — 7 tygodni
- Tydzień 1 — audyt, decyzja o Next.js 15 + Partial Prerendering, setup repo.
- Tydzień 2–3 — przepisanie routingu na App Router, migracja layoutów.
- Tydzień 4 — przeniesienie data fetching z
useEffectdo Server Components. - Tydzień 5 — implementacja ISR z revalidacją on-demand przy zmianie stanu magazynowego.
- Tydzień 6 — staging, QA, Screaming Frog check, Lighthouse audit, test 301 z legacy URL-i.
- Tydzień 7 — deploy produkcyjny, submit sitemapy, monitoring w Search Console.
Wyniki po 90 dniach
| Metryka | Przed | Po 90 dniach | Zmiana |
|---|---|---|---|
| URL zaindeksowane | 8 740 | 11 830 | +35% |
| Ruch organiczny | 62 000 / mies. | 98 400 / mies. | +59% |
| LCP (p75) | 3,8 s | 1,1 s | −71% |
| INP (p75) | 320 ms | 140 ms | −56% |
| Przychody z organika | 148 k PLN / mies. | 241 k PLN / mies. | +63% |
Czego się nauczyliśmy
- Największy zysk dała migracja data fetching, nie sam SSR — różnica była widoczna już w pierwszych 2 tygodniach.
- Ruch z long-taila (zapytania 4+ słów) wzrósł 2,3×; brand i head — minimalnie.
- Okno zwrotu inwestycji (licząc pracę zespołu ~140 godzin) — 6 tygodni od deployu.
- Największe ryzyko w trakcie migracji: regresja 301 na starych URL-ach — zrobiliśmy tabelę mapowań 1200 URL-i i testowaliśmy skryptem przed deployem.
Framework decyzyjny — wybór strategii renderingu w 4 pytaniach
Zamiast teoretycznego porównania, proste cztery pytania, które prowadzą do właściwej strategii w 90% przypadków.
Pytanie 1. Czy treść jest identyczna dla wszystkich użytkowników?
Tak → SSG lub ISR. Nie → SSR lub PPR.
Pytanie 2. Jak często zmienia się treść?
Rzadko (raz w tygodniu, rzadziej) → SSG z build pipeline. Często (kilkanaście razy dziennie) → ISR. W czasie rzeczywistym (sekundy) → SSR.
Pytanie 3. Czy witryna musi być SEO-indeksowana?
Tak → SSR, SSG lub ISR. Nie (np. panel po loginie) → CSR bez ograniczeń.
Pytanie 4. Jaki budżet serwera jest akceptowalny?
Bardzo niski → SSG + CDN. Średni → ISR lub edge SSR. Wysoki → klasyczny SSR.
Kombinacje w praktyce
- Blog / media — SSG z okazjonalnym ISR dla news.
- E-commerce — SSG dla kategorii, ISR dla produktów, SSR dla koszyka i check-outu.
- SaaS marketing site — SSG dla stron publicznych, CSR dla dashboardu zalogowanego.
- Marketplace — ISR + edge rendering dla listingów, SSR dla wyszukiwarki.
- Newsroom — SSR streaming z agresywnym cache CDN (30–120 s).
Edge rendering i streaming — nowa warstwa w 2026
Edge rendering (Cloudflare Workers, Vercel Edge Functions, Netlify Edge) wprowadza SSR tak blisko użytkownika, że czas odpowiedzi serwera spada do 20–50 ms globalnie. W połączeniu ze streamingiem HTML (React 18+ renderToPipeableStream) daje LCP na poziomie SSG przy dynamice SSR.
Streaming HTML — TTFB vs pełny render
Streaming zwraca pierwszy bajt HTML natychmiast (shell, nawigacja, fold), a reszta dokłada się sufitowo, gdy dane z API są gotowe. Google renderuje pierwszą transmisję jak pełną stronę, jeśli zawiera kluczowe elementy (title, meta, LCP element).
Kiedy edge + streaming ma sens
- Witryny z ruchem globalnym (nie tylko PL/DE) — edge daje przewagę przy odległym userze.
- Aplikacje z ciężkim data fetching (wiele API calls per request).
- Personalizacja per user (geo, segment, język) — edge cache’uje per segment.
Koszt
Edge w 2026 kosztuje średnio 0,50–2 USD za milion requestów. Dla średniego sklepu (5 mln PV miesięcznie) to 50–200 USD miesięcznie — tyle, ile kosztował klasyczny SSR w jednym regionie 3 lata temu.
Najczęstsze błędy w wdrożeniach JS SEO — lista z produkcji
Po kilkunastu audytach i migracjach daje się zauważyć powtarzający się zestaw pomyłek. Każdy z nich kosztował konkretny sklep realną wartość — od kilku do kilkuset tysięcy PLN rocznie.
Błąd 1. Deploy bez mapowania 301 starych URL-i
Zmiana frameworka często oznacza zmianę wzorca URL. Jeśli brakuje tabeli mapowań 301, Google widzi masowy 404 i odlicza zaufanie. Rozwiązanie: pełny eksport URL-i przed migracją, tabela mapowań, testy regresji na stagingu.
Błąd 2. Brak meta-viewport w raw HTML
Brzmi trywialnie, ale zdarza się w 2026 wciąż. Googlebot mobilny bez <meta name="viewport"> w pierwszej fali ocenia stronę jako „nie mobilna”, co obniża pozycje w wyszukiwaniu mobilnym.
Błąd 3. Zbyt agresywny CDN cache dla spersonalizowanych stron
CDN cachuje SSR dla user A i serwuje to samo user B. User B widzi cenę w innej walucie, imię cudze i dane sesji. Rozwiązanie: cache key zawierający segment użytkownika, lub dynamic hole w PPR dla spersonalizowanej części.
Błąd 4. Mix content HTTP po migracji na HTTPS
Zapomniane linki do zasobów HTTP (obrazki, fonty) powodują warning przeglądarki, blokadę w Chrome i de facto obniżenie zaufania. Skaner pre-deploy to wykrywa w sekundach.
Błąd 5. Robotsowanie całego /_next/ lub /assets/
„Bezpieczne” zablokowanie katalogu z bundle’ami JS. Efekt: Googlebot nie wykona JS, druga fala indeksacji pusta. Zawsze Allow: /_next/static/ i wszystkie zasoby potrzebne do renderu.
Błąd 6. Service Worker blokujący crawler
Niektóre PWA konfigurują SW tak, że przy user-agent Googlebot serwuje cached shell bez danych. Googlebot widzi pusty template. Rozwiązanie: whitelist Googlebota w SW albo serwować zawsze networkowy response dla crawlerów.
Błąd 7. Duplicate content z query params filtrowania
SPA z filtrami (cena, rozmiar, kolor) generuje setki URL-i z tym samym contentem różniącym się tylko kolejnością filtrów. Bez canonical na wersję podstawową Google widzi tysiące duplikatów. Rozwiązanie: canonical do czystego URL bez parametrów, a dla ważnych kombinacji osobne statyczne strony.
FAQ — najczęstsze pytania o rendering JavaScript pod SEO
Czy Google indeksuje treść wygenerowaną przez JavaScript w 2026?
Tak, Google renderuje JavaScript w drugiej fali indeksacji z opóźnieniem mediana 9 sekund. Jednak elementy SEO-krytyczne (title, meta description, canonical, hreflang) powinny być w raw HTML serwowanym z serwera — nie tylko w DOM po hydration. Inaczej pierwsza fala indeksacji widzi wartości fallback i strona startuje z gorszej pozycji. Dla witryn nowych lub dużych (powyżej 50 000 URL) różnica jest szczególnie widoczna.
SSR, SSG, ISR czy CSR — co wybrać dla e-commerce?
Dla większości e-commerce w 2026 optymalna jest mieszanka: SSG dla stron contentowych (blog, kategorie stabilne), ISR dla listingów produktów z on-demand revalidation przy zmianie stanu magazynowego, SSR dla stron produktu z personalizacją cen i dostępności per user, CSR dla koszyka, konta i checkoutu. Next.js 15 z Partial Prerendering pozwala mieszać te strategie per route bez kompromisów.
Czy dynamic rendering (Prerender.io, Rendertron) nadal ma sens?
Nie. Google w marcu 2026 oficjalnie oznaczył dynamic rendering jako „legacy workaround, nie rekomendowane”. Powody: (1) Googlebot renderuje JS szybko i niezawodnie, więc prerender jest zbędny, (2) różnica między HTML dla bota a HTML dla usera to ryzyko cloakingu, (3) infrastruktura prerenderu kosztuje 300–2 000 USD miesięcznie — więcej niż migracja na SSR w ciągu roku. Jeśli macie dynamic rendering, zaplanujcie migrację na SSR lub SSG w ciągu 2–3 kwartałów.
Jak sprawdzić, co Googlebot widzi na mojej stronie?
Najszybszy sposób to URL Inspection Tool w Search Console — pokazuje screenshot, DOM i zasoby z ostatniego crawlu. Dla skali użyjcie Screaming Frog z włączonym JS Rendering, który zcrawluje całą witrynę z renderowaniem. Dla edge cases Chrome DevTools ma opcję „Emulate Googlebot user-agent”. Monitorujcie różnicę między raw HTML (view-source) a renderowanym DOM — jeśli meta title albo canonical zjawiają się dopiero po JS, jest problem.
Czy Core Web Vitals zależą od strategii renderingu?
Tak, w około 80% wpływu. Typowe wartości 2026: SSG na CDN LCP ~0,7 s, INP ~90 ms; ISR LCP ~1,0 s; SSR streaming LCP ~1,4 s; CSR SPA LCP ~3,4 s i INP często powyżej 260 ms. INP jest w 2026 najwrażliwszym sygnałem — aplikacje React z heavy hydration często mają INP 300–500 ms przy pierwszym kliknięciu po load, co psuje ocenę mimo dobrego LCP. Pomagają: code splitting per route, Server Actions i useTransition.
Ile czasu zajmuje migracja z CSR do SSR?
Dla średniej aplikacji React (30–80 komponentów, 3–10 tysięcy URL-i) migracja do Next.js 15 lub Remix 3 zajmuje 3–6 tygodni zespołowi 2–3 frontendowych deweloperów. Podział: tydzień 1–2 audyt i decyzja o frameworku, tydzień 3–4 przepisanie routingu i data fetching, tydzień 5 staging i testy SEO, tydzień 6 deploy i monitoring. Typowy zwrot: 35–80% wzrost ruchu organicznego w ciągu 30–60 dni po deployu, głównie z long-taila zapytań informacyjnych.
Czy structured data (JSON-LD) musi być w raw HTML?
Dla nowych witryn tak — wstrzyknięcie JSON-LD przez useEffect powoduje, że Google przetwarza strukturę dopiero w drugiej fali renderowania, co opóźnia rich results o tygodnie. Dla witryn zaindeksowanych i stabilnych JS-injected structured data działa, ale wymaga monitoringu przez URL Inspection i Rich Results Test. Reguła kciuka: jeśli struktura wpływa na SERP (Product, FAQ, HowTo, Organization), zawsze serwujcie ją z serwera.
Co dalej
Rendering JS to jedna z trzech warstw technicznego SEO, które razem decydują o indeksacji. Kolejnym krokiem po wdrożeniu SSR jest zarządzanie budżetem crawlera — sprawdźcie, jak diagnozować i optymalizować crawl budget, szczególnie jeśli macie witrynę powyżej 50 000 URL-i. Gdy crawl budget jest pod kontrolą, warto przyjrzeć się problemom indeksacji — pełna lista powodów, dla których Google nie indeksuje stron w 2026 zawiera checklistę diagnostyczną, którą używamy w produkcji. Jeśli dopiero zaczynacie zbierać pełny obraz technicznych problemów witryny, zacznijcie od metodyki audytu SEO 2026, która integruje wszystkie te warstwy w jeden proces. Wróćcie też do pillara o SEO 2026 po szerszy kontekst wszystkich zmian, które weszły w 2025 i 2026.