Architektura SEO w Next.js 15: SSR, PPR i Server Components

W Next.js 15 wybór architektury renderowania decyduje o tym, czy strona jest czytelna zarówno dla klasycznych wyszukiwarek, jak i dla crawlerów AI. App Router z React Server Components i Partial Prerendering (PPR) przenosi generowanie treści na serwer. Od tego zależy, czy Googlebot, ChatGPT, Claude i Perplexity w ogóle uchwycą pełną treść strony. Ten artykuł porządkuje strategie renderowania i pokazuje, której strategii potrzebuje każda trasa.

Dlaczego architektura renderowania decyduje o widoczności

Kluczowe ustalenie pochodzi z analizy ruchu crawlerów w sieci Vercel: żaden z dużych crawlerów AI (GPTBot, ClaudeBot, Meta-ExternalAgent, PerplexityBot, Bytespider) nie renderuje JavaScriptu; w przypadku ChatGPT 11,50%, a w przypadku Claude 23,84% pobrań dotyczy plików JavaScript, ale nie są one wykonywane. W pełni renderują tylko Gemini (przez infrastrukturę Googlebota) i AppleBot. Dla każdej strony, której treść powstaje dopiero po stronie klienta w JavaScripcie, oznacza to, że crawlery AI widzą pustą skorupę.

Te crawlery AI nie są już zjawiskiem marginalnym. GPTBot, Claude, AppleBot i PerplexityBot generują łącznie około 1,3 mld pobrań miesięcznie, czyli nieco ponad 28% z 4,5 mld pobrań Googlebota w sieci Vercel. Jeśli chcesz być cytowany w odpowiedziach AI (Generative Engine Optimization, w skrócie GEO), musisz dostarczać treść po stronie serwera jako gotowy HTML.

Również klasyczny Googlebot karze renderowanie po stronie klienta, choć w subtelniejszy sposób. Googlebot renderuje JavaScript, ale w drugiej fali: strony wymagające renderowania trafiają oprócz kolejki crawlowania także do kolejki renderowania. Często cytowane międzynarodowe badanie określa skutki liczbowo: Google potrzebował 313 godzin na strony renderowane w JavaScripcie wobec 36 godzin na czysty HTML, czyli około dziewięciu razy dłużej. W dużych serwisach znacznie opóźnia to indeksowanie nowych i zaktualizowanych treści.

Do tego dochodzi twarda granica techniczna. Googlebot crawluje już tylko pierwsze 2 MB każdego zasobu zamiast wcześniejszych 15 MB, co oznacza spadek o 86,7%. Limit dotyczy każdego zasobu, czyli osobno HTML, bundla JavaScript i CSS. Przy rozdętych bundlach po stronie klienta istnieje więc ryzyko, że kluczowe skrypty zostaną obcięte.

Jak to działa: SSG, SSR, ISR i PPR w porównaniu pod kątem SEO

Next.js 15 oferuje cztery strategie renderowania. Wybór dla każdej trasy zależy od tego, jak dynamiczna jest treść i jak szybko musi być aktualna.

• SSG (Static Site Generation): Strona jest generowana jako HTML podczas buildu i serwowana z CDN. Najlepszy możliwy TTFB i LCP, idealne dla crawlerów AI, bo pełna treść od razu znajduje się w HTML. Sprawdza się w artykułach bazy wiedzy, stronach usług i wpisach na blogu.
• ISR (Incremental Static Regeneration): Jak SSG, ale strona jest generowana ponownie po upływie określonego czasu (revalidate) lub na żądanie przez trigger. Łączy statyczne serwowanie z aktualnością redakcyjną, np. w cennikach lub informacjach o stanach magazynowych.
• SSR (Server-Side Rendering): Strona jest renderowana na serwerze przy każdym żądaniu. Niezbędne przy treściach zależnych od użytkownika lub żądania (geotargeting, testy A/B). Treść znajduje się w HTML, ale TTFB zależy od czasu pracy serwera.
• PPR (Partial Prerendering, w Next.js 15 eksperymentalne): Łączy elementy statyczne i dynamiczne w obrębie jednej trasy. Statyczna powłoka jest prerenderowana podczas buildu i serwowana z CDN, a dynamiczne części są strumieniowo dosyłane jako HTML.

Z punktu widzenia architektury PPR to najciekawsze podejście dla SEO. Statyczna powłoka (nagłówek, główna treść, stopka) znajduje się od razu w początkowej odpowiedzi HTML i zapewnia niski TTFB oraz szybki LCP. Dynamiczne fragmenty umieszczone w granicach <Suspense> są strumieniowo dosyłane z serwera i również jako HTML wstawiane do tej samej odpowiedzi. Kluczowe dla crawlowalności: strumieniowana treść to HTML, a nie JavaScript doładowywany po stronie klienta. Crawler bez obsługi JS otrzymuje pełną treść, gdy tylko strumień się zakończy.

