JavaScript SEO: Strategické využití dynamického renderingu, prerenderingu a ISR

Eva Senková

JavaScript SEO v roce 2025: kontext, rizika a strategické volby

JavaScript SEO řeší, jak zajistit, aby obsah a odkazy v moderních webových aplikacích byly prohledávatelné, renderovatelné a indexovatelné bez kompromisů na výkonu a uživatelském zážitku (UX). V centru pozornosti jsou rozhodnutí o renderování: dynamic rendering (historicky přechodná taktika), prerendering (statická generace) a ISR – Incremental Static Regeneration (hybrid, který kombinuje výhody SSG a SSR). Tato příručka vysvětluje principy, architektury, anti-vzory a implementační vzory pro technické SEO a výkon.

Jak vyhledávače zpracovávají JavaScript

  • Crawling: roboty objevují URL z odkazů a sitemap. Pokud je navigace vázána na onclick nebo jen na pushState bez skutečného <a href>, mnoho URL zůstane neobjeveno.
  • Rendering: JavaScript se zpracovává ve webovém renderovacím systému (WRS). Rendering je nákladný – existuje renderovací rozpočet, který omezuje, kolik JS se vykoná a jak často se provádí re-render.
  • Indexace: až po úspěšném renderu může Googlebot vidět obsah a odkazy generované skripty. Neúspěšný render znamená „prázdnou“ stránku v indexu.

Modely renderování: CSR, SSR, SSG, ISR a hybridy

  • CSR (Client-Side Rendering): server posílá minimální HTML a velký JS balík. Výborné pro interaktivitu, rizikové pro SEO a LCP/INP, pokud chybí HTML kostra s obsahem.
  • SSR (Server-Side Rendering): HTML se generuje při každém požadavku na serveru. Skvělá první odezva, ale nákladné na infrastrukturu a TTFB.
  • SSG/Prerendering: HTML se generuje v době build-u. Bleskové TTFB a stabilní obsah; problémem jsou časté aktualizace a velké katalogy.
  • ISR (Incremental Static Regeneration): statika s rekalkulací po intervalu nebo na požádání. TTFB téměř jako u SSG, „čerstvost“ téměř jako u SSR.
  • Ostrovní architektura (islands/partial hydration): server posílá hotové HTML a interaktivita se připojuje modulárně jen tam, kde je potřeba – menší JS, lepší Core Web Vitals.

Dynamic rendering: co to je, kdy (ne)použít

Dynamic rendering znamená, že pro běžné uživatele servírujete SPA/CSR verzi a pro roboty speciálně přerenderované HTML (například přes headless Chrome). Byl to praktický „most“ v době, kdy prohlížeče robotů renderovaly JS omezeně. V roce 2025 má smysl jen jako dočasné řešení při migraci těžkých SPA nebo u legacy frameworků.

  • Výhody: rychlá náprava indexace bez refaktoringu frontendu; okamžitá viditelnost obsahu pro boty.
  • Nevýhody: vyšší složitost, riziko nekonzistence (rozdílný obsah pro boty vs. lidi), potenciál „cloaking“ signálů, provozní náklady (render farmy).
  • Kdy ano: extrémně dynamické SPA bez možnosti SSR/SSG v krátkém horizontu; velký historický obsah potřebující rychlou indexaci.
  • Kdy ne: u nových projektů – raději ISR/SSR/SSG; u obsahových webů, kde je žádoucí shoda obsahu pro boty i lidi.

Prerendering (SSG): statika pro rychlost a stabilitu

Prerendering vytváří HTML během build-u. Je ideální pro stránky se stabilním obsahem (blog, dokumentace, landingy, kategorie).

  • Výhody: skvělé TTFB, jednoduché CDN cachování, předvídatelné Core Web Vitals, jednodušší provoz.
  • Nevýhody: dlouhé buildy při velkém počtu stránek; změna dat vyžaduje redeploy; riziko zastaralého obsahu mezi buildy.
  • Zmírňující opatření: dělení buildů (sharding), on-demand rebuild konkrétních stránek, statické JSON manifesty pro navigaci, agresivní CDN cache s stale-while-revalidate.

