JavaScript SEO: prečo Google nevidí obsah vášho webu

Weby postavené na Reacte, Vue alebo Angulari vyzerajú v prehliadači úplne v poriadku, no v indexe vyhľadávača z nich niekedy zostane prázdna stránka s jedným nadpisom. Nie je to tak, že by Google JavaScript nespúšťal. Spúšťa ho, robí to však v samostatnom kroku, s vlastnými pravidlami a bez pamäte medzi načítaniami stránok. Tento návod vysvetľuje, ako celý proces prebieha, ako si za pár minút overíte, čo z vášho webu je vôbec viditeľné, a ktoré konkrétne rozhodnutia vo vývoji obsah spoľahlivo skryjú.

1. Ako Google spracúva JavaScript v troch krokoch

Pri klasickom webe si robot vyžiada stránku, dostane hotové HTML so všetkým textom a tým to končí. Pri webe, ktorý obsah dokladá až JavaScriptom, sa proces rozdelí na tri fázy: prehľadávanie (crawling), renderovanie (rendering) a indexovanie. Google to tak opisuje v dokumentácii k základom JavaScript SEO.

  1. Prehľadávanie. Googlebot si vytiahne adresu z frontu, overí v súbore robots.txt, či ju smie stiahnuť, a stiahne surové HTML. Z neho hneď vyberie odkazy v atribúte href a pridá ich do frontu. To, čo je v tejto chvíli v HTML, je jediné, čo robot zatiaľ o stránke vie.
  2. Renderovanie. Každá stránka s návratovým kódom 200 sa zaradí do frontu na vykreslenie, a to bez ohľadu na to, či na nej JavaScript vôbec je. Keď na ňu prídu voľné zdroje, vykreslí ju verzia prehliadača Chromium bez grafického rozhrania (headless) a spustí JavaScript. Google výslovne uvádza, že stránka môže vo fronte čakať niekoľko sekúnd, ale pokojne aj podstatne dlhšie.
  3. Indexovanie. Až z vykresleného HTML sa berie obsah do indexu a z neho sa druhýkrát vyberajú odkazy na ďalšie stránky.

Z tohto poradia vyplývajú tri praktické dôsledky, ktoré rozhodujú o všetkom ostatnom:

  • Objavovanie odkazov sa deje dvakrát, ale prvý raz iba z pôvodného HTML. Ak sa celá navigácia dokladá až skriptom, objaví sa v druhom kole a celý web sa indexuje pomalšie.
  • Renderovanie nie je zaručené okamžite. Pri obsahu, ktorý sa rýchlo mení (výpisy skladu, aktuality, termíny), môže index ukazovať zastaraný stav.
  • Čo skript nedoloží, to neexistuje. Ak volanie na API zlyhá alebo prekročí čas, robot uvidí to isté, čo používateľ s vypnutým JavaScriptom: kostru bez obsahu.

💡 Dôležitá výnimka: ak stránka vráti iný kód než 200, napríklad 404, renderovanie sa môže preskočiť úplne. Zároveň platí, že keď Google narazí na značku noindex v pôvodnom HTML, môže vykreslenie preskočiť tiež. Pokus odstrániť noindex až JavaScriptom preto nemusí zafungovať a stránka zostane mimo indexu.

2. Overte si za päť minút, čo Google naozaj vidí

Odhad tu nemá miesto. Rozdiel medzi pôvodným a vykresleným HTML sa dá zmerať a existujú na to tri postupy, od najrýchlejšieho po najpresnejší.

Test číslo jeden: zobrazenie zdroja. Na stránke stlačte Ctrl+U, čím sa otvorí pôvodný zdrojový kód tak, ako ho dostane robot v prvom kroku. V tomto kóde skúste vyhľadať (Ctrl+F) vetu zo svojho hlavného textu a názov produktu alebo služby. Ak tam nie sú, obsah sa dokladá až skriptom a všetko závisí od druhej fázy.

Test číslo dva: porovnanie s vykresleným kódom. Otvorte vývojárske nástroje (F12) a kartu Elements. Tá ukazuje DOM po spustení skriptov, teda približne to, čo uvidí vykresľovacia služba. Ak text vidíte tu, ale nie v zobrazení zdroja, viete presne, o aký typ webu ide.

Test číslo tri: nástroj na kontrolu URL. Najspoľahlivejší postup je priamo v Google Search Console. Zadajte adresu do horného poľa, kliknite na Testovať aktívnu adresu URL a potom na Zobraziť testovanú stránku. Dostanete vykreslené HTML, snímku obrazovky, zoznam načítaných zdrojov a výpis chýb konzoly presne tak, ako ich videl robot. Tá istá informácia sa dá získať aj cez Test rozšírených výsledkov.

