Migracja strony bez utraty pozycji
Checklista migracji ograniczającej ryzyko SEO: inwentarz URL, przekierowania tylko do odpowiedników, poprawne 404/410, testy i monitoring po zmianie.

Migracja nie gwarantuje zachowania każdej pozycji, ale można ograniczyć ryzyko: stary adres z rzeczywistym odpowiednikiem kieruj jednym stałym przekierowaniem do tego odpowiednika, a usunięty adres bez zamiennika pozostaw jako 404 lub 410. Masowe kierowanie wygaszonych treści do strony głównej albo luźno powiązanej podstrony może zostać potraktowane jak miękki błąd 404.
Google zaleca przygotować mapę stary–nowy, kierować przekierowania bezpośrednio do celu, unikać nieistotnych przekierowań i monitorować oba zestawy adresów. Stałe przekierowania nie powodują utraty PageRank, choć łańcuchy dokładają opóźnienie i komplikują obsługę. Źródło: Google Search Central — migracja witryny ze zmianą URL.
Przenosiliśmy tak własną witrynę: 81 starych adresów, cztery różne przedrostki bloga do skonsolidowania, zmiana technologii i zmiana kanonicznego adresu. Poniżej kolejność, którą stosujemy, i pułapki, na które trafiliśmy.
Krok 1. Inwentarz adresów - przed czymkolwiek innym
Nie da się przekierować tego, o czym się nie wie. Listę adresów buduj ze wszystkich dostępnych źródeł; żadne pojedyncze nie daje gwarancji kompletności:
- mapa witryny i eksport z systemu treści,
- raport adresów z narzędzi dla webmasterów (to, co wyszukiwarka faktycznie widziała),
- logi serwera za możliwie długi okres — tu wychodzą adresy, o których nikt nie pamięta, a które mają ruch i linki,
- lista stron z linkami z zewnątrz.
Logi pomagają odnaleźć warianty adresów pominięte w mapie witryny i narzędziach analitycznych. Zewnętrzne linki są dodatkowym sygnałem priorytetu, ale przekierowanie nadal musi prowadzić do rzeczywistego odpowiednika treści.
Krok 2. Werdykt dla każdego adresu
Dla każdego starego adresu jedna z czterech decyzji:
| Werdykt | Znaczenie | Cel przekierowania |
|---|---|---|
| zostaje | treść aktualna, adres bez zmian | brak lub sam nowy adres |
| przepisywana | temat zostaje, treść nowa | nowy odpowiednik |
| scalana | dwie strony o tym samym | strona-gospodarz |
| wygaszana | brak odpowiednika lub treść celowo usunięta | brak przekierowania; odpowiedź 404 lub 410 |
Dwie zasady, które trzymamy twardo:
- Zero nieistotnych przekierowań. Adres dostaje cel tylko wtedy, gdy nowa strona rzeczywiście zastępuje starą. Brak odpowiednika oznacza 404 lub 410; nie kieruj go „dla SEO” do strony głównej.
- Scalenie oznacza zachowanie potrzebnej odpowiedzi. Jeśli strona A zastępuje stronę B, nowy cel powinien rzeczywiście obsługiwać jej użyteczną intencję i aktualne informacje. Nie przenoś mechanicznie fragmentów nieaktualnych lub zbędnych tylko po to, by uzasadnić przekierowanie.
Krok 3. Mapa przekierowań bez łańcuchów
Trzy pułapki, które psują najwięcej i wszystkie są łatwe do przeoczenia:
Łańcuch przekierowań. Stary adres prowadzi na drugi, a ten na trzeci. Każdy skok dodaje żądanie i utrudnia diagnozę. Reguła wdrożeniowa: kieruj bezpośrednio do końcowego celu. Google podaje, że stałe przekierowania nie tracą PageRank, więc argumentem przeciw łańcuchom są przede wszystkim opóźnienia, limity i operacyjna złożoność — nie rzekomy procent „mocy linku” tracony na każdym skoku.
Kolejność reguł. Sposób ewaluacji zależy od serwera i warstwy routingu. W wielu konfiguracjach zbyt ogólna reguła umieszczona przed szczegółową przejmuje przeznaczony dla niej ruch, dlatego kolejność trzeba sprawdzić w dokumentacji i teście całej mapy.
Warianty ukośnika, liter i parametrów. Najpierw ustal, jakie warianty rzeczywiście działały i jak serwer rozróżnia wielkość liter. Normalizacja powinna być jawna i przetestowana; zbyt szeroka reguła może połączyć adresy, które w starym systemie oznaczały coś innego.
Krok 4. Test przed uruchomieniem
Automatyczny test, który sprawdza całą listę adresów i weryfikuje trzy rzeczy: kod odpowiedzi, cel przekierowania i to, że cel odpowiada poprawnie. Uruchamiany na środowisku testowym, przed dniem migracji.
Warunek przejścia jest binarny: każdy adres z inwentarza ma oczekiwany wynik testu. Może nim być 200 dla adresu pozostającego, pojedyncze 301/308 do właściwego odpowiednika albo zaplanowane 404/410 dla treści usuniętej. „Obsłużony” nie znaczy „przekierowany”.
Test powinien zapisać wynik i wykrywać pętle, łańcuchy, błędne cele oraz nieoczekiwane kody odpowiedzi. Czas jego przygotowania zależy od liczby wariantów i środowiska.
Krok 5. Co jeszcze musi być gotowe w dniu migracji
- Adresy kanoniczne wskazujące nowe adresy, spójnie na całej witrynie.
- Mapa witryny z nowymi adresami, zgłoszona po przełączeniu.
- Plik z regułami dla robotów — sprawdź, czy przypadkiem nie blokujesz nowej struktury. Klasyczna katastrofa: reguła blokująca ze środowiska testowego przeniesiona na produkcję.
- Dane strukturalne przeniesione, nie zgubione przy zmianie szablonów.
- Wydajność sprawdzona na kluczowych szablonach. Regresja może pogorszyć doświadczenie i wynik biznesowy, ale nie należy przypisywać każdego wahania pozycji jednej metryce — wydajność omawiamy w bezkosztowym pozycjonowaniu.
- Tytuły i opisy — jeśli je zmieniasz, rób to świadomie i mierz, bo zmiana tytułu na dobrze rankującej stronie potrafi ruszyć pozycje w obie strony.
Krok 6. Kolejność w dniu przenosin
- Przed przełączeniem: zapisz stan odniesienia — ruch, kliknięcia, wyświetlenia, indeksację, konwersje i błędy z uzgodnionego okresu.
- Wdróż nową witrynę na środowisko umożliwiające test bez przypadkowej indeksacji wersji roboczej.
- Przetestuj inwentarz, kanoniczne adresy, mapę witryny, dane strukturalne i reguły dla robotów.
- Przełącz ruch oraz aktywuj docelowe przekierowania.
- Powtórz test na produkcji i porównaj wynik z oczekiwaną mapą.
- Zgłoś nową mapę witryny i — jeśli dotyczy — zmianę adresu w Search Console.
- Monitoruj błędy, crawl, indeksację, ruch i wynik biznesowy; zachowaj dostęp do starego środowiska i logów przez uzgodniony okres.
Czego się spodziewać po migracji
Uczciwie, bo tu rodzą się niepotrzebne paniki:
- Tymczasowe wahania są możliwe. Google musi ponownie odwiedzić stare i nowe adresy oraz zaktualizować indeks.
- Nie ma gwarantowanego terminu powrotu. Według Google przeniesienie średniej witryny może zająć kilka tygodni, a większej — dłużej; szybkość crawlowania zależy między innymi od rozmiaru i serwera.
- Diagnozuj na bieżąco, jeśli ważne adresy nie są odkrywane, cele zwracają błędy, kanoniczne są sprzeczne albo ruch i konwersje wychodzą poza uzgodniony zakres. Nie czekaj mechanicznie dwóch miesięcy na błąd wdrożeniowy.
Nie wyciągaj wniosku z pojedynczego dnia, ale reaguj natychmiast na błędy techniczne. Trend widoczności oceniaj w kontekście sezonowości, zmian treści i porównywalnego okresu.
Kiedy nie migrować
- Gdy nie ma powodu biznesowego. Zmiana technologii sama w sobie nie podnosi pozycji. Koszt bez zwrotu — kiedy zmiana ma sens, rozstrzygamy w Next.js czy WordPress.
- Gdy nie ma kto zrobić inwentarza adresów. To warunek konieczny, nie etap do pominięcia.
- Gdy kluczowe cele i testy nie są gotowe. Nie uruchamiaj migracji z przypadkowymi błędami lub zastępczą, cienką treścią tylko po to, by dotrzymać daty. Strona usunięta bez odpowiednika powinna zwrócić właściwe 404/410.
- Gdy chodzi o samą zmianę wyglądu. Wtedy zmień szablon, nie strukturę adresów.
Najczęstsze pytania
Czy trzeba przekierowywać adresy bez ruchu?
Tylko jeśli ma rzeczywisty nowy odpowiednik. Brak ruchu nie dowodzi braku wartości, więc sprawdź linki, logi i cel treści. Jeśli odpowiednika nie ma, zwróć 404 lub 410 zamiast kierować do luźno powiązanej strony.
Jak długo trzymać przekierowania?
Google zaleca utrzymywać przekierowania co najmniej rok; z perspektywy użytkowników warto pozostawić je tak długo, jak stare adresy nadal są używane. Koszt nie zawsze jest zerowy — mapa wymaga testów przy kolejnych zmianach — ale zwykle warto zachować stabilne, potrzebne reguły dłużej.
Czy da się migrować etapami?
Tak. Przy dużych witrynach etapowanie może ograniczyć rozmiar pojedynczego wdrożenia, ale wydłuża okres z dwiema strukturami i komplikuje monitoring. Adresy kanoniczne, linkowanie, zależności między sekcjami oraz mapa przekierowań muszą być rozstrzygnięte tak, aby nie migrować tych samych adresów wielokrotnie.
Przenieśliśmy tak własną witrynę z pełnym pokryciem starych adresów i możemy pokazać, jak wygląda taka mapa w praktyce. Zobacz migrację WordPress do Next.js albo podaj adres strony — odezwiemy się z diagnozą.

Autor
Maciej Szukalski
Założyciel Condictor · architekt systemów · badania i rozwój
Od 2014 roku projektuje i buduje produkty cyfrowe. Specjalizuje się w architekturze, badaniach oraz aplikacjach z warstwami automatyzacji i inteligencji.
Poznaj doświadczenie i sposób pracyMasz problem do rozwiązania?
Sprawdźmy, od czego warto zacząć
Opisz sytuację w kilku zdaniach. Wrócimy z pytaniami lub propozycją konkretnego następnego kroku.
