Problém není rychlost, ale viditelnost pro robota

V praxi se často stává, že web má výborné výsledky v nástrojích jako PageSpeed Insights nebo Lighthouse, ale v organickém vyhledávání nepřináší téměř žádnou návštěvnost. Důvod je jednoduchý: rychlé načtení pro uživatele neznamená, že Google dokáže obsah správně najít, vykreslit, pochopit a zařadit do indexu. Vyhledávač nehodnotí jen výkon, ale celý řetězec od crawlability přes renderování až po kvalitu a relevanci obsahu.

Googlebot nejprve stránku stáhne, pak ji zpracuje, vykreslí a teprve poté rozhoduje, zda ji zařadí do indexu. Pokud je důležitý obsah schovaný za JavaScriptem, blokovaný robots.txt, nebo se načítá až po interakci uživatele, robot jej nemusí vidět vůbec. To je časté zejména u moderních webů postavených v Reactu, Next.js bez správného SSR/SSG nastavení nebo u WordPressu s agresivním lazy loadingem a optimalizací skriptů.

Co Google skutečně potřebuje vidět

Pro indexaci nestačí, že stránka „nějak“ funguje. Google potřebuje včas a bez překážek vidět hlavní obsah, interní odkazy, nadpisy, metadata a strukturovaná data. Pokud je klíčový text generován až na klientovi, může být indexace opožděná nebo neúplná. U nových webů to často znamená, že se stránky sice otevřou v prohlížeči, ale v Search Console zůstávají bez záznamu nebo s chybou „Crawled – currently not indexed“.

Typický příklad z praxe: e-shop má homepage i kategorie pod 2 sekundy, ale produkty se v Googlu neobjevují. Po kontrole vyjde najevo, že seznam produktů je načítán přes API až po vykreslení stránky a Googlebot jej v renderu nevidí stabilně. V HTML je jen prázdný kontejner. Výsledek? Dobrá rychlost, nulová indexace produktových URL.

Co zkontrolovat jako první

  • HTML zdroj – je v něm skutečný obsah, nebo jen skeleton?
  • robots.txt – neblokuje omylem CSS, JS nebo důležité sekce?
  • meta robots – není na stránce noindex, nofollow?
  • canonical – neukazuje na jinou URL, která obsah nahrazuje?
  • status kód – vrací stránka 200, nebo třeba 302/soft 404?
  • interní prolinkování – vede na stránku dostatek odkazů z relevantních částí webu?

JavaScript je častý viník, ne výkon

Moderní frontendové frameworky výrazně zlepšily UX, ale zároveň přidaly nové SEO riziko. Pokud je web postavený jako čisté SPA bez server-side renderingu, může být pro uživatele rychlý, ale pro vyhledávač dlouho nečitelný. Google sice umí JavaScript renderovat, ale ne vždy okamžitě a ne vždy bezchybně. V případě velkého webu nebo slabšího crawl budgetu se některé stránky vůbec nedostanou do fáze plného vykreslení.

Nejčastější problém je rozdíl mezi tím, co vidí člověk v prohlížeči, a tím, co Google dostane v prvním i druhém průchodu. Pokud se obsah načítá přes fetch po interakci, nebo pokud je render podmíněn cookies či lokálním stavem, robot může dostat jinou verzi stránky než uživatel. To komplikuje indexaci i interpretaci obsahu.

U webů v Next.js nebo Nuxtu proto dává smysl preferovat SSR nebo SSG pro klíčové landing pages, kategorie i články. U WordPressu zase pomáhá omezit builderové prvky, které generují těžký DOM a skrývají text za skripty. Cílem je, aby důležitý obsah existoval v HTML už při prvním načtení.

Praktický test renderu

  • Otevřete stránku v Google Search Console → Kontrola adresy URL.
  • Porovnejte zobrazenou stránku a prohledanou stránku.
  • V nástroji URL Inspection sledujte, zda Google vidí text, odkazy a obrázky.
  • V DevTools vypněte JavaScript a ověřte, co zůstane v HTML.
  • Použijte Rich Results Test a Schema Markup Validator pro kontrolu strukturovaných dat.

Indexaci blokují i drobné technické chyby

V mnoha případech není problém v architektuře, ale v detailech. Jedna špatně nastavená direktiva, duplicitní canonical nebo chybný redirect řetězec dokáže vyřadit stránku z indexu i na rychlém webu. Google je v tomto směru konzervativní: pokud dostane protichůdné signály, často stránku raději nezařadí vůbec.

