Next.js 15 SEO architektúra: SSR, PPR a Server Components

Voľba architektúry renderovania v Next.js 15 rozhoduje o tom, či je stránka rovnako čitateľná pre klasické vyhľadávače aj pre AI crawlery. App Router s React Server Components a Partial Prerendering (PPR) presúva tvorbu obsahu na server. Od toho závisí, či Googlebot, ChatGPT, Claude a Perplexity vôbec zachytia celý obsah stránky. Článok zaraďuje stratégie renderovania do súvislostí a ukazuje, ktorá route potrebuje akú stratégiu.

Prečo architektúra renderovania rozhoduje o viditeľnosti

Kľúčové zistenie pochádza z analýzy crawlerov v sieti Vercel: Žiadny z hlavných AI crawlerov (GPTBot, ClaudeBot, Meta-ExternalAgent, PerplexityBot, Bytespider) nerenderuje JavaScript; JavaScript súbory tvoria 11,50 % požiadaviek ChatGPT a 23,84 % požiadaviek Claude, žiadny z nich ich však nespúšťa. Plnohodnotne renderujú len Gemini (cez infraštruktúru Googlebotu) a AppleBot. Pre každú stránku, ktorej obsah vzniká až na strane klienta cez JavaScript, to znamená: AI crawlery vidia prázdnu schránku.

AI crawlery už nie sú okrajovým javom. GPTBot, Claude, AppleBot a PerplexityBot spolu generujú približne 1,3 miliardy fetchov mesačne, o niečo viac ako 28 % zo 4,5 miliardy fetchov Googlebotu v sieti Vercel. Ak chceš byť v regióne DACH citovaný v odpovediach AI (Generative Engine Optimization, skrátene GEO), musíš svoj obsah doručovať zo servera ako hotové HTML.

Aj klasický Googlebot penalizuje renderovanie na strane klienta, hoci jemnejšie. Googlebot JavaScript renderuje, ale v druhej vlne: stránky, ktoré vyžadujú renderovanie, sa okrem fronty na crawlovanie dostanú aj do fronty na renderovanie. Často citovaný medzinárodný výskum vyčísľuje dôsledok: Google potreboval na stránky renderované JavaScriptom 313 hodín oproti 36 hodinám pri čistom HTML, teda približne deväťkrát dlhšie. Pri veľkých weboch to výrazne odďaľuje indexovanie nového a aktualizovaného obsahu.

K tomu sa pridáva tvrdá technická hranica. Googlebot už crawluje len prvé 2 MB na zdroj namiesto predchádzajúcich 15 MB, čo je zníženie o 86,7 %. Limit platí pre každý zdroj zvlášť, teda pre HTML, JavaScript bundle aj CSS. Pri nafúknutých klientskych bundloch tak hrozí, že sa rozhodujúce skripty odrežú.

Ako to funguje: SSG, SSR, ISR a PPR v porovnaní pre SEO

Next.js 15 pozná štyri stratégie renderovania. Voľba pre každú route sa riadi otázkou, aký dynamický je obsah a ako rýchlo musí byť aktuálny.

• SSG (Static Site Generation): Stránka sa vygeneruje ako HTML počas buildu a doručuje sa z CDN. Najlepšie možné TTFB a LCP, ideálne pre AI crawlery, pretože celý obsah je hneď v HTML. Vhodné pre KB články, stránky služieb a blogové príspevky.
• ISR (Incremental Static Regeneration): Ako SSG, ale stránka sa po uplynutí časového intervalu (revalidate) alebo cez on-demand trigger vygeneruje nanovo. Spája statické doručovanie s redakčnou aktuálnosťou, napríklad pri cenníkoch alebo zobrazení skladových zásob.
• SSR (Server-Side Rendering): Stránka sa renderuje na serveri pri každej požiadavke. Je nevyhnutné pri obsahu, ktorý závisí od používateľa alebo od požiadavky (geotargeting, A/B testy). Obsah je v HTML, TTFB však závisí od času spracovania na serveri.
• PPR (Partial Prerendering, v Next.js 15 experimentálne): Kombinuje statické a dynamické časti v rámci jednej route. Statický shell sa predrenderuje počas buildu a doručuje sa z CDN, dynamické časti sa dostreamujú ako HTML.

PPR je z hľadiska architektúry pre SEO najzaujímavejší prístup. Statický shell (hlavička, hlavný obsah, pätička) je hneď v úvodnej HTML odpovedi a zabezpečuje nízke TTFB a rýchle LCP. Dynamické fragmenty v hraniciach <Suspense> server dostreamuje a vloží ich takisto ako HTML do tej istej odpovede. Pre crawlovateľnosť je rozhodujúce: streamovaný obsah je HTML, nie JavaScript dodatočne načítaný na strane klienta. Crawler bez spúšťania JavaScriptu dostane celý obsah, len čo sa stream dokončí.

