Checklista przekierowań przy migracji strony: 15 kontroli przed zmianą DNS
Użyj 15-punktowej checklisty przekierowań, aby ochronić URL-e o najwyższej wartości, uniknąć łańcuchów i wychwycić błędy migracji zanim zmienisz DNS.

Migracja strony wygrywa albo przegrywa na dyscyplinie przekierowań częściej niż na designie, kodzie czy samym komunikacie launchowym. Zanim zmienisz DNS, najważniejsze pytanie brzmi: czy każdy ważny stary URL trafia do właściwego nowego celu jednym czystym skokiem?
Ta checklista jest dla zespołów, które przenoszą:
- stronę na nową domenę,
- projekt do nowego CMS-a,
- monolit do architektury headless,
- subdomenę do root domeny,
- starszą strukturę docsów albo bloga do nowego systemu URL.
Jeśli potrzebujesz przykładu stricte e-commerce, przeczytaj też jak przenieść Shopify do headless bez utraty SEO i URL-i. Ten materiał jest szerszą checklistą, którą da się zastosować niemal do każdego stacku.
Jeśli migracja obejmuje również zmianę domeny z wildcard forwardingiem, trzymaj obok też poradnik jak przekierować domenę bez utraty ścieżki i parametrów UTM.
Cel, którego nie można negocjować
Przed startem chcesz, żeby wszystkie poniższe punkty były prawdziwe:
- stare URL-e o wysokiej wartości trafiają do właściwych nowych URL-i,
- trwałe zmiany używają trwałego zamiaru przekierowania,
- przekierowania rozwiązują się jednym skokiem, kiedy tylko to możliwe,
- linki wewnętrzne już wskazują nowe canonical URL-e,
- monitoring po starcie jest gotowy, zanim ruch zostanie przełączony.
Jeśli któregoś z tych punktów brakuje, ryzyko migracji rośnie bardzo szybko.

