Technologie

JavaScript SEO: dynamické renderování, prerendering a ISR

Driver 0

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

JavaScript SEO řeší, jak zpřístupnit obsah a odkazy v moderních webových aplikacích tak, aby byly prohledávatelné, renderovatelné a indexovatelné bez kompromisů na výkonu a uživatelském zážitku. V centru pozornosti stojí 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 pouze 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 renderingový rozpočet, který omezuje, kolik JS se vykoná a jak často se re-renderuje.
  • 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 bundle. Výborné pro interaktivitu, avšak rizikové pro SEO a metriky 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áročná na infrastrukturu a TTFB.
  • SSG/Prerendering: HTML se generuje v době build-u. Bleskové TTFB a stabilní obsah; nevýhodou jsou časté aktualizace a rozsáhlé 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žívat

Dynamic rendering znamená, že pro běžné uživatele podáváte 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ů vykreslovaly JS omezeně. V roce 2025 má smysl pouze jako dočasné řešení při migraci těžkých SPA či u legacy frameworků.

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

Prerendering (SSG): statika pro rychlost a stabilitu

Prerendering vytváří HTML během build procesu. Je ideální pro stránky s relativně stabilním obsahem (blogy, dokumentace, landingy, kategorie).

  • Výhody: vynikající 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.
  • Mitigace: 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říklad 60 s). Po jeho uplynutí první uživatel spustí regeneraci na pozadí; ostatní dostanou „stale“ verzi, dokud se nová nesdílí.
  • On-demand revalidation: při změně obsahu (CMS webhook) vyvolá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 doby buildů.
  • Výzvy: konzistence (časové okno stale vs. fresh), správné nastavení cache hlaviček, invalidace vícenásobných závislých stránek (například 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 hlavní trychtýř, ISR pro detail.
  3. Potřebujete personalizaci na první bajt? 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 překážek. Nepoužívejte hashbang (#!) URL.
  • HTTP statusy: 200 pro existující, 404/410 pro neexistující, 301/308 pro přesuny. Vyhněte se univerzálnímu SPA „fallback 200“.
  • Kanoničnost: generujte <link rel="canonical"> na serveru; vyhněte se dynamickým změnám po hydrataci.
  • Hreflang: renderujte všechny hreflang páry v HTML na serveru; zahrňte regionální varianty a konzistenci URL.
  • Robots a meta: robots.txt nesmí blokovat kritické zdroje (CSS/JS), které jsou nutné pro renderování. 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), nikoli až po hydrataci.

Výkon a Core Web Vitals pro JS náročné weby

  • INP a LCP: snižujte velikost JS bundle, používejte code-splitting a islands. Pro obrázky nastavte fetchpriority="high" pro hlavní obrázek a loading="lazy" pro ostatní.
  • Prioritizace zdrojů: rel=preload pro klíčové CSS/fonty; module/nomodule použijte jen pokud je to nutné.
  • Serverové TTFB: SSR/ISR provozujte co nejblíže uživateli (edge runtimes), vyvarujte se náročných synchronních volání v pipeline požadavku.
  • Hydratace: preferujte částečnou/progresivní hydrataci a defer pro neblokující JS.

Implementační vzory: dynamic rendering

  1. Detekce botů: na reverse proxy (například podle User-Agent plus validace DNS). Dávejte pozor na udržování seznamu UA a falešné pozitivy.
  2. Renderovací služba: headless prohlížeč (Puppeteer/Playwright) generuje HTML, které se kešuje na CDN.
  3. Parita obsahu: automatizujte rozdíly mezi verzí pro bota a uživatele (snapshot testy), aby nedocházelo k cloakingu.
  4. Vyladěné cache: nastavte Cache-Control, ETag, stale-while-revalidate pro rychlé odpovědi i při opakovaném renderu.

Implementační vzory: prerendering (SSG)

  1. Generování tras: během buildu získáte seznam URL z datového zdroje (CMS/API). Segmentujte podle priority.
  2. Rozdělení buildů: velké kolekce budete budovat po dávkách (například 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 vracejte 404, nikoli univerzální SPA 200. Pro „někdy existující“ použijte soft 404 jen pokud skutečně musíte (lepší je opravdová 404).

Implementační vzory: ISR

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

Diagnostika a testování JavaScript SEO

  • „Live“ render vs. „Indexed“: porovnejte HTML, které odesíláte uživateli, s HTML, které vidí robot (serverové logy + nástroje pro render snapshot).
  • Objevitelnost odkazů: projděte site crawlerem, který simuluje JS i non-JS; sledujte rozdíl v počtu nalezených URL.
  • Robots a zdroje: ujistěte se, že robots.txt neblokuje /assets/*.js a /*.css potřebné pro renderování.
  • Strukturovaná data: validujte JSON-LD podle schémat; kontrolujte rozdíl mezi serverovou a klientskou verzí.
  • Log-based SEO: analyzujte serverové logy: poměr 200/301/404 pro Googlebota, 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 trailingem nebo bez – konzistentně.
  • Router spojený se serverem: všechny veřejné routy musí mít serverového handlera (SSR/ISR/SSG výstup). SPA fallback 200 pouze pro ne-SEO části aplikace.
  • Facetovaná navigace: parametry pro filtr/sort nekanoická na unikátní URL, pokud nemají vyhledávací dotaz; používejte rel="canonical" na hlavní výpis.

Parita obsahu a pravidla proti cloakingu

Co servírujete botům, by mělo věcně odpovídat verzi pro uživatele. Rozdíly ve stylování jsou přípustné, 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).
  • Upozornění při odchylkách nad práh (například >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). Vyhýbejte se opožděné injekci přes klientský JS.
  • Synchronizace: při ISR on-demand invalidujte i JSON-LD bloky (například 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ží data déle než prohlížeč.
  • ETag/Last-Modified: umožňují efektivní 304. Při ISR kombinujte s revalidací na edge.
  • Vary: vyhněte se používání 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 →
Driver

Website:

Related Story