Server Components tvoria základ pod tým. Renderujú sa výhradne na serveri a pre svoju vlastnú logiku neposielajú žiadny klientsky JavaScript. To drasticky znižuje objem hydratácie, čo sa priamo prejaví na INP (Interaction to Next Paint), a zmenšuje JS bundly vzhľadom na limit 2 MB. Interaktivita sa pridáva cielene cez Client Components ("use client") na okrajoch, nie plošne pre celú stránku.

Next.js 16, vydaný 21. októbra 2025, prináša dve zmeny, ktoré sú pre tento článok dôležité. Príznak experimental.ppr zanikol, Partial Prerendering tam funguje cez Cache Components (cacheComponents: true v next.config). Zo súboru middleware sa stal proxy.ts, middleware.ts sa považuje za zastaraný. SEO logika tohto článku zostáva rovnaká: statický shell aj streamované časti prichádzajú ku crawleru ako HTML.

Osvedčené postupy pre SEO architektúru Next.js 15

Stratégiu renderovania vyberaj vedome pre každú route

Štandardné pravidlo: tak staticky, ako sa dá, tak dynamicky, ako treba. Obsahové stránky (KB, blog, služby) patria na SSG alebo ISR. Personalizované stránky alebo stránky blízke reálnemu času využívajú SSR alebo PPR s úzko vymedzenými hranicami <Suspense>, aby SEO relevantný shell zostal statický a streamovali sa len skutočne dynamické časti.

Využívaj Metadata API naplno na serveri

App Router generuje metadáta na serveri cez objekt metadata alebo funkciu generateMetadata. Dôležité:

• Nastav metadataBase: Bez metadataBase Next.js vyhodnotí relatívne cesty k obrázkom pre Open Graph a Twitter voči náhradnej adrese, mimo Vercelu voči localhost. URL obrázkov sú potom absolútne, ale smerujú na adresu, na ktorú sa žiadny crawler nedostane. Základnú URL preto vždy nastav na svoju produkčnú doménu.
• Canonical pre každú route: nastav cez alternates.canonical, aby si sa vyhol duplicitnému obsahu z variantov parametrov alebo ciest.
• hreflang pre región DACH: vypíš cez alternates.languages s de-AT, de-DE a x-default. Je to náchylné na chyby: medzinárodná štúdia zistila, že 31,02 % viacjazyčných webov obsahuje protichodné hreflang direktívy a 16,04 % hreflang klastrov nemá sebareferenčné tagy. Každá jazyková varianta musí odkazovať na seba aj na všetky ostatné.
• Vkladaj JSON-LD na serveri: ako <script type="application/ld+json"> priamo v Server Component. Štruktúrované dáta sú rozšírené: JSON-LD sa v roku 2024 nachádza na 41 % všetkých stránok, o 7 percentuálnych bodov viac ako 34 % v roku 2022. Keď sa renderuje na serveri, prečítajú ho aj AI crawlery bez spúšťania JavaScriptu.

Povinné súbory generuj dynamicky

Next.js 15 nahrádza SEO pluginy tretích strán súbormi založenými na konvenciách:

• sitemap.ts: generuje XML sitemapu programovo vrátane lastModified pre každú URL, čo dáva presný signál lastmod.
• robots.ts: vytvára robots.txt dynamicky vrátane odkazu sitemap a cielených pravidiel pre jednotlivých user agentov.
• 301 presmerovania: trvalé presmerovania patria do next.config (redirects()) alebo pri dynamickej logike do middleware (od Next.js 16 proxy.ts). Používaj stavový kód 308/301, aby sa preniesla sila odkazov aj signály pre indexovanie.

Edge, CDN a caching pre nízke TTFB v Rakúsku

Statické a ISR stránky sa doručujú z CDN z edge lokality blízko používateľa, čo minimalizuje TTFB pre návštevníkov v Rakúsku a v regióne DACH. Riadiš to cez revalidate (časový interval), hlavičky cache-control a on-demand revalidáciu pomocou revalidatePath alebo revalidateTag. HTTP/3 navyše znižuje réžiu pri nadväzovaní spojenia. Keďže Google má v Rakúsku v máji 2026 podiel na trhu 81,87 % a Bing 9,01 %, optimalizácia pre Googlebot zostáva prioritou, Bing však nezanedbávaj.

Pri on-demand revalidácii spusti IndexNow

Keď redakčný trigger revaliduje stránku, môžeš v tom istom Route Handleri odoslať IndexNow ping do Bingu a Yandexu. Indexovanie sa tam tým citeľne zrýchli: IndexNow dodáva 18 % všetkých kliknutých nových URL vo webovom vyhľadávaní, pričom denne sa odošle viac ako 3,5 miliardy URL. Pre Google IndexNow crawlovanie nenahrádza, viditeľnosť v ekosystéme Bingu však účinne dopĺňa.