ISR (Incremental Static Regeneration): statika, která se sama obnovuje

ISR kombinuje SSG s plánovanou nebo event-driven revalidací.

  • Časové okno: nastavíte revalidate interval (např. 60 s). Po jeho uplynutí první uživatel spustí re-generování na pozadí; ostatní obdrží „stale“ verzi, dokud není nová publikována.
  • On-demand revalidation: při změně obsahu (CMS webhook) zavoláte zabezpečený endpoint, který invaliduje konkrétní URL nebo segment.
  • Výhody: rychlost statiky + čerstvost SSR; škáluje na desetitisíce URL bez extrémních build časů.
  • Výzvy: konzistence (časové okno stale vs. fresh), správné cache hlavičky, invalidace více závislých stránek (např. produkt i kategorie).

Rozhodovací strom: kdy zvolit které renderování

  1. Má obsah dlouhý „half-life“? Ano → SSG/ISR. Ne → SSR/ISR.
  2. Je katalog obrovský (100k+ URL)? Ano → ISR s on-demand revalidací; případně SSR pro horní část trychtýře, ISR pro detail.
  3. Potřebujete personalizaci na první byte? Ano → SSR/edge SSR s cachováním podle segmentů; případně ostrovy s CSR jen pro personalizované widgety.
  4. Legacy SPA bez refaktoringu? Dočasně → dynamic rendering, střednědobě → migrace na ISR/SSR.

