Jak po migraci ověřit, že přesměrování fungují

Většinu škod při migraci nezpůsobí špatná strategie přesměrování. Způsobí je dobrá strategie, kterou po spuštění nikdo neověřil. Mapa přesměrování se sestaví, web se spustí a první skutečná kontrola přijde až o několik týdnů později při vyhodnocení návštěvnosti, kdy už je propad vidět v číslech. Řešením je postup naplánované průběžné kontroly, ne lepší tabulka.

Cover ilustrace k článku o kontrole přesměrování po migraci webu.

Mapa přesměrování je datová sada, ne dokument k odevzdání

Mapa přesměrování, která se sestaví v tabulce, předá vývojářům a už nikdy se neotevře, má jediný účel. Až něco selže, bude na koho ukázat. Mapa redirectů která skutečně funguje, je pevná datová sada s jasně definovanou strukturou, protože všechno navazující, tedy implementace, testování i ověření přesměrování po spuštění, se proti ní spouští automatizovaně.

Minimální sada sloupců je stará URL, nová URL, zamýšlený stavový kód, typ URL (produkt, kategorie, článek, filtr, média, ostatní) a příznak zdroje, který říká, odkud stará URL pochází. Ten poslední je důležitější, než vypadá. Inventuru starých URL je potřeba sestavit ze všech zdrojů, které o vašich URL vědí, protože každý z nich zná jinou podmnožinu.

  • Kompletní crawl současného webu ukáže, na co se dnes odkazuje.
  • Search Console ukáže, co má zobrazení, včetně URL, na které se už interně neodkazuje.
  • Analytika ukáže, přes které stránky lidé na web skutečně přicházejí.
  • Profil zpětných odkazů ukáže, kam míří jiné weby. Tyto URL nesou hodnotu bez ohledu na to, jestli se vám ještě líbí.
  • Serverové logy ukazují, o které URL Googlebot stále žádá, včetně URL, které jsou roky neaktivní.

Těchto pět seznamů spojte do jednoho. Zbavte ho duplicit a sjednoťte protokol, doménu, koncová lomítka a měřicí parametry (UTM), aby se stejná URL nezapsala třikrát v mírně jiné podobě. Teprve tenhle jeden seznam je skutečný rozsah migrace. Na většině webů je znatelně větší než export z CMS, se kterým projekt začínal, a ten rozdíl je přesně ta množina URL, které by tiše skončily na 404.

Rozhodnutí, co si který typ URL zaslouží

Ne každá stará URL si zaslouží přesměrování 1:1 a předstírat opak je způsob, jak mapy nabobtnají do neudržovatelných seznamů. Rozhodnutí je pro každý typ jednoduché.

Typ staré URLRozhodnutíProč
Má návštěvnost, odkazy nebo zobrazení a existuje ekvivalent301 na odpovídající stránkuZachová hodnotu i záměr uživatele
Má hodnotu, ale nemá přímý ekvivalent301 na nejbližší nadřazenou stránku (kategorie, rozcestník)Nejbližší příbuzná stránka je lepší než homepage, pokud původní obsah skutečně nahrazuje
Žádná návštěvnost, žádné odkazy, žádný ekvivalent410 (nebo čistá 404)Jasné 404 nebo 410 je lepší než přesměrování nikam
URL s parametry a filtryPřepis podle pravidla, ne řádek po řádkuJedno pravidlo pro vzor nahradí tisíce řádků

Filtrované URL a URL s parametry jsou jediný typ, kde by mapa neměla rozhodovat sama. Rozhodnutí musí vycházet z pravidel indexace. Používám pro ně stejný rámec jako u filtrované navigace.

Odolejte pokušení přesměrovat všechno zbylé na domovskou stránku. Dokumentace Googlu k přesunu webu je v tom jasná. Nepřesměrovávejte mnoho starých URL na jeden nesouvisející cíl, například na domovskou stránku nového webu, protože to může mást uživatele a může to být vyhodnoceno jako soft 404. Takové přesměrování nemusí přenést signály, které jste chtěli zachovat. Uživatel, který klikl na starý odkaz na produkt, přistane na domovské stránce a diví se, co se stalo. Pokud ekvivalent neexistuje, vraťte stavový kód 404 nebo 410.

48hodinový pracovní postup kontroly migrace

Těch 48 hodin je můj standard práce, ne pravidlo od Googlu. Do 48 hodin od spuštění můžete spolehlivě ověřit, zda se každá stará URL chová podle mapy, protože kontrolu děláte vy, ne vyhledávač. Postup, který používám u migračních projektů, má pět kroků.

  1. Před spuštěním uložte výchozí stav. Finální crawl starého webu, export ze Search Console a hotová mapa. Uložte je tam, kde se nad nimi dá dotazovat. Proti této trojici se pak zodpoví každá otázka po spuštění.
  2. Před spuštěním testujte na stagingu. Projeďte celý seznam starých URL na stagingu v list módu crawleru. U každého řádku zaznamenejte finální URL a stavový kód a oba údaje porovnejte s mapou. Nesrovnalosti opravte dřív, než budou veřejné.
  3. V den spuštění projeďte celý seznam starých URL na produkci. Ne vzorek. Použijte celý seznam. U každého řádku zaznamenejte první stavový kód, finální cíl, délku řetězce, stavový kód cíle a jeho indexovatelnost. Je to jedna automatizovaná úloha a je jádrem celého postupu.
  4. Během prvních 48 hodin opravujte chyby podle priority. Nejdřív 404 a 500 na URL s návštěvností nebo odkazy, pak přesměrování mířící na noindexované cíle nebo na 404, nakonec řetězce o dvou a více krocích. Potom crawl opakujte, dokud se výsledek neshoduje s mapou.
  5. Druhý den odešlete starou sitemapu vedle nové. Sitemapa plná přesměrovaných URL vypadá jako chyba, ale je to záměr. Předá Googlu kompletní seznam přesunů ke zpracování a vám dá pohled na pokrytí v Search Console, zatímco staré URL vypadávají.