Optimalizuj Core Web Vitals vstavanými nástrojmi

Next.js 15 prináša nástroje na všetky tri metriky CWV:

• next/image pre LCP a CLS: doručuje moderné formáty, responzívne veľkosti a rezervované miesto, ktoré zabraňuje posunom layoutu.
• next/font pre CLS: hostuje písma sám a predchádza posunom layoutu pri výmene písma.
• Streaming a Suspense pre LCP: renderujú kritický obsah ako prvý a pomalé zdroje dát vyčlenia do samostatných častí.
• Server Components a code splitting pre INP: znižujú množstvo klientskeho JS, a tým aj čas spracovania interakcií.

Cielene obslúž AI crawlery a GEO

Obsah renderovaný na serveri je základným predpokladom, aby ChatGPT, Claude a Perplexity text zachytili. Prístup jednotlivých AI botov riadi robots.txt (cez robots.ts), voliteľný llms.txt môže označiť kľúčový obsah. Pre citovateľnosť v odpovediach AI sú dôležité konkrétne fakty, čísla so zdrojmi a jasne zodpovedané otázky priamo v HTML zo servera.

Časté chyby

• Dočítavanie obsahu na strane klienta: ak dáta získavaš až cez useEffect/fetch v klientovi, obsah bude pre hlavné AI crawlery neviditeľný a Googlebot sa zdrží vo fronte na renderovanie.
• Zabudnutý metadataBase: URL obrázkov OG mimo Vercelu smerujú na localhost namiesto na vlastnú doménu a pokazia náhľady na sociálnych sieťach a čiastočne aj v AI.
• Neúplný hreflang: chýbajúca sebareferencia alebo chýbajúci x-default vedú k zdokumentovaným chybám v klastroch.
• Všetko ako Client Component: plošné "use client" v koreni zahodí výhody Server Components a nafúkne bundle smerom k limitu 2 MB.
• Príliš široké hranice Suspense pri PPR: ak označíš za dynamické príliš veľa, statický shell sa zmenší a výhoda v TTFB zanikne.
• Reťazce presmerovaní a soft presmerovania: presmerovania na strane klienta namiesto 301/308 neprenášajú signály pre indexovanie spoľahlivo.

Metriky a meranie

Účinok architektúry vidno na konkrétnych ukazovateľoch:

• Core Web Vitals (terénne dáta): meraj LCP, INP a CLS z reálnych dát CrUX a Search Console. Pre porovnanie: medzinárodne spĺňa všetky tri Core Web Vitals 48 % mobilných a 56 % desktopových origins; na mobile je LCP v zelenom pásme v 62 %, INP v 77 % a CLS v 81 % prípadov. LCP je tak na mobile limitujúcou metrikou a práve tam pôsobia SSG/PPR a streaming.
• Sleduj INP namiesto FID: od zmeny platí prísnejšia metrika. Medzinárodne malo v roku 2024 dobré CWV pri INP len 43 % mobilných webov oproti 48 % pri starom FID. Preto je optimalizácia INP cez Server Components obzvlášť dôležitá.
• Kontroluj rozdiel pri renderovaní: porovnaj doručený zdrojový HTML kód (View Source) s vyrenderovaným DOM. Čo je len v DOM, to AI crawlery nevidia.
• Latencia indexovania: v Google Search Console sleduj čas od publikovania po indexovanie ako ukazovateľ efektivity crawlovania.
• Veľkosť bundlov voči limitu 2 MB: monitoruj JS a CSS bundly pre každú route.

Čo ďalej

Architektúra Next.js 15 je silná, ale zložitá. Odráža sa to aj vo vnímaní vývojárov: podľa medzinárodného prieskumu State of JavaScript 2025 používa Next.js 59 % respondentov, s 21 % pozitívnych oproti 17 % negatívnych hodnotení, pričom rastúca zložitosť opakovane zaznieva v kritike. Praktický dôsledok: stratégie renderovania vyberaj vedome pre každú route, PPR nasadzuj s úzko vymedzenými hranicami Suspense a povinné SEO súbory (sitemap.ts, robots.ts, Metadata API, canonical, hreflang) dôsledne generuj na serveri. Tak vznikne web, ktorý je pre Googlebot rýchly, pre AI crawlery úplne čitateľný a v regióne DACH sa doručuje s dobrým výkonom. Ako ďalšie kroky sa odporúčajú audit renderovania (HTML vs. DOM), meranie CWV na úrovni terénnych dát a napojenie IndexNow na revalidačný flow.