JavaScript a SEO: Jak Neztratit Pozice Kvůli Špatnému Renderování

V roce 2025 jsem analyzovala e-shop postavený na moderním React frameworku. Majitel investoval do designu, rychlosti a obsahu. Jenže z 2 000 produktových stránek Google indexoval pouhých 600. Zbytek? Neviditelný.

Problém nebyl v obsahu ani v odkazech. Byl v JavaScriptu. Přesněji řečeno v tom, jak Google ten JavaScript zpracovával — a hlavně nezpracovával.

Za roky v SEO jsem viděla desítky podobných případů. Weby, které vypadaly perfektně pro uživatele, ale pro Googlebot byly z velké části prázdné. A majitelé netušili proč.

V tomto průvodci vám ukážu, jak Google v roce 2026 renderuje JavaScript, proč to někdy selhává a co konkrétně udělat, aby váš obsah nezůstal skrytý.

Jak Google Renderuje JavaScript v 2026

Googlebot už dávno není jen textový robot, který čte HTML. Dnes je to sofistikovaný systém, který umí spouštět JavaScript podobně jako váš prohlížeč. Ale má své limity.

Evergreen Googlebot - co umí a neumí

Od roku 2019 Google používá takzvaný Evergreen Googlebot — verzi Chrome, která se automaticky aktualizuje na nejnovější stabilní verzi. V lednu 2026 je to Chrome 144.

Co to znamená v praxi:

Funkce	Podpora
ES6+ syntaxe	Plná
React, Vue, Angular	Plná
Web Components	Plná
Service Workers	Částečná
WebGL/Canvas text	Nepodporováno
Lokální storage	Omezená

Googlebot zvládne většinu moderního JavaScriptu. Problém ale není v tom, co umí. Je v tom, co stihne.

Render queue - proč JS stránky čekají déle

Tady začíná jádro problému. Když Googlebot navštíví stránku, nestáhne ji a okamžitě nevyrenderuje. Proces je dvoufázový a mezi fázemi může být zpoždění dny až týdny.

Proč? Protože renderování je drahé. Podle studie Onely potřebuje Google přibližně 9x více času na procházení JavaScript stránek oproti čistému HTML. A Google má omezený budget.

Stránky čekají ve vykreslovací frontě (Render Queue). Priorita závisí na:

Autoritě domény
Frekvenci změn obsahu
Dostupných zdrojích na straně Google

Pro nový web nebo stránky s nízkou autoritou může čekání trvat týdny. A mezitím? Obsah v indexu chybí.

Dva průchody - crawl vs render

Celý proces crawlování a indexace JavaScriptových stránek vypadá takto:

První průchod (Crawl):

Googlebot stáhne HTML
Získá základní informace (meta tagy, odkazy v HTML)
Obsah generovaný JavaScriptem nevidí

Druhý průchod (Render):

Stránka se dostane z fronty
Googlebot spustí JavaScript
Vykreslí finální DOM
Teprve teď vidí skutečný obsah

Mezi těmito průchody může uplynout značná doba. A pokud váš hlavní obsah existuje jen po renderování, Google ho během prvního průchodu prostě nevidí.

Vykreslovací strategie (rendering) a jejich SEO dopad

Způsob, jakým váš web generuje HTML, má zásadní vliv na SEO. Pojďme si projít hlavní přístupy.

CSR (vykreslování na straně klienta) - rizika pro SEO

Client-Side Rendering (CSR) znamená, že server pošle prázdnou HTML kostru a veškerý obsah se generuje JavaScriptem v prohlížeči uživatele.

<html>
<head><title>Můj e-shop</title></head>
<body>
  <div id="root"></div>
  <script src="app.js"></script>
</body>
</html>

Problém je zřejmý. V prvním průchodu Googlebot vidí prázdnou stránku. Musí čekat na render queue.

Kdy je CSR problematické:

Stránky s důležitým obsahem (produkty, články)
Weby s nízkou autoritou
Obsah, který potřebujete rychle zaindexovat

Kdy CSR nevadí:

Interní dashboardy (není třeba indexovat)
Části za přihlášením
Interaktivní prvky bez SEO hodnoty

SSR (vykreslování na serveru) - zlatý standard

Server-Side Rendering (SSR) generuje kompletní HTML na serveru. Googlebot dostane hotovou stránku okamžitě.

<html>
<head><title>Bílé tričko | Můj e-shop</title></head>
<body>
  <h1>Bílé bavlněné tričko</h1>
  <p>Kvalitní bavlna 100%, velikosti S-XXL...</p>
  <script src="app.js"></script>
</body>
</html>

JavaScript se stále načte a přidá interaktivitu. Ale kritický obsah je dostupný okamžitě.

Výhody pro SEO:

