Migracja strony bez utraty pozycji: checklista przed, w dniu i po wdrożeniu

Migracja strony bez utraty pozycji to praca na adresach i treści, a nie na wyglądzie. Widoczność spada wtedy, gdy zrywa się mapowanie starych adresów na nowe albo gdy razem z przeprowadzką nieoczekiwanie zmienia się treść podstron — robot trafia wtedy na błąd 404, pętlę przekierowań albo stronę, która nie odpowiada już na to samo zapytanie. Nowy layout, nowe kolory i nowy system zarządzania treścią same z siebie nie wypychają serwisu z wyników wyszukiwania. Poniżej masz checklistę operacyjną w trzech blokach — przed, w dniu wdrożenia i po — oraz plan wycofania zmian, który trzeba przygotować, zanim cokolwiek ruszy.

Migracja strony bez utraty pozycji zaczyna się od adresów, nie od wyglądu

Widoczność gubią dwie rzeczy: zerwane mapowanie adresów i niekontrolowana zmiana treści. Wszystko inne — inny szablon, inne zdjęcia, inna kolorystyka — jest dla wyszukiwarki drugorzędne, dopóki adres nadal odpowiada tym samym kodem i tą samą odpowiedzią na to samo zapytanie.

Zerwane mapowanie ma kilka twarzy i wszystkie są widoczne w raporcie „Indeksowanie stron” w Google Search Console: błędy 404, błędy przekierowań, błędy serwera 5xx, wymagane uwierzytelnienie 401, blokada w robots.txt, znacznik noindex oraz duplikaty i wersje alternatywne. To gotowa lista rzeczy do sprawdzenia po każdym wdrożeniu — Google sam ją dla Ciebie porządkuje.

Pięć typów migracji i ryzyko, które każdy z nich niesie

Nie każda migracja jest tak samo ryzykowna — decyduje o tym, ile jednocześnie zmieniasz. Najgorsze scenariusze to te, w których zmiana domeny, struktury adresów i treści wchodzą jednym wdrożeniem, bo po spadku nie wiadomo, który element go wywołał.

Zmiana platformy zasługuje na osobną decyzję jeszcze przed migracją, bo od niej zależy, jak wyglądają adresy w nowym serwisie — pomaga tu porównanie, czy lepszy będzie WordPress, czy strona dedykowana, a w handlu — to, czy prowadzisz sklep na abonament czy dedykowany, bo platformy abonamentowe narzucają własne wzorce adresów i ograniczają zakres przekierowań. Przy zmianie hostingu obserwuj też, co po przeprowadzce dzieje się z Core Web Vitals, czyli LCP, INP i CLS, bo nowe środowisko potrafi zmienić czasy odpowiedzi w obie strony.

Blok „przed”: cztery rzeczy, których nie odtworzysz po starcie

Przed wdrożeniem zbierasz dane, które przestają istnieć w momencie wyłączenia starego serwisu. To jest ta część migracji, której nie da się nadrobić później.

1. Pełna lista adresów starego serwisu. Przeczołgaj serwis narzędziem typu Screaming Frog, dołóż adresy z mapy strony i z raportów Search Console, a wynik zapisz jako plik, nie jako zakładkę w przeglądarce.
2. Mapa 1:1 stary adres → nowy adres. Jeden wiersz, jeden adres źródłowy, jeden adres docelowy. Bez wyjątków i bez pól pustych.
3. Decyzja dla adresów bez odpowiednika. Każdy taki adres dostaje albo przekierowanie na najbliższy tematycznie odpowiednik, albo status 410 z informacją, że treść została wycofana. Milczące 404 to decyzja niepodjęta.
4. Zrzut danych wyjściowych z Search Console. Raport skuteczności podaje kliknięcia, wyświetlenia, CTR i średnią pozycję, a dane sięgają 16 miesięcy wstecz. Eksport zrobiony przed migracją jest jedynym wiarygodnym punktem odniesienia po niej.

Środowisko testowe zamykasz na tym samym etapie. Najpewniejszą blokadą jest wymaganie uwierzytelnienia na poziomie serwera — sam znacznik noindex i wpis w robots.txt potrafią zginąć przy kopiowaniu środowiska albo przy wdrożeniu na produkcję, a wtedy testowa wersja trafia do wyników razem z produkcyjną.

Jeśli migrację prowadzi zewnętrzny zespół, ten sam zakres warto opisać na wejściu — możesz to zrobić w kreatorze briefu, który układa wymagania w formę gotową do rozmowy z wykonawcą.

Blok „w dniu wdrożenia”: kolejność, która ma znaczenie

W dniu startu wykonujesz cztery czynności w ustalonej kolejności i każdą potwierdzasz obserwacją, a nie deklaracją wykonawcy.

Najpierw włączasz przekierowania 301 zgodnie z mapą i sprawdzasz kilkanaście losowych adresów z arkusza: każdy ma prowadzić jednym skokiem do właściwego celu, bez pętli i bez łańcucha kolejnych przeskoków. Następnie zdejmujesz z nowego serwisu blokadę indeksowania — to moment, w którym najczęściej zostaje po testach znacznik noindex albo reguła w robots.txt blokująca cały katalog.

