Przekierowania 301 przy migracji: mapa, wdrożenie, weryfikacja

Przekierowania 301 przy migracji decydują o tym, czy serwis po przełączeniu zachowa ruch, czy zacznie budować widoczność od nowa. Nowy szablon, nowa domena albo nowa struktura kategorii to dla Google tysiące adresów, które nagle przestają istnieć. Jeśli każdy z nich prowadzi jednym skokiem do swojego odpowiednika, wyszukiwarka przenosi sygnały i po kilku tygodniach indeks wraca do normy. Jeśli mapa ma dziury, łańcuchy albo masowe przekierowania na stronę główną, strata zostaje na długo.

Ten tekst rozwija jeden etap opisany w naszym przewodniku o tym, jak przeprowadzić migrację strony bez utraty widoczności. Skupiamy się wyłącznie na mapie przekierowań: skąd wziąć listę adresów, jak dobrać pary, jak przetestować całość przed przełączeniem i jak długo trzymać reguły po wdrożeniu. Fakty o zachowaniu Googlebota pochodzą z dokumentacji Google; liczby bez źródła to redakcyjna reguła kciuka, nie wynik naszego testu.

Skąd wziąć pełną listę starych adresów

Mapa przekierowań jest tak dobra, jak lista adresów, od której się zaczyna. Crawl serwisu pokaże tylko strony podlinkowane wewnętrznie, a to zwykle mniej niż połowa adresów, które Google zna. Brakuje w nim starych wpisów wyjętych z menu, wersji z parametrami, stron kampanii i adresów z poprzednich migracji, do których wciąż prowadzą linki z zewnątrz. Dlatego listę skleja się z kilku źródeł:

• crawl całego serwisu z kodem odpowiedzi i adresem kanonicznym każdej strony,
• wszystkie mapy witryny, także stare pliki zgłoszone kiedyś w Search Console,
• eksport stron z raportu Skuteczność w Search Console za 16 miesięcy (to maksimum, jakie trzyma narzędzie),
• strony docelowe z analityki, najlepiej z konwersjami,
• adresy z linkami zewnętrznymi z narzędzia do analizy linków,
• logi serwera z ostatnich miesięcy, filtrowane po Googlebocie.

Logi są najczęściej pomijane, a dają adresy, których nie zna żadne inne źródło: stare paginacje, pliki PDF, zasoby z dawnych wersji szablonu. Po scaleniu i usunięciu duplikatów każdy adres dostaje kolumny z ruchem, liczbą linkujących domen i konwersjami. To pozwala ustalić priorytety: najcenniejsze 10–20 procent adresów dopasowuje się ręcznie, resztę obsługują reguły.

Zasada jeden do jednego i jej wyjątki

Podstawowa reguła brzmi: każdy stary adres prowadzi do najbliższego tematycznie odpowiednika na nowej stronie. Wpis o konfiguracji wtyczki trafia do tego samego wpisu pod nowym adresem, kategoria do kategorii, strona usługi do strony usługi. Google w dokumentacji o przenoszeniu witryny ze zmianą adresów URL zaleca stałe przekierowania po stronie serwera, czyli kody 301 lub 308. Dla wyszukiwarki oba kody znaczą to samo: silny sygnał, że adres docelowy powinien przejąć miejsce starego w indeksie.

Wyjątki są trzy. Pierwszy to konsolidacja: jeśli kilka krótkich wpisów łączysz w jeden obszerny tekst, wszystkie stare adresy mogą prowadzić do nowego, wspólnego artykułu. Google wprost dopuszcza taki przypadek. Drugi to zmiana struktury, przy której nowe adresy powstają według wzorca, na przykład /blog/2023/05/tytul zamienia się w /poradniki/tytul. Wtedy zamiast tysięcy par wystarczy jedna reguła z wyrażeniem regularnym, a ręczne pary dopisuje się tylko dla wyjątków. Trzeci to przekierowania tymczasowe (302, 307), które mają sens wyłącznie wtedy, gdy zmiana naprawdę jest chwilowa. Przy migracji kod 302 to najczęściej błąd konfiguracji, a nie świadoma decyzja, i Google traktuje go jako słaby sygnał.