Okamžitá indexace obsahu
Žádné čekání v render queue
Správné meta tagy od začátku
Lepší výkon na pomalých zařízeních

SSG (statické generování stránek) - kdy použít

Static Site Generation (SSG) vytváří HTML soubory v době buildu, ne při každém požadavku.

Pro SEO je to ideální řešení — máte výhody SSR bez zatížení serveru. Ale funguje jen pro obsah, který se nemění často.

Ideální pro:

Blogové články
Landing pages
Dokumentaci
Kategorie s pomalými změnami

Nevhodné pro:

Stránky se real-time daty
Personalizovaný obsah
Časté aktualizace (zásoby, ceny)

Hydratace (hydration) a její náklady

Hydratace (hydration) je proces, kdy se statické HTML "oživí" JavaScriptem. Problém? Trvá to a blokuje interaktivitu.

Typický průběh:

HTML se načte a zobrazí (uživatel vidí obsah)
JavaScript se stáhne
JavaScript se parsuje
Hydration proběhne
Stránka je interaktivní

Mezi krokem 1 a 5 může uživatel klikat, ale nic se neděje. To přímo ovlivňuje INP metriku a uživatelskou zkušenost.

Řešení? Částečná hydratace (partial hydration) nebo ostrovní architektura (island architecture) — hydrujete jen interaktivní části, ne celou stránku.

Jak Ověřit, že Google Vidí Váš Obsah

Než začnete optimalizovat, potřebujete vědět, co Google skutečně vidí. Existuje několik spolehlivých metod.

URL Inspection v Search Console

Nejpřesnější nástroj. V Google Search Console zadejte URL do horního pole a počkejte na výsledky.

Co hledat:

Stav indexace — je stránka zaindexovaná?
Poslední crawl — kdy Google naposledy navštívil
Canonical — jakou verzi Google považuje za hlavní

Klikněte na "View Crawled Page" pro zobrazení HTML, které Google získal.

"View Rendered Page" - co hledat

V URL Inspection klikněte na "View Tested Page" a pak "Screenshot". Uvidíte přesně to, co viděl Google.

Červené vlajky:

Prázdné sekce místo obsahu
Chybějící produkty nebo články
Loading spinnery místo textu
Chybové hlášky v konzoli

Porovnejte screenshot s tím, jak stránku vidíte vy. Každý rozdíl je potenciální problém.

Mobile-Friendly Test pro rychlé ověření

Rychlejší alternativa bez Search Console. Otevřete Mobile-Friendly Test, zadejte URL.

Nástroj zobrazí:

Screenshot renderované stránky
HTML po vykreslení
Případné problémy s načítáním zdrojů

Tip: Kontrolujte sekci "Page loading issues". Pokud Google nemohl načíst JavaScript soubory, obsah chybí.

Site: operator pro kontrolu indexace

Základní, ale účinný test. Zadejte do Google:

site:vasedomena.cz/produkty/

Uvidíte, kolik stránek z dané sekce je skutečně v indexu. Porovnejte s počtem stránek na webu.

Pro kontrolu konkrétního obsahu:

site:vasedomena.cz "přesný text z produktu"

Pokud Google text nevidí, stránka se nezobrazí.

Optimalizace JavaScript pro SEO

Teď k praktickým řešením. Co konkrétně udělat, aby JavaScript nepřekážel indexaci.

Defer vs Async - rozhodovací strom

Způsob načítání skriptů ovlivňuje rychlost i rendering:

<script src="app.js"></script>

<script src="analytics.js" async></script>

<script src="app.js" defer></script>

Kdy použít co:

Typ skriptu	Doporučení
Hlavní aplikace	defer
Analytics	async
Třetí strany (chat, reklamy)	async nebo lazy
Kritický pro obsah	inline nebo preload

Pravidlo: Pokud skript není nutný pro zobrazení obsahu nad ohybem, použijte defer.

Critical JS inline

Malé množství kritického JavaScriptu můžete vložit přímo do HTML. Tím eliminujete round-trip pro stažení externího souboru. Doporučený limit: maximálně 1-2 KB.

Code splitting pro rychlejší initial load

Místo jednoho velkého bundle.js rozdělte kód na menší části pomocí dynamických importů. Frameworky jako Next.js nebo Nuxt to dělají automaticky. Výhody: rychlejší počáteční načtení, menší blokování main threadu a lepší Core Web Vitals.

Lazy loading komponent

Komponenty mimo viewport načítejte až když se k nim uživatel přiblíží pomocí Intersection Observer. Důležité: Obsah důležitý pro SEO (hlavní text, produktové informace) nikdy lazy neloadujte. Google ho nemusí vidět.

Framework-specifické SEO Tipy

Každý framework má své specifika. Tady jsou konkrétní doporučení.

React/Next.js - SSR a getStaticProps