Trzeci krok to mapa strony: nowy plik sitemap.xml z aktualnymi adresami, zgłoszony w Search Console. Czwarty, najczęściej pomijany, to sprawdzenie, że stara wersja serwisu nie odpowiada równolegle — po zmianie hostingu potrafi jeszcze przez jakiś czas działać pod starym adresem IP albo pod adresem technicznym, serwując pełną kopię treści.

Przy zmianie domeny dochodzi piąty element: narzędzie zmiany adresu w Google Search Console. Zgłaszasz w nim przeniesienie z usługi starej domeny na nową, mając już działające przekierowania i dostęp do obu usług. To komunikat dla Google, że przeprowadzka jest zamierzona, a nie awaria starego serwisu.

Blok „po”: harmonogram kontroli w pierwszej dobie, tygodniu i miesiącu

Po starcie kontrola ma harmonogram, a nie polega na sprawdzaniu pozycji co godzinę. Trzy horyzonty odpowiadają na trzy różne pytania.

Pierwsza doba — czy nowy serwis jest dostępny dla robota. Weź kilkanaście najważniejszych adresów i przepuść je przez narzędzie do sprawdzania adresów URL. To ono rozstrzyga status konkretnego adresu; operator site: daje wynik przybliżony i nie jest dowodem. Wyklucz kolejno blokadę w robots.txt, znacznik noindex, błędy serwera 5xx, błędy 404, błędy przekierowań i wymagane uwierzytelnienie 401.

Pierwszy tydzień — czy indeks nadąża. Czytasz raport „Indeksowanie stron”: ile adresów ma status „Zindeksowano”, ile „Nie zindeksowano” i z jakich przyczyn. Rosnąca liczba błędów przekierowań albo duplikatów oznacza, że mapa ma dziury — czytanie takich raportów opisuje szerzej audyt SEO i to, co blokuje widoczność.

Po miesiącu — czy wróciła widoczność, a nie tylko dostępność. Porównujesz raport skuteczności ze zrzutem sprzed migracji na poziomie zapytań i adresów, nie sumy. Adresy, które wypadły, dzielisz na trzy grupy: takie, które nie mają przekierowania (dopisujesz je do mapy), takie, których treść realnie się zmieniła (decydujesz, czy wracasz do poprzedniej wersji), i takie, które przekierowałeś świadomie na inny cel. Firmy działające lokalnie sprawdzają dodatkowo, czy adresy podane w wizytówce i katalogach nadal działają — to element pozycjonowania lokalnego, który po migracji potrafi zostać z linkami na stare adresy.

Plan wycofania zmian: co musi być gotowe, zanim cokolwiek wystartuje

Plan wycofania to zestaw zasobów i decyzji przygotowanych przed wdrożeniem, dzięki którym da się wrócić do stanu sprzed migracji. Po starcie jest już na to za późno — brakującej kopii bazy nie da się wytworzyć wstecz.

Przed wdrożeniem musisz mieć:

• zamrożoną kopię starego serwisu — pliki i baza danych w stanie z chwili zamrożenia, odłożone poza serwerem produkcyjnym,
• opłacony stary hosting i domenę przez ustalony z góry okres po migracji, a nie do najbliższego terminu odnowienia,
• obniżony TTL wpisów DNS ustawiony na kilka dni przed zmianą, żeby powrót nie czekał na wygaśnięcie starej pamięci podręcznej,
• odwrotną mapę przekierowań — ten sam arkusz czytany od prawej do lewej, gotowy do wgrania,
• zapisany stan konfiguracji starego serwisu: robots.txt, mapa strony, reguły przekierowań, ustawienia w Search Console,
• kryterium i osobę decyzyjną — co konkretnie uruchamia wycofanie (na przykład masowe błędy 5xx albo skokowy wzrost adresów z błędem przekierowania) i kto podejmuje tę decyzję.

Część zmian jest jednokierunkowa: treści przepisane na nowo i nowe adresy, które zdążyły wejść do indeksu, wracają wolniej niż konfiguracja serwera. Plan wycofania obejmuje więc przede wszystkim pierwsze dni po starcie, a jego celem jest ratowanie dostępności serwisu.

Jak odróżnić normalną zmienność od awarii i od kary

Spadek pozycji bez komunikatu w sekcji „Działania ręczne” w Search Console nie jest karą. Ta sekcja jest jedynym miejscem, w którym Google informuje o ręcznym działaniu — jeśli nie zgłasza problemów, żadnej kary nie ma i nie ma czego odwoływać.

Powielona treść też nie jest karą: duplicate content nie znajduje się na liście zasad antyspamowych Google. Może natomiast doprowadzić do konsolidacji adresów albo gorszego rankowania — i dokładnie to widać po migracji, gdy stara i nowa wersja odpowiadają równolegle.

Zostaje pytanie o czas. Google podaje, że część zmian daje efekt w ciągu godzin, a część dopiero w skali miesięcy, i zaleca odczekanie kilku tygodni przed oceną skutków (przewodnik startowy Google, aktualizacja z 10 grudnia 2025). Rzetelna ocena migracji polega więc na sprawdzeniu w tej kolejności: czy adresy są dostępne, czy są w indeksie, czy pokazują się na te same zapytania. Gdy strona wciąż nie pojawia się w wynikach, Google prowadzi po polsku stronę pomocy „Dlaczego moja strona nie wyświetla się w wynikach wyszukiwania Google?” z listą przyczyn do przejścia, zanim ktokolwiek zacznie mówić o karze.