Rychlost je jen jedna z vrstev technického SEO
Velká část majitelů webů si myslí, že jakmile se stránka načte za dvě sekundy, SEO problém je vyřešený. Jenže Google neřeší pouze pocit rychlosti v prohlížeči. Sleduje, jestli je obsah vůbec dostupný pro crawl, zda je správně interpretovatelný, jaké signály stránka vysílá o tématu a jestli odpovídá tomu, co uživatel skutečně hledá. Rychlost je tedy hygienický faktor, ne automatická vstupenka na první pozice.
V praxi to vidím často u webů na Next.js, WordPressu i headless řešeních. V Lighthouse mají slušné skóre, LCP pod 2,5 s a mobilní rychlost vypadá dobře. Přesto je organická návštěvnost slabá. Důvod bývá kombinace špatné indexace, tenkého obsahu, duplicitních URL, slabé interní struktury nebo nejasného vyhledávacího záměru. Google potom web „přehlíží“, i když se návštěvníkovi zdá svižný.
Google stránku sice otevře, ale nepochopí její hodnotu
Jedním z nejčastějších problémů je rozdíl mezi nactením stránky a pochopením jejího obsahu. U moderních webů je obsah často renderovaný přes JavaScript. Pro uživatele vše funguje, ale crawler může vidět prázdný shell, opožděně načítaná data nebo obsah, který se zobrazí až po interakci. To je typické hlavně u SPA aplikací, složitých filtrů nebo produktových katalogů.
Ověřte si to v těchto nástrojích:
- Google Search Console – URL Inspection, vykreslená stránka, indexační stav.
- Rich Results Test – kontrola strukturovaných dat.
- PageSpeed Insights – nejen výkon, ale i diagnostika renderingu.
- Chrome DevTools – porovnání DOM před a po vykreslení JS.
- Screaming Frog s JavaScript renderingem – pro kontrolu, co crawler skutečně vidí.
Typický příklad: e-shop má na homepage rychlý hero banner a několik bloků s produkty. Na první pohled vše běží dobře. Jenže samotný produktový seznam se načítá z API až po 3–4 sekundách a bez JS není v HTML vůbec. Google pak stránku sice indexuje, ale její tematická relevance je slabá, protože hlavní obsah je pro něj hůř dostupný. V takovém případě pomůže server-side rendering, prerendering nebo alespoň hybridní přístup.
Rychlý web s chudým obsahem nevyhraje vyhledávací záměr
Další častý důvod je, že web odpovídá na dotaz jen povrchově. Může se načíst rychle, ale pokud text neřeší konkrétní problém, Google ho nebude upřednostňovat před komplexnějším výsledkem. Dnes je klíčové pracovat s search intentem a tématickými clustery, ne jen s jednotlivými klíčovými slovy.
Dejme tomu, že cílíte na „technické SEO“. Stránka, která jen stručně popíše, že technické SEO zahrnuje rychlost webu a meta tagy, bude slabá. Lepší je pokrýt i indexaci, crawl budget, canonicalizaci, robots.txt, sitemap.xml, schema markup, interní prolinkování, Core Web Vitals a řešení pro JavaScript weby. Google pak lépe vyhodnotí, že stránka skutečně pokrývá celé téma.
Praktický postup:
- V Google Search Console zjistěte, na jaké dotazy web už získává impresi.
- V Ahrefs, Semrush nebo Collabim porovnejte, zda obsah odpovídá záměru dotazu.
- Proveďte analýzu SERPu: jsou výsledky informační, transakční, lokální nebo srovnávací?
- Doplňte obsah o odpovědi, které konkurence pokrývá lépe, ale bez zbytečného plýtvání textem.
Google dnes mnohem lépe rozpoznává, zda stránka řeší téma do hloubky. U článků, kategorií i landing pages proto funguje semantic SEO: související pojmy, entity, jasné členění a přirozená terminologie. Stránka může být rychlá, ale když je obsah příliš úzký, nebude mít šanci konkurovat stránkám s vyšší tematickou autoritou.
Technické chyby, které rychlost maskuje
Rychlé načtení často zakryje problémy, které z pohledu SEO působí nenápadně. Google totiž nehodnotí jen výkon, ale i konzistenci a dostupnost obsahu v rámci celého webu. Mezi nejčastější chyby patří:
- Duplicitní URL – stejné nebo velmi podobné stránky dostupné přes více cest.
- Špatně nastavený canonical – Google si vybere jinou variantu stránky, než chcete.
- Chybné přesměrování – řetězce redirectů, 302 místo 301, přesměrování na obecné URL.
- Blokace v robots.txt – důležité části webu nejsou crawlitelné.
- Slabá interní struktura – důležité stránky jsou příliš hluboko v architektuře webu.
- Chybějící nebo nekonzistentní schema markup – Google nemá jasné signály o typu obsahu.
Například u WordPressu bývá častý problém, že rychlost je vyřešená cache pluginem, ale zároveň vznikají indexované archivní stránky, tagy, autor stránky a parametry URL, které rozmělní autoritu. Naopak u headless webů bývá problém v tom, že frontend je rychlý, ale sitemap neobsahuje všechny důležité URL nebo se generuje špatný canonical.
Kontrolujte v Google Search Console report „Stránky“ a sledujte, co je vyloučené a proč. V Screaming Frog si projděte canonicaly, status kódy, hloubku kliknutí a interní odkazy. U větších webů sledujte také crawl logy, abyste věděli, zda Googlebot skutečně navštěvuje důležité části webu, nebo se zbytečně točí kolem parametrů a filtrování.
Core Web Vitals nejsou všechno, ale bez nich to nepůjde
Core Web Vitals jsou důležité, ale jejich role je často špatně pochopená. Samotné dobré metriky ještě nezaručí lepší pozice, pokud web trpí slabým obsahem nebo indexačními problémy. Na druhou stranu špatné CWV mohou zhoršit uživatelský signál a u konkurence s podobnou kvalitou obsahu rozhodnout.
Sledujte hlavně:
- LCP – ideálně do 2,5 s.
- INP – pod 200 ms.
- CLS – pod 0,1.
V praxi je důležité rozlišovat laboratorní a terénní data. PageSpeed Insights ukazuje Lighthouse test, ale Google hodnotí i CrUX data z reálných návštěv. Web může v labu vypadat skvěle, ale v reálu mít pomalé mobilní připojení, těžké fonty, blokující skripty nebo přetížené tag manager kontejnery. Zvlášť pozor na reklamní skripty, chat widgety, heatmapy a příliš mnoho externích knihoven.
U webů s nejlepšími rychlostními parametry často pomáhá jednoduché pravidlo: načíst jen to, co je skutečně vidět nad přehybem, zbytek deferovat. Zároveň je dobré zredukovat počet JS bundleů, optimalizovat obrázky do WebP nebo AVIF a zajistit stabilní layout. Ale opakuji: pokud je obsah slabý, performance vás nezachrání.
Jak postupovat, když web běží rychle, ale organika neroste
Nejlepší je jít systematicky od techniky k obsahu a zpět. Začal bych tímto postupem:
- Ověřit indexaci – Search Console, pokrytí URL, vyloučené stránky, canonicaly.
- Zkontrolovat renderování – co vidí Googlebot v HTML a po vykreslení JS.
- Projít interní strukturu – důležité stránky musí být dostupné na pár kliknutí.
- Analyzovat záměr vyhledávání – odpovídá obsah tomu, co uživatel opravdu hledá?
- Doplnit entity a související témata – aby stránka byla tematicky úplná.
- Nasadit strukturovaná data – Article, Product, FAQ, Breadcrumb, Organization podle typu webu.
U větších webů doporučuji vytvořit si checklist pro každou důležitou šablonu: homepage, kategorie, produkt, článek, landing page. Každá šablona by měla mít jasně definovaný title, meta description, H1, logickou hierarchii nadpisů, interní odkazy, canonical, schema markup a obsah odpovídající intentu. Tím výrazně snížíte riziko, že bude web rychlý, ale z pohledu Googlu nerozpoznatelný.
Pokud chcete rychle najít slabé místo, porovnejte tři vrstvy najednou: technický výkon, indexační stav a kvalitu obsahu. Rychlost je jen jedna součást skládačky. Teprve když jsou všechny vrstvy v souladu, začne web v organickém vyhledávání skutečně růst.