Google věřil mapě stránek, ne chybě 404

Věděli jste, že k odstranění stránky z Googlu nemusí 404 stačit?

Na jednom velkém webu, na kterém jsem pracoval, jsme zrušili celou sekci. Všechny její URL adresy vracely 404. Záměrně, poctivě, hotovo.

Kvůli technické chybě v enterprise CMS však zůstaly všechny smazané URL adresy v XML mapě stránek ještě pár týdnů.

Zobrazení a kliknutí sekce klesla zhruba na polovinu. A tam se zastavila. V Googlu tak pořád zůstávala polovina jejich viditelnosti. Stránky se dál zobrazovaly a lidé na ně dál klikali. A končili rovnou na 404ce.

Pak mapu stránek opravili. Zobrazení i kliknutí sekce vzápětí spadla téměř na nulu.

Pořád stejné 404. Změnila se jen mapa stránek.

Chyba 404 vypadá jako náhoda. Mapa stránek jako záměr

Podívejte se na to z pohledu Googlu.

Aby Google 404 viděl, musí URL adresu znovu navštívit. Na velkém webu se to nestane u všech URL adres ve stejný den.

A stránky vracejí 404 omylem často. Nepovede se nasazení. Rozbije se routing. CDN hodinu vrací chybovou stránku.

Mapa stránek je pravý opak. Je to soubor, který někdo vědomě udržuje. Ten soubor říká: tyhle URL adresy existují, jsou důležité, zaindexujte je prosím.

Teď si představte oba signály u stejné URL adresy. Stránka tvrdí, že už neexistuje. Mapa stránek tvrdí, že je důležitá. Který z nich vypadá jako omyl?

Zvenku ta 404. Já to vidím tak, že Google dál věřil mapě stránek a URL adresy zůstaly v indexu déle, než měly.

Do Googlu nevidím. Když ale mapu stránek opravili, nic jiného se na webu nezměnilo a propad přišel hned potom.

Smazané URL adresy v mapě stránek propad zpomalily

V SEO už léta koluje jedna rada. Když stránky smažete, nechte je ještě nějakou dobu v mapě stránek, ideálně s novým datem v lastmod, aby je Google prošel dřív a 404 zpracoval rychleji.

Na papíře to dává smysl. Na tomhle webu to fungovalo přesně naopak.

To, že URL adresy zůstaly v mapě stránek, nic neurychlilo. Propad to jen zpomalilo. Až jejich odstranění poslalo sekci téměř na nulu.

Je to jeden web, ne kontrolovaný experiment. Skutečné srovnání před a po mi ale řekne víc než teorie. Zrušená stránka musí z mapy stránek zmizet ve stejném nasazení. Ne v dalším sprintu. Ne „až Google uvidí tu 404“.

Co vás stojí napůl smazaná sekce

Těch pár týdnů nebyla sekce vidět jako produkt, jen jako chyba.

Lidé něco hledali, viděli výsledek, klikli, skončili na 404 a vrátili se do Googlu. Odtud nejspíš ke konkurenci. Horší kombinace neexistuje – stránku už jste ztratili, a stejně kvůli ní dál ztrácíte důvěru lidí.

Protichůdné signály dostává i Googlebot. Pokaždé, když mapa stránek znovu nabídne mrtvou URL adresu, dává Googlu důvod vrátit se k ní místo ke stránce, kterou v indexu opravdu chcete.

A v datech vám přibude šum. Přehled „Page indexing“ v Search Console se zaplní chybami 404, které jste Googlu sami odeslali. Skutečné problémy mezi nimi zapadnou.

Nejhorší je, že se na vygenerovanou mapu stránek už nikdo nepodívá. Stejná chyba se tak opakuje při každém odstraňování stránek.

Držte každý soubor mapy stránek pod 10–15 MB

Mapy stránek se potichu rozbíjejí nejen při odstraňování stránek. Druhá věc, na kterou na enterprise webech pořád narážím, je velikost.

Oficiální limit Googlu je 50 MB v nekomprimované podobě nebo 50 000 URL adres na soubor. Na papíře je tedy všechno pod tím v pořádku.

V praxi to tak není. Na několika dalších enterprise webech jsem řešil problémy s mapami stránek těsně pod limitem. Když se soubor přiblíží ke 45 MB, Google ho většinou nedokáže spolehlivě načíst. Soubory přečte jen zčásti nebo je přeskočí a vy pak hádáte, které URL adresy Google vlastně viděl.

Moje pravidlo je mnohem přísnější. Držte každý soubor mapy stránek pod 10–15 MB v nekomprimované podobě. Větší soubory rozdělte pomocí indexu map stránek a nic tím neztratíte.