Next.js je v roce 2026 de facto standard pro SEO-friendly React aplikace. Používejte getStaticProps pro statické stránky a getServerSideProps pro dynamický obsah. Tip: ISR (Incremental Static Regeneration) kombinuje výhody SSG a SSR — stránky se generují staticky, ale automaticky se obnovují.

Vue/Nuxt - univerzální rendering

Nuxt 3 nabízí podobné možnosti jako Next.js. Hybridní režim umožňuje různé strategie pro různé routy — blog staticky, produkty s ISR, košík čistě na klientovi.

WordPress + React/Vue integrace

Dvě hlavní možnosti: Headless WordPress (WordPress jako API + Next.js/Nuxt frontend) nebo WordPress + React bloky (klasický WordPress s Gutenberg bloky). Pro SEO je varianta 2 bezpečnější — obsah je vždy v HTML.

Časté chyby (co nikdy nedělat)

Za roky praxe jsem viděla opakující se chyby. Tady jsou nejhorší z nich.

Obsah za uživatelskou interakcí (click to reveal)

Google často nebude klikat na tlačítka. Obsah v display:none nebo za modály může být ignorován. Řešení: Obsah zobrazujte defaultně v HTML. JavaScript použijte jen pro UX (skrytí/zobrazení).

Nekonečné scrollování bez stránkování

Nekonečné scrollování (infinite scroll) je skvělé pro UX, ale katastrofa pro SEO — Google nescrolluje donekonečna a jednotlivé položky nemají vlastní URL. Řešení: Kombinujte infinite scroll s klasickým stránkováním (pagination). Každá "stránka" musí mít vlastní URL a odkaz v HTML.

Směrování pouze na klientovi (client-only routing) bez fallbacku

Problém: Pokud uživatel (nebo Google) přistoupí přímo na /produkt/123, server vrátí 404 nebo index.html bez obsahu. Řešení: Implementujte SSR nebo předvykreslování (prerendering).

Obsah v canvas nebo iframe

Text vykreslený v canvasu je pro Google neviditelný. Iframes jsou samostatné dokumenty — jejich obsah se nepočítá k vaší stránce. Řešení: Důležitý obsah vždy jako HTML text.

JavaScript a Core Web Vitals

JavaScript přímo ovlivňuje všechny tři metriky Core Web Vitals.

Dopad na INP a TBT

INP (Interaction to Next Paint) měří, jak rychle stránka reaguje na interakce. Těžký JavaScript je hlavním viníkem špatného INP. TBT (Total Blocking Time) měří, jak dlouho je main thread blokovaný.

Největší problémy: velké JavaScript bundly, synchronní operace a dlouhé úlohy (Long Tasks) nad 50 ms. Řešení: rozdělte výpočty na menší části pomocí requestIdleCallback.

Zdroje blokující vykreslení (render-blocking resources)

JavaScript v <head> bez async nebo defer blokuje vykreslení celé stránky. V Chrome DevTools → Coverage uvidíte, kolik staženého kódu se skutečně používá. Běžné je 50-70 % nepoužitého kódu.

Správa skriptů třetích stran (third-party scripts)

Externí skripty (analytics, chatboti, reklamy) jsou často největším problémem. Každý může přidat 100+ ms k načítání.

Strategie:

Audit — kolik skriptů třetích stran máte? Potřebujete je všechny?
Líné načítání (lazy loading) — chatbot načtěte až po 5 sekundách nebo při scrollu
Vzor fasády (facade pattern) — místo těžkého widgetu zobrazit zástupný prvek, skutečný widget až při interakci

Případová studie

Módní e-shop: Z 30 % indexace na 98 % díky migraci na SSR

Klientka provozující e-shop s módou postavený na Reactu měla vážný problém - z 2 000 produktů Google indexoval jen 600. Zbytek byl neviditelný kvůli vykreslování na straně klienta (client-side rendering).

Metrika	Před	Po 8 týdnech
Domain Authority	26	34
Organická návštěvnost	2 100/měs	8 400/měs

Co rozhodlo: Po migraci na Next.js s SSR jsem nastartovala strategickou budování odkazů na módních portálech s DA50+. PR články o módních trendech a stylingu přinesly kvalitní zpětné odkazy, které pomohly Google rychleji procházet nově indexovatelné stránky.

→ Chcete podobné výsledky?

Problém - 70 % produktů nebylo indexováno

E-shop s módou, 2 000 produktů. Postaven na čistém Reactu s vykreslováním na straně klienta (client-side rendering). Po roce provozu měl slušnou doménovou autoritu, ale organická návštěvnost stagnovala.

Diagnostika:

site:domena.cz ukázal 600 zaindexovaných stránek místo 2 000+
URL Inspection: Screenshot ukazoval loading spinner místo produktů
Search Console: 1 400 stránek ve stavu "Crawled - currently not indexed"

