SEO a technická nalezitelnost

Někdo nechce, aby se interní stránka ukazovala ve výsledcích, tak ji zablokuje v robots.txt. Logické přání, špatný nástroj. robots.txt neříká „neindexuj". Říká jen „necrawluj". Když na takovou URL vedou odkazy, Google ji může ve výsledcích pořád ukázat, jen bez normálního popisku.

Jenže když už to máš v robots.txt, tak noindex na stránce už Google stránku nikdy nestáhne, poslechne zákaz v robots.txt. Blokace, kterou jsi myslel jako zámek, se tak chová jako cedule „nevstupovat" pověšená přes dveře, za kterými leží vzkaz „tuhle místnost vyřaď z mapy".

Cílem této kapitolu je základně vysvětlit co to je crawl, render, index a zobrazení ve výsledcích. A že skoro každý nástroj, kterým je „ovládáš", je jen signál, ne absolutní příkaz. Canonical, sitemapa, hreflang, strukturovaná data: Google je čte, váží a někdy ignoruje. Kdo čeká magii („nastavíme canonical a hotovo"), dostane zklamání. Kdo posílá konzistentní signály, dostane šanci.

Tahle kapitola není o klíčových slovech ani o copywritingu. Je o tom, jestli stroj tvůj obsah vůbec najde, stáhne, vykreslí, zařadí a ukáže správnou URL.

Crawl, render, index, serving

Google Search se dá číst jako řada otázek. Umí URL objevit? Smí ji stáhnout? Musí ji renderovat? Vyhodnotí ji jako vhodnou do indexu? A když ano, jakou verzi ukáže ve výsledcích?

Obecné fáze jsou crawling, indexing a serving. U JavaScriptu mezi stažení HTML a indexaci vstupuje ještě renderování ve Web Rendering Service, tedy v headless Chromu. Právě tam se obsah často ztratí. Když title, canonical, meta robots nebo hlavní text existují až po klientském JavaScriptu, přidáváš čekání, křehkost a další místo, kde se může něco rozbít.

Praktické pravidlo je jednoduché: kritické SEO signály a hlavní obsah patří do HTML první odpovědi. Klientský JavaScript může stránku vylepšit, ale nemá být jediným zdrojem toho, co má Google najít. Proto o nalezitelnosti rozhoduje volba renderování.

robots.txt vs. noindex: co je crawl a co je index

Zopakujme rozlišení, protože stojí za polovinou problémů v Search Console.

robots.txt s Disallow říká crawlerovi „sem nelez". Šetří server, řídí crawl budget. Neřídí index. Stránka blokovaná v robots může v indexu zůstat, pokud na ni vedou odkazy.

noindex říká „tuhle stránku nezařazuj do výsledků". Dává se buď meta tagem <meta name="robots" content="noindex">, nebo HTTP hlavičkou X-Robots-Tag (ta umí i ne-HTML soubory jako PDF). Když Googlebot noindex najde, stránku z indexu vyhodí bez ohledu na odkazy.

A v tom je háček: pro jednu URL jdou tyhle dva záměry snadno proti sobě. Aby noindex zabral, crawler musí stránku stáhnout a tag přečíst, takže nesmí být blokovaná v robots.txt. Chceš stránku ven z indexu? Dej jí noindex a crawl neblokuj, dokud ji Google znovu nestáhne. Citlivý obsah neřeš přes robots, ale přihlášením, oprávněním nebo stavem 404/410. robots.txt není bezpečnostní vrstva.

Canonical je nápověda, ne příkaz

rel="canonical" říká Googlu, kterou ze sady duplicitních nebo podobných URL považuješ za hlavní. Pomáhá konsolidovat signály z duplicit, hlavně odkazy, a napovídá, která URL se má zobrazit. Ale pořád je to nápověda. Google může zvolit jinou kanonickou URL než ty, když mu ostatní signály ukazují jinam.

Canonical se proto neposílá jedním kanálem. Sčítá se: značka v HTML nebo HTTP hlavičce, 301 redirect, URL v sitemapě, interní odkazy. Čím víc těchhle signálů míří konzistentně na jednu URL, tím vyšší šance, že Google zvolí tu tvoji. Jeden canonical tag obklopený interními odkazy na jinou verzi je rozpor. A v rozporu rozhoduje Google, ne ty.

Sitemapa není příkaz k indexaci

Sitemapa říká „tyhle URL existují, podívej se na ně". Pomáhá objevit stránky, na které vede málo interních odkazů. Nezaručí zaindexování. Do sitemapy patří hlavně kanonické, dostupné a indexovatelné URL. Když do ní nasypeš odpad, učíš Google, že tvoje mapa není dobrý průvodce.

Pravidla jsou jednoduchá. Jeden soubor pojme 50 000 URL nebo 50 MB nekomprimovaně, podle toho, co přijde dřív. Větší web se dělí do víc souborů spojených přes sitemap index.