Server Components stanowią fundament tego wszystkiego. Renderują się wyłącznie na serwerze i dla własnej logiki wysyłają do klienta zero JavaScriptu. To drastycznie zmniejsza zakres hydratacji, co bezpośrednio przekłada się na INP (Interaction to Next Paint), i zmniejsza bundle JS w odniesieniu do limitu 2 MB. Interaktywność dodaje się celowo na obrzeżach przez Client Components ("use client"), a nie hurtowo dla całej strony.

Next.js 16, wydany 21 października 2025 roku, wprowadza dwie zmiany istotne dla tego artykułu. Flaga experimental.ppr zniknęła, a Partial Prerendering działa tam przez Cache Components (cacheComponents: true w next.config). Plik middleware zmienił się w proxy.ts, a middleware.ts uznaje się za przestarzały. Logika SEO tego artykułu pozostaje taka sama: statyczna powłoka i strumieniowane części docierają do crawlera jako HTML.

Dobre praktyki architektury SEO w Next.js 15

Świadomy wybór strategii renderowania dla każdej trasy

Standardowa zasada: tak statycznie, jak to możliwe, tak dynamicznie, jak to konieczne. Strony z treścią (baza wiedzy, blog, usługi) powinny korzystać z SSG lub ISR. Strony spersonalizowane lub działające niemal w czasie rzeczywistym używają SSR lub PPR z wąsko zakreślonymi granicami <Suspense>, tak aby istotna dla SEO powłoka pozostała statyczna, a strumieniowane były tylko naprawdę dynamiczne części.

Pełne wykorzystanie Metadata API po stronie serwera

App Router generuje metadane po stronie serwera przez obiekt metadata lub funkcję generateMetadata. Ważne:

• Ustawienie metadataBase: Bez metadataBase Next.js uzupełnia względne ścieżki obrazów Open Graph i Twitter na podstawie wartości zastępczej, a poza Vercelem na podstawie localhost. Adresy URL obrazów są wtedy bezwzględne, ale wskazują adres, do którego nie dotrze żaden crawler. Dlatego zawsze ustawiaj bazowy URL na swoją domenę produkcyjną.
• Canonical dla każdej trasy: ustawiaj przez alternates.canonical, aby uniknąć duplicate content wynikającego z wariantów parametrów lub ścieżek.
• hreflang dla regionu DACH: podawaj przez alternates.languages z de-AT, de-DE i x-default. To częste źródło błędów: międzynarodowe badanie wykazało, że 31,02% wielojęzycznych witryn zawiera sprzeczne dyrektywy hreflang, a 16,04% klastrów hreflang nie ma samoodwołujących się tagów. Każda wersja językowa musi odwoływać się do siebie i do wszystkich pozostałych.
• Osadzanie JSON-LD po stronie serwera: jako <script type="application/ld+json"> bezpośrednio w Server Component. Dane strukturalne są powszechne: w 2024 roku JSON-LD występuje na 41% wszystkich stron, o 7 punktów procentowych więcej niż 34% w 2022 roku. Renderowany po stronie serwera jest czytelny także dla crawlerów AI, które nie wykonują JS.

Dynamiczne generowanie obowiązkowych plików

Next.js 15 zastępuje zewnętrzne wtyczki SEO plikami opartymi na konwencjach:

• sitemap.ts: programowo generuje mapę witryny XML, łącznie z lastModified dla każdego URL jako precyzyjnym sygnałem lastmod.
• robots.ts: dynamicznie tworzy plik robots.txt, łącznie z odwołaniem do sitemap i regułami dla wybranych user agentów.
• Przekierowania 301: stałe przekierowania należą do next.config (redirects()) albo, przy dynamicznej logice, do middleware (od Next.js 16 proxy.ts). Używaj kodu statusu 308/301, aby moc linków i sygnały indeksowania zostały przeniesione.

Edge, CDN i cache dla niskiego TTFB

Strony statyczne i ISR są serwowane z CDN z lokalizacji edge blisko użytkownika, co minimalizuje TTFB dla odwiedzających w całej Europie. Można tym sterować przez revalidate (interwał czasowy), nagłówki cache-control i rewalidację na żądanie za pomocą revalidatePath lub revalidateTag. HTTP/3 dodatkowo zmniejsza narzut związany z nawiązywaniem połączenia. Ponieważ Google ma w Austrii w maju 2026 roku 81,87% udziału w rynku, a Bing 9,01%, optymalizacja pod Googlebota pozostaje priorytetem, ale bez zaniedbywania Binga.

Wywoływanie IndexNow przy rewalidacji na żądanie

Gdy trigger redakcyjny rewaliduje stronę, w tym samym Route Handlerze można wysłać ping IndexNow do Binga i Yandexa. To wyraźnie przyspiesza indeksowanie w tych wyszukiwarkach: IndexNow odpowiada za 18% wszystkich klikniętych nowych adresów URL w wyszukiwaniu internetowym, przy ponad 3,5 mld URL zgłaszanych dziennie. W przypadku Google IndexNow nie zastępuje crawlowania, ale skutecznie uzupełnia widoczność w ekosystemie Binga.

