Migracja strony bez utraty widoczności: plan, mapa przekierowań 1:1 i pomiar przed i po

Kiedy zmiana strony jest migracją — i które zmiany bolą najbardziej

Nie każda przebudowa serwisu to migracja w rozumieniu SEO. Kryterium jest jedno: czy zmieniają się adresy URL, których wyszukiwarka używa jako identyfikatorów stron. Jeśli tak — każdy stary adres musi dostać jednoznaczną odpowiedź, co się z nim stało. Jeśli nie — ryzyko leży gdzie indziej: w treści, szablonach i infrastrukturze.

Ten poradnik skupia się na scenariuszach ze zmianą adresów. Podstawy — jak Google traktuje kody odpowiedzi i rodzaje przekierowań — opisaliśmy w artykule filarowym o SEO technicznym; tu zajmujemy się samym procesem.

Zanim cokolwiek przełączysz: inwentaryzacja i punkt odniesienia

Pełna lista adresów — z kilku źródeł, nie z jednego

Mapy przekierowań nie da się zbudować z listy, której się nie ma. Żadne pojedyncze źródło nie jest kompletne, dlatego inwentaryzację składamy z kilku miejsc i deduplikujemy:

Punkt odniesienia: zmierz, zanim zmienisz

Po migracji jedyną uczciwą odpowiedzią na pytanie „czy coś straciliśmy” jest porównanie z danymi sprzed zmiany. Przed startem eksportujemy z Search Console skuteczność (strony i zapytania) z możliwie długiego okresu, spisujemy liczbę stron zaindeksowanych z raportu „Indeksowanie stron” i bieżącą listę błędów 404. Bez tego po migracji zostają wrażenia — a wrażenia zawsze mówią, że kiedyś było lepiej.

Nie wszystkie adresy są równe

Strony z ruchem, pozycjami i linkami dostają w mapie ręczną weryfikację — adres po adresie. Reszta może iść regułami wzorcowymi. Ta hierarchia decyduje też o kolejności kontroli po starcie: najpierw sprawdzamy to, co zarabia.

Mapa przekierowań 1:1

Fundamentalna zasada z dokumentacji migracji Google: każdy stary adres prowadzi do odpowiadającego mu nowego adresu. Google wprost odradza kierowania wielu starych adresów na jeden nietrafny cel, taki jak strona główna nowego serwisu. Strona bez odpowiednika powinna dostać 404 lub 410 — świadome zakończenie życia adresu jest lepsze niż przekierowanie donikąd, które dla użytkownika wygląda jak błąd, a w Search Console potrafi skończyć jako soft 404.

Reguły wzorcowe i ręczne wyjątki

W praktyce mapa składa się z dwóch warstw. Reguły wzorcowe — obsługują przewidywalne zmiany ścieżek (np. zmianę katalogu) i załatwiają większość adresów hurtem. Lista ręczna — obsługuje wyjątki i najważniejsze strony, dla których reguła mogłaby wskazać zły cel. Kolejność ma znaczenie: wyjątki przed regułami, inaczej reguła przechwyci wszystko.

Rodzaj przekierowania i łańcuchy

Do trwałej zmiany adresu służy stałe przekierowanie serwerowe (301/308) — to silny sygnał, że wersją kanoniczną ma być cel, i to cel pojawia się w wynikach. Przekierowania tymczasowe (302/307) zostawiamy sytuacjom naprawdę tymczasowym. Dokumentacja Google podaje też twardy limit: roboty podążają domyślnie za maksymalnie 10 skokami przekierowań. Dlatego przy kolejnej migracji stare łańcuchy spłaszczamy — każde przekierowanie ma prowadzić bezpośrednio do finalnego celu — a linki wewnętrzne w nowym serwisie aktualizujemy tak, by w ogóle nie przechodziły przez przekierowania.

Dzień startu i pierwsze 48 godzin

Najwięcej migracji psuje się nie na mapie, tylko na przełączeniu — przez rzeczy, które zostały ze środowiska testowego. Kolejność kroków i kontroli:

Po starcie: monitoring i pomiar przed/po

Dokumentacja Google daje realistyczny punkt odniesienia: przetworzenie migracji małego lub średniego serwisu zajmuje zwykle kilka tygodni dla większości stron, a większe serwisy potrzebują więcej czasu. W tym okresie stare adresy stopniowo znikają z indeksu na rzecz nowych — to normalne. Nienormalne jest co innego i właśnie tego szukamy:

