JavaScript

SEO a JavaScript prakticky: proč Google nevidí váš obsah a jak to opravit

JavaScript SEO je disciplína, která řeší jedinou otázku: zda se obsah, který na stránce vykreslí JavaScript, dostane do indexu vyhledávače. Google JavaScript spouští, ale ne stejně jako prohlížeč návštěvníka a ne ve stejnou chvíli — a právě v té mezeře se ztrácejí produkty, kategorie a celé sekce webů.

Proč vás to stojí peníze: e-shop, jehož výpis produktů se dotahuje až po kliknutí na „Načíst další", má v indexu první dvanáctku a zbytek nikde. Web postavený na frameworku, který posílá prázdné HTML a obsah domalovává až v prohlížeči, se do vyhledávání dostane se zpožděním, protože renderování stojí ve frontě. A jazykové modely, které JavaScript nespouštějí vůbec, na takovém webu neuvidí nic.

Jak Google zpracovává JavaScript

Google zpracovává weby s JavaScriptem ve třech fázích. Klíčové je, že mezi nimi nemusí navazovat hned — a to je celý zdroj problémů.

  1. 1

    Procházení (crawling)

    Googlebot si vezme adresu z fronty a nejdřív se podívá do robots.txt, jestli ji smí stáhnout. Pokud je zakázaná, HTTP požadavek vůbec neodešle — a JavaScript na zablokované stránce nikdy nespustí. Ze staženého HTML pak vytáhne odkazy v atributu href a přidá je do fronty.

  2. 2

    Renderování (rendering)

    Každá stránka s kódem 200 jde do fronty na renderování, ať už na ní JavaScript je, nebo není. Až to zdroje Googlu dovolí, stránku vykreslí bezhlavé Chromium a JavaScript spustí. Ve frontě může stránka stát pár vteřin, ale klidně i podstatně déle. U stránek s jiným kódem než 200 se renderování může přeskočit úplně.

  3. 3

    Indexace (indexing)

    Z vyrenderovaného HTML Google indexuje obsah a znovu z něj vytáhne odkazy, které pošle zpátky do fronty na procházení. Co v tomhle vyrenderovaném HTML není, to Google neuvidí a nezaindexuje.

⚠️

Zablokovaný JavaScript v robots.txt znamená prázdnou stránku

Když v robots.txt zakážete adresář se skripty nebo styly, Google si je nestáhne a nemá čím stránku vykreslit. Výsledkem není částečně zaindexovaná stránka, ale stránka bez obsahu. Je to jedna z nejdražších a zároveň nejsnáz opravitelných chyb, na jaké v auditech narážíme.

Co Googlebot umí a co ne

Googlebot renderuje v aktuální verzi Chromia, takže moderní JavaScript zvládá. Není to ale prohlížeč se skutečným uživatelem, a proto se v několika ohledech chová jinak.

Co Googlebot udělá

Ano
  • + Spustí JavaScript v aktuální verzi Chromia
  • + Najde odkazy, které do stránky vloží JavaScript
  • + Přečte titulek, popisek i kanonický odkaz nastavený skriptem
  • + Zpracuje strukturovaná data vložená JavaScriptem
  • + Zvládne webové komponenty, pokud světlý DOM prochází přes slot

Co Googlebot neudělá

Ne
  • Neklikne, neroluje a nevyplní formulář — se stránkou neinteraguje
  • Neudrží stav mezi načteními: cookies i local a session storage se mažou
  • Nepovolí přístup ke kameře, poloze a dalším oprávněním
  • Nepodporuje WebSocket ani WebRTC, umí jen HTTP požadavky
  • Nemusí stahovat zdroje, které k obsahu nepřispívají — třeba měřicí skripty

Z posledního bodu plyne praktický důsledek, na který se často zapomíná: klientská analytika nemusí dávat úplný obraz o tom, co na webu Googlebot dělá. Pro sledování jeho aktivity slouží report Statistiky procházení v Search Console.