⚠️ Na čo sa pri teste pozerať: v prvom rade na zoznam zablokovaných zdrojov. Ak je súbor so skriptom zakázaný v robots.txt, Google ho nespustí a obsah, ktorý mal doložiť, nikdy neuvidí. Podrobnosti k správnemu nastaveniu sú v článku o robots.txt a sitemap.

Užitočná je aj druhá vrstva kontroly: podľa dokumentácie k riešeniu problémov s JavaScriptom vykresľovacia služba nemusí sťahovať zdroje, ktoré k obsahu stránky neprispievajú, napríklad požiadavky na reporting. Klientske merania preto neukazujú úplný obraz o tom, čo robot na webe robil. Presnejší pohľad dáva prehľad Štatistiky prehľadávania v Search Console.

3. Spôsoby renderovania a ktorý si vybrať

Otázka „ako sa má web vykresľovať“ nie je vecou vkusu, ale kompromisu medzi rýchlosťou vývoja, rýchlosťou stránky a istotou indexovania. Prehľad možností a toho, čo z nich pre vyhľadávanie plynie:

SpôsobČo dostane robot v prvom krokuVhodné preRiziko pre SEO
Statické generovanie (SSG)Hotové HTML so všetkým obsahomBlogy, katalógy, prezentačné webyPrakticky žiadne
Serverové renderovanie (SSR)Hotové HTML zostavené pri požiadavkeE-shopy, weby s často sa meniacimi dátamiNízke, pozor na čas odpovede servera
SSR s hydratáciouHotové HTML, skript ho následne oživíAplikácie s interakciou aj verejným obsahomNízke, ak sa obsah po oživení nemení
Klientske renderovanie (CSR)Prázdna kostra bez obsahuPrihlásené časti aplikáciíVysoké pri verejných stránkach
Dynamické renderovanieRobot dostane inú verziu než používateľDnes už nič, ide o dočasnú náhraduZložitosť navyše, Google ho neodporúča

Posledný riadok si zaslúži vysvetlenie, pretože ho stále odporúčajú roky staré návody. Google v dokumentácii k dynamickému renderovaniu uvádza, že išlo o obchádzku a nie o dlhodobé riešenie, a namiesto neho odporúča serverové renderovanie, statické generovanie alebo hydratáciu. Dôvod je jednoduchý: udržiavať dve verzie webu je drahé a každý ich rozdiel je zdrojom chýb.

Praktické pravidlo: každá stránka, ktorá má prinášať návštevnosť z vyhľadávania, má mať svoj hlavný obsah už v pôvodnom HTML. Časti, ktoré do vyhľadávania nepatria (košík, používateľský účet, filtre, interaktívne kalkulačky), môžu pokojne zostať na klientskom renderovaní. Toto rozdelenie je zároveň dobré pre používateľov, pretože priamo ovplyvňuje rýchlosť načítania a Core Web Vitals.

4. Chyby, ktoré obsah skryjú najčastejšie

Nasledujúce body vychádzajú z obmedzení, ktoré Google opisuje v návode na riešenie problémov s JavaScriptom. Nejde o odhady, ale o dokumentované správanie vykresľovacej služby.

  • Blokovanie skriptov v robots.txt. Historicky sa priečinky ako /js/ alebo /assets/ zakazovali „pre poriadok“. Dnes to znamená, že robot stránku nevykreslí správne. Skripty a štýly potrebné na zobrazenie obsahu musia byť prístupné.
  • Spoliehanie sa na uložený stav. Vykresľovacia služba neuchováva stav medzi načítaniami stránok. Local Storage, Session Storage aj HTTP cookies sa medzi jednotlivými načítaniami mažú. Ak sa obsah zobrazí až po tom, čo si aplikácia niečo prečíta z lokálneho úložiska, robot ho neuvidí nikdy.
  • Obsah za povolením alebo za interakciou. Googlebot žiadosti o povolenie (kamera, poloha, notifikácie) odmieta. Rovnako neklikne na tlačidlo „Zobraziť viac“, nevyplní formulár a neprejde cez cookie lištu, ktorá obsah prekrýva. Text skrytý za takouto akciou je pre index neviditeľný.
  • Mäkké chyby 404 v jednostránkových aplikáciách. Keď smerovanie rieši klient, neexistujúci produkt často vráti kód 200 s hláškou „nenájdené“. Google pre tento prípad odporúča dve riešenia: buď skriptom presmerovať na adresu, ktorá zo servera vráti skutočnú 404, alebo na chybovú stránku doplniť značku noindex.
  • Zastarané súbory z medzipamäti. Googlebot ukladá zdroje agresívne do medzipamäti a hlavičky medzipamäte môže ignorovať. Riešením je pomenovanie súborov podľa obsahu, takzvaný fingerprint, teda názvy typu main.2bb85551.js, ktoré sa pri každej zmene obsahu zmenia.
  • Chyby v konzole. Jedna neošetrená výnimka dokáže zastaviť celý zvyšok vykresľovania. V teste v Search Console sa preto vždy oplatí prejsť výpis konzoly, nielen snímku obrazovky.
  • Obsah v shadow DOM bez slotu. Pri webových komponentoch Google spája shadow DOM a light DOM a indexuje len to, čo je vo výslednom vykreslenom HTML viditeľné. Ak sa obsah neprojektuje cez prvok <slot>, do indexu sa nedostane.
  • Štruktúrované údaje vkladané skriptom bez kontroly. Vkladať JSON-LD JavaScriptom sa smie, Google generovanie štruktúrovaných údajov skriptom v úvodnej dokumentácii pripúšťa. Výsledok však treba overiť v Teste rozšírených výsledkov, Google zároveň odporúča sledovať stav aj po nasadení, lebo značky sa môžu pokaziť chybou v šablóne alebo na serveri. Podrobnosti k samotnému značkovaniu sú v článku o štruktúrovaných údajoch.

