XML sitemapa prakticky: co do ní patří a co ne
Do XML sitemapy patří jen finální adresy: stav 200, kanonická verze sebe sama, žádný noindex. Nic dalšího tam nemá co dělat. Přesměrování, stránkování, filtrované výpisy a zakázané adresy udělají ze souboru seznam, kterému robot postupně přestane věřit. Z nepovinných údajů uvnitř navíc Google pracuje jedině s lastmod, a i to jen za jedné podmínky.
Do sitemapy patří jen to, co chcete mít v indexu
Sitemapa není mapa webu pro návštěvníka ani inventura všeho, co server umí vrátit. Je to váš návrh seznamu adres k zaindexování. Robot ho bere jako doporučení a podle jeho kvality si dělá obrázek, jestli má smysl soubor otevírat i příště.
Do sitemapy patří:
- adresy se stavem
200 OK, ne 301, ne 404, ne 500, - jen kanonické verze adres, tedy ty, které samy na sebe odkazují v tagu canonical,
- stránky bez direktivy noindex,
- adresy v jednom tvaru: HTTPS, jedna doména (s www, nebo bez, ne obojí), stejné řešení koncového lomítka jako na webu,
- absolutní adresy včetně protokolu, relativní zápis XML sitemapa nezná.
Do sitemapy nepatří:
- cokoliv, co se přesměrovává trvale nebo dočasně, i kdyby cílová stránka byla naprosto v pořádku,
- stránky s noindexem, protože posíláte vnitřně rozporný pokyn ve smyslu „zaindexuj tohle, ale neindexuj to“,
- adresy zakázané v robots.txt, robot je nesmí načíst, takže z nich máte jen chybové hlášení v Search Console,
- druhé a další strany stránkování typu
/blog/page/7/, - filtrované a řazené výpisy s parametry
?barva=cerna&razeni=cena, klasická past e-shopů, - vyhledávání na webu, košík, pokladna, přihlášení, děkovací stránky,
- přílohové stránky obrázků, které WordPress dodnes umí generovat.
Jedna výjimka existuje. Adresy s noindexem do sitemapy dejte tehdy, když potřebujete, aby si robot toho noindexu rychle všiml a stránky z indexu vyhodil. Je to dočasný krok na pár týdnů, ne trvalý stav.
A jedno upřesnění, protože se to na e-shopech plete pravidelně: XML feed pro Heureku nebo Zboží.cz nemá se sitemapou nic společného. Jiný formát, jiný příjemce, jiný účel. Do Search Console ho neposílejte.
Proč Google ignoruje priority a changefreq?
Protože si obě hodnoty nastavuje majitel webu sám a prakticky každý si tam dal to nejvyšší číslo. Google to má v dokumentaci k sitemapám napsané otevřeně: značky <priority> a <changefreq> ignoruje. Pokud tedy hledáte, čím si přilepšit, tudy cesta nevede.
Přesto je skoro každý generátor pořád vypisuje. Škodí to? Samo o sobě ne, jen to nafukuje soubor. U katalogu se 40 000 adresami ušetříte odstraněním obou řádků zhruba 2 až 3 MB, což se hodí ve chvíli, kdy se blížíte limitu velikosti. Jiný efekt bych od toho nečekal.
U Seznamu si troufám tvrdit míň. Veřejná dokumentace SeznamBota o práci s prioritou nic konkrétního neříká, takže nevím, jestli s ní počítá. Chovám se k tomu stejně jako u Googlu a zatím jsem nezaznamenal, že by to někde vadilo.
Jak nastavit lastmod, aby s ním robot počítal
Lastmod je jediný nepovinný údaj, se kterým Google podle vlastního vyjádření pracuje. Ovšem jen tehdy, když je „konzistentně a ověřitelně přesný“. Ta podmínka není formalita. Když robot dorazí na stránku s dnešním datem změny a najde přesně to, co viděl v únoru, přestane údaj brát vážně. A to na celém webu, ne u té jedné adresy.
V praxi z toho plyne pár pravidel:
- datum měňte při skutečné úpravě hlavního obsahu, ne když opravíte překlep v patičce nebo přepíšete rok v copyrightu,
- formát dodržte podle W3C: buď
2026-08-04, nebo2026-08-04T09:12:00+02:00, čas s posunem je přesnější, - nikdy nedávejte do lastmodu čas generování souboru, což dělá kdejaký doplněk i kdejaká vlastní implementace,
- u e-shopů si pohlídejte noční přepočet skladu, ten posune datum u všech produktů naráz a údaj je rázem bezcenný.
Tohle je mimochodem nejčastější věc, kterou u klientů opravuji. Přijde e-shop s 15 000 produkty, všechny mají lastmod ze včerejška, protože se v noci přepsal příznak dostupnosti, a majitel se diví, že nové položky visí neindexované celé týdny. Když se datum přestane hýbat u všeho a začne se hýbat jen u reálných změn, bývá to za pár týdnů znát. Zázraky nečekejte. U velkých katalogů to ale pomáhá.
Kolik adres se vejde do jedné sitemapy?
Padesát tisíc adres a 50 MB nekomprimovaně na jeden soubor. Tak zní hranice protokolu sitemaps.org a drží se jich Google i ostatní vyhledávače. Pod nimi si každý doplněk nastavuje vlastní limit, obvykle mnohem nižší.
| Co | Hodnota | Poznámka |
|---|---|---|
| Adres v jednom souboru | 50 000 | tvrdý limit protokolu |
| Velikost souboru | 50 MB | 52 428 800 bajtů, měří se nekomprimovaná velikost |
| Sitemap v index souboru | 50 000 | index smí mít také do 50 MB |
| WordPress jádro | 2 000 na soubor | filtr wp_sitemaps_max_urls |
| Yoast SEO | 1 000 na soubor | výchozí hodnota |
| Rank Math | 200 na soubor | výchozí, dá se zvednout v nastavení |
Komprese gzipem je povolená a u velkých katalogů se vyplatí, jenže limit 50 MB se počítá až po rozbalení. Jakmile překročíte kteroukoliv hranici, rozdělte sitemapu na víc souborů a udělejte index sitemap, tedy soubor, který odkazuje na ostatní. Do Search Console pak posíláte jen ten index.
wp-sitemap.xml, Yoast, nebo Rank Math?
WordPress umí od verze 5.5 (srpen 2020) vlastní sitemapu na adrese /wp-sitemap.xml. Jako základ zdarma slouží slušně, má ale dvě mouchy: přidává archivy autorů, což na jednoautorském blogu vyrobí duplicitu s výpisem článků, a neumí lastmod. Bez lastmodu přicházíte o jediný údaj, který má prokazatelnou váhu.
Yoast i Rank Math jádrovou sitemapu automaticky vypnou a nasadí vlastní, oba na adrese /sitemap_index.xml. Oba respektují noindex a oba umí lastmod. Rozdíl je hlavně v drobnostech: Rank Math dělí ve výchozím nastavení po 200 adresách, což u většího blogu nadělá desítky souborů, a já to obvykle zvedám na 1 000 až 2 000. Yoast má naopak méně přehledné vyřazování jednotlivých typů obsahu.
Co dělám skoro pokaždé: vypnu sitemapu pro archivy autorů, pro přílohy a pro štítky, pokud se s nimi na webu reálně nepracuje. U e-shopů na Shoptetu nebo Upgates se sitemapa generuje automaticky a její obsah moc neovlivníte. Tam se soustřeďte spíš na to, aby vám platforma necpala filtrované adresy do interního prolinkování. Detaily se u obou platforem občas mění, takže si aktuální možnosti raději ověřte v administraci.
Řádek v robots.txt nestačí, sitemapu ohlaste i ručně
Do souboru robots.txt patří řádek s absolutní adresou sitemapy. Řádků může být víc, na pořadí nezáleží a na velikosti písmen v direktivě také ne:
Sitemap: https://www.vasedomena.cz/sitemap_index.xml
Přečte si ho Google, Seznam i většina ostatních robotů. Nedozvíte se z něj ale nic o tom, kolik adres bylo objeveno a kolik zaindexováno, a přesně to chcete v Search Console vidět. Sitemapu tam přidáte v sekci Sitemapy, vyplníte cestu za doménou a odešlete. Zpracování bývá do 24 hodin, u velkých souborů i déle. Starý pingovací endpoint google.com/ping?sitemap= Google v roce 2023 zrušil, takže jestli ho máte někde v cronu, klidně ho vyhoďte.
U Seznamu jděte do Správce webu na webmaster.seznam.cz, ověřte web a přidejte sitemapu v příslušné sekci. Seznam navíc podporuje protokol IndexNow, kterým hlásíte jednotlivé změněné adresy okamžitě. Sitemapu to nenahrazuje, dělá něco jiného, ale na webech s častými změnami se to vyplatí. Víc o tom, čím se český vyhledávač liší, píšu v článku o optimalizaci pro Seznam.cz.
Jak poznáte, že máte sitemapu zaneřáděnou?
Nejrychlejší kontrola zabere tři minuty. Otevřete sitemapu v prohlížeči a podívejte se na počet adres. Pak ho porovnejte s tím, kolik stránek na webu opravdu máte. Když má firemní web třicet stránek a sitemapa hlásí 480 adres, je uvnitř něco, co tam nepatří.
Další signály:
- v Search Console sedí „Objeveno“ vysoko nad „Zaindexováno“ a v přehledu indexace přibývá důvod „Stránka s přesměrováním“ nebo „Alternativní stránka s kanonickým tagem“,
- v sitemapě najdete adresy s otazníkem a parametry,
- všechny adresy mají stejný lastmod,
- sitemapa obsahuje HTTP verze, i když web běží na HTTPS,
- report u odeslané sitemapy hlásí chybu při čtení nebo nulový počet objevených adres.
Pokud chcete tvrdá čísla, nahrajte adresy ze sitemapy do crawleru v režimu seznamu a projděte stavové kódy. Zdravá sitemapa má přes 99 % adres se stavem 200. Pod 95 % už je co opravovat. Základní přehled o tom, co v sitemapě vázne, dá i bezplatná SEO kontrola webu, která vedle sitemapy prověří robots.txt a kanonické adresy.
Poslední poznámka z praxe. Sitemapa indexaci nezaručí. Je to nabídka, ne objednávka. Když se stránky neindexují a sitemapa je přitom čistá, problém leží jinde: v kvalitě obsahu, v interním prolinkování nebo v tom, že o web nikdo nestojí. Opravte ji, ale nečekejte od ní víc, než umí.
Časté dotazy
Musím mít XML sitemapu, když má web jen třicet stránek?
Nemusíte. Malý web s funkčním interním prolinkováním roboti projdou i bez ní. Hodí se ale jako kontrolní nástroj, protože v Search Console uvidíte poměr objevených a zaindexovaných adres. Nasazení zabere pár minut, takže není důvod ji vynechávat.
Patří do sitemapy stránkování typu /blog/page/2/?
Nepatří. Druhé a další strany výpisu jsou navigační stránky bez vlastní hodnoty pro vyhledávání, do sitemapy dávejte konkrétní články a produkty. Ke stránkování se robot dostane odkazy z první strany. Výjimkou jsou weby, kde se hlubší strany výpisu procházejí špatně, tam stránkování v sitemapě dočasně pomůže obsah objevit.
Jak často mám sitemapu odesílat znovu do Search Console?
Stačí jednou. Google si adresu sitemapy pamatuje a stahuje ji sám, obvykle v řádu hodin až dnů podle toho, jak často se web mění. Opakované odesílání proces nezrychlí. Znovu ji odešlete jen tehdy, když změníte adresu souboru nebo když report hlásí chybu při čtení.
Související návody
JavaScript a SEO: kdy robot obsah uvidí a kdy ne
Google JavaScript spustí, ale s odkladem a ne vždycky. Seznam s ním pracuje omezeně. Obsah, na kterém závisí návštěvnost, patří do HTML.
Stránkování výpisů: jak ho udělat, aby se produkty indexovaly
Druhá a další strana výpisu je jediná cesta, kudy se robot dostane k produktům na konci. Většina chyb ve stránkování je proto přeindexováním naopak.
Stavové kódy HTTP: co který znamená pro vyhledávač
Kód odpovědi je první věc, kterou robot uvidí. Rozhoduje, jestli stránku vůbec zpracuje a jestli si má pamatovat starou adresu.
Pojmy z tohoto textu
- JSON-LD Formát zápisu strukturovaných dat. Vkládá se jako samostatný blok a nemíchá se do značek obsahu.
- llms.txt Textový soubor v kořeni webu, který jazykovým modelům shrnuje, co na webu je a kde to najdou.
- Duplicitní obsah Tentýž nebo velmi podobný text na víc adresách. Není to postih, ale vyhledávač si vybere jednu verzi a ostatní potlačí.
- Smíšený obsah Stav, kdy se stránka načte přes HTTPS, ale některé její části se stahují přes nešifrované HTTP.
- Míra prokliku Podíl lidí, kteří na výsledek klikli, ze všech, kterým se zobrazil. Nejrychlejší páka, jak přivést víc návštěv bez změny pozice.
- Dlouhý chvost Velké množství dotazů s malou hledaností, které dohromady tvoří většinu návštěv z vyhledávání.
Nevíte, jestli se vás to týká?
Pusťte kontrolu na svůj web a uvidíte, jestli tenhle problém máte. Trvá to necelou minutu.