Prejsť na hlavný obsah
TechSEO Vitals

Google veril mape stránok, nie chybe 404

Celá sekcia webu vracala 404, a predsa v Googli zostala polovica jej viditeľnosti. Zmizla až po oprave mapy stránok – samotné chyby 404 na to nestačili.

Zdieľať na

Vedeli ste, že na odstránenie stránky z Googlu nemusí 404 stačiť?

Na jednom veľkom webe, pre ktorý som pracoval, sme zrušili celú sekciu. Všetky jej URL adresy vracali 404. Zámerne, poriadne, hotovo.

Pre technickú chybu v enterprise CMS však zostali v XML mape stránok všetky zmazané URL adresy ešte pár týždňov.

Zobrazenia a kliknutia sekcie klesli zhruba na polovicu. A tam sa zastavili. V Googli tak stále zostávala polovica ich viditeľnosti. Stránky sa ďalej zobrazovali a ľudia na ne ďalej klikali. A končili rovno na 404ke.

Potom mapu stránok opravili. Zobrazenia aj kliknutia sekcie vzápätí spadli takmer na nulu.

Stále tie isté 404. Zmenila sa len mapa stránok.

Chyba 404 vyzerá ako náhoda. Mapa stránok ako zámer

Pozrite sa na to z pohľadu Googlu.

Aby Google 404 videl, musí URL adresu znova navštíviť. Na veľkom webe sa to nedeje pri všetkých URL adresách v ten istý deň.

A stránky vracajú 404 omylom často. Nepodarí sa nasadenie. Rozbije sa routing. CDN hodinu vracia chybovú stránku.

Mapa stránok je pravý opak. Je to súbor, ktorý niekto vedome udržiava. Ten súbor hovorí: tieto URL adresy existujú, sú dôležité, zaindexujte ich, prosím.

A teraz si predstavte oba signály na tej istej URL adrese. Stránka tvrdí, že už neexistuje. Mapa stránok tvrdí, že je dôležitá. Ktorý z nich vyzerá ako omyl?

Zvonku tá 404. Ja to vidím tak, že Google ďalej veril mape stránok a URL adresy zostali v indexe dlhšie, než mali.

Do Googlu nevidím. Keď však mapu stránok opravili, nič iné sa na webe nezmenilo a prepad prišiel hneď potom.

Zmazané URL adresy v mape stránok prepad spomalili

V SEO už roky koluje jedna rada. Keď stránky zmažete, nechajte ich ešte nejaký čas v mape stránok, ideálne s novým dátumom v lastmod, aby ich Google prešiel skôr a 404 spracoval rýchlejšie.

Na papieri to dáva zmysel. Na tomto webe to fungovalo presne naopak.

To, že URL adresy zostali v mape stránok, nič neurýchlilo. Prepad to len spomalilo. Až ich odstránenie poslalo sekciu takmer na nulu.

Je to jeden web, nie kontrolovaný experiment. Skutočné porovnanie pred a po mi však povie viac než teória. Keď stránku zrušíte, z mapy stránok musí zmiznúť v tom istom nasadení. Nie v ďalšom sprinte. Nie „až keď Google uvidí tú 404“.

Čo vás stojí napoly zmazaná sekcia

Tých pár týždňov bola sekcia ako produkt neviditeľná a ako chyba viditeľná.

Ľudia niečo hľadali, videli výsledok, klikli, skončili na 404 a vrátili sa do Googlu. Odtiaľ zrejme rovno ku konkurencii. Horšia kombinácia neexistuje – stránku ste už stratili, a aj tak kvôli nej ďalej strácate dôveru ľudí.

Protichodné signály dostáva aj Googlebot. Zakaždým, keď mapa stránok znova ponúkne mŕtvu URL adresu, dáva Googlu dôvod vrátiť sa k nej namiesto stránky, ktorú v indexe naozaj chcete.

A v dátach vám pribudne šum. Prehľad „Page indexing“ v Search Console sa zaplní chybami 404, ktoré ste Googlu odoslali sami. Skutočné problémy medzi nimi zapadnú.

Najhoršie je, že sa na vygenerovanú mapu stránok už nikto nepozrie. Tá istá chyba sa tak opakuje pri každom odstraňovaní stránok.

Držte každý súbor mapy stránok pod 10 – 15 MB

Mapy stránok sa potichu rozbíjajú nielen pri odstraňovaní stránok. Druhá vec, na ktorú pri enterprise weboch neustále narážam, je veľkosť.

Oficiálny limit Googlu je 50 MB v nekomprimovanej podobe alebo 50 000 URL adries na súbor. Na papieri je teda všetko pod tým v poriadku.

V praxi to tak nie je. Na viacerých ďalších enterprise weboch som riešil problémy s mapami stránok tesne pod limitom. Keď sa súbor priblíži k 45 MB, Google ho väčšinou nedokáže spoľahlivo načítať. Súbory prečíta len čiastočne alebo ich preskočí a vy potom hádate, ktoré URL adresy Google vlastne videl.

Moje pravidlo je oveľa prísnejšie. Držte každý súbor mapy stránok pod 10 – 15 MB v nekomprimovanej podobe. Väčšie mapy rozdeľte pomocou indexovej mapy stránok a nič tým nestratíte.

Háčik je v tom, že mapy stránok nezostávajú rovnako veľké. Každý nový produkt a každá nová jazyková verzia ich trochu zväčší a nikto to nekontroluje, kým sa niečo nerozbije. Preto to strážim cez vlastný nástroj – VitalSentinel, ktorý monitoruje mapy stránok, takže rastúci súbor vidím dávno predtým, než ho Google prestane načítavať.