Mezi nejčastější chyby patří:

  • noindex na šabloně po migraci nebo při testování, který zůstal aktivní;
  • canonical směřující na homepage nebo jinou variantu URL;
  • duplicitní parametry v URL bez správného ošetření;
  • přesměrování 302 tam, kde má být 301;
  • soft 404 u tenkých nebo prázdných stránek;
  • blokace v robots.txt na úrovni šablony, ne jednotlivé stránky.

Jeden z typických scénářů: web po redesignu běží rychleji o 40 %, ale organická návštěvnost spadne na polovinu. Analýza ukáže, že nové šablony mají canonical na staré URL, část kategorií je noindex a sitemap obsahuje jen homepage. Google pak nemá jasný signál, co má indexovat, i když se stránka načte bez problémů.

Obsah může být rychlý, ale stále bez hodnoty pro vyhledávání

Další častý omyl je představa, že technická rychlost automaticky znamená SEO úspěch. Google ale vyhodnocuje i relevanci, originalitu a užitečnost obsahu. Pokud je stránka krátká, generická nebo příliš podobná stovkám jiných webů, nemusí získat prostor v indexu ani při perfektním výkonu. To platí zejména u kategorií, lokálních landing pages a produktových stránek.

Vyhledávač dnes mnohem lépe rozpoznává záměr dotazu a očekává obsah, který odpovídá konkrétní potřebě. Stránka o „rychlém webu“ bez dat, bez příkladů a bez jasné struktury má malou šanci uspět proti konkurenci, která pokrývá téma do hloubky. Proto je důležité kombinovat technické SEO s tematickými clustery, interním prolinkováním a jasnými nadpisy H1–H3.

Prakticky to znamená: každá důležitá URL by měla mít vlastní vyhledávací záměr, unikátní text, titulky, meta description a odpovídající schema markup. U článků dává smysl doplnit Article nebo BlogPosting, u produktů Product, u lokálních firem LocalBusiness. Strukturovaná data sama o sobě indexaci nezachrání, ale pomáhají Googlu pochopit kontext.

Jak problém diagnostikovat a opravit v praxi

Postup by měl být systematický. Nejprve ověřte, zda je stránka vůbec crawlable. V Search Console sledujte stav indexace, pokrytí a případné vyloučené adresy. Pokud se stránka objevuje jako „Objeveno – momentálně neindexováno“ nebo „Procházeno – momentálně neindexováno“, jde často o kombinaci slabého obsahu, nepřesných signálů a nízké interní autority.

Poté zkontrolujte render. V ideálním případě by hlavní obsah měl být přítomen už v serverově vráceném HTML. Pokud ne, upravte architekturu tak, aby kritické sekce nebyly závislé na klientském JavaScriptu. U WordPressu pomůže omezit zbytečné pluginy, optimalizovat cache a vypnout skripty, které blokují vykreslení. U custom vývoje je vhodné nasadit SSR, ISR nebo statický export pro stránky, které se často nemění.

Dalším krokem je audit interních odkazů a sitemap. Do XML sitemap patří jen indexovatelné, kanonické a skutečně důležité URL. Interní odkazy by měly vést z homepage, kategorií a souvisejících článků na klíčové landing pages. Pokud je stránka dostupná jen přes vyhledávání na webu nebo přes filtr, Google ji může přehlédnout.

Na závěr se vyplatí porovnat data z Google Search Console, serverových logů a nástroje jako Screaming Frog nebo Sitebulb. Logy ukážou, zda Googlebot stránku skutečně navštěvuje, Search Console potvrdí, zda ji indexuje, a crawler odhalí technické překážky. Teprve kombinace těchto dat ukáže, proč se rychlý web v Googlu „neobjevuje“.

Kdy pomůže výkon a kdy už ne

Rychlost webu je důležitá pro uživatele i SEO, ale sama o sobě je jen jedna část skládačky. Pokud má web LCP pod 2,5 sekundy, CLS pod 0,1 a INP v dobrém rozmezí, je to výborný základ. Jestli ale Google nevidí obsah, má špatné canonical signály nebo se stránka renderuje až po interakci, výkon žádnou indexaci nezajistí.

Nejúčinnější přístup je proto dvojí: technicky zjednodušit cestu robota k obsahu a zároveň posílit relevanci stránky. To znamená čisté HTML, správné status kódy, bezchybný render, kvalitní interní propojení, strukturovaná data a obsah odpovídající záměru hledání. Teprve pak rychlý web skutečně funguje i pro Google, nejen pro měření v PageSpeed Insights.