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.

hreflang potřebuje vzájemné odkazy

Vícejazyčný web říká hreflang anotacemi „tahle stránka má českou a anglickou verzi". Pravidlo, na kterém to nejčastěji padá: odkazy musí být vzájemné. Když česká verze ukazuje na anglickou, ale anglická neukazuje zpátky, Google anotaci ignoruje. Důvod je obranný: jinak by si cizí web mohl nárokovat, že je tvoje alternativa.

Hreflang tedy není seznam přání, ale konzistentní graf. Každá jazyková verze má uvést sebe i ostatní relevantní verze. Pro jazykový rozcestník nebo výchozí variantu je tu x-default. Která jazyková verze vlastně existuje a jak se trh dělí, je rozhodnutí informační architektury; hreflang ho jen technicky zapojí.

Structured data: způsobilost, ne ranking

JSON-LD strukturovaná data popisují stroji, co stránka je. Recept, produkt, článek, událost. Dělají ji způsobilou pro rich results, tedy rozšířené výsledky s hvězdičkami, cenou, obrázkem nebo dalšími prvky. Nezaručují je. Validní schéma neznamená, že Google rich result opravdu ukáže.

A dvě věci se kolem schématu pořád pletou. Strukturovaná data nejsou zkratka k lepší pozici a zneužití schématu se může vrátit jako ztráta způsobilosti pro rich results. Google doporučuje JSON-LD, protože se dobře udržuje, a validaci přes Rich Results Test.

Crawl budget se utratí za smetí

Crawl budget je crawl capacity (kolik Google unese, aby nepřetížil server) krát crawl demand (jak moc o web stojí). Problém není, že by byl malý, ale když crawler chodí na stránky, které za to nestojí.

Nejčastější žrout, který Google v téhle souvislosti řeší, je faceted navigation. Každá kombinace filtrů je nová URL, a pár filtrů s více hodnotami vyrobí prakticky nekonečno adres, drtivou většinou prázdných nebo skoro stejných. Crawler na nich utratí rozpočet dřív, než dojde na hodnotný obsah. Facety bez dobrého nastavení umí spolykat většinu crawl budgetu.

Co s tím? Kombinace, které nikdy nemají být crawlované, blokuj v robots.txt nebo nevytvářej jako odkazy. Tady blokace crawlu dává smysl, protože šetří rozpočet. U URL, které už jsou v indexu a chceš je odstranit, nejdřív potřebuješ crawl s noindex, 404/410 nebo jiný jasný signál. Filtry, které crawlovat chceš, drž v čistém tvaru: standardní & jako oddělovač, konzistentní pořadí parametrů, prázdné kombinace jako 404.

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.

Zdroje

• Google Search Central — How Search Works a JavaScript SEO basics (crawl/index/serving, render ve Web Rendering Service).
• Google Search Central — robots.txt intro a block-indexing (robots ≠ noindex, paradox blokace).
• Google Search Central — canonicalization a consolidate duplicate URLs (canonical jako hint, sčítání signálů).
• Google Search Central — build sitemap (50 000 URL / 50 MB, ignorovaný priority/changefreq, lastmod jen když přesný).
• Google Search Central — localized versions + x-default hreflang (return linky povinné).
• Google Search Central — structured data intro a policies (eligibility, ne ranking; JSON-LD; Rich Results Test).
• Google Search Central — faceted navigation a crawl budget (capacity + demand, facety jako hlavní žrout).
• Search Console Help — Performance report a URL Inspection (index vs. live test), Page Indexing report, Core Web Vitals report; data se uchovávají 16 měsíců; webmaster-tools limits (2 000/den, 600/min).

Tahle kapitola naplňuje sliby, na které odkazuje zbytek wiki. Pojmy definuje slovník, strukturu rozhoduje informační architektura a SEO ji udrží průchodnou pro stroje. Render závisí na volbě renderování, title/canonical jsou pole obsahového modelu, alt text patří médiím a podkladům. Sémantické nadpisy a alt text jsou sdílený signál s přístupností: co čte čtečka, čte i Googlebot. Terénní data sdílí s Core Web Vitals, kontroluje se při redesignu a spuštění, Performance report je výchozí stav pro discovery i analytiku.