SEO migrace webu: postup, kontrolní seznam a role specialisty

SEO migrace webu je proces zachování organické viditelnosti při změně domény, URL, struktury, redakčního systému (CMS), designu nebo technologie.

Cílem není zaručit nulový výkyv, ale předat vyhledávači konzistentní signály a rychle odhalit chyby po spuštění.

Největší chyby vznikají před dnem spuštění: SEO specialista se přizve až k hotovému webu, staré URL nejsou zmapované a nová navigace už neodpovídá tomu, co lidé hledají.

Proto má SEO specialista vstoupit do projektu ještě před schválením struktury.

Kdy jde o SEO migraci

SEO plán potřebujete při změně:

• domény nebo subdomény,
• HTTP na HTTPS,
• URL struktury,
• informační architektury a navigace,
• CMS nebo e-commerce platformy,
• vykreslování na serveru (server-side rendering) nebo v prohlížeči (client-side rendering),
• designu spojeného s odstraněním obsahu,
• jazykových verzí a atributů hreflang,
• více webů slučovaných do jednoho,
• mobilní nebo samostatné verze webu.

Samotná vizuální změna bez zásahu do URL, obsahu a HTML může mít nízké SEO riziko. Redesign však v praxi často změní komponenty, nadpisy, interní odkazy, vykreslování i měření, takže je kontrola stále potřebná.

Proč je při migraci potřeba SEO specialista

SEO specialista propojuje historii starého webu, vyhledávací poptávku, technickou implementaci a plán nového řešení.

Vývojář ví, jak přesměrování nasadit; specialista určí, kam jednotlivé URL mapovat a jak ověřit dopad.

Konkrétní odpovědnost specialisty:

1. Identifikovat organicky hodnotné URL.
2. Ohlídat, aby nová architektura neztratila důležité záměry hledání.
3. Připravit nebo zkontrolovat mapu přesměrování.
4. Nastavit kanonické URL, pravidla pro roboty, sitemapu a hreflang.
5. Zkontrolovat serverové HTML a vykreslování.
6. Připravit akceptační testy SEO pro testovací i produkční prostředí.
7. Zaznamenat výchozí stav a nastavit sledování po spuštění.
8. Rozlišit očekávaný výkyv od skutečné chyby.

Když se SEO specialista zapojí až po spuštění, může opravit chyby 404 a nesprávné kanonické URL. Bez dalšího redesignu však nemůže vrátit zrušenou kategorii, chybějící obsah ani nepromyšlenou navigaci.

Fáze 1: vytvořte inventuru starého webu

Inventura spojuje více zdrojů, protože žádný není úplný:

• seznam URL získaný procházením webu,
• XML sitemapu,
• vstupní stránky z Google Search Console a GA4,
• URL s externími odkazy,
• CMS nebo databázový export,
• vstupní stránky placených kampaní,
• produktové datové kanály,
• serverové logy u velkého webu,
• ručně známé stránky mimo navigaci.

Ke každé URL přidejte typ stránky, stav, organickou návštěvnost, konverze, odkazy, kanonickou adresu a plánovaný nový cíl.

Inventura není pouhým seznamem adres, ale podkladem pro rozhodování.

Fáze 2: rozhodněte, co zachovat, sloučit a odstranit

Každá stará URL má dostat jeden z výsledků:

• zachovat beze změny,
• přesunout na nový ekvivalent,
• sloučit do relevantnější stránky,
• odstranit bez náhrady,
• ponechat dočasně během přechodu.

Ne každá 404 je chyba. Stránka bez hodnoty a náhrady může správně vracet 404 nebo 410. Chybou je odstranit URL s návštěvností či odkazy bez relevantního cíle.

Pokud lze fungující URL zachovat, často je to nejbezpečnější varianta. Nový CMS nepotřebuje automaticky novou adresářovou strukturu.

Fáze 3: připravte mapu přesměrování

Mapa přesměrování (redirect map) přiřazuje každou měněnou starou URL k nejbližšímu relevantnímu novému cíli. Používejte trvalé serverové přesměrování se stavovým kódem 301 nebo 308.

Zásady:

• jedna stará URL vede přímo na konečný cíl,
• nevytvářet řetězce a smyčky,
• nepřesměrovávat vše na domovskou stránku,
• zachovat význam a záměr,
• zahrnout URL s parametry a historické varianty,
• zkontrolovat velká a malá písmena, lomítka a protokol,
• ponechat přesměrování dlouhodobě.

U tisíců URL používám automatizaci pro první návrh párování, ale výsledná kontrola musí zohlednit záměr stránky. Podobný HTML titulek neznamená, že jde o stejný obsah.

Fáze 4: zkontrolujte testovací prostředí

