Migrace webových stránek patří k nejnáročnějším disciplínám optimalizace pro vyhledávače. Bez ohledu na to, jak velké jsou vaše zkušenosti s technickým SEO, jak důkladný plán migrace jste připravili a jak dlouhý je váš kontrolní seznam, mohou vždycky nastat neočekávané potíže.
Sledování webu po migraci je proto stejně důležité, jako samotný přenos dat, a to hlavně v prvním měsíci, kdy se případné komplikace projeví. Ke kterým chybám po spuštění nového webu dochází, a jak je zvládnout bez poškození provozu?
Náhodné zobrazování chybných stránek 404
Tento problém je pro testování SEO doslova noční můrou, protože zkresluje všechny statistiky. Když nemůžete věřit naměřeným údajům, tak ani nezjistíte, co je vlastně poškozené, a jaký to má vliv na výkon.
Pokud se vám na různých URL adresách náhodně zobrazují chybové stránky 404 a po ruční kontrole se stránky načítají správně se stavem 200, stávají se ostatní zprávy nevěrohodné a kvalitní analýza je tak téměř vyloučená.
Příčinou náhodných chyb 404 jsou často problémy na straně serveru, jako je třeba omezení rychlosti a zamítnutí přístupu robotům po příliš velkém množství žádostí.
Mezi další důvody patří:
- Špatně nastavené ukládání do mezipaměti,
- Nejednotný překlad DNS,
- Nástroje na vyrovnávání zatížení směřující požadavky na nedostupný server.
Pro přesnou identifikaci problému proveďte důkladnou analýzu protokolů serveru, abyste mohli zkontrolovat vzory požadavků a odpovědí robotů.
Mějte na paměti, že bez přístupu k protokolům nic nezmůžete a zajistěte, aby členové vašeho SEO týmu uměli používat nástroje pro protokolování a znali alespoň základy toho, jak fungují. Díky sledování protokolů aktivity botů můžete ukázat potíže vývojářům. Bez něj vám hrozí nekonečné debaty o přesnosti SEO nástrojů.
Náhodné zobrazování chybných stránek 500
Mohlo by se zdát, že jde o stejnou chybu jako v případě stránek 404, ale příčina je obvykle úplně jiná a stejně špatně se hledá. Dokonce i nástroje jako Screaming Frog nebo Lumar mohou při procházení webu spustit zobrazování chyb 500.
Tyto potíže bývají důsledkem přetížení serveru složitými databázovými dotazy nebo špatně nakonfigurovaného ukládání do mezipaměti. V takovém případě se každý požadavek zpracovává samostatně, čímž dochází ke zvýšení zátěže, pomalému načítání a občasným selháním.
Stejně jako u chyb 404 neobjevíte problém bez přístupu k serverovým protokolům.
Špatné načítání zdrojů
Krátce po migraci dat může dojít k nečekanému poklesu hodnocení a návštěvnosti webu. Na první pohled se ovšem nic vážného neděje, stránky se uživatelům načítají správně a styly i JavaScript fungují bezvadně.
Jenže v kontrolním nástroji Google Search Console se ty stejné stránky jeví jako nefunkční a bez stylů. Potíže přitom nemají žádnou spojitost a je velmi složité vysvětlit vývojářům, že k nim dochází.
Na jejich původ lze přijít v chybových a varovných hlášeních ve vaší webové Konzoli. K nevyzpytatelnému chování stránek mohlo dojít třeba tím, že Googlebot kvůli načítání do mezipaměti někdy viděl web správně, ale jindy už ne.
Prověřte výkon webu v různých prohlížečích, sledujte pečlivě hlášení v Konzoli a mějte na paměti, že i malé technické detaily, jako je sekvence načítání zdrojů, mohou mít při přehlédnutí varovných signálů velký dopad na SEO.
Pokud se nevyznáte v terminologii vývojářů, nechte si situaci vysvětlit od odborníka nebo se zkuste zeptat na platformách AI.
Neexistující URL adresy
Během pomigrační kontroly objevených, ale neindexovaných stránek webu v Google Search Console někdy narazíte na neexistující URL adresy označené jako duplicitní stránky. Ty by se měly za normálního stavu vracet jako chyby 404, ale vyhledávače je mají za bezchybné se stavovým kódem 200.
Což znamená dvě velké hrozby:
- Z pohledu SEO jde o plýtvání rozpočtem na procházení a také o poškození hodnocení, protože vyhledávací roboti potenciálně indexují irelevantní a duplicitní stránky, jejichž URL adresy považují za legitimní.
- Z pohledu zabezpečení vzniká riziko přetížení serveru, pokud by nějací útočníci začali generovat tisíce náhodných URL.
Tato chyba se dá jen velmi špatně odhalit, dokud se z ní nestane skutečný problém. Předcházejte mu tím, že:
- Budete pravidelně kontrolovat, zda některé sekce webu umožňují opatřit neexistující URL adresy stavem 200.
- Sestavíte seznam těchto kritických částí a jednou měsíčně je otestujete pomocí prohledávače. Chybu mohou způsobit i nevelké změny v backendu.
- Zaměříte se na automaticky a dynamicky generované stránky, u kterých se tato záležitost děje nejčastěji.
Hreflang a kanonické značky u neexistujících URL adres
Správa značení hreflang na vícejazyčných webech je dost náročná a i z malých pochybení se mohou stát velké nesnáze.
Nesprávné značky hreflang matou vyhledávače, které je používají pro identifikaci odpovídající jazykové nebo lokální verze webu. Když je značení chybné, mohou mít roboti potíže s pochopením struktury webu nebo implementaci hreflang zcela ignorovat.
Potížím s těmito značkami se vyhnete když:
- Vytvoříte pro migraci zevrubný seznam kontrol potřebných pro každou konkrétní lokalitu. Obecné migrační seznamy kontrol vám dají dobrý základ, ale musíte je přizpůsobit svému webu a CMS.
- Budete ručně testovat lokalizované stránky v různých šablonách, díky čemuž zajistíte správné použití hreflang a kanonických značek.
Kolaps vykreslení JavaScript
Poměrně často dělá problémy po migraci obsah založený na JavaScript. Návštěvníci webu jej vidí, ale vyhledávače ne.
K tomu většinou dojde, když widgety a obsahové sekce spoléhají na vykreslení JavaScript, jenže roboti skripty provádějí špatně nebo je neúplně prohledávají.
Jednoduchým testem zjistíte, jak daný widget funguje:
- Zobrazuje okamžitě celý obsah, nebo nejprve vyžaduje interakci uživatele?
Platí-li to druhé, widget se nejspíš spoléhá na JavaScript a vyhledávací roboti nebo nástroje AI jej nevidí.
Na to, kde k selhání vykreslení JavaScript dochází, přijdete, když spustíte procházení stránek s povoleným JavaScript a také čisté procházení HTML a porovnáte výsledky.
Pomoci vám může i jednoduchý ruční test:
- Najděte konkrétní prvek nebo větu z widgetu ve zdrojovém kódu HTML.
- Když se vám to nepodaří, velmi pravděpodobně o něm neví ani vyhledávače.
Řešení spočívá v zajištění správného načítání skriptů pro uživatele i roboty nebo zlepšení vykreslování na straně serveru. Při procesu migrace webu většinou nezbývá moc prostoru na nějaké velké testování, proto si osvojte tyto dva snadné postupy, abyste mohli případné problémy s vykreslováním rychle objevit a opravit.
Ztráta sledovacích dat
Když po migraci přijdete o sledované údaje, je to sice nenápadná, ale dost drahá záležitost. Může se stát, že návštěvníci webu přicházející prostřednictvím placených reklam nevykazují při procházení webu žádné parametry sledování jejich cesty.
Kvůli tomu už nejsou následná zobrazení stránek v rámci stejné relace připisována původní placené kampani, což poškozuje remarketingové aktivity. Příčinou je nevhodné zacházení s parametry URL v průběhu migrace.
Komplikovaná migrace webu není jen záležitostí SEO týmu, ale musí o ní vědět a počítat s ní i ostatní oddělení, s jejichž činností nějak souvisí. Před zahájením přenosu dat raději třikrát prověřte plán migrace a ujistěte se, že všechny zúčastněné týmy jsou v pozoru.
Na testování výsledků migrace by se měli kromě specialistů na SEO podílet také analytici, vývojáři i marketéři, aby atribuce uživatelů a parametry sledování zůstaly dostatečně pod kontrolou. Každý tým musí mít pro srovnání k dispozici zprávu před a po spuštění migrace, aby mohl hned hlásit podezřelé situace a upozornit na možné komplikace.
Zmizelé stránky
Tento konkrétní příklad vám ukáže, jak důležité je mít před migrací shromážděná kompletní data o celém webu.
K čemu došlo? Testování po migraci nevykazovalo žádné chyby a web fungoval podle předpokladů při stagingu i po interním přepnutí protokolu DNS. Jakmile ale došlo k aktivaci externího DNS, zmizela celá třetina příspěvků z blogu.
Zbytek webu zůstal nedotčený a tím pádem bylo možné chybu snadno přehlédnout. K čemuž také došlo, protože všichni testovali sledování, formuláře, přesměrování nebo značení a chybějícího obsahu blogu si nikdo nevšiml.
Na problém čirou náhodou přišla regionální manažerka, která několik dní před migrací aktualizovala obrázek v příspěvku a chtěla se podívat, jestli se změna přenesla. K jejímu údivu na stránce nenašla nejen obrázek, ale vůbec nic.
Před zahájením migrace vždycky proveďte kompletní audit webu a po jejím ukončení data porovnejte, abyste včas zachytili podobné nesrovnalosti, než přerostou ve vážné komplikace.
Negativní vliv na CMS
Ne všechny potíže po migraci webu se týkají oboru SEO, škody mohou nastat také jinde. Můžete třeba zjistit, že programy Screaming Frog a Lumar po spuštění prohledávání webu začnou zahlcovat panel správce CMS. Kvůli velkému nárůstu požadavků pak editoři nemohou provádět změny na stránkách a aktualizovat obsah.
To znamená, že vaše CMS a webové stránky nestíhají v případě většího tlaku při procházení webu, což je samozřejmě špatně.
Crawlery neboli prohledávače webů jsou často využívány pro analýzu konkurence a jako takové je může váš web kdykoliv zajímat. Zajistěte, aby stránky a CMS i po migraci fungovaly za všech okolností správně a aby obsahové týmy SEO dostaly přístup do CMS a ke správě aktualizací obsahu.
Získáte tak lepší přehled, jak odolný váš web ve skutečnosti je.
Největší malér: Slabý monitoring po migraci
Každou zásadní změnou, a tím spíše migrací velkého množství dat, podstupujete riziko, že se něco pokazí nebo nepovede. Některé problémy jako chybějící stránky nebo nefunkční přesměrování ”vylezou” na povrch hned, jiné jsou skryté a projeví se až za čas, kdy už ale může být pozdě.
Monitorování webu po migraci je proto stejně důležité, jako migrace samotná.
Hrozby zmírníte tím, že:
- Vytvoříte detailní plán celé akce počítající se všemi potenciálními komplikacemi,
- Všechno podrobně zdokumentujete,
- Spustíte audit webu před i po migraci,
- Budete spolupracovat napříč týmy.
Mějte na paměti, úspěch migrace nezávisí jen na přenosu dat, ale také na neustálém sledování, testování a zlepšování.
Zdroj: marketingland.com, facebook.com, cpcstrategy.com
Autor: Martin Kulhánek
Foto zdroj: pixabay.com