💡 Rýchla diagnostika: ak stránka v teste vyzerá prázdna, prejdite tri veci v tomto poradí: zablokované zdroje, chyby konzoly, návratový kód. Podľa mojej skúsenosti sa väčšina prípadov vysvetlí už v prvých dvoch. Je to poradie, ktoré mi šetrí čas, nie meraný podiel.

5. Odkazy a adresy v jednostránkových aplikáciách

Toto je oblasť, kde sa najčastejšie stráca celý web naraz, nielen jedna stránka. Google objavuje adresy výhradne z prvkov <a> s atribútom href. Všetko ostatné je pre neho slepá ulička.

Nefunguje: odkaz zostavený ako <div onclick="...">, tlačidlo, ktoré volá funkciu smerovača, ani prvok <a> bez atribútu href. Vkladať odkazy do DOM skriptom je v poriadku, ak je výsledkom platný prvok <a href="...">, ako to opisuje dokumentácia k prehľadávateľným odkazom.

Nefungujú ani fragmenty. Adresy typu example.sk/#/produkty boli súčasťou schémy na prehľadávanie AJAX, ktorú Google oznámil ako zrušenú v októbri 2015. Dnes sa na ne spoliehať nedá. Namiesto toho sa má smerovanie riešiť cez History API, teda metódou history.pushState(), ktorá vytvorí normálnu adresu example.sk/produkty a tá funguje aj pri priamom otvorení.

Praktický test trvá desať sekúnd: skopírujte adresu z prehliadača po tom, čo ste sa preklikali do hlbšej sekcie, a otvorte ju v novom, čistom okne. Ak sa zobrazí presne tá istá stránka, adresa je použiteľná. Ak vás to hodí na domovskú stránku alebo na prázdnu kostru, nedostane sa na ňu ani robot.

Rovnaká logika platí pre nekonečné rolovanie a stránkovanie. Ak sa ďalšie položky dokladajú len pri rolovaní a neexistuje k nim adresa, do indexu sa dostane iba prvá obrazovka. Riešenie je opísané v článku o stránkovaní a filtroch: každá stránka výpisu má mať vlastnú adresu a odkaz na ňu. K premyslenej štruktúre adries sa hodí aj návod k štruktúre webu a URL.

Posledná vec, na ktorú sa zabúda: kanonická značka. Vložiť ju skriptom je možné, ale Google odporúča dať ju priamo do HTML. Ak sa vkladá skriptom, musí byť na stránke jediná a musí obsahovať tú istú hodnotu, aká je v pôvodnom HTML. Viacero protichodných kanonických značiek vedie k nepredvídateľným výsledkom.

6. Kontrolný zoznam pred spustením webu

Nasledujúci zoznam prejdite pri každom novom webe na javascriptovom rámci, ideálne ešte na testovacej verzii. Každý bod má jednoznačnú odpoveď áno alebo nie.

  1. Je hlavný text stránky v zobrazení zdroja? Skúste vyhľadať prvú vetu textu v zobrazení zdroja (Ctrl+U). Ak tam nie je, vyriešte to serverovým renderovaním alebo statickým generovaním skôr, než sa začnete zaoberať čímkoľvek iným.
  2. Sú titulok a meta popis unikátne pre každú adresu? Pri jednostránkových aplikáciách sa často zdedí titulok domovskej stránky na všetkých adresách. Pomôcka k formulácii je v článku o meta title a popise.
  3. Fungujú adresy po priamom otvorení v novom okne? Vrátane hlbokých stránok produktov a článkov.
  4. Sú všetky odkazy prvkami <a href>? Prejdite hlavnú navigáciu, pätičku aj odkazy vnútri textu.
  5. Vracia neexistujúca adresa kód 404? Otvorte vymyslenú adresu a skontrolujte návratový kód v karte Network vývojárskych nástrojov.
  6. Sú skripty a štýly povolené v robots.txt? Skontrolujte v teste v Search Console zoznam zablokovaných zdrojov.
  7. Je konzola bez chýb? A to nielen vo vašom prehliadači, ale aj vo výpise z testu.
  8. Majú súbory fingerprint v názve? Zabráni to tomu, aby robot pracoval so starou verziou skriptu.
  9. Je sitemap vygenerovaná zo skutočného zoznamu adries? Pri aplikáciách sa často zabúda, že nové adresy do nej treba dopĺňať automaticky.