Kompresia vás tu nezachráni. Keď mapu stránok s veľkosťou 45 MB skomprimujete gzipom, pri prenose sa zmenší na pár megabajtov. Limit sa však vzťahuje na nekomprimovaný súbor. Gzip zrýchli prenos. Na tom, čo musí Google spracovať, nič nemení.

Najviac súbory nafukuje hreflang. Pri každej URL adrese je jeden riadok s odkazom alternate pre každú jazykovú verziu:

<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 riadok pre každú jazykovú verziu -->
</url>

Každý taký riadok má zhruba 110 bajtov. Pri dvadsiatich jazykových verziách tak jedna URL adresa zaberie viac než 2 KB. Do súboru s veľkosťou 10 MB sa zmestí len asi 4 000 – 5 000 URL adries.

V takom prípade narazíte aj na oficiálny limit 50 MB už zhruba pri 21 000 URL adresách. K stropu 50 000 URL adries sa vôbec nedostanete. Problém s veľkosťou príde skôr a väčšinou si ho ani nevšimnete.

Ja hreflang radšej presúvam do headu. Google podporuje všetky tri spôsoby – v HTML, v HTTP hlavičkách aj v mape stránok – rovnocenne. V heade sú anotácie priamo na stránke, ktorú opisujú, a mapa stránok bude opäť len zoznamom URL adries. Každá stránka bude o pár KB väčšia. Mapa stránok sa zmenší o viac než 90 %.

Hlavne si vyberte jeden spôsob. Hreflang v heade aj v mape stránok znamená dva zdroje, ktoré si skôr či neskôr začnú odporovať.

Keď mapu stránok odstránite, Google na ňu hneď nezabudne

V Google Search Console ju tým odstránite len z prehľadu „Sitemaps“. Google tým neprestane ten súbor sťahovať. Jeho URL adresu už pozná a ešte nejaký čas ju bude používať.

Najčastejšie to bývajú staré mapy stránok po migrácii. Nikto si na ne nepamätá, ale stále obsahujú URL adresy zo štruktúry, ktorá už neexistuje.

Ak mapu stránok rušíte, zrušte ju naozaj. Samotný súbor musí vracať 404 alebo 410. Odkaz naň vymažte z robots.txt aj zo všetkých indexových máp stránok. Až potom mapu odstráňte v Search Console.

Ako dnes odstraňujem stránky

Natrvalo zrušená stránka vracia 410, nie 404. Kód 404 znamená „nenájdené“ – stránka sa zajtra môže vrátiť. Kód 410 znamená „natrvalo odstránené“ a Google ho zvyčajne spracuje o niečo rýchlejšie. Nech vraciate ktorýkoľvek, musí to tak zostať.

URL adresa zmizne z mapy stránok v tom istom nasadení. Ak CMS generuje mapy stránok pravidelne alebo ich cachuje, pregenerovanie aj vymazanie cache patria k odstráneniu stránky. Nerieši sa to až dodatočne.

Preč musia aj interné odkazy. Menu, súvisiace produkty, odkazy v pätičke. Kým na URL adresu odkazuje váš vlastný web, Googlebot ju bude ďalej vidieť.

Presmerujte len vtedy, keď existuje naozaj rovnocenná stránka. Nie na domovskú stránku, nie na nadradenú kategóriu „pre istotu“.

Potom kontrolujte výsledok, nie proces. Po nasadení si stiahnite produkčnú mapu stránok a overte, že v nej nie je žiadna z odstránených URL adries. Nakoniec sledujte ich indexáciu, kým z indexu naozaj nevypadnú, nie do ďalšieho auditu.

Na webe, o ktorom som písal, išlo v tých pár týždňoch o chybu CMS, nie o rozhodnutie. Práve preto patrí upratanie mapy stránok do procesu odstraňovania od prvého dňa, nie do úlohy niekedy potom.

Kód 404 hovorí Googlu, že stránka zmizla. Či tomu Google uverí, rozhoduje vaša mapa stránok.

Pôvodná verzia tohto článku je anglická. Do slovenčiny je preložená automaticky.

Martin Štěpánek

Martin Štěpánek

Konzultant enterprise technického SEO

Som konzultant enterprise technického SEO a vývojár. Vyše desať rokov som web staval, až potom som ho začal opravovať, a produkčný kód píšem dodnes. Čítam odpovede, ktoré váš web naozaj posiela, poviem vám, ktoré nálezy stoja za sprint, a opravu odovzdám vašim vývojárom sám.

Každé dva týždne

Newsletter o technickom SEO, ktorý vývojári aj SEO špecialisti naozaj dočítajú

Jeden konkrétny problém rozoberiem do detailu a poviem jasne, čo s ním. Porovnám to s primárnou dokumentáciou aj s tým, čo vidím v auditoch. A k tomu tri správy z posledných dvoch týždňov, ktoré vyberiem a vysvetlím.

Mersudin ForbesMersudin ForbesMark Williams-CookMark Williams-CookAleyda SolisAleyda Solis
Odporúčajú ho lídri v odbore

Prihlásiť sa

Nové vydanie každé dva týždne. Odhlásenie jedným klikom.

Iba v angličtine

Prihlásením súhlasím so Zásadami ochrany osobných údajov a Obchodnými podmienkami.

Žiadny spam. Odhlásenie kedykoľvek jedným klikom.
Poznámky z technického SEO