Jeśli zmieniasz przy okazji architekturę serwisu, warto najpierw zaprojektować docelowe ścieżki, a dopiero potem budować pary. Zasady dobrych adresów i ich związek z linkowaniem opisujemy w przewodniku po strukturze URL i linkowaniu wewnętrznym.

Łańcuchy i pętle przekierowań: jak ich uniknąć

Łańcuch powstaje, gdy adres A prowadzi do B, a B do C. Najczęściej to spadek po wcześniejszej migracji: stare reguły z poprzedniej zmiany wskazują adresy, które teraz same zostaną przekierowane. Googlebot według dokumentacji kodów odpowiedzi HTTP podąża za maksymalnie 10 skokami, ale Google zaleca przekierowywać od razu do adresu końcowego, a jeśli to niemożliwe, trzymać łańcuch na poziomie najwyżej 3 skoków, na pewno poniżej 5. Każdy dodatkowy krok to też opóźnienie dla użytkownika.

Rozwiązanie jest mechaniczne. Przed wdrożeniem zbierz wszystkie istniejące przekierowania (z pliku konfiguracyjnego serwera, wtyczki, panelu CMS), a następnie podmień w nich adres docelowy na finalny adres z nowej mapy. Arkusz z dwiema kolumnami pozwala to sprawdzić formułą: jeśli adres docelowy jakiejś pary występuje jednocześnie w kolumnie adresów źródłowych, masz łańcuch.

Pętla to łańcuch, który wraca do punktu wyjścia, na przykład reguła dopisująca ukośnik koliduje z regułą, która go usuwa. Przeglądarka pokaże błąd zbyt wielu przekierowań, a robot porzuci adres. Pętle najczęściej pojawiają się na styku warstw: serwer, CDN i wtyczka w CMS jednocześnie próbują normalizować adres. Zasada praktyczna: jedna warstwa odpowiada za przekierowania, pozostałe ich nie dotykają.

Przekierowania stron, które nie mają odpowiednika

Nie każdy adres musi dostać parę. Strona wygasłej promocji, tag z jednym wpisem albo zduplikowana wersja do druku nie mają sensownego celu, a przekierowanie ich na siłę szkodzi. Google ostrzega, że masowe przekierowanie wielu adresów na jedną niepowiązaną stronę, typowo na stronę główną, może zostać potraktowane jak miękki błąd 404. Sygnały tych adresów i tak przepadną, a użytkownik trafi w miejsce, którego nie szukał.

Dla takich stron są trzy uczciwe opcje:

1. przekierowanie do strony nadrzędnej, jeśli realnie odpowiada na tę samą potrzebę (produkt wycofany bez następcy prowadzi do kategorii z podobnymi produktami),
2. kod 410, gdy treść została usunięta celowo i nie wróci,
3. kod 404 z pomocną stroną błędu, gdy adres nie ma wartości ani ruchu.

Decyzję podejmuj na podstawie danych z inwentaryzacji. Adres bez ruchu i bez linków zewnętrznych spokojnie może zwrócić 404. Adres z kilkunastoma linkującymi domenami zasługuje na najlepszy możliwy cel, nawet jeśli to tylko strona kategorii. W sklepach internetowych ten problem dotyczy setek wycofanych produktów; osobne zasady dla katalogu opisujemy w tekście o tym, jak przenieść sklep na nowy silnik.

Parametry, wersje z ukośnikiem i wielkość liter

Najwięcej niespodzianek dają drobiazgi, które w arkuszu wyglądają jak ten sam adres. Trzy z nich trzeba ustalić przed napisaniem pierwszej reguły.

Ukośnik na końcu. Adres /poradnik i /poradnik/ to dla serwera dwa różne zasoby. Wybierz jedną wersję dla nowej strony i upewnij się, że reguły migracji prowadzą od razu do niej. Częsty błąd: reguła migracji prowadzi do wersji z ukośnikiem, a serwer dokleja drugie przekierowanie do wersji bez niego. Powstaje łańcuch, którego nikt nie zaplanował.