Keď je zoznam prejdený, má zmysel pustiť sa do bežnej optimalizácie. JavaScript SEO totiž nie je samostatná disciplína, ale iba vrstva navyše: keď je vyriešená, platia rovnaké pravidlá ako všade inde a hodí sa prejsť aj štandardný SEO audit.

Súvisiace: Core Web Vitals · Robots.txt a sitemap · Štruktúra webu a URL

Zdroje

  • Google Search Central: Understand JavaScript SEO basics, tri fázy spracovania, front na renderovanie, kanonická značka, medzipamäť a webové komponenty (overené 8/2026).
  • Google Search Central Blog: Deprecating our AJAX crawling scheme (október 2015), zrušenie schémy s fragmentmi v adresách.
  • Google Search Central: Intro to structured data, generovanie štruktúrovaných údajov skriptom a potreba sledovať ich stav po nasadení.
  • Google Search Central: Fix Search-related JavaScript problems – neuchovávanie stavu medzi načítaniami, odmietanie povolení, mäkké chyby 404, fingerprinting súborov.
  • Google Search Central: Dynamic rendering as a workaround – dynamické renderovanie ako dočasná obchádzka a odporúčanie použiť SSR, statické generovanie alebo hydratáciu.
  • Google Search Central: Make your links crawlable – podmienky, za ktorých Google odkaz vôbec objaví.
  • web.dev: Rendering on the web – porovnanie statického generovania, serverového renderovania, hydratácie a klientskeho renderovania.

Časté otázky

Spúšťa Google vôbec JavaScript?

Áno. Google stránky vykresľuje verziou prehliadača Chromium bez grafického rozhrania (headless) a spúšťa pri tom JavaScript. Robí to však až v druhom kroku, po prehľadávaní, a stránka môže vo fronte na vykreslenie chvíľu čakať. Obsah doložený skriptom je preto indexovaný neskôr než obsah, ktorý je priamo v HTML.

Ako zistím, či Google vidí obsah mojej stránky?

Použite nástroj na kontrolu URL v Google Search Console: zadajte adresu, kliknite na Testovať aktívnu adresu URL a potom na Zobraziť testovanú stránku. Uvidíte vykreslené HTML, snímku obrazovky, zablokované zdroje a chyby konzoly. Rýchla predbežná kontrola sa dá urobiť aj cez Ctrl+U, kde uvidíte pôvodné HTML bez spustených skriptov.

Je React alebo Vue zlý pre SEO?

Samotný rámec problém nie je, rozhoduje spôsob renderovania. Ak sa stránky generujú staticky alebo na serveri, robot dostane hotové HTML a SEO sa nelíši od klasického webu. Problém vzniká pri čisto klientskom renderovaní, keď robot v prvom kroku dostane prázdnu kostru.

Prečo mám v indexe stránky s hláškou o nenájdenom produkte?

Ide o takzvanú mäkkú chybu 404. V jednostránkových aplikáciách rieši smerovanie klient, takže server vráti kód 200 aj pri neexistujúcej položke. Google odporúča buď skriptom presmerovať na adresu, ktorá zo servera vráti skutočný kód 404, alebo na chybovú stránku doplniť značku noindex.

Prečo sa mi obsah zobrazí v prehliadači, ale nie v teste?

Najčastejšie ide o jednu z troch príčin: skripty sú zakázané v robots.txt, chyba v konzole zastavila vykresľovanie, alebo obsah závisí od uloženého stavu. Vykresľovacia služba totiž medzi načítaniami stránok maže Local Storage, Session Storage aj cookies, takže sa na ne nedá spoliehať.

Má zmysel dnes nasadzovať dynamické renderovanie?

Google ho označuje za dočasnú obchádzku, nie za dlhodobé riešenie, a namiesto neho odporúča serverové renderovanie, statické generovanie alebo hydratáciu. Dynamické renderovanie znamená udržiavať dve verzie webu, čo pridáva náklady aj priestor na chyby.