• Rosnąca lista 404 — adresy, które miały mieć odpowiednik, a zwracają błąd, to dziury w mapie; raport indeksowania pokazuje je wprost.
• Nowe adresy nie przybywają w indeksie — sygnał blokad, problemów z renderowaniem albo sitemapą.
• Przekierowania z łańcuchami — pojawiają się, gdy nowe reguły nałożyły się na stare; wykrywa je crawl próbki starych adresów.

Przekierowania utrzymujemy co najmniej rok — tyle wskazuje dokumentacja Google — a w praktyce tak długo, jak to możliwe. Zdjęcie ich po kilku tygodniach, „bo już działa”, to jeden z najprostszych sposobów zmarnowania poprawnie przeprowadzonej migracji.

Migracja bez zmiany adresów: hosting i CDN

Przeniesienie serwisu na nowy hosting lub za nowy CDN to inny scenariusz: adresy się nie zmieniają, więc nie ma mapy przekierowań — jest za to okno przełączenia infrastruktury. Google ma dla tego przypadku osobny przewodnik i zaleca kolejno: przygotowanie i przetestowanie kopii na nowej infrastrukturze (np. w środowisku z dostępem ograniczonym po IP), sprawdzenie narzędziem URL Inspection, czy robot widzi nową infrastrukturę, obniżenie TTL rekordów DNS do niskiej wartości co najmniej tydzień przed przełączeniem oraz monitoring logów po obu stronach aż stary serwer przestanie dostawać ruch. Przejściowy spadek tempa crawlowania tuż po przełączeniu jest według dokumentacji normalny.

Czego migracja nie naprawi

Migracja przenosi widoczność — nie tworzy jej. Serwis, który przed zmianą nie odpowiadał na intencje użytkowników, po zmianie adresów odpowiada na nie dokładnie tak samo. Dobry plan migracji chroni to, co jest; nadzieje na wzrost trzeba wiązać z treścią i architekturą, nie z samą przeprowadzką.

Migracja bywa natomiast dobrą okazją do porządków, które i tak czekały: spłaszczenia starych łańcuchów przekierowań, podlinkowania stron-sierot, uporządkowania duplikatów i wersji parametrycznych. To realny zysk — pod warunkiem, że jest zaplanowany, a nie robiony przy okazji w dniu startu.

Checklista minimum przed startem migracji

Jedenaście punktów do odhaczenia, zanim ktokolwiek przełączy DNS albo wgra nową wersję:

• Inwentaryzacja — lista adresów złożona z co najmniej trzech źródeł (CMS/sitemapa, Search Console, logi lub crawl) i zdeduplikowana.
• Punkt odniesienia — eksport skuteczności z Search Console, liczba stron zaindeksowanych i lista 404 zapisane przed zmianą.
• Mapa 1:1 — każdy stary adres ma cel; strony z ruchem i linkami zweryfikowane ręcznie.
• Świadome 404/410 — strony bez odpowiednika zakończone jawnie, nie przekierowane hurtem na stronę główną.
• Przekierowania stałe — serwerowe 301/308, bezpośrednio do celu, bez łańcuchów.
• Nowa wersja bez blokad — zero noindex i blokad robots.txt przeniesionych ze środowiska testowego.
• Linki wewnętrzne — w nowym serwisie prowadzą wprost do nowych adresów, nie przez przekierowania.
• Sitemapa — przygotowana z nowymi adresami, gotowa do zgłoszenia w Search Console w dniu startu.
• Obie właściwości GSC — stara i nowa zweryfikowane przed startem.
• Change of Address — zaplanowane przy zmianie domeny (nie dotyczy HTTP → HTTPS).
• Plan kontroli po starcie — kto i kiedy sprawdza przekierowania, raport indeksowania i listę 404 w pierwszych tygodniach.

Podsumowanie

Migracja to nie projekt „przenosin” z dodatkiem SEO, tylko operacja na widoczności prowadzona według czterech zasad: policz wszystko przed zmianą, zaplanuj los każdego adresu (cel 1:1 albo świadome 404/410), przełączaj w kontrolowanej kolejności i mierz po staremu — porównując do zapisanego punktu odniesienia, nie do wrażeń. Google daje w dokumentacji dwa twarde punkty zaczepienia: kilka tygodni przetwarzania dla małych i średnich serwisów oraz co najmniej rok utrzymywania przekierowań.

Najczęstsze przyczyny strat są przy tym banalne: dziury w inwentaryzacji, hurtowe przekierowanie na stronę główną, noindex ze stagingu i łańcuchy po kilku migracjach naraz. Wszystkie są do wychwycenia przed startem — dokładnie po to jest checklista wyżej. Ten poradnik aktualizujemy, gdy dokumentacja Google zmieni opisane tu mechanizmy.