Wielkość liter. Ścieżka w adresie URL rozróżnia wielkie i małe litery, a serwery na Linuksie traktują /Oferta i /oferta jako różne adresy. Jeśli stary serwis działał na serwerze, który wielkość liter ignorował, w linkach zewnętrznych mogą krążyć dziesiątki wariantów jednego adresu. Bezpieczne rozwiązanie to reguła sprowadzająca ścieżkę do małych liter przed dopasowaniem mapy, ale tylko jeśli nowa strona nie używa wielkich liter celowo.

Parametry. Adresy z parametrami śledzącymi (utm, identyfikatory kampanii) powinny trafiać do tej samej strony docelowej co adres bez parametrów, a parametry warto przenieść dalej, żeby analityka nie straciła źródeł ruchu. Parametry funkcjonalne, jak filtry czy sortowanie, wymagają osobnej decyzji: albo mają odpowiednik na nowej stronie, albo prowadzą do czystej wersji kategorii. Do tego dochodzą warianty hosta: HTTP i HTTPS, z www i bez www. Każdy z nich powinien jednym skokiem trafiać do finalnego adresu, a nie przechodzić przez kolejne normalizacje.

Testowanie mapy przed przełączeniem

Mapę testuje się na środowisku testowym, zanim zobaczy ją Googlebot. Wystarczy crawler w trybie listy albo prosty skrypt, który dla każdego starego adresu zapisze kolejne kody odpowiedzi i adres końcowy. Oczekiwany wynik dla każdej pary jest jeden:

Test automatyczny nie wystarczy dla najważniejszych adresów. Przy stronach, które przynoszą większość ruchu i konwersji, sprawdź ręcznie, czy cel ma ten sam tytuł, treść i intencję. Przekierowanie technicznie poprawne, ale prowadzące do uboższej strony, zachowa adres, a mimo to obniży pozycje.

Ten sam skrypt uruchom ponownie zaraz po przełączeniu, tym razem na produkcji. Środowisko testowe często różni się konfiguracją serwera, CDN albo kolejnością reguł, więc wynik ze stagingu nie gwarantuje wyniku na żywej stronie. Równolegle zgłoś w Search Console nową mapę witryny z docelowymi adresami; szczegóły jej przygotowania opisujemy w tekście o tym, co umieścić w sitemap XML.

Jak długo utrzymywać przekierowania

Google zaleca utrzymywać przekierowania tak długo, jak to możliwe, i co najmniej przez rok. Ten czas jest potrzebny, by wyszukiwarka ponownie odwiedziła stare adresy, przeniosła sygnały i przypisała do nowych stron linki z innych serwisów. Z perspektywy użytkowników warto trzymać je jeszcze dłużej, bo stare adresy żyją w zakładkach, dokumentach i wiadomościach e-mail przez lata. Przy zmianie domeny obowiązuje też wymóg narzędzia do zmiany adresu w Search Console: stara domena musi przekierowywać przez co najmniej 180 dni.

Koszt utrzymania jest niewielki, a ryzyko wyłączenia duże: linki zewnętrzne prowadzące do starych adresów zaczną kończyć się błędem 404. Jeśli lista reguł urośnie do rozmiarów, które spowalniają serwer, zamiast ją kasować, przenieś ją do wydajniejszej warstwy, na przykład do konfiguracji serwera zamiast wtyczki w CMS.

Według Google mała lub średnia witryna potrzebuje kilku tygodni, aby większość adresów została przetworzona po przeniesieniu. Spadek w tym okresie jest normalny. Jeśli jednak ruch nie wraca po dwóch miesiącach, a mapa przeszła testy, sprawdź, czy przyczyną nie jest coś niezależnego od migracji, na przykład zbieżna w czasie aktualizacja algorytmu. Jak odróżnić jedno od drugiego, wyjaśniamy w tekście o tym, jak działają aktualizacje algorytmów Google w 2026 roku.

FAQ