Checklista przekierowań
1. Zinwentaryzuj aktualne URL-e
Nie planuj przekierowań z pamięci.
Wyciągnij URL-e z:
- XML sitemap,
- landing pages z analityki,
- top stron z Search Console,
- aktywnych URL-i kampanii,
- szablonów e-maili,
- backlinków i docsów partnerów,
- starszych wpisów blogowych i artykułów supportowych.
Jeśli URL ma ruch z wyszukiwarki, kampanii albo supportu, powinien znaleźć się w inwentarzu migracyjnym.
2. Wybierz finalny canonical hostname na początku
Zanim zaczniesz pisać reguły, ustal jeden standard:
https://nowa-marka.example- albo
https://www.nowa-marka.example
Nie zostawiaj decyzji o hoście „na później”. Właśnie stąd biorą się łańcuchy typu http -> https -> www -> final.
3. Trzymaj mapę przekierowań w realnym arkuszu albo CSV
Minimum kolumn:
old_url,new_url,status,priority,owner,notes
https://stara-marka.example/cennik,https://nowa-marka.example/cennik,301,high,marketing,core landing page
https://stara-marka.example/docs/api,https://nowa-marka.example/docs/api,301,high,engineering,docs migrationTo daje jeden wspólny punkt odniesienia dla marketingu, SEO, engineeringu i supportu.
4. Chroń najcenniejsze URL-e najpierw
Na pierwszym miejscu ustaw:
- homepage,
- pricing,
- docs,
- top landing pages z organicu,
- strony kampanii,
- URL-e supportowe używane w e-mailach.
Nie poświęcaj tyle samo czasu archiwum o niskim ruchu, co swoim najważniejszym stronom konwersyjnym.
5. Dopasuj stary URL do najlepszego nowego celu
Celem nie zawsze jest zachowanie ścieżki jeden do jednego. Celem jest najlepszy możliwy nowy adres.
Dobre przykłady:
- stara strona produktu -> nowa strona produktu,
- stary artykuł docs -> odpowiedni nowy artykuł,
- wygaszona strona kampanii -> najbliższa aktualna oferta.
Złe przykłady:
- wszystko -> homepage,
- wygasłe docs -> homepage,
- zepsute deep linki -> ogólna kategoria bez kontekstu.
6. Używaj trwałych przekierowań dla trwałych zmian
Jeśli stary URL nie wróci, stosuj trwały zamiar przekierowania.
Jeśli nie masz pewności co do kodu statusu, wróć do 301 vs 302 vs 307 vs 308.
Kluczowe jest to, żeby nie zostawiać trwałej migracji na przekierowaniu o charakterze tymczasowym przez długie miesiące.
7. Zachowuj strukturę ścieżki tam, gdzie to nadal ma sens
Jeśli nowy serwis zachowuje podobną strukturę, reguły path-preserving zmniejszają ilość pracy ręcznej.
Przykłady:
/docs/*->/docs/*/blog/*->/blog/*/features/*->/features/*
Jeśli nowa struktura zmienia się mocno, lepiej dodać jawne mapowania dla URL-i o najwyższej wartości niż liczyć, że wildcard wszystko załatwi.
8. Zachowaj ważne parametry query
To jest ważne dla:
- atrybucji kampanii,
- parametrów afiliacyjnych,
- linków śledzących z e-maili i lifecycle,
- parametrów funkcjonalnych używanych przez stronę albo aplikację.
Nie każdy parametr query musi żyć wiecznie, ale te istotne powinny być obsłużone świadomie.
9. Usuń łańcuchy przekierowań jeszcze przed startem
Nie czekaj, aż PageSpeed albo użytkownicy powiedzą Ci, że ścieżka przekierowania jest chaotyczna.
Skróć łańcuchy od razu:
stary-url -> pośredni-url -> finalny-urlpowinno zamienić się w:
stary-url -> finalny-urlJeśli potrzebujesz głębszego procesu debugowania, wróć do łańcuchów i pętli przekierowań.
10. Testuj na stagingu albo hostach kontrolowanych
Przed publicznym cutoverem sprawdź:
- homepage,
- top landing pages,
- ścieżki docs,
- wpisy blogowe,
- URL-e z parametrami,
- ścieżki mobile-targeted, jeśli istnieją.
Rób zarówno testy w przeglądarce, jak i proste testy CLI:
curl -IL https://stara-marka.example/docs/api11. Zaktualizuj linki wewnętrzne przed albo tuż po starcie
Przekierowania są siatką bezpieczeństwa. Linki wewnętrzne powinny nadal prowadzić bezpośrednio do nowych canonical URL-i.
Dotyczy to:
- nawigacji,
- stopki,
- linków w treści,
- CTA produktowych,
- sidebarów w docs,
- szablonów e-mailowych, jeśli migracja zmienia publiczne URL-e.
12. Zaktualizuj sitemapę, canonicals i nawigację
Mapa przekierowań to tylko fragment migracji. Równolegle zaktualizuj:
- XML sitemap,
- canonical tags,
- hreflang, jeśli występuje,
- główną nawigację,
- URL-e w danych strukturalnych, jeśli to potrzebne.
Jeśli przekierowania mówią jedno, a canonicals drugie, tworzysz sobie sprzątanie na później.
13. Przygotuj monitoring po starcie jeszcze przed startem
Na pierwsze 7-14 dni po migracji przygotuj plan:
- śledzenia 404,
- sprawdzania najważniejszych przekierowanych URL-i,
- monitorowania ruchu na stronach o wysokiej wartości,
- przeglądu linków kampanii,
- potwierdzenia, że docs i support nadal trafiają tam, gdzie trzeba.
Właśnie tutaj analityka, Redirect Checker i Broken Link Monitor stają się realnie przydatne.
14. Utrzymaj starą warstwę przekierowań wystarczająco długo
Jednym z najczęstszych błędów jest traktowanie przekierowań jak zadania „na tydzień po starcie”. W praktyce stare linki potrafią dostawać ruch miesiącami albo latami.
Dotyczy to szczególnie:
- backlinków,
- zakładek,
- PDF-ów,
- docsów partnerów,
- starych postów social media.
Planuj trwałość redirect layer, a nie tylko przetrwanie tygodnia launchowego.
15. Udokumentuj wyjątki i edge case’y
Nie każdy URL zasługuje na przekierowanie. Niektóre powinny zwracać 404 albo 410. Część starych ścieżek aplikacji może wymagać logiki urządzeń zamiast zwykłego przekierowania.
Udokumentuj takie przypadki wprost, żeby później nie zamieniły się w „dziwne zachowanie, którego nikt już nie pamięta”.
Praktyczna kolejność działań
Jeśli chcesz najkrótszego sensownego rolloutowego porządku:
- wyeksportuj URL-e,
- wybierz canonical host,
- zbuduj mapę przekierowań,
- przetestuj top URL-e,
- usuń łańcuchy,
- zaktualizuj linki wewnętrzne i sitemapę,
- uruchom migrację,
- monitoruj 404 oraz ruch przekierowany.
Taka kolejność porządkuje pracę między engineeringiem, marketingiem i SEO.
Gdzie pomaga UrlEdge
UrlEdge szczególnie dobrze sprawdza się wtedy, gdy migracja potrzebuje:
- importu przekierowań hurtowo,
- wildcard path forwardingu,
- szybkiej globalnej propagacji,
- narzędzi QA dla przekierowań,
- obserwowalności ruchu po starcie.
To szczególnie przydatne wtedy, gdy nie chcesz rozrzucać logiki przekierowań między kod aplikacji, reverse proxy, pluginy CMS i funkcje forwardingu u dostawcy DNS.
FAQ
Czy każdy stary URL powinien gdzieś przekierowywać?
Nie. Część przestarzałych URL-i powinna zwracać prawdziwy stan błędu. Ale strony, które nadal mają wartość biznesową albo wyraźne oczekiwanie użytkownika, powinny prowadzić do sensownego celu.
Czy przekierowanie wszystkiego na homepage jest akceptowalne?
Zwykle nie. To jedna z najsłabszych strategii migracyjnych, bo wyrzuca intencję ścieżki i frustruje zarówno użytkowników, jak i crawlery.
Jak długo trzymać przekierowania migracyjne?
Dłużej, niż większość zespołów zakłada. Ważne przekierowania często muszą zostać znacznie dłużej niż sam miesiąc po premierze.
Co testować najpierw, jeśli czasu jest mało?
Na pierwszym miejscu: homepage, pricing, docs, top landing pages, aktywne linki kampanii i URL-e z najsilniejszym historycznym ruchem.
Powiązane materiały UrlEdge
- Bulk URL Management
- Permanent 301 Redirects
- Łańcuchy i pętle przekierowań
- Migracja Shopify do headless
Rzetelne źródła
Chcesz lepiej uporządkować swoje przekierowania?
Zacznij korzystać z UrlEdge i zarządzaj ruchem na edge.
ZacznijPowiązane artykuły
Zobacz wszystko
Alternatywa dla Firebase Dynamic Links po wyłączeniu usługi
Firebase podaje, że Dynamic Links zostało wyłączone 25 sierpnia 2025. Zobacz, jak zastąpić je smart linkami, app links i lepiej kontrolowaną ścieżką zapasową.

301 vs 302 vs 307 vs 308: które przekierowanie wybrać?
301 i 308 nadają się do zmian trwałych, a 302 i 307 do tymczasowych. Kluczowe pytanie brzmi: czy metoda HTTP musi pozostać bez zmian?