Vývojář vám poslal nabídku na nový web a v ní zkratky, které nikdo nevysvětlil: SSR, SSG, možná ISR. Nebo už web v Reactu máte a někde jste zaslechli, že „je špatně pro SEO". Všechny ty zkratky přitom popisují jedinou věc: kdo a kdy sestaví stránku, kterou návštěvník uvidí. Na tomhle jediném rozhodnutí stojí, jestli Google dostane hotový obsah, nebo stavebnici, kterou si musí složit sám. Celé se to dá vysvětlit na nábytku, bez jediného řádku kódu — a jestli je na tom váš web dobře, si ověříte za minutu v prohlížeči.
Kdo stránku sestaví: čtyři režimy bez programátorštiny
Představte si každou stránku webu jako kus nábytku a Googlebota jako zákazníka, který si ho objednal. Čtyři režimy renderingu jsou čtyři způsoby doručení: v ploché krabici s návodem, smontovaný na objednávku, hotový ze skladu — nebo ze skladu, který se průběžně obměňuje.
CSR: plochá krabice s návodem
Client-side rendering znamená, že server pošle prohlížeči plochou krabici: pár řádků HTML, balík JavaScriptu a instrukce, odkud si stáhnout obsah. Stránku si prohlížeč smontuje sám, až u návštěvníka. Takhle fungují single-page aplikace postavené na Reactu, Vue a podobných knihovnách.
Pro uživatele to má půvab: jakmile se web jednou načte, přepínání mezi stránkami je plynulé, nic neprobliká. Daň je dvojí. První načtení trvá déle, než se krabice vybalí a smontuje. A hlavně: kdo montovat neumí, vidí prázdnou krabici. K tomu se za chvíli vrátím, protože přesně tam vzniká problém se SEO.
SSR: skříň smontovaná na objednávku
Server-side rendering: stránku sestaví server ve chvíli, kdy o ni někdo požádá, a pošle ji hotovou. Zní to jako novinka, ale takhle funguje web od devadesátých let. Klasický WordPress nebo Shoptet nedělá celý život nic jiného, jen se tomu neříkalo SSR — zkratka se ujala, až když se to JavaScriptové frameworky musely naučit znovu.
Výhoda: každý dostane hotovou a čerstvou stránku, Google nevyjímaje. Nevýhoda: server montuje pořád dokola, i když si sto lidí za sebou objedná tu samou skříň. Řeší se to ukládáním hotových stránek do mezipaměti (cache) a tím se SSR začíná přelévat do dalších dvou režimů.
SSG: sklad hotových skříní
Static site generation smontuje všechny stránky předem, jednou, při publikaci webu. Pak už se jen expedují ze skladu. Rychlejší výdej neexistuje, proto se takhle staví weby, kde se obsah nemění každou hodinu: dokumentace, firemní prezentace, blogy.
Háček: každá změna znamená přestavět sklad. U webu o padesáti stránkách je to otázka minut a nikoho to nebolí. U e-shopu s dvaceti tisíci produkty, kde se ceny a dostupnost mění pořád, je přestavování skladu kvůli každé maličkosti neúnosné.
ISR: sklad, který se sám obměňuje
Incremental static regeneration je odpověď na ten háček; přišel s ním framework Next.js. Stránky jsou hotové předem jako u SSG, ale sklad se průběžně obnovuje: když stránka zestárne, systém ji na pozadí smontuje znovu a starou verzi vymění. Návštěvník i Google dostávají vždycky hotový kus, nanejvýš o pár minut starší. Pro velké weby s měnícím se obsahem je to rozumný kompromis.
Co z každého režimu dostane Google
Google čte web ve třech krocích: stránku najde, stáhne a rozhodne, jestli ji zaindexuje (podrobně v článku o tom, jak funguje Google). Pro rendering je zásadní, co přijde v tom staženém HTML:
Ta fronta není strašák z dob, kdy Google JavaScript neuměl. Umí ho dobře: stránky vykresluje v aktuálním Chromiu, tedy stejném jádru, jaké máte v prohlížeči. Jenže vykreslování ho stojí výpočetní výkon, takže ho dávkuje. Stránka s obsahem v JavaScriptu se podle dokumentace ve frontě zdrží pár vteřin, ale může to trvat i déle. A hlavně je to celý další krok, ve kterém se dá udělat chyba: skript zablokovaný v robots.txt nebo obsah, který se dotahuje příliš pomalu, a Google zaindexuje prázdnou krabici. U webu o pár stránkách se fronta nepozná; u desítek tisíc adres už ano. Co všechno se při vykreslování kazí, rozebírám v článku o JavaScript SEO.
Google k tomu v dokumentaci píše větu, kterou bych podepsala: posílat hotové HTML je pořád dobrý nápad, protože je rychlejší pro lidi i pro roboty — a ne všichni roboti umí JavaScript spouštět. V roce 2026 to platí dvojnásob. Roboti AI nástrojů (ChatGPT, Perplexity a další) si typicky berou jen surové HTML a montovat nic nebudou. Web postavený čistě na CSR je pro ně z velké části neviditelný.
Kdyby vám někdo nabízel „speciální verzi webu pro roboty" (říká se tomu dynamic rendering: robotům se servíruje smontovaná verze, lidem krabice), vězte, že Google to ve své dokumentaci označuje za provizorní obezličku, ne za řešení. Doporučuje rovnou serverové nebo statické vykreslování.
Kolik zákazníků vám tenhle měsíc uteče ke konkurenci jen proto, že vás Google nenabídne? Pošlete mi adresu webu — do 48 hodin víte, co opravit, aby vás lidé našli. Audit dělám ručně a zdarma.
Jak poznáte, který režim váš web používá
Nemusíte se ptát vývojáře, stačí prohlížeč:
- Otevřete stránku, na které vám záleží — třeba popis produktu nebo článek.
- Stiskněte Ctrl+U (na Macu Cmd+Option+U). Zobrazí se zdrojový kód: přesně to HTML, které server posílá.
- Stiskněte Ctrl+F a vyhledejte kus věty, kterou na stránce vidíte.
Věta tam je? Server posílá hotový obsah a Google ho dostane bez čekání. Místo textu jen hradba skriptů? Stránka se skládá až v prohlížeči a Google stojí frontu.
Dvě upozornění. Nepoužívejte pravé tlačítko a „Prozkoumat" — vývojářské nástroje ukazují stránku už smontovanou, tím byste si test zkazili. A počítejte s tím, že weby bývají hybridní: kostra stránky přijde hotová, ale recenze, ceny nebo dostupnost se dotahují JavaScriptem dodatečně. Testujte proto přesně ten obsah, na kterém vám záleží, ne jen nadpis. Důkladnější kontrolu pak nabízí Search Console: v Kontrole adresy URL si zobrazíte stránku tak, jak ji vidí Google po vykreslení.
Kdy na tom záleží a kdy vůbec ne
Podle čeho bych se rozhodovala, kdyby se váš web stavěl dnes:
- Všechno, co se má hledat (firemní web, blog, e-shop): chtějte hotové HTML. Jestli přes SSR, SSG, nebo ISR, je provozní otázka podle toho, jak často se obsah mění — pro Google jsou rovnocenné.
- Aplikace za přihlášením (administrace, klientská zóna, interní nástroje): CSR je úplně v pořádku. Google tam nemá co pohledávat a plynulost rozhraní je důležitější.
- Kombinace obou: veřejná část hotová ze serveru, aplikační část jako CSR. Tak to staví většina rozumných projektů.
A poctivě: většina majitelů firemních webů tohle rozhodnutí vůbec nedělá. WordPress, Shoptet a další běžné platformy posílají hotové HTML od přírody; rendering za vás vyřešil někdo dávno před vámi. Problém vzniká skoro výhradně u webů na míru — když se firemní prezentace postaví jako single-page aplikace, protože to tak vývojářský tým umí nejlíp, a otázka „co dostane Google?" při zadání nezazní. Když vám tým staví web na Next.js, co po něm chtít najdete v samostatné kuchařce o Next.js a SEO; a pokud řešíte web s odděleným redakčním systémem, mrkněte na headless CMS a SEO.
A jedno časté nedorozumění: režim renderingu není totéž co rychlost webu. Statická stránka bývá na první načtení nejrychlejší, ale i SSR web se dá ubít čtyřmegabajtovými fotkami. Rychlost se měří jinde, v metrikách Core Web Vitals, a rendering je jen jeden z dílů skládačky.
Časté otázky
Je web v Reactu špatný pro SEO?
Sám o sobě ne. React je nástroj; rozhoduje, jestli se stránky vykreslují na serveru, nebo až v prohlížeči. Frameworky jako Next.js umí React vykreslovat na serveru, a pak Google dostává hotové HTML jako z každého jiného webu. Problém je React nasazený jako čistá single-page aplikace na webu, který se má hledat.
Co je pro SEO lepší: SSR, nebo SSG?
Z pohledu Googlu jsou rovnocenné, v obou případech dostane hotové HTML. Vybírejte podle provozu: SSG (případně ISR) je levnější a snese nápor návštěv, SSR má v každé vteřině čerstvá data. Na pozice ve vyhledávání tahle volba vliv nemá.
Google přece JavaScript umí. Proč to tedy řešit?
Protože „umí" neznamená „hned a vždycky". Vykreslování Google dávkuje, takže CSR stránky čekají ve frontě, a každá chyba ve skriptech může indexaci pokazit. A roboti AI nástrojů JavaScript většinou nespouštějí vůbec. Hotové HTML je jediná varianta, u které nemusíte doufat.
Věta, kterou chtějte slyšet od vývojáře
Až budete zadávat nový web nebo redesign, nemusíte si pamatovat ani jednu z těch čtyř zkratek. Stačí jedna otázka: „Dostane Google hotové HTML?" Kdo odpoví jasně, renderingu rozumí. Kdo začne mlžit, tomu pošlete tenhle článek.
U webu, který už stojí, si za minutu ověříte sami, jestli posílá hotové skříně, nebo ploché krabice. Co s nimi Google doopravdy udělal — jestli je smontoval, jak dlouho mu to trvalo a které stránky mu cestou vypadly — už z prohlížeče nevyčtete; to se pozná až z dat. Ta druhá část je moje práce: audit webu u mě dostanete zdarma a uvidíte v něm černé na bílém, co Google z vašeho webu opravdu přečetl.
Zdroje k faktům v článku:
- Zpracování JavaScriptu ve třech fázích, fronta na vykreslování, aktuální Chromium a poznámka, že ne všichni roboti umí JavaScript (ověřeno 16. 7. 2026): developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- Dynamic rendering jako provizorium; Google doporučuje serverové či statické vykreslování (ověřeno 16. 7. 2026): developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering
- Incremental static regeneration ve frameworku Next.js (ověřeno 16. 7. 2026): nextjs.org/docs/app/guides/incremental-static-regeneration
