Rychlý web pro uživatele neznamená rychlý web pro Google
Majitelé webů často hodnotí rychlost podle pocitu: stránka se načte do dvou vteřin, menu reaguje okamžitě a Lighthouse ukazuje slušné skóre. Jenže Google nepracuje jako běžný návštěvník. Nejprve musí stránku objevit, stáhnout, renderovat, pochopit a zařadit do indexu. A právě v těchto krocích se často ztrácí čas i signály kvality.
Typický příklad: web běží na moderním JavaScriptu, uživatel vidí obsah hned, ale Googlebot dostane prázdnou HTML šablonu a kompletní obsah se vykreslí až po několika sekundách. Pro člověka je web rychlý, pro crawler pomalý a hůře čitelný. Výsledek? Pozdější indexace, slabší viditelnost nových stránek a někdy i neúplné zařazení obsahu.
Google navíc nehodnotí jen „rychlost“ v běžném smyslu. Sleduje i to, jak snadno dokáže stránku zpracovat technicky. Pokud je web zbytečně složitý, má mnoho parametrických URL, blokované zdroje nebo nestabilní DOM, vzniká zdržení, které se v analytice uživatele vůbec nemusí projevit.
Nejčastější důvody, proč Google ztrácí čas
V praxi se opakuje několik technických příčin. Nejsou to exotické chyby, ale běžné problémy, které se často skryjí za pěkným designem a dobrým výsledkem v PageSpeed Insights.
1. JavaScript renderuje obsah pozdě nebo neúplně
Moderní frontendové stacky jako React, Next.js nebo Vue nejsou samy o sobě problém. Problém nastává, když je klíčový obsah dostupný až po vykreslení v prohlížeči. Google sice umí JavaScript renderovat, ale je to dvoufázový proces a renderování může přijít se zpožděním. U rozsáhlejších webů se tak indexace protahuje i o desítky minut až hodin.
Praktický test: otevřete stránku v Google Search Console v nástroji Kontrola adresy URL a porovnejte HTML zdroj s vykreslenou verzí. Pokud v renderovaném HTML chybí hlavní text, odkazy nebo produktové informace, je problém na straně vykreslování.
2. Crawl budget se pálí na zbytečných URL
Velké weby často vytvářejí tisíce variant URL kvůli filtrům, parametrům, stránkování nebo interním vyhledáváním. Google pak místo důležitých stránek tráví čas procházením duplicit a nekonečných kombinací. U e-shopů je to velmi časté: například kategorii lze otevřít přes 12 filtrů a 8 řazení, čímž vzniknou stovky téměř totožných URL.
Signál problému poznáte v Search Console v sekci Stránky, kde roste počet „Prolezeno – momentálně neindexováno“ nebo „Duplicitní, Google zvolil jinou kanonickou adresu“. To je jasná indikace, že crawler investuje energii do méně důležitých adres.
3. Pomalá odpověď serveru a řetězce přesměrování
I když je frontend lehký, server může být pomalý. Doba odezvy TTFB nad 600 ms už začíná být varovná, zejména u webů s vyšší návštěvností nebo častou změnou obsahu. Ještě horší jsou přesměrovací řetězce: například http → https → www → finální URL. Každý skok znamená další round-trip a další ztrátu času pro crawl i pro uživatele.
Podle měření v praxi umí zkrácení redirect chainu z 3 kroků na 1 krok zlepšit nejen crawl efektivitu, ale i rychlost prvního zobrazení obsahu o stovky milisekund. U velkých webů to v součtu dělá rozdíl v řádu tisíců URL denně.
4. Interní odkazy nejsou dostatečně silné nebo konzistentní
Google objevuje stránky hlavně přes odkazy. Pokud jsou důležité stránky ukryté hluboko v architektuře webu, bez interního prolinkování a bez kontextu, robot je najde později nebo méně často. Častý problém je také používání odkazů jen v JavaScriptu, v dropdown menu bez HTML fallbacku nebo v prvcích, které nejsou skutečnými odkazy.
U webů s více než 1 000 URL doporučuji kontrolovat hloubku prokliku. Stránky, které jsou více než 3 kliky od homepage, bývají indexované pomaleji a získávají méně interní autority. Nástroje jako Screaming Frog, Sitebulb nebo Ahrefs umí tuto hloubku vizualizovat velmi přesně.
Jak poznat, že Google web skutečně brzdí
Nejdůležitější je oddělit dojem od dat. Když web „působí rychle“, ale organika stagnuje, bývá problém v jedné z těchto metrik:
- Google Search Console – pokles počtu indexovaných stránek, nárůst vyloučených URL, časté „Objeveno – momentálně neindexováno“.
- Crawl stats – kolísání počtu stažených stránek, dlouhé odezvy serveru, vysoký podíl 3xx a 4xx odpovědí.
- Server logy – Googlebot navštěvuje často méně důležité URL a ignoruje nové landing pages.
- Core Web Vitals – LCP, INP a CLS sice primárně hodnotí UX, ale často odhalí i technické brzdy v renderování a JavaScriptu.
Velmi užitečné je porovnání reálných uživatelských dat a crawl dat. Například web může mít průměrný LCP 2,1 s na mobilu, ale Googlebotovi se kvůli renderovacímu frontendu stahuje dokument v několika fázích a výsledná indexace nového obsahu trvá 2–4 dny. To je typický rozdíl mezi „rychlostí pro uživatele“ a „rychlostí pro vyhledávač“.
Co opravit jako první, aby se indexace zrychlila
Neexistuje univerzální fix, ale pořadí priorit bývá velmi podobné. Nejlepší výsledky přináší zásahy do míst, která ovlivňují objevování a renderování obsahu.
Začněte u HTML a serveru
Pokud je to možné, dodávejte hlavní obsah už v prvním HTML odpovědi. U Next.js nebo podobných frameworků preferujte server-side rendering nebo static generation pro důležité landing pages. U WordPressu zkontrolujte, zda pluginy nepřidávají zbytečné skripty a zda hosting zvládá rychlou TTFB i při špičce.
Praktický cíl: pro důležité stránky se snažte dostat TTFB pod 300–500 ms a eliminovat vícestupňová přesměrování.
Upravte interní prolinkování podle priority
Nejdůležitější stránky musí být propojené z homepage, kategorií, tematických hubů a souvisejících článků. Nestačí je mít v XML sitemapě. Sitemap pomáhá objevit URL, ale interní odkazy určují, co je opravdu důležité. V tematických clusterech doporučuji, aby každý podpůrný článek odkazoval na hlavní pilířovou stránku a na 2–3 relevantní související URL.
Omezte duplicitní a parametrické URL
U e-shopů a katalogů nastavte kanonické adresy, pravidla pro parametrické URL a v případě potřeby i blokaci méně hodnotných kombinací přes robots.txt nebo noindex. Pozor: robots.txt není řešení pro duplicity, které už Google objevil a indexuje. Pokud je URL veřejně dostupná, je lepší nejdřív zredukovat její vznik, ne až následně hasit následky.
Projděte logy a zjistěte, co Google skutečně dělá
Analýza log souborů je jeden z nejpřesnějších nástrojů technického SEO. Ukáže vám, zda Googlebot navštěvuje nové produkty, blogové články nebo důležité kategorie, nebo zda se ztrácí na stránkách s filtrem, interním vyhledáváním a nekonečným stránkováním. V praxi často zjistíte, že 20 % URL spotřebuje 80 % crawl aktivit.
Na logy se vyplatí použít nástroje jako Splunk, ELK stack, Oncrawl nebo Botify. U menších webů stačí i export serverových logů a jednoduchá analýza v Google Sheets nebo Pythonu.
Jaké nástroje použít a co v nich sledovat
Pro rychlou diagnostiku doporučuji kombinaci několika nástrojů. Každý z nich zachytí jiný typ problému.
- Google Search Console – indexace, stav stránek, crawl stats, ruční kontrola URL.
- Screaming Frog – hloubka prolinkování, duplicity, kanonické URL, redirect chains, status codes.
- PageSpeed Insights / Lighthouse – LCP, INP, CLS, JavaScript payload, render blocking resources.
- WebPageTest – waterfall, TTFB, přesměrování, rozdíl mezi prvním a opakovaným načtením.
- Server log analyzátory – reálné chování Googlebota a jeho prioritizace URL.
Pokud chcete rychle odhalit, proč je web pro Google pomalý, sledujte hlavně tři věci: kolik URL robot skutečně prochází, jak dlouho trvá renderování obsahu a zda se důležité stránky objevují v interním odkazu z více míst webu. Teprve pak má smysl ladit drobnosti jako minifikace CSS nebo komprese obrázků.
Praktický scénář: kdy se „rychlý“ web indexuje 3× pomaleji
U jednoho e-shopu s asi 18 000 URL běžel frontend na moderním JS frameworku a UX testy ukazovaly výborné výsledky. Přesto nové produktové stránky čekaly na indexaci 48–72 hodin. Analýza ukázala tři problémy: produkty se vykreslovaly až po hydratační fázi, interní odkazy vedly hlavně přes JS komponenty a filtrace generovala tisíce variant URL.
Po přechodu na server-side rendering u produktových detailů, úpravě interních odkazů a omezení parametrů klesla doba objevení nové URL v průměru na 6–12 hodin. Současně se snížil počet vyloučených URL v Search Console a crawl stats ukázaly, že Googlebot začal více navštěvovat produktové stránky místo fasetových kombinací. To je přesně situace, kdy web zůstává pro uživatele stejně rychlý, ale pro Google se stává mnohem snadněji zpracovatelný.
Co si pohlídat průběžně, aby se problém nevrátil
Technické SEO není jednorázová oprava. Jakmile přidáte nový modul, filtr, jazykovou mutaci nebo redesign, může se situace vrátit během několika týdnů. Proto doporučuji zavést pravidelný monitoring:
- měsíční kontrolu indexace v Search Console,
- automatizovaný crawl po každém větším release,
- průběžnou analýzu logů pro Googlebota,
- sledování TTFB a Core Web Vitals na šablonách s největší návštěvností,
- audit nově vzniklých parametrů, filtrů a interních odkazů.
Pokud web působí rychle, ale Google ho zdržuje, není problém v jedné „špatné rychlosti“. Obvykle jde o souhru renderování, architektury webu, duplicity a crawl priority. Jakmile to změříte na datech, většinou se ukáže, že největší zrychlení nepřinese další optimalizace obrázků, ale zjednodušení toho, co musí Google vůbec pochopit.
