--- title: "Architektura SEO w Next.js 15: SSR, PPR i Server Components" description: "Architektura SEO w Next.js 15: App Router, Partial Prerendering (PPR), Server Components i Metadata API dla maksymalnej widoczności w AI." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/architektura-seo-w-nextjs-15-ssr-ppr-i-server-components" category: "SEO & GEO" topic: "Techniczne SEO" updated: "2026-10-28T13:33:41.263Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Architektura SEO w Next.js 15: SSR, PPR i Server Components Architektura SEO w Next.js 15 łączy App Router z React Server Components i Partial Prerendering (PPR), aby dostarczać treść po stronie serwera jako gotowy HTML. Server Components wysyłają do klienta zero JavaScriptu, a PPR serwuje statyczną powłokę z CDN i strumieniowo dosyła dynamiczne części jako HTML. Dzięki temu strony są czytelne zarówno dla Googlebota, jak i dla crawlerów AI, które nie wykonują JavaScriptu. ## W skrócie - Żaden z dużych crawlerów AI nie renderuje JavaScriptu, dlatego HTML generowany po stronie serwera to podstawowy warunek GEO i widoczności w AI. - W nowych pracach nad SEO App Router z Server Components jest lepszym wyborem niż Pages Router, bo Server Components wysyłają do klienta zero JavaScriptu. - Świadomie wybieraj strategię dla każdej trasy: SSG/ISR dla stron z treścią, SSR/PPR tylko przy naprawdę dynamicznych lub spersonalizowanych treściach. - PPR serwuje statyczną powłokę z CDN, co daje niski TTFB/LCP, i strumieniowo dosyła dynamiczne części jako HTML, który odczytają także crawlery bez obsługi JS. - Metadata API generuje po stronie serwera title, canonical, hreflang (de-AT/de-DE/x-default) i Open Graph; metadataBase jest do tego obowiązkowe. JSON-LD trafia na stronę jako tag script bezpośrednio z Server Component. - sitemap.ts i robots.ts zastępują zewnętrzne wtyczki; przekierowania 301 należą do next.config albo do middleware (od Next.js 16 proxy.ts). - Obniżony do 2 MB na zasób limit Googlebota sprawia, że lekkie bundle z przewagą logiki po stronie serwera stają się obowiązkiem SEO. 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](https://blckalpaca.at/pl/slownik/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](https://vercel.com/blog/the-rise-of-the-ai-crawler). 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](https://vercel.com/blog/the-rise-of-the-ai-crawler) w sieci Vercel. Jeśli chcesz być cytowany w odpowiedziach AI ([Generative Engine Optimization, w skrócie GEO](https://blckalpaca.at/pl/uslugi/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](https://www.onely.com/blog/google-needs-9x-more-time-to-crawl-js-than-html/). 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%](https://ppc.land/google-slashes-web-crawl-limit-by-86-7-as-cost-pressures-mount/). 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](https://blckalpaca.at/pl/slownik/testy-ab)). 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](https://blckalpaca.at/pl/slownik/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 `` 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](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/renderowanie-javascriptu-a-crawlery-ai-luka-w-widocznosci) 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](https://nextjs.org/blog/next-16), 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)](https://blckalpaca.at/pl/uslugi/agencja-seo) 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 ``, 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](https://searchengineland.com/study-31-of-international-websites-contain-hreflang-errors-395161). Każda wersja językowa musi odwoływać się do siebie i do wszystkich pozostałych. - **Osadzanie JSON-LD po stronie serwera:** jako `