Čtyři způsoby renderování

Kde se HTML vyrobí, rozhoduje o tom, co uvidí robot i jak rychle uvidí obsah člověk. Tohle jsou čtyři základní přístupy a jejich dopad na vyhledávání.

Způsob Jak funguje Co to znamená pro SEO
Serverové renderování (SSR) Server sestaví celé HTML při každém požadavku Nejbezpečnější varianta. Robot dostane hotový obsah bez čekání na frontu. Daň je delší doba do prvního bajtu
Statické renderování HTML se vygeneruje předem, při buildu, a servíruje se jako soubor Stejně bezpečné jako SSR a ještě rychlejší. Nehodí se tam, kde nejde předem znát všechny adresy nebo kde je obsah personalizovaný
Klientské renderování (CSR) Server pošle skoro prázdné HTML, obsah domaluje JavaScript v prohlížeči Nejrizikovější. Google si poradí, ale až po renderování — a ostatní roboti nemusí vůbec
Hydratace Server pošle hotové HTML, JavaScript ho pak v prohlížeči „oživí" a doplní interaktivitu Pro robota v pořádku, obsah je v HTML. Pozor na uživatele: stránka vypadá načteně, ale do doběhnutí skriptů nereaguje

Doporučení Chrome týmu i dokumentace Googlu míří stejným směrem: volte serverové nebo statické renderování před plnou hydratací. Nejde přitom o rozhodnutí pro celý web — je naprosto v pořádku serverově renderovat kategorie a produkty a nechat klientské renderování jen tam, kde je aplikace opravdu interaktivní.

Dynamické renderování a proč ho nepoužívat

Dynamické renderování je technika, kdy server podle hlavičky rozpozná robota a pošle mu předrenderovanou statickou verzi stránky, zatímco člověk dostane běžnou klientskou verzi. Roky se doporučovalo jako řešení pro weby na JavaScriptu. Dnes už ne.

Dynamické renderování bylo náhradní řešení, ne dlouhodobé řešení problémů s obsahem generovaným JavaScriptem.

Google Search Central, Dynamic rendering as a workaround (překlad)

Google místo něj doporučuje serverové renderování, statické renderování nebo hydrataci. Důvod je prozaický: dynamické renderování zavádí do infrastruktury další vrstvu, kterou musí někdo provozovat a hlídat, a když se rozbije, rozbije se přesně to, co vidí vyhledávač.

Za cloaking se přitom dynamické renderování nepovažuje — dokud oběma stranám servíruje srovnatelný obsah. Web, který lidem ukazuje jednu věc a robotům druhou, cloaking dělá bez ohledu na použitou techniku.

Jak za tři minuty poznat, že máte problém

Nepotřebujete na to nástroj za tisíce. Stačí Search Console a prohlížeč.

  1. 1

    Podívejte se na vyrenderované HTML

    V Search Console otevřete Kontrolu URL, zadejte adresu, klikněte na test živé adresy a otevřete vyrenderované HTML. Tohle je to jediné, co Google indexuje. Použít můžete i Test strukturovaných dat, který ukáže totéž rychleji.

  2. 2

    Vyhledejte v něm svůj obsah

    Zkopírujte si větu z odstavce uprostřed stránky, název třetího produktu ve výpisu a text jednoho odkazu v navigaci. Pak je ve vyrenderovaném HTML najděte. Co tam není, to v indexu nebude.

  3. 3

    Zkontrolujte nenačtené zdroje a chyby

    Ve výsledku testu je seznam zdrojů, které se nepodařilo načíst, a výpis chyb konzole. Blokovaný soubor nebo spadlý skript tady poznáte okamžitě — a bývá to příčina toho, proč obsah v předchozím kroku chyběl.

  4. 4

    Ověřte to i bez JavaScriptu

    Vypněte si v prohlížeči JavaScript a stránku načtěte znovu. Co zůstane, uvidí každý robot. Co zmizí, uvidí jen ti, kdo skripty spouštějí — tedy Google ano, většina ostatních ne.