U té staré sitemapy je jeden detail, který dokumentace neřeší. Google říká, že varování u sitemapy se starými URL jsou normální. Odeslat obě doporučuje i Google, kvůli sledování přesunu. Dokumentace říká jen to, že ji po odeslání nové můžete odstranit. Jak dlouho ji nechat kvůli sledování, už neřeší.

Praktické číslo pochází od Johna Muellera, který v březnu 2022 na Twitteru psal o jednom až třech měsících a dřívější údaj šesti měsíců tím snížil. Zároveň poznamenal, že dnes je efekt minimální. Berte to jako vodítko pro monitoring, ne jako nástroj, který něco změní.

Z mé vlastní praxe. Crawl v den spuštění je naskriptovaný ještě před migračním týdnem, ne psaný během něj. Spuštění migrace nikdy nepřipadne na klidný den a kontrola, která vyžaduje hodinu ručního nastavení, je kontrola, která se vynechá. Skript používá mapu jako vstup a vrací seznam rozdílů. Spustit ho zvládne kdokoli z týmu, a právě o to jde.

Jak dlouho přesměrování ponechat

Doporučení Googlu k přesunu webu zní udržovat přesměrování co nejdéle, obecně alespoň rok, a z pohledu uživatelů zvážit jejich ponechání natrvalo. V praxi přesměrování ponechávám alespoň rok a u URL, na které stále míří externí odkazy, zpravidla natrvalo. Odstranění přesměrování nesmaže starý odkaz na cizím webu, jen rozhodne o tom, že klik teď skončí na 404.

Čeho se vyvarovat

  • Nestavte mapu jen z exportu z CMS. Problém udělají právě ty URL, na které CMS zapomnělo, tedy staré struktury, kampaňové vstupní stránky a URL, které existují jen ve zpětných odkazech a v logách.
  • Nedovolte, aby se slugy měnily po schválení mapy. „Vylepšení“ slugu na poslední chvíli tiše znehodnotí řádky a mapu, která už byla schválená, nikdo znovu nekontroluje.
  • Nenasazujte řetězce přesměrování. Ze staré URL na novou jedním krokem. Googlebot sice zvládne až deset skoků, ale Google sám doporučuje mířit rovnou na finální cíl, a když to nejde, držet řetězec ideálně do tří skoků a rozhodně pod pěti. Dlouhé řetězce navíc zdržují uživatele a někteří klienti je po několika skocích přestanou sledovat. Pokud mapa vytvoří A→B→C, srovnejte to před spuštěním na A→C a upravte interní prolinkování tak, aby web sám odkazoval rovnou na finální URL.
  • Nehodnoťte migraci podle pozic týden po spuštění. Pozice jsou nejpomalejší signál, jaký máte. Stavové kódy jsou okamžité, stav indexace se mění postupně v řádu týdnů. Sledujte nejdřív ty.
  • Nemíchejte redesign, změnu platformy a přestavbu URL do jednoho spuštění, pokud se tomu dá vyhnout. Když návštěvnost klesne, tři souběžné změny znamenají, že příčinu nelze přiřadit.
  • Netestujte jen na stagingu. Staging má často jiný .htaccess nebo jiné CDN než produkce a po spuštění se polovina pravidel chová jinak. Test v den spuštění patří na produkci.
  • Nemažte starou sitemapu hned po spuštění. „Aby nevyhazovala chyby“ je špatný důvod. Varování u ní jsou normální a právě na ní uvidíte, jak staré URL z indexu mizí. Nechte ji jeden až tři měsíce, pak ji odstraňte.
  • Nezapomeňte na vstupy mimo CMS. Staré kampaňové vstupní stránky z PPC a e-mailingu v exportu z CMS nejsou a po spuštění skončí na 404. Do inventury patří i vstupní stránky z analytiky a logy.

Co měřit po spuštění ostrého webu?

  • Shoda s mapou. Podíl starých URL, které se správně vyřeší jedním krokem. Během prvních 48 hodin by měl dosáhnout fakticky 100 %, cokoli nižšího je nedodělaná práce, ne zaokrouhlovací chyba.
  • Požadavky s 404 v serverových logách na starých URL. Každý takový požadavek prověřte jako URL, kterou mohla inventura minout. První měsíc je jednou týdně vracejte zpět do mapy.
  • Stav indexace u nových URL v Search Console, proti uloženému výchozímu stavu, kolik starých URL bylo indexovaných. Když běží hromadný export ze Search Console, je porovnání jeden dotaz do BigQuery, ne ruční práce.
  • Zobrazení podle sekcí, staré proti novým, na stejných sadách dotazů. Porovnání na úrovni sekcí odhalí lokalizovaný problém ve chvíli, kdy celkový graf webu ještě vypadá dobře.

O tom, jestli se migrace povede, nerozhoduje jen kvalita mapy. Rozhodne se v prvních dvou dnech, kdy je oprava ještě levná a nikdo ji nevidí v reportu návštěvnosti.