Indexovatelnost: pravidla, na která se zapomíná

  • Skutečné odkazy: používejte <a href="/cesta"> bez onclick bariér. Nepoužívejte hashbang (#!) URL.
  • HTTP statusy: 200 pro existující, 404/410 pro neexistující, 301/308 pro přesuny. Vyhýbejte se univerzálnímu SPA „fallback 200“.
  • Kanoničnost: generujte <link rel="canonical"> na serveru; vyhněte se dynamické změně po hydrataci.
  • Hreflang: renderujte všechny hreflang páry v HTML na serveru; zohledněte regionální varianty a konzistenci URL.
  • Roboti a meta: robots.txt nesmí blokovat kritické zdroje (CSS/JS), které jsou nezbytné pro render. Meta robots v HTML musí odpovídat indexačním záměrům.
  • Strukturovaná data: JSON-LD vložte již v serverovém HTML (SSR/SSG/ISR), ne až po hydrataci.

Výkon a Core Web Vitals pro JS-heavy weby

  • INP a LCP: snižujte velikost JS balíku, používejte code-splitting a islands. Pro obrázky nasazujte fetchpriority="high" pro hlavní obrázek a loading="lazy" pro ostatní.
  • Prioritizace zdrojů: rel=preload pro klíčové CSS/písma; module/nomodule jen pokud je to opravdu potřeba.
  • Serverové TTFB: SSR/ISR provozujte co nejblíže uživateli (edge runtimes), vyhněte se těžkým synchronním voláním v request pipeline.
  • Hydratace: preferujte částečnou/progresivní hydrataci a defer pro neblokující JS.

Implementační vzory: dynamic rendering

  1. Detekce botů: na reverse proxy (např. podle User-Agent + validace DNS). Pozor na udržování seznamu UA a na falešné pozitivy.
  2. Render služba: headless prohlížeč (Puppeteer/Playwright) generuje HTML, které se cachuje na CDN.
  3. Obsahová parita: automatizujte rozdíly mezi bot a user verzí (snapshot testy), aby se zabránilo cloakingu.
  4. Vyladěné cache: nastavte Cache-Control, ETag, stale-while-revalidate pro rychlé odpovědi i při re-renderu.

Implementační vzory: prerendering (SSG)

  1. Generování tras: během build-u získejte seznam URL z datového zdroje (CMS/API). Segmentujte podle priority.
  2. Rozdělení buildů: velké kolekce budujte v dávkách (např. podle abecedy, kategorií, data). Paralelizujte.
  3. CDN a invalidace: publikujte artefakty na edge; při změně dat invalidujte dotčené objekty.
  4. Fallback strategie: pro neexistující URL vraťte 404, ne univerzální SPA 200. Pro „někdy existující“ použijte soft 404 jen pokud je nutné (lépe skutečná 404).

Implementační vzory: ISR

  1. Intervaly: rozdílné revalidate intervaly pro typy stránek (např. domov 60 s, kategorie 300 s, detail 3 600 s).
  2. On-demand webhooky: CMS při publikaci zavolá endpoint s identifikátorem URL/slugu; backend spustí re-generaci a invalidaci CDN.
  3. Závislosti: při změně detailu produktu invalidujte i kategorie a výpisy, které produkt obsahují (udržujte inverzní index závislostí).
  4. Konzistence: povolte stale-while-revalidate, ale sledujte uživatelsky kritické stránky (např. ceníky) – zde preferujte on-demand revalidaci před intervaly.

Diagnostika a testování JavaScript SEO

  • „Live“ render vs. „Indexed“: porovnejte HTML zasílané uživateli s HTML, které vidí robot (serverové logy + nástroje na render snapshot)
  • Objevitelnost odkazů: projděte site crawlerem, který simuluje JS i non-JS; sledujte rozdíl v počtu nalezených URL.
  • Roboti a zdroje: ujistěte se, že robots.txt neblokuje /assets/*.js a /*.css potřebné k renderu.
  • Strukturovaná data: validujte JSON-LD proti schématům; sledujte rozdíl mezi serverovou a klientskou verzí.
  • Log-based SEO: analyzujte serverové logy: poměr 200/301/404 pro Googlebot, frekvenci recrawlu, TTFB při SSR/ISR požadavcích.

URL design a router

  • Čisté, stabilní cesty: bez hash fragmentů; jeden kanonický formát s nebo bez trailing slash – konzistentně.
  • Router napojený na server: všechny veřejné trasy musí mít serverový handler (SSR/ISR/SSG output). SPA fallback 200 pouze pro ne-SEO části aplikace.
  • Faceted navigace: parametry pro filtr/sort nekanonizujte na unikátní URL, pokud nepředstavují vyhledávací dotaz; používejte rel="canonical" na hlavní výpis.

Obsahová parita a anti-cloaking pravidla

Co dáváte botům, by mělo významově odpovídat verzi pro uživatele. Rozdíly ve stylizaci jsou v pořádku, rozdíly v obsahu (text, ceny, odkazy) nikoli – zejména u dynamic renderingu. Automatizujte testy parity:

  • Generujte DOM snapshoty pro UA=Googlebot vs. UA=Chrome a porovnejte relevantní segmenty (H1–H3, hlavní text, interní odkazy, meta tagy).
  • Upozornění při odchylkách nad práh (např. >15 % změna textu nebo počet odkazů).

Strukturovaná data a JS

  • Server-first: vkládejte JSON-LD již do serverového HTML (SSR/SSG/ISR). Vyhněte se opožděné injekci přes klientský JS.
  • Synchronizace: při ISR on-demand invalidujte i JSON-LD bloky (např. změny ceny, availability), aby nebyly zastaralé.

Cache a HTTP hlavičky pro SEO a výkon

  • Cache-Control: public, max-age=0, s-maxage=86400, stale-while-revalidate=60 – příklad pro HTML za CDN, kde CDN drží déle než prohlížeč.
  • ETag/Last-Modified: umožní efektivní 304 odpovědi. Při ISR kombinujte s revalidací na edge.
  • Vary: vyhněte se Vary: User-Agent (kromě specifického dynamic renderingu) – snižuje cache hit-rate.

Migrační scénáře: SPA → ISR/SSR

  1. Audit objevitelnosti: změřte, kolik URL dokáže crawler bez JS vs. s JS. Identifikujte blokované zdroje a SPA fallbacky.
  2. Definujte statické segmenty: homepage, kategorie, blog, dokumentace → SSG/ISR; vysoko dynamické/privátní → SSR/CSR.
  3. Postupná adopce:

Súvisiace články