Co je v sitemapě k ničemu: Google ignoruje <priority> i <changefreq>. Nepiš je, neřídí crawl. Smysl má <lastmod>, ale jen když je ověřitelně přesný. Když stránce sedmým rokem tvrdíš, že se změnila včera, Google ti přestane věřit. Nepřesný lastmod je horší než žádný. Buď ho generuj z reálné změny obsahu, nebo ho vynech.

Search Console: jediný pohled Googlovýma očima

Žádný externí nástroj ti neřekne, co Google s tvými stránkami doopravdy udělal. Search Console ano, je to jediný pohled očima Googlu.

URL Inspection ukáže crawl, index a serving stav konkrétní URL přímo z indexu. Pozor na past, do které skoro každý jednou spadne. Tlačítko Live Test neověří, že jsi zaindexovaný. Ověří jen, že Google stránku umí stáhnout právě teď. Zelený live test ≠ v indexu. Index status je z posledního crawlu, live test je aktuální dostupnost. To jsou dvě různé odpovědi. Žádný test nezaručí, že stránka v indexu skončí.

Page Indexing report (dřív Coverage) ukazuje stavy jako „Crawled – currently not indexed" nebo „Discovered – not indexed". To je diagnóza: Google stránku zná, ale nezařadil ji. Pro hromadnou kontrolu existuje URL Inspection API s limity 2 000 dotazů/den a 600/min na property.

A Performance report je tvůj výchozí stav organické návštěvnosti, kliky a imprese podle dotazu a stránky. Search Console ukládá data posledních 16 měsíců, takže před zásahem (redesign, migrace) exportuj srovnání „odkud jsme vyšli". Tahle výchozí organická návštěvnost je vstup do discovery a do měřicího plánu analytiky. Core Web Vitals mají v Search Console vlastní report: výkon a nalezitelnost nejsou totéž, ale Google je oba vyhodnocuje z terénních dat.

Když se to nasčítá: jak vypadá kolaps

Velký propad organiky málokdy způsobí jediná chyba. Častěji se nasčítá několik rozporů. Nedokončená migrace nechá starou i novou doménu současně crawlable. Soft 404 vrací status 200, ale stránka je prázdná. Automaticky generované parametry vyrábějí tisíce slabých URL. Canonical ukazuje jedním směrem, interní odkazy druhým. Search Console pak plní stavy typu „Crawled – currently not indexed" a tým se diví, proč Google „nebere" obsah, který mu sám rozbil na šum.

Druhý typický scénář je banálnější a o to bolestivější: staging carry-over. Z testovacího prostředí se do produkce protáhne Disallow: / v robots.txt nebo zděděný noindex v šabloně, a web se deindexuje. Proto se politika přesměrování a kontrola robots/noindex ověřuje při redesignu i spuštění a migraci přes URL Inspection, ne až podle propadu návštěvnosti.

Praktický checklist

• Kritický title, canonical, meta robots a hlavní obsah jsou v HTML první odpovědi.
• Crawl a index jsou oddělené: noindex na to, co nemá být ve výsledcích, robots.txt na to, co se nemá crawlovat.
• Citlivý obsah chrání přihlášení, oprávnění nebo 404/410, ne robots.txt.
• Canonical jede víc kanály konzistentně: tag, sitemapa, interní odkazy i 301 míří na stejnou URL.
• Sitemapa je do 50 000 URL / 50 MB na soubor, bez priority a changefreq, lastmod jen když je přesný.
• hreflang má vzájemné odkazy, self-reference a případně x-default.
• Strukturovaná data jsou validovaná Rich Results Testem, bez očekávání lepších pozic.
• Facety mají crawl kontroly, ne volné generování URL.
• Search Console je propojená a data z Performance se exportují před každým zásahem.

Typické chyby

• Blokace v robots místo noindexu. Blokovaná stránka zůstane v indexu přes odkazy a Google na ní noindex nikdy nepřečte.
• SEO signály jen po klientském JavaScriptu. Google musí čekat na render a kritický obsah se může ztratit.
• Nekonzistentní canonical. Tag míří jinam než interní odkazy a sitemapa; v rozporu rozhodne Google.
• Sitemapa plná priority/changefreq a lhavého lastmod. První dvě Google ignoruje, u třetího přestane věřit.
• hreflang bez return linků. Celý cluster se ignoruje.
• „Zelený live test = jsme zaindexovaní." Live test ověří jen dostupnost pro crawl, ne zařazení do indexu.

Před spuštěním: SEO checklist

Než web pustíš ven, projdi tohle:

• robots.txt nepouští Disallow: / (klasický pozůstatek ze stagingu) a nezakazuje důležité sekce.
• Kanonické URL míří na produkční verzi, ne na staging nebo duplicitu.
• Sitemapa existuje, je aktuální a odeslaná do Search Console.
• Přesměrování ze starých URL jedou jako 301 na úrovni serveru. Mapu provádí redesign a spuštění a migrace.
• hreflang je vzájemný, ale jen pokud je web vícejazyčný.
• Strukturovaná data projdou Rich Results Testem, pokud je používáš.
• Title, meta description a canonical jsou vyplněné. Jsou to pole obsahového modelu.
• Po spuštění: URL Inspection v Search Console na klíčových stránkách a odeslaná sitemapa.