UrlEdge
Wróć do bloga
2026-03-12 UrlEdge Editorial7 min read

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.

Mały zespół planujący i weryfikujący checklistę migracji strony przy laptopie

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:

  1. stare URL-e o wysokiej wartości trafiają do właściwych nowych URL-i,
  2. trwałe zmiany używają trwałego zamiaru przekierowania,
  3. przekierowania rozwiązują się jednym skokiem, kiedy tylko to możliwe,
  4. linki wewnętrzne już wskazują nowe canonical URL-e,
  5. 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.

Zespół planujący migrację strony przy laptopie i sprawdzający redirecty, QA oraz launch checklistę

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 migration

To 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-url

powinno zamienić się w:

stary-url -> finalny-url

Jeś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/api

11. 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:

  1. wyeksportuj URL-e,
  2. wybierz canonical host,
  3. zbuduj mapę przekierowań,
  4. przetestuj top URL-e,
  5. usuń łańcuchy,
  6. zaktualizuj linki wewnętrzne i sitemapę,
  7. uruchom migrację,
  8. 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

Rzetelne źródła

Chcesz lepiej uporządkować swoje przekierowania?

Zacznij korzystać z UrlEdge i zarządzaj ruchem na edge.

Zacznij

Powiązane artykuły

Zobacz wszystko