Háček je v tom, že mapy stránek nezůstávají stejně velké. Každý nový produkt a každá nová jazyková verze mapy trochu zvětší a nikdo to nekontroluje, dokud se něco nerozbije. Proto to hlídám vlastním nástrojem – VitalSentinel, který monitoruje mapy stránek, takže rostoucí soubor vidím dávno předtím, než ho Google přestane načítat.

Komprese vás tu nezachrání. Když mapu stránek o velikosti 45 MB zkomprimujete gzipem, při přenosu se zmenší na pár megabajtů. Limit se ale počítá z nekomprimované velikosti. Gzip zrychlí přenos. Na tom, co musí Google zpracovat, nic nemění.

Nejvíc soubory nafukuje hreflang. Každá URL adresa má v mapě jeden řádek alternate pro každou jazykovou verzi:

<url>
  <loc>https://www.example.com/de-de/products/whey-protein-1kg/</loc>
  <xhtml:link rel="alternate" hreflang="de-DE" href="https://www.example.com/de-de/products/whey-protein-1kg/"/>
  <xhtml:link rel="alternate" hreflang="de-AT" href="https://www.example.com/de-at/products/whey-protein-1kg/"/>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://www.example.com/fr-fr/products/whey-protein-1kg/"/>
  <!-- ...jeden řádek pro každou jazykovou verzi -->
</url>

Každý takový řádek má zhruba 110 bajtů. Při dvaceti jazykových verzích zabere jedna URL adresa víc než 2 KB. Do souboru o 10 MB se tak vejde jen asi 4 000–5 000 URL adres.

V takovém případě narazíte i na oficiální limit 50 MB už zhruba u 21 000 URL adres. Ke stropu 50 000 URL adres se vůbec nedostanete. Limit velikosti vás zastaví dřív a většinou si toho ani nevšimnete.

Já hreflang radši přesouvám do headu. Google podporuje všechny tři způsoby – v HTML, v HTTP hlavičkách i v mapě stránek – rovnocenně. V headu jsou anotace přímo na stránce, kterou popisují, a mapa stránek bude opět jen seznamem URL adres. Každá stránka bude o pár KB větší. Mapa stránek se zmenší o víc než 90 %.

Hlavně si vyberte jeden způsob. Hreflang v headu i v mapě stránek znamená dva zdroje, které si dřív nebo později začnou odporovat.

Když mapu stránek odeberete, Google na ni hned nezapomene

Odebráním v Google Search Console zmizí mapa stránek jen z přehledu „Sitemaps“. Google tím ten soubor stahovat nepřestane. Jeho URL adresu už zná a nějakou dobu ji ještě bude používat.

Nejčastěji to bývají staré mapy stránek po migraci. Nikdo si na ně nepamatuje, ale pořád obsahují URL adresy ze struktury, která už neexistuje.

Pokud mapu stránek rušíte, zrušte ji doopravdy. Samotný soubor musí vracet 404 nebo 410. Odkaz na něj smažte z robots.txt i ze všech indexů map stránek. Teprve potom mapu odeberte v Search Console.

Jak teď stránky odstraňuji

Natrvalo zrušená stránka vrací 410, ne 404. Kód 404 znamená „nenalezeno“ – stránka se zítra může vrátit. Kód 410 znamená „trvale odstraněno“ a Google ho obvykle zpracuje o něco rychleji. Ať vracíte kterýkoli, musí to tak zůstat.

URL adresa zmizí z mapy stránek ve stejném nasazení. Pokud CMS generuje mapy stránek pravidelně nebo je cachuje, patří přegenerování i promazání cache k odstranění stránky. Neřeší se to až dodatečně.

Pryč musí i interní odkazy. Menu, související produkty, odkazy v patičce. Dokud na URL adresu odkazuje váš vlastní web, Googlebot ji bude dál vidět.

Přesměrujte jen tehdy, když existuje skutečně rovnocenná stránka. Ne na domovskou stránku, ne na nadřazenou kategorii „pro jistotu“.

Pak kontrolujte výsledek, ne proces. Po nasazení si stáhněte produkční mapu stránek a ověřte, že v ní žádná z odstraněných URL adres není. Nakonec sledujte jejich indexaci, dokud z indexu opravdu nevypadnou, ne do příštího auditu.

Na webu, o kterém jsem psal, šlo v těch pár týdnech o chybu CMS, ne o rozhodnutí. Právě proto patří úklid mapy stránek do procesu odstraňování od prvního dne, ne do tiketu někdy potom.

Kód 404 Googlu říká, že stránka zmizela. Jestli tomu Google uvěří, rozhoduje vaše mapa stránek.