Testovací prostředí (staging) má být chráněné před indexací, ale zároveň dostupné týmu a nástroji pro procházení webu. Před spuštěním kontroluji:

• stavové kódy všech šablon,
• HTML titulek, meta popisek a H1,
• kanonické URL,
• meta robots a X-Robots-Tag,
• robots.txt připravený pro produkci,
• interní odkazy bez adresy testovacího prostředí,
• drobečkovou navigaci a hlavní nabídku,
• obsah v serverovém i vykresleném HTML,
• strukturovaná data,
• hreflang a jazykové mapování,
• Core Web Vitals a hlavní regresní rizika,
• analytiku a konverze,
• vlastní stránku 404 se správným stavovým kódem.

Blokaci testovacího prostředí nesmíte omylem přenést na produkční web. Typickou chybou při spuštění je direktiva noindex nebo pravidlo v souboru robots.txt, které zůstalo z testování.

Fáze 5: vytvořte kontrolní seznam pro spuštění

Před spuštěním musí mít každý úkol vlastníka a způsob kontroly.

Plán spuštění má obsahovat také podmínky pro návrat k předchozí verzi (rollback). Pokud nefungují platby nebo většina přesměrování, tým musí vědět, kdo o návratu rozhoduje.

Fáze 6: kontrolujte web bezprostředně po spuštění

První kontrola probíhá v minutách a hodinách, ne za měsíc.

Ověřte:

• domovská stránka a reprezentativní URL vracejí stavový kód 200,
• staré URL vracejí jeden 301/308 na správný cíl,
• produkce není blokovaná,
• kanonické URL používají výslednou doménu,
• interní odkazy nevedou na testovací prostředí ani přes přesměrování,
• sitemap je dostupná a správná,
• analytika zaznamenává návštěvy a konverze,
• nejsou plošné 404 nebo 5xx,
• Google může vykreslit hlavní obsah.

Při změně domény přidejte novou službu do Google Search Console, odešlete sitemapu a použijte nástroj „Změna adresy“, pokud odpovídá danému typu přesunu.

Fáze 7: monitorujte organický výkon

Po spuštění sledujte denně technické chyby a v delších oknech organický trend.

Segmentujte data podle:

• typu stránky,
• staré a nové URL,
• značkových a neznačkových dotazů,
• země a zařízení,
• adresářů a jazyků,
• stavu indexace a kanonických URL,
• konverzí.

Celková návštěvnost může skrýt problém jedné obchodně důležité sekce. Stejně tak běžná sezónnost může vypadat jako chyba migrace.

Výsledky porovnávejte s výchozím stavem před spuštěním a zaznamenejte datum každé opravy. U velkého webu sledujte také serverové protokoly a rychlost, s jakou Google přechází na nové URL.

Co dělat při propadu po migraci

Nejdříve určete rozsah problému. Klesl výkon celého webu, konkrétního typu stránek, jedné země, nebo pouze určitého tematického celku?

Kontrolujte v tomto pořadí:

1. Stavové kódy HTTP, dostupnost a vykreslování.
2. Pravidla pro roboty, noindex, kanonické URL a hreflang.
3. Mapu přesměrování a řetězce přesměrování.
4. Ztracený obsah a interní odkazy.
5. Změny HTML titulků, H1 a záměru stránek.
6. Sitemapu a GSC stav.
7. Analytiku a změnu měření.
8. Sezónnost, aktualizace Googlu a konkurenci.

Nevracejte naslepo starý titulek nebo text, dokud nevíte, která šablona a které dotazy se změnily. Diagnostika má pracovat s hypotézou a důkazy.

Nejčastější chyby SEO migrace

• SEO se přizve až po dokončení webu,
• zbytečně se změní všechny URL,
• staré adresy se přesměrují na domovskou stránku,
• přesměrování tvoří řetězce,
• noindex z testovacího prostředí zůstane na produkčním webu,
• zmizí důležitý text a interní odkazy,
• kanonická URL míří na starou doménu,
• sitemap obsahuje přesměrování a chyby 404,
• analytika se testuje až po spuštění,
• sledování pokrývá jen celkovou návštěvnost,
• přesměrování se po několika týdnech odstraní.

Kolik stojí SEO dohled nad migrací

Cena závisí na velikosti webu, počtu šablon a URL, změně technologie, jazycích a zapojení vývojového týmu.

Menší redesign se zachovanými URL může vyžadovat několik konzultačních bloků. E-shop nebo změna domény potřebuje samostatný projekt.

Nejdříve obvykle prověřím rozsah v rámci SEO konzultace.

U složitější migrace navazuje technické SEO nebo SEO audit s inventurou, mapou přesměrování, akceptačními testy a kontrolou po spuštění.