Kuchařka: hotová řešení

Osm situací, které v auditech potkáváme nejčastěji, i s kódem k převzetí. Předejte je vývojáři, ať se nemusí prokousávat dokumentací.

Odkazy jako skutečné odkazy

Google objeví jen odkaz zapsaný jako prvek a s atributem href. Obsluha kliknutí na jiném prvku pro něj odkaz není.

<!-- Google odkaz nenajde --> <span onclick="jdi('/boty/')">Boty</span>   <!-- Google odkaz najde --> <a href="/boty/">Boty</a>

History API místo fragmentů

Adresy s mřížkou Googlebot spolehlivě nezpracuje. Schéma procházení AJAXu je zrušené od roku 2015.

<!-- Špatně --> <a href="#/produkty">Produkty</a>   <!-- Správně --> <a href="/produkty/">Produkty</a> history.pushState({}, '', '/produkty/');

Neexistující produkt: přesměrování

V aplikaci s klientským směrováním vrací i chybová stránka kód 200. Řešením je přesměrovat na adresu, kde server odpoví kódem 404.

fetch('/api/produkty/' + id)   .then(res => res.json())   .then(produkt => {     if (!produkt.existuje) {       window.location.href = '/nenalezeno';     }   });

Neexistující produkt: noindex

Druhá varianta téhož. Použijte ji, když přesměrování není možné. Předpokládá, že na stránce žádná jiná značka robots není.

if (!produkt.existuje) {   const meta = document.createElement('meta');   meta.name = 'robots';   meta.content = 'noindex';   document.head.appendChild(meta); }

Kanonický odkaz ze skriptu

Google ho při renderování převezme, ale musí být na stránce jediný. Nikdy JavaScriptem neměňte kanonický odkaz, který už v HTML je.

const odkaz = document.createElement('link'); odkaz.setAttribute('rel', 'canonical'); odkaz.href = 'https://www.eshop.cz/boty/'; document.head.appendChild(odkaz);

Odložené načítání obrázků

Nativní atribut prohlížeče. Nespoléhá na rolování ani na knihovnu a Google si s ním poradí.

<img src="/img/bota.jpg" loading="lazy"      width="800" height="600" alt="Běžecká bota">

Otisk obsahu v názvu souboru

Google si zdroje agresivně ukládá do mezipaměti a hlavičky může ignorovat. Otisk v názvu zaručí, že po nasazení načte novou verzi.

<!-- Špatně --> <script src="/js/main.js"></script>   <!-- Správně --> <script src="/js/main.2bb85551.js"></script>

Nekonečný scroll s vlastními adresami

Každá dávka musí mít trvalou adresu s absolutním číslem stránky a musí na ni vést odkaz. Relativní parametry do adresy nepatří.

<!-- Špatně --> /boty/?datum=vcera   <!-- Správně --> /boty/?strana=12

Lazy loading a nekonečné scrollování

Odložené načítání obrázků a obsahu je správná věc — šetří data a zrychluje stránku. Rozbije se ale v okamžiku, kdy se načtení váže na akci uživatele. Googlebot neroluje a neklikne. Obsah, který se objeví až po rolování nebo po stisku tlačítka, pro něj neexistuje.

Obsah se musí načíst tím, že je ve viditelné části stránky — ne akcí uživatele.

Rozdíl mezi „funguje" a „nefunguje" není v knihovně, ale v tom, co načtení spouští.

Google uvidí

  • loading="lazy" na obrázku nebo rámu
  • IntersectionObserver API
  • knihovna načítající obsah při vstupu do výřezu

Google neuvidí

  • tlačítko „Načíst další produkty"
  • obsah odkrytý až po rolování
  • záložky a rozbalovací panely načítané při kliknutí