Příčina byla jasná. Google stáhl HTML, viděl prázdnou kostru, čekal na render queue. A protože web neměl extra vysokou autoritu, čekal dlouho. Mezitím se obsah měnil a Google nestíhal.

Přechod na SSR

Řešení zahrnovalo migraci na Next.js s SSR:

Fáze 1 (týden 1-2):

Setup Next.js projektu
Migrace komponent (většina fungovala bez úprav)
Implementace getStaticProps pro produktové stránky

Fáze 2 (týden 3):

ISR s revalidací každých 30 minut pro produkty
SSG pro kategorie a statické stránky
Redirect staré struktury URL na novou

Fáze 3 (týden 4):

Testování indexace přes Search Console
Optimalizace rychlosti
Monitoring Core Web Vitals

Výsledky

Po 8 týdnech od spuštění:

Metrika	Před	Po
Indexované stránky	600	1 950
Organická návštěvnost	2 100/měsíc	8 400/měsíc
Průměrná pozice	zlepšení o 47 %	-
LCP	4,2 s	1,8 s
INP	890 ms	180 ms

Klíčové bylo, že po přechodu na SSR Google okamžitě viděl obsah bez čekání ve vykreslovací frontě (render queue). Nové produkty se indexovaly do 24-48 hodin místo týdnů.

Závěr: JavaScript není nepřítel — špatná implementace ano

JavaScript a SEO spolu můžou fungovat. Ale vyžaduje to promyšlenou architekturu a pochopení toho, jak vyhledávače pracují.

Klíčové body:

Google umí renderovat JavaScript, ale je to drahé a trvá to
SSR nebo SSG jsou pro SEO kritický obsah preferované
Vždy ověřte, co Google skutečně vidí (URL Inspection)
Third-party skripty jsou často větší problém než váš vlastní kód

3 věci, které můžete udělat ještě dnes:

Otevřete Search Console a zkontrolujte 5 důležitých stránek přes URL Inspection
Porovnejte screenshot renderované stránky s tím, co vidíte vy
Změřte, kolik stránek je skutečně v indexu (site:vasedomena.cz)

Potřebujete pomoct s JavaScript SEO?

Pomáhám firmám řešit problémy s indexací a renderováním. Bez složitých smluv, jen výsledky.

Domluvte si konzultaci

Související články

Často kladené otázky (FAQ)

Umí Google renderovat všechny JavaScript frameworky?

Ano, Evergreen Googlebot podporuje všechny moderní frameworky — React, Vue, Angular, Svelte i další. Používá aktuální verzi Chrome (v lednu 2026 verze 144). Problém není v podpoře frameworku, ale v čase potřebném pro vykreslení a v omezeních render queue. Některé specifické funkce (WebGL text, některé Web APIs) ale podporovány nejsou.

Jak dlouho trvá, než Google vyrenderuje JS stránku?

Záleží na autoritě webu a dostupných zdrojích Google. Pro vysoce autoritativní weby to může být hodiny. Pro nové weby nebo stránky s nízkou prioritou i týdny. Průměrně se uvádí 2-7 dní, ale viděla jsem případy, kdy JavaScript obsah čekal v render queue i měsíc. Proto je SSR tak důležité — eliminuje toto čekání úplně.

Je lepší SSR nebo SSG pro SEO?

Obojí je pro SEO výborné, protože obsah je dostupný okamžitě. SSG je preferované pro obsah, který se nemění často (blog, landing pages, dokumentace) — je rychlejší a levnější na provoz. SSR použijte pro dynamický obsah, kde potřebujete aktuální data při každém požadavku (produkty se stavem skladu, personalizovaný obsah). Ideální je hybridní přístup s ISR (Incremental Static Regeneration).

Jak zjistím, jestli Google vidí můj JS obsah?

Nejspolehlivější je URL Inspection v Google Search Console. Zadejte URL, počkejte na analýzu a klikněte na "View Tested Page" → "Screenshot". Uvidíte přesně to, co vidí Google. Pro rychlý test použijte Mobile-Friendly Test nebo jednoduše vyhledejte unikátní frázi z vašeho obsahu: site:vasedomena.cz "přesný text". Pokud se stránka nezobrazí, Google text nevidí.

Škodí hodně JavaScriptu SEO?

Ne přímo. Množství JavaScriptu samo o sobě není problém. Problém je, když JavaScript:

Brání nebo zpožďuje zobrazení obsahu
Blokuje main thread a zhoršuje INP
Zvětšuje render-blocking resources
Generuje obsah, který Google nemusí vyrenderovat včas

Důležité je, jak JavaScript používáte, ne kolik ho máte. Optimalizovaný web s 500 KB JS může být pro SEO lepší než neoptimalizovaný s 50 KB.