Optymalizacja Core Web Vitals wbudowanymi narzędziami

Next.js 15 zawiera narzędzia na wszystkie trzy metryki CWV:

• next/image na LCP i CLS: dostarcza nowoczesne formaty, responsywne rozmiary i zarezerwowane miejsce, które zapobiega przesunięciom układu.
• next/font na CLS: hostuje fonty lokalnie i zapobiega przesunięciom układu spowodowanym podmianą fontów.
• Streaming i Suspense na LCP: renderują najpierw kluczową treść, a wolne źródła danych przenoszą na później.
• Server Components i code splitting na INP: zmniejszają ilość JS po stronie klienta, a tym samym czas przetwarzania interakcji.

Celowa obsługa crawlerów AI i GEO

Treść renderowana po stronie serwera to podstawowy warunek, aby ChatGPT, Claude i Perplexity mogły odczytać tekst. Dostęp poszczególnych botów AI reguluje robots.txt (przez robots.ts), a opcjonalny plik llms.txt może wskazywać kluczowe treści. Dla cytowalności w odpowiedziach AI liczą się konkretne fakty, liczby ze źródłami i jasne odpowiedzi na pytania bezpośrednio w HTML generowanym po stronie serwera.

Częste błędy

• Doładowywanie treści po stronie klienta: pobieranie danych dopiero w kliencie przez useEffect/fetch sprawia, że treść jest niewidoczna dla dużych crawlerów AI, a Googlebot dociera do niej z opóźnieniem przez kolejkę renderowania.
• Pominięcie metadataBase: poza Vercelem adresy URL obrazów OG wskazują na localhost zamiast na Twoją domenę i psują podglądy w social mediach, a częściowo także w narzędziach AI.
• Niekompletny hreflang: brak samoodwołania lub brak x-default prowadzi do udokumentowanych błędów klastrów.
• Zamiana wszystkiego w Client Component: globalne "use client" w korzeniu marnuje zalety Server Components i rozdyma bundle w kierunku limitu 2 MB.
• Zbyt szerokie granice Suspense przy PPR: gdy zbyt wiele zostanie oznaczone jako dynamiczne, statyczna powłoka się kurczy, a przewaga w TTFB znika.
• Łańcuchy przekierowań i soft redirecty: przekierowania po stronie klienta zamiast 301/308 nie przenoszą poprawnie sygnałów indeksowania.

Metryki i pomiar

Efekt architektury widać w konkretnych wskaźnikach:

• Core Web Vitals (dane terenowe): mierz LCP, INP i CLS na podstawie rzeczywistych danych z CrUX/Search Console. Dla porównania: w skali międzynarodowej 48% originów mobilnych i 56% desktopowych spełnia wszystkie trzy Core Web Vitals; na urządzeniach mobilnych LCP jest w zielonym zakresie w 62%, INP w 77%, a CLS w 81%. LCP jest więc na urządzeniach mobilnych metryką ograniczającą i właśnie tam działają SSG/PPR oraz streaming.
• INP zamiast FID: od zmiany obowiązuje surowsza metryka. W skali międzynarodowej w 2024 roku tylko 43% witryn mobilnych miało dobre CWV przy INP wobec 48% przy starym FID. Dlatego optymalizacja INP za pomocą Server Components jest szczególnie istotna.
• Sprawdzanie różnicy w renderowaniu: porównaj dostarczony kod źródłowy HTML (View Source) z wyrenderowanym DOM. Tego, co jest tylko w DOM, crawlery AI nie widzą.
• Opóźnienie indeksowania: śledź w Google Search Console czas od publikacji do indeksacji jako wskaźnik efektywności crawlowania.
• Rozmiar bundla a limit 2 MB: monitoruj bundle JS i CSS dla każdej trasy.

Dalsze materiały

Architektura Next.js 15 ma ogromne możliwości, ale jest złożona. Odzwierciedla to postrzeganie wśród deweloperów: według międzynarodowej ankiety State of JavaScript 2025 z Next.js korzysta 59% ankietowanych; 21% ocenia go pozytywnie, a 17% negatywnie, przy czym rosnąca złożoność jest wielokrotnie krytykowana. Praktyczny wniosek: świadomie wybierać strategię renderowania dla każdej trasy, stosować PPR z wąsko zakreślonymi granicami Suspense i konsekwentnie generować obowiązkowe pliki SEO (sitemap.ts, robots.ts, Metadata API, canonical, hreflang) po stronie serwera. Tak powstaje serwis szybki dla Googlebota, w pełni czytelny dla crawlerów AI i wydajnie serwowany w całej Europie. Jako kolejne kroki warto przeprowadzić audyt renderowania (HTML vs DOM) i pomiar CWV na danych terenowych oraz podłączyć IndexNow do procesu rewalidacji.