U nekonečného scrollování to samo nestačí. Aby byl obsah indexovatelný, musí mít každá dávka vlastní trvalou adresu, na které se vždy zobrazí totéž, adresy musí být propojené odkazy a při rolování se má zobrazená adresa aktualizovat přes History API. Bez toho máte jeden dlouhý web bez vstupních stránek.

💡

Odložené načítání nepatří na to, co je hned vidět

Obrázek v horní části stránky načtený odloženě se zobrazí později, než by musel — a to je vidět. Nechte odložené načítání pro to, co je pod ohybem stránky.

Nejčastější chyby z našich auditů

Tyhle nálezy pocházejí z technických auditů, kterými začínáme spolupráci. Skoro žádný z nich nevznikl nedbalostí — jsou to důsledky rozhodnutí, která dávala smysl z pohledu vývoje a nikdo je nekonfrontoval s tím, jak funguje robot.

Prázdná stránka

Skripty a styly zakázané v robots.txt

Zpravidla pozůstatek starého pravidla typu Disallow: /assets/. Google si soubory nestáhne, stránku nemá čím vykreslit a v indexu skončí kostra bez obsahu.

Neviditelný obsah

Obsah načtený až po kliknutí

Popis produktu v záložce, parametry v rozbalovacím panelu, další produkty pod tlačítkem. Pokud se obsah dotahuje až při kliknutí, Googlebot ho nikdy nevyvolá.

Neexistující adresy

Mřížka v adrese místo cesty

Adresy typu /#/produkty/boty. Pro Google je to pořád jen domovská stránka a všechny podstránky splývají do jedné. Řeší se přechodem na History API.

Ztracený stav

Obsah závislý na cookie nebo úložišti prohlížeče

Typicky výběr pobočky, měny nebo jazyka uložený při první návštěvě. Googlebot stav mezi načteními nedrží, takže vidí variantu pro úplně nového návštěvníka — nebo nic.

Nevratný signál

Noindex ve výchozím HTML, který má JavaScript odstranit

Když Google narazí na noindex, může renderování a spuštění JavaScriptu přeskočit. Značka, kterou měl skript odebrat, tak zůstane a stránka se neindexuje.

Falešné omezení

Placený obsah jen skrytý JavaScriptem

Server pošle celý text a skript ho schová, dokud se neověří předplatné. Není to omezení přístupu, jen jeho iluze — obsah je v HTML a dostane se k němu kdokoli.

JavaScript a AI vyhledávače

Tady je potřeba oddělit doložené od dohadů.

Co platí: Google JavaScript spouští, jen s odkladem daným frontou na renderování. Ostatní roboti to dělat nemusí a dokumentace Googlu na to sama upozorňuje — jiné vyhledávače se mohou rozhodnout JavaScript ignorovat a obsah jím vygenerovaný pak neuvidí. Čím víc obsahu máte přímo ve zdrojovém HTML, tím míň jste závislí na tom, jak se který robot zachová.

Co nevíme: jak přesně JavaScript zpracovávají jednotlivé AI nástroje. Přesná čísla vám nikdo doložit nemůže, protože je nikdo nezveřejnil. Kdo tvrdí, že „AI weby na JavaScriptu nečte" jako univerzální pravdu, prodává zjednodušení — a kdo tvrdí opak, taky.

💡

Praktický závěr místo spekulace

Serverové nebo statické renderování hlavního obsahu je jediná odpověď, která platí bez ohledu na to, jak se roboti chovají dnes a jak se budou chovat za rok. Obsah, který je v HTML, uvidí každý. Zbytek je sázka.

Časté otázky

Umí Google číst weby postavené na Reactu, Vue nebo Angularu?

Ano. Google renderuje v aktuální verzi Chromia, takže moderní frameworky zvládá. Otázka není, jestli to umí, ale za jak dlouho a jestli mu v tom něco nebrání.

Rozhodující je nastavení konkrétního projektu — jestli obsah přijde už v HTML, nebo se domalovává až v prohlížeči, a jestli má robot přístup ke všem skriptům. Samotný framework problém není.

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

Nedá se říct přesně. Google uvádí, že stránka může ve frontě na renderování stát pár vteřin, ale i podstatně déle. Konkrétní číslo, které by platilo obecně, neexistuje.

Pro praxi z toho plyne jednoduché pravidlo: čím rychleji se obsah musí objevit ve výsledcích — u novinek, akcí, sezónního zboží — tím méně byste na renderování měli spoléhat.

Jak zjistím, co z mé stránky Google skutečně vidí?

V Search Console otevřete Kontrolu URL, spusťte test živé adresy a podívejte se na vyrenderované HTML. To je přesně ten obsah, který jde do indexu. Stejný náhled dá i Test strukturovaných dat.

Zdrojový kód stránky v prohlížeči vám tuhle otázku nezodpoví — ukáže HTML před spuštěním skriptů, ne po něm.

Musíme kvůli SEO přepsat web na serverové renderování?

Většinou ne celý. Rozhodnutí se dělá po částech: kategorie, produkty a články, které mají přivádět návštěvnost z vyhledávání, patří do serverového nebo statického renderování. Přihlášená část aplikace, konfigurátor nebo košík klidně můžou zůstat klientské.

Než sáhnete k přepisu, ověřte, jestli problém není jinde. Blokované skripty nebo obsah načítaný po kliknutí se opraví za odpoledne, zatímco změna architektury je práce na měsíce.

Je dynamické renderování cloaking?

Ne, pokud oběma stranám servírujete srovnatelný obsah. Google to za cloaking obecně nepovažuje a chybové stránky, které při nastavování vzniknou, bere jako každou jinou chybu.

Cloakingem se to stane ve chvíli, kdy robot dostane něco úplně jiného než člověk. Google to ilustruje příkladem webu, který lidem ukazuje stránku o kočkách a robotům o psech.

Škodí lazy loading SEO?

Samo o sobě ne, naopak — je to doporučená praxe pro rychlost a pohodlí návštěvníka. Problém vzniká jen tehdy, když se načtení váže na rolování nebo kliknutí, protože Googlebot ani jedno nedělá.

Bezpečné je nativní loading="lazy" a IntersectionObserver, protože obojí reaguje na to, že je prvek ve viditelné části stránky, ne na akci uživatele. Výsledek si ověříte ve vyrenderovaném HTML: adresa obrázku musí být v atributu src.

🔍

Nevíte, co z vašeho webu Google skutečně vidí?

Projdeme vyrenderované HTML, porovnáme ho s tím, co má na stránce být, a řekneme vám, jestli je problém v pár řádcích konfigurace, nebo v architektuře. Rozdíl mezi tím a tím jsou stovky hodin práce vývojářů.

Bez prezentací a bez garantovaných pozic. Jen čísla, která si můžete ověřit.

Mgr. Michal Binka, SEO specialista a konzultant

Autor článku

Mgr. Michal Binka

SEO specialista a konzultant, zakladatel SEO PRAKTICKY

SEO dělá přes dvacet let — od dob, kdy weby žádný JavaScript neměly, přes éru, kdy ho vyhledávače neuměly přečíst, až po dnešek, kdy ho číst umí, ale ne vždy včas. Napsal tři knihy o SEO a vede tým specialistů v brněnském Technologickém parku.

Nemá kouzelné tlačítko na zapnutí SEO a negarantuje pozice. Garantuje proces, transparentnost a čísla, která si každý může ověřit.

  • 23+ let v SEO
  • Autor 3 knih o SEO
  • Zlatý Shoptet Partner
  • Certifikovaný Collabim specialista

Zdroje

Dokumentace Google i web.dev se průběžně mění. U každého zdroje je uvedeno datum poslední aktualizace k datu vydání článku — než podle něj zasáhnete do webu, ověřte si aktuální znění přímo u zdroje.