Migracje witryn

TL;DR — Migracja witryny to każda duża zmiana w serwisie, która może przenieść adresy URL lub zmienić sposób, w jaki Google je odczytuje — nowa domena, przejście na HTTPS, nowa platforma, reorganizacja folderów, a nawet redesign. Sposób ochrony ruchu jest za każdym razem taki sam: przekieruj każdą starą stronę do najlepiej odpowiadającej jej nowej strony za pomocą przekierowania 301 i utrzymuj te przekierowania przez długi czas. Tymczasowy spadek ruchu jest normalny; jeśli ruch nigdy się nie odbuduje, coś się zepsuło.

Czym jest migracja witryny

“Migration” (tłumaczenie) „Migracja” brzmi dramatycznie — i czasami taka jest. Oznacza jednak po prostu istotną zmianę w witrynie, która może wpłynąć na to, jak wyszukiwarki znajdują, odczytują i pozycjonują jej strony. Przeniesienie do nowej domeny jest migracją. Przejście z http:// na https:// jest migracją. Przeniesienie bloga z blog.example.com do example.com/blog/ jest migracją. Nawet redesign, który zachowuje wszystkie adresy URL bez zmian, liczy się jako migracja, ponieważ zmieniają się treści i szablony oceniane przez Google.

Łączy się je w jedną grupę, ponieważ wiążą się z tym samym ryzykiem i wymagają tego samego schematu działania.

Jedna zasada, która ma największe znaczenie

Gdy adres URL się zmienia, trzeba poinformować przeglądarki i wyszukiwarki, dokąd przeniesiono stronę. Służy do tego przekierowanie — konkretnie przekierowanie 301 (stałe), które mówi: “this page moved here for good.” (tłumaczenie) „ta strona została tu przeniesiona na stałe”. To właśnie przekierowania faktycznie przenoszą pozycje ze starych adresów URL na nowe. Google twierdzi, że przekierowania 301 i inne przekierowania stałe nie powodują utraty PageRank.

Najważniejsza część: przypisz każdej starej stronie jedną, najlepiej dopasowaną nową stronę. Nie przekierowuj wszystkiego na stronę główną. Jeśli stara strona produktu nie ma rzeczywistego odpowiednika, przekieruj ją do najbliższej kategorii, a nie na stronę główną. Google i tak traktuje zbiór starych stron przekierowanych na stronę główną jak błędy 404 “page not found” (tłumaczenie) „nie znaleziono strony”, więc nie daje to żadnej korzyści.

Częste błędy

• “Redirects lose my link credit.” (tłumaczenie) „Przekierowania powodują utratę wartości moich linków”. Nie powodują. Stałe przekierowania nie kosztują Cię PageRank. Ten mit nie żyje od lat.
• “The Change of Address tool moves my site for me.” (tłumaczenie) „Narzędzie Change of Address przenosi moją witrynę za mnie”. Nie przenosi. To narzędzie Google Search Console jedynie informuje Google o przeniesieniu do nowej domeny — właściwą pracę wykonują przekierowania. Działa też tylko przy przenoszeniu całej domeny, a nie przy przejściu na HTTPS czy reorganizacji folderów.
• “My traffic dropped, the migration failed.” (tłumaczenie) „Mój ruch spadł, więc migracja się nie udała”. Zwykle nie. Tymczasowe wahanie, gdy Google ponownie porządkuje informacje, jest normalne. Daj temu kilka tygodni. Dowód potwierdzający to twierdzenie Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Zakres: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Site move with URL changes
• “I can take the redirects down after a few months.” (tłumaczenie) „Mogę wyłączyć przekierowania po kilku miesiącach”. Utrzymuj je znacznie dłużej — najlepiej przez lata, a tam, gdzie to możliwe, właściwie bezterminowo.

Zmieniaj jedną rzecz naraz

Największym ryzykiem każdej migracji jest zmiana zbyt wielu rzeczy jednocześnie. Nowa domena i nowa platforma i nowa struktura adresów URL tego samego dnia to trzy nałożone na siebie migracje, a ryzyko się potęguje. Jeśli możesz podzielić dużą zmianę na etapy, zrób to.

Chcesz poznać cały proces — siedem faz, strategię przekierowań i listę kontrolną dopasowaną do każdego rodzaju migracji? Przejdź do karty Advanced.

TL;DR — Ryzyko migracji to zakres zmian × liczba zmian wykonywanych jednocześnie. Przekierowania 301/308 stanowią kręgosłup — przenoszą pozycje i nie powodują utraty PageRank; wszystko inne (narzędzie Change of Address, mapy witryny, linki wewnętrzne, adresy kanoniczne) jest sygnałem wspierającym. Mapuj stare→nowe w relacji 1:1, nigdy nie przekierowuj masowo na stronę główną (soft 404), unikaj łańcuchów i utrzymuj przekierowania znacznie dłużej, niż sugeruje zapis “12 months” (tłumaczenie) „12 miesięcy”. Spodziewaj się tymczasowych wahań i odbudowy; trwały spadek oznacza, że coś się zepsuło — zwykle aktywna blokada środowiska stagingowego, usunięty hreflang/adres kanoniczny, przypadkowy noindex albo przekierowania do niewłaściwych stron. Poniżej: uniwersalny proces w 7 fazach, a następnie każdy z 7 rodzajów migracji wraz z typowymi pułapkami.

Ten materiał obejmuje klasyfikację, zasady, model ryzyka, decyzje dotyczące rodzaju migracji oraz diagnozowanie odbudowy. Skorzystaj z listy kontrolnej migracji witryny, aby uzyskać wykonalną sekwencję zadań, wskazanych właścicieli, bramki wydania i kryteria akceptacji.

Czym naprawdę jest migracja (i jej 7 rodzajów)

Migracja witryny to każda istotna zmiana struktury adresów URL, domeny, platformy, protokołu lub hostingu, która może wpłynąć na sposób, w jaki wyszukiwarki ją crawlują, indeksują i pozycjonują. Pojęcie obejmuje wszystko: od jednolinijkowego przejścia na HTTPS po pełny rebranding, w którym setki tysięcy adresów URL trafiają do nowej domeny na nowym CMS-ie.

Najbardziej użyteczną rzeczą, jaką możesz zrobić przed napisaniem choćby jednego przekierowania, jest sklasyfikowanie migracji — i zauważenie, że większość rzeczywistych migracji łączy kilka rodzajów naraz. Oto siedem rodzajów, w przybliżeniu uporządkowanych według ryzyka:

Liczby odpowiadają kolejności sekcji w szczegółowym omówieniu poniżej; tabela jest posortowana według ryzyka, aby pokazać, gdzie mieści się Twoja migracja. Ryzyko = zakres zmian × liczba zmian wykonywanych jednocześnie. Redesign przy tych samych adresach URL ma niskie ryzyko. Jednoczesna zmiana domeny + restrukturyzacja adresów URL + zmiana platformy to trzy nakładające się rodzaje wysokiego ryzyka — Google samo zaleca zmieniać jedną rzecz naraz.

Uniwersalny proces migracji

Ten proces dotyczy każdego rodzaju migracji, zanim dodasz opisane niżej kroki właściwe dla danego typu. Przeprowadziłem wiele takich migracji i wspólny mianownik każdej udanej jest taki sam: do powodzenia migracji potrzeba czegoś więcej niż listy kontrolnej. Lista chroni przed pominięciem kroków; o powodzeniu decydują proces i udział SEO na każdym etapie.

Faza 1 — Planowanie

• Sklasyfikuj każdy występujący rodzaj. Zmiana platformy, która zarazem restrukturyzuje adresy URL i przenosi witrynę do nowej domeny, to trzy migracje jednocześnie. Nazwij je wszystkie z góry, aby określić rzeczywiste ryzyko.
• Ustal oczekiwania z kierownictwem przed uruchomieniem, nie po nim. Ruch niemal na pewno będzie się wahał. Uprzedź interesariuszy, że tymczasowy spadek jest normalny i oczekiwany — aby zwykłe wahanie nie wywołało panicznego rollbacku.
• Zawsze miej plan wycofania zmian. Zawsze powinien istnieć sposób powrotu do pierwotnego stanu, nawet jeśli zakładasz jego użycie tylko w skrajnych sytuacjach.
• Zaplanuj uruchomienie na okres małego ruchu. Google zaleca, by w miarę możliwości przeprowadzać przenosiny przy niższym ruchu. W praktyce: od poniedziałku do czwartku, nie w piątki ani w szczycie sezonu sprzedażowego — tak, aby zespół był dostępny do naprawy problemów, a podczas stabilizacji zagrożony był mniejszy przychód.
• Wyznacz kierownika projektu SEO i używaj systemu zarządzania projektami. Migracje obejmują development, treści, analitykę i SEO; ktoś musi odpowiadać za mapę zależności.

Faza 2 — Benchmark i crawl starej witryny

Nie da się przeprowadzić QA migracji bez obrazu “before” (tłumaczenie) „przed”. Uchwyć go, dopóki stara witryna jest jeszcze dostępna:

• Pełny crawl starej witryny (Screaming Frog, Ahrefs Site Audit lub odpowiednik). Zapisz go. Po uruchomieniu będzie bazą do porównania różnic.
• Zbierz wszystko dla każdego adresu URL: kody statusu, tytuły, metaopisy, tagi kanoniczne, hreflang, strukturę nagłówków, strukturę linków wewnętrznych i Core Web Vitals.
• Zapisz pozycje wszystkich kluczowych stron przed uruchomieniem.
• Wyeksportuj benchmarki ruchu — dane skuteczności z Search Console (ostatnie 3/6/12 miesięcy) oraz dane GA4 na poziomie strony/sesji.
• Wyeksportuj najlepsze strony według linków zwrotnych (Ahrefs + raport Links w GSC). Te adresy URL bezwzględnie muszą być poprawnie przekierowane — przenoszą wartość linków.
• Zbierz każde istniejące przekierowanie z każdego źródła: CMS-a, CDN-u, konfiguracji .htaccess/serwera, raportu Search Console Page with redirect oraz analityki. Pominięcie jednego źródła tworzy po uruchomieniu łańcuchy przekierowań.
• Przeprowadź audyt starszych problemów, zanim je przeniesiesz. Nowa domena lub CMS nie usprawiedliwia importowania starych błędów kanonicznych, rozrostu indeksu ani blokad crawlowania.

Faza 3 — Mapowanie adresów URL

Utwórz arkusz z mapowaniem jeden do jednego: każdy stary adres URL → jeden najlepiej dopasowany nowy adres URL. Bez wyjątków — każdy adres URL otrzymuje rozstrzygnięcie.

• Usunięte strony z bliskim odpowiednikiem: przekieruj do najbliższej aktywnej strony o powiązanej tematyce. Google mówi jasno: nie przekierowuj wielu starych adresów URL do jednego nieistotnego miejsca docelowego, takiego jak strona główna. Dowód potwierdzający to twierdzenie Google advises against redirecting many old URLs to one irrelevant destination such as the home page and says that can be treated as a soft 404. Zakres: Google Search guidance for site moves with changed URLs; relevant replacements remain appropriate. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Site move with URL changes
• Strony bez żadnego odpowiednika: zwróć prawidłowy kod 410 (usunięto) lub 404. Nie przekierowuj ich na stronę główną — zostanie to potraktowane jako soft 404.
• Śledzenie poszczególnych adresów URL jest najważniejsze, ponieważ daje jasną mapę tego, czym każdy adres był i czym powinien się stać. Ta mapa jest migracją.

Faza 4 — Strategia przekierowań

To kręgosłup całego projektu.

• Przy stałych przenosinach używaj 301 (Moved Permanently) lub 308. Google zaleca stałe przekierowania po stronie serwera, takie jak 301 i 308.
• Przekierowania 301 przenoszą PageRank — kropka. Dokumentacja Google mówi, że stałe przekierowania nie powodują utraty PageRank, a Gary Illyes potwierdził już lata temu, że przekierowania 30x nie tracą PageRank. Każdy poradnik twierdzący, że stałe przekierowania wyciekają wartość linków, jest nieaktualny. Dowód potwierdzający to twierdzenie Google says 301 and other permanent redirects do not cause a loss in PageRank. Zakres: Google Search handling of permanent redirects during site moves; this does not guarantee unchanged rankings after a migration. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Site move with URL changes
• Unikaj łańcuchów przekierowań. Mapuj stary → nowy bezpośrednio. Google zaleca krótkie łańcuchy — najlepiej nie więcej niż 3 i mniej niż 5. Googlebot podąży za około 10 skokami, więc krótkie łańcuchy nie są katastrofalne, ale każdy skok to możliwość awarii i opóźnienie konsolidacji sygnałów. Częstym, cichym źródłem łańcuchów jest niespójność końcowego ukośnika (/page wobec /page/) — wybierz jedną postać kanoniczną i przekieruj drugą.
• Przekieruj też zasoby — obrazy, pliki PDF i inne pliki nie-HTML, nie tylko strony.
• Tylko po stronie serwera. Przekierowania JavaScript są ostatecznością; Google może ich nigdy nie przetworzyć, jeśli renderowanie się nie powiedzie.
• Nie myl przekierowań tymczasowych ze stałymi. 302/307 nie informuje procesu indeksowania, że cel powinien być kanoniczny — stary adres URL pozostaje w indeksie, a sygnały w większości zostają na miejscu. Używaj przekierowań tymczasowych wyłącznie w rzeczywiście tymczasowych sytuacjach.
• Utrzymuj przekierowania znacznie dłużej niż “one year.” (tłumaczenie) „jeden rok”. Minimalny okres Google to “at least 1 year” (tłumaczenie) „co najmniej rok”, ale Illyes wyjaśnił, że wartość około 12 miesięcy służy przede wszystkim Google — użytkownicy docenią, jeśli przekierowania pozostaną właściwie na zawsze. Bing skłania się ku minimum 1–2 lat. Moja zasada: utrzymuj je tak długo, jak stare adresy URL pozyskują jakikolwiek ruch lub linki, co w praktyce oznacza bezterminowo. Dowód potwierdzający to twierdzenie Google recommends keeping site-move redirects as long as possible, generally for at least one year. Zakres: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Site move with URL changes

Faza 5 — Staging i testy przed uruchomieniem

• Zablokuj indeksowanie witryny stagingowej — użyj noindex i/lub reguły Disallow w robots.txt na hoście stagingowym. Ogranicz dostęp do środowiska stagingowego lub deweloperskiego, aby przede wszystkim zapobiec jego indeksowaniu. (I zanotuj tę blokadę na Fazę 6 — przy uruchomieniu musi zostać usunięta.)
• Używaj tymczasowej nazwy hosta (np. beta.example.com) do testów publicznych.
• Przetestuj każde przekierowanie stary → nowy. Często przekierowuje się do niewłaściwych (nieistniejących) adresów URL — wykonaj crawl pełnej listy starych adresów na stagingu i sprawdź, czy każdy prowadzi jednym skokiem do zamierzonej aktywnej strony.
• Porównaj crawl stagingu z bazą z Fazy 2: tytuły, metaopisy, tagi kanoniczne, hreflang, dane uporządkowane, meta robots, linki wewnętrzne i szybkość stron.
• Potwierdź, że adresy kanoniczne wskazują aktywną witrynę, a nie adresy stagingowe.
• Sprawdź działanie analityki (GA4, weryfikacja GSC, tag manager) oraz przetestuj formularze, checkout i inne ścieżki konwersji.
• Upewnij się, że Googlebot nie jest blokowany przez firewall ani ochronę DoS — potwierdź, że może dotrzeć do DNS-u i hosta.

Faza 6 — Uruchomienie

• Natychmiast usuń wszystkie blokady crawlowania — usuń noindex i reguły stagingowego robots.txt, które służyły tylko podczas budowy. To najczęstsza katastrofa migracyjna: uruchomienie witryny z nadal aktywną blokadą stagingu. Nie zapomnij usunąć blokad noindex lub robots.txt potrzebnych wyłącznie na czas migracji.
• Włącz jednocześnie wszystkie przekierowania 301.
• Zaktualizuj i ponownie prześlij bieżącą produkcyjną mapę witryny XML, zawierającą wyłącznie nowe kanoniczne adresy URL. Jeśli mapa starych adresów pomoże wykrywać lub monitorować przekierowania, prześlij ją jako oddzielną, wyraźnie tymczasową mapę; nigdy nie mieszaj starych i nowych zasobów, a starą mapę usuń, gdy przestanie dostarczać użytecznych danych. Zobacz wskazówki Google dotyczące przenoszenia witryn.
• Wyrywkowo sprawdź przekierowania narzędziem URL Inspection w GSC.
• Użyj narzędzia Change of Address — tylko przy przenoszeniu całej domeny (zobacz Rodzaj 1).
• W przypadku Bing prześlij adresy przez IndexNow — to obecny mechanizm. Stare narzędzie Site Move w Bing wycofano około 2021 roku, więc nie stosuj się do poradników, które nadal je zalecają. IndexNow pozwala przesłać po migracji wszystkie przeniesione adresy URL jednocześnie.
• Zapewnij wydajność serwera. Zaraz po przenosinach Google będzie crawlować nową witrynę intensywniej niż zwykle.

Faza 7 — Monitoring po uruchomieniu

• Spodziewaj się tymczasowych wahań. Google mówi, by podczas przenosin oczekiwać przejściowych wahań pozycji witryny. Spadek nie dowodzi niepowodzenia migracji. Martin Splitt zauważył, że jeśli dosłownie kopiujesz całą strukturę adresów URL i treść do nowej domeny, spadek wcale nie musi wystąpić.
• Znaj ramy czasowe. Według Google przeniesienie większości stron średniej witryny w indeksie może zająć kilka tygodni; większe witryny potrzebują więcej czasu. Pełna stabilizacja często trwa kilka miesięcy.
• Diagnozuj spadki, które się nie odbudowują. Prawie nigdy nie powodują ich same „przenosiny”. Najbardziej użyteczna obserwacja Gary’ego Illyesa o migracjach brzmi: spadki ruchu po przenosinach zwykle wynikają z brakujących lub niepożądanych tagów/dyrektyw w nowej witrynie — usuniętego hreflang, dodatkowego noindex, uszkodzonych adresów kanonicznych. Najpierw sprawdź tę listę.
• Masowo wykonaj QA przekierowań — ponownie wykonaj crawl listy starych adresów i potwierdź, że każdy zwraca 301 do właściwej aktywnej strony (bez łańcucha i bez 404 na końcu).
• Obserwuj wybór adresu kanonicznego. Jeśli wiele linków zewnętrznych — oraz zabłąkanych linków wewnętrznych — nadal wskazuje stary adres URL, Google może dalej indeksować stary, a nie nowy adres. Dlatego aktualizacja linków wewnętrznych jest równie ważna jak przekierowania, a kontakt z autorami najważniejszych linków (świeże linki bezpośrednie są lepsze od przekierowanych) wart jest wysiłku.
• Monitoruj w GSC: raport indeksowania stron, Performance (kliknięcia/wyświetlenia według strony), statystyki crawlowania i nowe działania ręczne. Przez pierwszy miesiąc zapisuj pozycje co tydzień. Bing zaleca obserwowanie logów serwera przez co najmniej trzy miesiące po migracji.

Czy przekierowanie zadziałało? Pomiar wpływu bez oszukiwania samego siebie

Nie oceniaj migracji na podstawie zrzutu z dnia uruchomienia. Ustal stare adresy URL, nowe adresy URL, grupy zapytań/stron i metryki przed uruchomieniem, a następnie analizuj te same kohorty w czterech punktach kontrolnych:

W każdym punkcie kontrolnym porównuj okres po zmianie z równoważnym okresem przed zmianą i wyklucz dzień zmiany. Dzień uruchomienia miesza stary i nowy stan, częściowe wdrożenia, zmiany pamięci podręcznej, ruch QA i przerwy w śledzeniu; przypisanie go do którejkolwiek strony zanieczyszcza porównanie. Zachowaj stałe definicje kohort i metryk, a segmentację według brand/non-brand, urządzenia, kraju, szablonu lub rodzaju migracji stosuj tylko wtedy, gdy te przekroje były częścią planu pomiaru.

Zanim przypiszesz migracji wzrost lub stratę, oznacz inne zmiany w tym oknie: wydania, aktualizacje treści, zmiany śledzenia, sezonowość, kampanie oraz historię potwierdzonych aktualizacji rankingu Google. Nakładająca się aktualizacja algorytmu nie dowodzi ani niewinności, ani winy migracji; oznacza zaburzoną atrybucję, więc raportuj niepewność i w większym stopniu opieraj się na bezpośrednich dowodach wdrożeniowych, takich jak testy odpowiedzi, pokrycie indeksu, wybór adresu kanonicznego i logi serwera.

“No change” (tłumaczenie) „Brak zmiany” to prawidłowy wynik. Zadaniem przekierowania często jest zachowanie dostępu, sygnałów i konwersji podczas przenoszenia adresów URL. Płaskie wyniki przy czystych odpowiedziach jednym skokiem mogą oznaczać sukces. Zapisz ten wniosek zamiast szukać historii wzrostu, której dane nie potwierdzają.

Planowane narzędzie Before/After Impact Checker należy do tego miejsca w procesie: gdy zostanie udostępnione, będzie mogło standaryzować wykluczanie dnia zmiany i porównania po 7/14/30/90 dniach. Do tego czasu używaj arkusza kalkulacyjnego lub warstwy raportowej i zapisuj dokładne zakresy dat, filtry, kohortę oraz adnotacje dla każdego punktu kontrolnego.

7 rodzajów migracji

Opisany wyżej uniwersalny proces stanowi większość pracy. Poniżej znajdują się elementy właściwe dla każdego rodzaju — pułapki i obowiązkowe działania, które często zaskakują zespoły.

Rodzaj 1 — Zmiana domeny / rebranding

Na czym polega: przeniesienie wszystkich stron z oldbrand.com do newbrand.com — nowa domena, nowa usługa w GSC, najlepiej bez jednoczesnych zmian struktury adresów URL.

Ryzyko: najwyższe. Każdy adres URL się zmienia, linki zewnętrzne wymagają aktualizacji, a historia GSC zostaje podzielona między dwie usługi.

Pułapki i obowiązkowe działania:

• Nie łącz zmiany domeny z redesignem i restrukturyzacją adresów URL. Własna dokumentacja narzędzia Change of Address ostrzega, że połączenie przenosin domeny z redesignem treści i struktury URL prawdopodobnie spowoduje pewną utratę ruchu. Najpierw przenieś domenę; strukturę zmień później.
• Sprawdź historię nowej domeny przed jej rejestracją. Sprawdź archive.org — wcześniej zarejestrowana domena z historią działań ręcznych może od początku zaszkodzić nowej marce.
• Nie pozwól wygasnąć starej domenie. Przedłużaj ją i utrzymuj przekierowania; jeśli wygaśnie i przejmie ją ktoś inny, przekierowania (i wartość linków) znikną.
• Nie twórz łańcucha zmian domeny (A → B, a zaraz potem B → C). Narzędzia Change of Address nie można łączyć w łańcuch.

Narzędzie Change of Address — co robi, a czego nie robi. Wokół tego powstaje najwięcej nieporozumień. Narzędzie informuje Google, by kładło nacisk na crawling i indeksowanie nowej witryny, przekazuje sygnały i preferuje adresy kanoniczne nowej witryny — przez 180 dni. Co istotne:

• Działa przy przenoszeniu domeny lub subdomeny bez zakresu ścieżki — nie przy przenoszeniu pojedynczych stron lub folderów wewnątrz witryny.
• Musisz być zweryfikowanym właścicielem kwalifikujących się starych i nowych usług Search Console. Kwalifikuje się usługa domeny, podobnie jak usługa z prefiksem URL na poziomie katalogu głównego; usługa z prefiksem URL ograniczona do ścieżki się nie kwalifikuje. Zobacz wymagania Change of Address i wskazówki dotyczące kwalifikowania usług.
• To ścisłe przenosiny 1:1 — narzędzia nie można używać do łączenia ani częściowych przenosin.
• Jest opcjonalne, a nie wymagane. To jeden dodatkowy sygnał; jeśli przekierowania są ustawione prawidłowo, poradzisz sobie bez niego. Właściwą pracę wykonują 301; narzędzie jedynie przyspiesza i uściśla komunikat. (Osobne, szczegółowe omówienie Change of Address znajduje się w klastrze Search Engine Tools.)

Okno 180 dni nie jest terminem wyłączenia przekierowań. Po 180 dniach Google nie rozpoznaje już za pomocą narzędzia relacji między starą i nową witryną — traktuje starą witrynę jako niepowiązaną. Właśnie dlatego przekierowania muszą działać dłużej niż narzędzie. Utrzymuj je przez co najmniej rok (minimum Google), a realistycznie znacznie dłużej.

Rodzaj 2 — HTTP → HTTPS

Na czym polega: przejście z nieszyfrowanego HTTP na HTTPS (TLS/SSL). Każdy adres URL zmienia się z http:// na https://. HTTPS jest (lekkim) sygnałem rankingowym od 2014 roku; dziś korzystanie z HTTP stanowi aktywną wadę.

Ryzyko: niskie–średnie, jeśli wykonano poprawnie; wysokie, jeśli pojawią się problemy z certyfikatem lub mixed content.

Pułapki i obowiązkowe działania:

• NIE używaj narzędzia Change of Address. Google wyraźnie zaleca zamiast tego stosowanie wytycznych dotyczących przenosin witryny przy HTTP → HTTPS.
• Używaj przekierowań 301 dla każdego adresu URL, a nie reguły zbiorczej kierującej wszystko na stronę główną HTTPS. Im czytelniej zasygnalizujesz, że jest to tylko ogólna zmiana protokołu, tym płynniej Google ją przeprowadzi.
• Napraw mixed content. Każdy zasób (obraz, skrypt, arkusz stylów) nadal wczytywany przez HTTP po zmianie wywołuje ostrzeżenia i wysyła sprzeczne sygnały. Używaj adresów względnych wobec protokołu lub względnych — a Content Security Policy upgrade-insecure-requests szybko uporządkuje pozostałości.
• Google automatycznie preferuje HTTPS jako adres kanoniczny — z wyjątkiem nieważnego certyfikatu, niezabezpieczonych zależności (mixed content), przekierowania z powrotem do HTTP lub innych sprzecznych sygnałów. Źle wdrożony certyfikat nie tylko źle wygląda; może utrzymać wersję HTTP jako kanoniczną.
• Uważaj na HSTS. HSTS nakazuje przeglądarkom łączyć się wyłącznie przez HTTPS przez określony czas. Włącz go przed pełnym ustabilizowaniem TLS, a błąd certyfikatu stanie się twardą awarią dla powracających użytkowników. Dodaj go po uzyskaniu pewności, zaczynając od niskiego max-age i zwiększając go z czasem.
• Używaj silnego certyfikatu (2048-bit RSA lub EC; celuj w A/A+ w teście Qualys SSL) i ustaw flagę Secure dla ciasteczek.

Rodzaj 3 — Zmiana platformy / CMS

Na czym polega: przejście na nowy CMS lub stos technologiczny (np. WordPress → headless, Magento → Shopify). Często pociąga za sobą zmiany adresów URL, szablonów, linków wewnętrznych i renderowania.

Ryzyko: wysokie — ponieważ wiele rzeczy zmienia się jednocześnie.

Pułapki i obowiązkowe działania:

• Spodziewaj się zmian adresów URL — różne platformy generują różne struktury slugów, hierarchie kategorii i paginację. Zaplanuj mapę URL przed wyborem platformy, a nie po nim.
• Przekierowania nie przenoszą się automatycznie. Klasyczny błąd to brak skopiowania starszych przekierowań z plików .htaccess na nowy host. Zbierz reguły przekierowań ze wszystkich źródeł (CMS, CDN, konfiguracja serwera, raport GSC Page with redirect) przed zbudowaniem nowej warstwy przekierowań.
• Wdróż ponownie dane uporządkowane — nie zakładaj, że znaczniki schema zostaną przeniesione. Zweryfikuj je po uruchomieniu.
• Przetestuj renderowanie JavaScript, jeśli przechodzisz na interfejs headless/SPA — renderowanie zmienia sposób przetwarzania stron przez Googlebota. Renderowanie treści (szczególnie JavaScript) jest jednym z najważniejszych elementów mojego QA po migracji.
• Zmierz szybkość stron i mobile przed zmianą. Nowe motywy są często cięższe; Google indeksuje wersję mobilną, więc upewnij się, że nowa platforma nie jest wolniejsza ani uszkodzona na urządzeniach mobilnych.
• Wymuś spójność końcowego ukośnika — platformy obsługują go różnie, a niespójność po cichu tworzy łańcuchy przekierowań.
• Ponownie wdróż analitykę i tagi weryfikacyjne (GA4, GSC, tag manager) na nowej platformie przed uruchomieniem.
• Poważna restrukturyzacja, w której jednocześnie zmieniają się adresy URL, linki wewnętrzne i szablony, oznacza, że Google nie może po prostu zachować dotychczasowego obrazu witryny — oczekuj więc dłuższej stabilizacji niż przy przenosinach 1:1.

Rodzaj 4 — Zmiana struktury URL / restrukturyzacja witryny

Na czym polega: zmiana ścieżek URL w tej samej domenie — np. /category/post/ → /post/. Domena pozostaje bez zmian; treść może się zmienić lub pozostać taka sama.

Ryzyko: średnie. Autorytet domeny pozostaje nienaruszony, ale każdy zmieniony adres URL wymaga przekierowania, a graf linków wewnętrznych — aktualizacji.

Pułapki i obowiązkowe działania:

• Linki wewnętrzne to element, o którym ludzie zapominają. Wciąż widzę ten sam schemat: adresy URL zostają przekierowane, ale rel=canonical, nawigacja, stopka lub linki w treści nie są aktualizowane. Te nieaktualne sygnały znacznie utrudniają Google wybór nowych adresów jako kanonicznych — nawet przy działających przekierowaniach.
• Kanonikalizacja może się opóźniać. Jeśli stary URL ma więcej linków zwrotnych, a linki wewnętrzne nadal na niego wskazują, Google może preferować go jako kanoniczny nawet po przekierowaniu 301. Aktualizacja linków wewnętrznych bezpośrednio do nowych adresów URL jest kluczowa.
• NIE używaj narzędzia Change of Address przy restrukturyzacji w tej samej domenie. Instrukcja Google jest prosta: dodaj przekierowania i zaktualizuj mapy witryny.
• Zaktualizuj breadcrumbs, nawigację i mapy witryny do nowych ścieżek. Mapy witryny powinny zawierać wyłącznie nowe adresy URL.

Rodzaj 5 — Redesign witryny (te same adresy URL)

Na czym polega: redesign, przy którym domena i adresy URL pozostają bez zmian, ale zmieniają się szablony, tekst, nawigacja, obrazy lub elementy SEO on-page. To rodzaj o najniższym ryzyku — ale ryzyko nie jest zerowe.

Ryzyko: niskie, ale zmiany on-page nadal mogą wpłynąć na pozycje.

Pułapki i obowiązkowe działania:

• Elementy on-page psują się po cichu. Redesign często usuwa lub zmienia tagi <title>, metaopisy, strukturę nagłówków i dane uporządkowane. Zmapuj każdy z tych elementów i porównaj go z bazą starej witryny.
• Obserwuj linkowanie wewnętrzne. Redesign nawigacji może po cichu usunąć wartościowe linki wewnętrzne, które przekazywały autorytet głębokim stronom.
• Zmierz Core Web Vitals przed i po zmianie. Nowy CSS, JS, fonty i obrazy niemal zawsze zmieniają szybkość stron.
• Świadomie podchodź do zmian treści. Redesigny typu “Same URL” (tłumaczenie) „ten sam URL” często odchudzają lub konsolidują treść — nie zakładaj, że uboższa strona będzie działać tak samo.
• Punktem odniesienia są tu wytyczne Google site move without URL changes; dotyczą minimalizowania wpływu zmian infrastruktury lub prezentacji przy niezmienionych adresach URL.

Rodzaj 6 — Subdomena ↔ podfolder

Na czym polega: przeniesienie treści między subdomeną i podfolderem — najczęściej blog.example.com → example.com/blog/. Konsolidacja łączy w jednym miejscu autorytet wcześniej rozdzielony między dwa hosty.

Ryzyko: średnie–wysokie. Google do wielu celów traktuje subdomeny i domenę główną jako oddzielne byty, więc konsolidacja wywołuje rzeczywiste zawirowania związane z ponownym indeksowaniem.

Pułapki i obowiązkowe działania:

• Obie wersje są dla Google oddzielnymi bytami — mają oddzielny budżet crawlowania i częściowo oddzielne sygnały. Konsolidacja do podfolderu często daje korzyść netto, ale wymaga czasu i zachowuje się jak prawdziwe przenosiny.
• NIE używaj narzędzia Change of Address do przenosin subdomena → podfolder w tej samej domenie głównej (należą do tej samej rodziny co przypadek www/non-www, który Google każe obsługiwać adresami kanonicznymi/przekierowaniami, a nie tym narzędziem).
• Usługi GSC: prawdopodobnie masz oddzielne usługi dla subdomeny i domeny głównej. Po konsolidacji dane trafiają do usługi domeny głównej — obserwuj spadek pokrycia usługi subdomeny i wzrost w usłudze głównej.
• Przekieruj każdy URL subdomeny do odpowiednika w podfolderze i zaktualizuj linki wewnętrzne, aby wskazywały bezpośrednio nowe adresy w podfolderze (bez przekierowania). Cały profil linków zwrotnych subdomeny zasila domenę główną przez 301; kontakt w sprawie najważniejszych linków nadal pomaga.
• Uzgodnij analitykę — jeśli subdomena miała własne śledzenie lub śledzenie cross-domain, skonfiguruj ponownie GA4, aby nie stracić ciągłości.

Rodzaj 7 — Konsolidacja domen / łączenie witryn

Na czym polega: połączenie dwóch lub więcej oddzielnych witryn w jedną — np. włączenie treści przejętego konkurenta do głównej domeny albo połączenie oddzielnych witryn marki dla różnych krajów/produktów.

Ryzyko: bardzo wysokie. To w ogóle nie jest standardowa migracja — nie ma tu przenosin 1:1, które można zasygnalizować, a połączony byt jest pod wieloma względami dla Google właściwie nową witryną. Jak ujął to Martin Splitt, połączenie dwóch witryn nie jest już tyle migracją, ile tworzeniem nowej witryny z wersji scalonej.

Pułapki i obowiązkowe działania:

• Nie możesz użyć narzędzia Change of Address. Opiera się ono na przenosinach 1:1 z jednej domeny do drugiej — scalenie nimi nie jest. To praca wykonywana dla poszczególnych adresów URL.
• Spodziewaj się pewnej utraty ruchu. Google ostrzega, że przeniesienie witryn A, B i C do nowej lokalizacji D może wywołać dezorientację i spadek ruchu. Zaplanuj wydłużony okres stabilizacji.
• Najpierw wykonaj deduplikację. Jeśli łączone witryny pokrywają się tematycznie, scalenie tworzy duplikaty treści. Wybierz stronę kanoniczną dla każdego nakładającego się tematu przed przekierowaniem.
• Przekierowania każdego adresu URL do najbardziej odpowiedniej strony — nigdy zbiorcze przekierowanie całej przejętej domeny na stronę główną (soft 404 dla wszystkiego poza stroną główną). Wartość linków na poziomie strony przenosi się najlepiej, gdy każda strona trafia do prawdziwego odpowiednika.
• Zachowaj usługę GSC dla każdej łączonej witryny i monitoruj pokrycie każdej z nich (oczekiwany spadek) równolegle z domeną główną (oczekiwany wzrost).

Wybierz specjalistyczny przewodnik

Skorzystaj z przewodnika odpowiadającego decyzji lub trybowi awarii, który musisz rozwiązać:

• Hosting Migration SEO — przy zmianach serwera, CDN-u, DNS-u lub hostingu, które zachowują stałe adresy URL.
• CMS Migration SEO — przy zmianach platformy i CMS-a, w tym ryzyku związanego z szablonami, renderowaniem i zgodnością danych.
• URL Structure Migration — przy zmianach ścieżek, taksonomii lub folderów w tej samej domenie.
• Site Split / Carve-Out SEO Migration — przy przenoszeniu określonej sekcji jednej witryny do oddzielnej usługi.
• Post-Acquisition SEO Integration — przy decydowaniu, jak integrować przejęte witryny, marki i treści.
• Post-Migration Traffic Loss — przy diagnozowaniu widoczności lub ruchu, które nie odbudowują się po uruchomieniu.

Gdzie ten temat się mieści

Migracja dotyka wielu tematów sąsiednich: przekierowań, które ją przenoszą, kanonikalizacji decydującej o tym, który adres URL zachowa Google, protokołu HTTPS, hreflang w witrynach międzynarodowych oraz narzędzia Change of Address sygnalizującego przenosiny domeny. Każdy z nich zasługuje na osobne, szczegółowe omówienie — ale kręgosłup każdej migracji jest taki sam: mapuj stare na nowe 1:1, przekierowuj stałymi przekierowaniami, utrzymuj je, a potem obserwuj właściwe sygnały.

Podsumowanie AI

Skrócone ujęcie wersji Advanced:

• Migracja witryny to każda duża zmiana adresów URL, domeny, platformy, protokołu lub hosta, która może wpłynąć na crawling, indeksowanie i pozycjonowanie. Ryzyko = zakres zmian × liczba zmian wykonywanych jednocześnie.
• 7 rodzajów według ryzyka: redesign (te same adresy URL, niskie) → HTTP→HTTPS (niskie–średnie) → restrukturyzacja URL (średnie) → subdomena↔podfolder (średnie–wysokie) → zmiana CMS-a (wysokie) → zmiana domeny/rebranding (najwyższe) → łączenie/konsolidacja domen (bardzo wysokie).
• Uniwersalny proces w 7 fazach: planowanie i klasyfikacja → benchmark/crawl starej witryny → budowa mapy URL 1:1 → strategia przekierowań → staging i testy przed uruchomieniem → uruchomienie → monitoring po uruchomieniu.
• Przekierowania 301/308 są kręgosłupem. Przenoszą pozycje i nie powodują utraty PageRank. Wszystko inne (narzędzie Change of Address, mapy witryny, linki wewnętrzne, adresy kanoniczne) jest sygnałem wspierającym.
• Mapuj stare→nowe 1:1. Nigdy nie przekierowuj zbiorczo na stronę główną (jest to traktowane jako soft 404). Unikaj łańcuchów (utrzymuj je poniżej około 3–5 skoków). Utrzymuj przekierowania znacznie dłużej niż “12 months” (tłumaczenie) „12 miesięcy” — dla użytkowników właściwie bezterminowo.
• Spodziewaj się tymczasowych wahań i odbudowy. Utrzymujący się spadek zwykle oznacza awarię — aktywną blokadę stagingu, usunięty hreflang/adres kanoniczny, przypadkowy noindex lub przekierowania do niewłaściwych stron — a nie same przenosiny.
• Narzędzie Change of Address: tylko na poziomie domeny, ścisłe 1:1, opcjonalne. Nie służy do HTTP→HTTPS, restrukturyzacji w tej samej domenie ani scaleń.
• Bing: stare narzędzie Site Move jest wycofane (około 2021); do przesyłania migrowanych adresów URL używaj IndexNow. Bing skłania się ku utrzymywaniu przekierowań przez 1–2 lata.

Oficjalna dokumentacja

Dokumentacja źródłowa wyszukiwarek.

Google

• Site move with URL changes — podstawowy schemat migracji: przekierowania, harmonogram, oczekiwania i utrzymywanie przekierowań przez około rok.
• Site move without URL changes — przenosiny hostingu/infrastruktury i redesign; tymczasowe nazwy hostów, DNS oraz ostrzeżenia dotyczące firewalla/DoS.
• Redirects and Google Search — przekierowania stałe i tymczasowe oraz ryzyko przekierowań JavaScript.
• Change of Address tool (Search Console Help) — obsługiwany zakres przenosin, wymagania dotyczące usług, wykluczenia i wskazówki o przekierowaniach.
• Consolidate duplicate URLs — preferencja kanoniczna HTTPS i powód, dla którego 301 jest silniejszym sygnałem kanonicznym niż przekierowanie tymczasowe.
• Canonicalization — sposób wybierania kanonicznego adresu URL przez Google (wskazówka, nie dyrektywa).
• Enable HTTPS on your servers (web.dev) — certyfikaty TLS, mixed content i wskazówki HSTS (stara dokumentacja Google o HTTPS przekierowuje teraz tutaj).

Bing / Microsoft

• Website Migration with Bing — schemat migracji Bing, czas utrzymywania przekierowań i monitoring logów po migracji.
• IndexNow — obecny mechanizm przesyłania zmigrowanych adresów URL do Bing (stare narzędzie Site Move zostało wycofane).

Cytaty ze źródła

Oficjalne wypowiedzi przedstawicieli Google. Każdy link prowadzi bezpośrednio do cytowanego fragmentu na stronie źródłowej.

Google — przekierowania i PageRank

• “301 and other permanent redirects don’t cause a loss in PageRank.” (tłumaczenie: „Przekierowania 301 i inne przekierowania stałe nie powodują utraty PageRank.”) — Search Central, Site move with URL changes. Przejdź do cytatu
• “keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5” (tłumaczenie: „utrzymuj małą liczbę przekierowań w łańcuchu, najlepiej nie więcej niż 3 i mniej niż 5”) — Search Central, Site move with URL changes. Przejdź do cytatu
• “Keep the redirects for as long as possible, generally at least 1 year.” (tłumaczenie: „Utrzymuj przekierowania tak długo, jak to możliwe, zazwyczaj przez co najmniej 1 rok.”) — Search Central, Site move with URL changes. Przejdź do cytatu
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page” (tłumaczenie: „Nie przekierowuj wielu starych adresów URL do jednego niepowiązanego docelowego adresu URL, takiego jak strona główna”) — Search Central, Site move with URL changes. Przejdź do cytatu

Google — oczekiwania i harmonogram

• “Expect temporary fluctuation in site ranking during the move.” (tłumaczenie: „Podczas przenoszenia witryny spodziewaj się przejściowych wahań jej pozycji.”) — Search Central, Site move with URL changes. Przejdź do cytatu
• “a medium-sized website can take a few weeks for most pages to move in our index” (tłumaczenie: „w przypadku witryny średniej wielkości przeniesienie większości stron w naszym indeksie może potrwać kilka tygodni”) — Search Central, Site move with URL changes. Przejdź do cytatu
• “Check your redirects from the old site to the new one. We frequently see people redirecting to the wrong (non-existent) URLs.” (tłumaczenie: „Sprawdź przekierowania ze starej witryny do nowej. Często widzimy, że użytkownicy przekierowują do niewłaściwych (nieistniejących) adresów URL.”) — Search Central, Site move with URL changes. Przejdź do cytatu

Google — narzędzie Change of Address (okres 180 dni)

• “Maintain the redirects for at least 180 days—longer if you still see any traffic to them from Google Search.” (tłumaczenie: „Utrzymuj przekierowania przez co najmniej 180 dni — dłużej, jeśli nadal widzisz kierowany do nich ruch z wyszukiwarki Google.”) — Search Console Help, Change of Address. Przeczytaj źródło
• “After the 180 day period, Google does not recognize any relationship between the old and new sites, and treats the old site as an unrelated site.” (tłumaczenie: „Po upływie 180 dni Google nie rozpoznaje żadnego związku między starą a nową witryną i traktuje starą witrynę jako niepowiązaną.”) — Search Console Help, Change of Address. Przeczytaj źródło

Google — sygnały kanoniczne HTTPS i przekierowań

• “Google prefers HTTPS pages over equivalent HTTP pages as canonical, except when there are issues or conflicting signals.” (tłumaczenie: „Google preferuje strony HTTPS jako kanoniczne względem odpowiadających im stron HTTP, z wyjątkiem sytuacji, gdy występują problemy lub sprzeczne sygnały.”) — Search Central, Consolidate duplicate URLs. Przejdź do cytatu
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (tłumaczenie: „Googlebot podąża za przekierowaniem, ale proces indeksowania nie używa przekierowania jako sygnału, że jego cel powinien być stroną kanoniczną.”) (w odniesieniu do przekierowań tymczasowych) — Search Central, Redirects and Google Search. Przejdź do cytatu

Google — ostrzeżenia dotyczące uruchomienia i infrastruktury

• “Make sure it does not block Googlebot’s ability to reach the DNS or the hosting provider’s servers.” (tłumaczenie: „Upewnij się, że nie blokuje to Googlebotowi dostępu do DNS ani serwerów dostawcy hostingu.”) (ochrona zapory sieciowej / DoS) — Search Central, Site move without URL changes. Przejdź do cytatu
• “it’s normal to see a temporary drop in Googlebot’s crawl rate immediately after the launch, followed by a steady increase over the next few days.” (tłumaczenie: „bezpośrednio po uruchomieniu normalny jest tymczasowy spadek częstotliwości indeksowania przez Googlebota, po którym w kolejnych dniach następuje stały wzrost.”) (przenoszenie serwera/hostingu) — Search Central, Site move without URL changes. Przejdź do cytatu

Główna lista kontrolna migracji

Wykonaj tę listę przy każdej migracji niezależnie od jej typu, a następnie dodaj poniższą listę właściwą dla danego typu.

Przed uruchomieniem

• Sklasyfikowano każdy występujący typ migracji (i uniknięto łączenia typów wysokiego ryzyka).
• Interesariuszy poinformowano, że przejściowy spadek jest normalny; uruchomienie zaplanowano na okres małego ruchu.
• Plan wycofania udokumentowano i przetestowano.
• Pełne indeksowanie starej witryny zapisano jako punkt odniesienia do QA.
• Wyeksportowano pozycje, skuteczność w GSC (3/6/12 mies.), dane GA4 oraz strony z największą liczbą linków zwrotnych.
• Zebrano wszystkie istniejące przekierowania z CMS, CDN, konfiguracji serwera i raportu GSC Page with redirect.
• Utworzono mapę adresów URL stary→nowy w relacji jeden do jednego (każdy URL ma przypisany wynik; usunięte strony → 410/404, nie strona główna).
• Plan przekierowań wykorzystuje 301/308, pojedynczy skok (bez łańcuchów) i obejmuje także obrazy/PDF-y.
• Zablokowano indeksowanie środowiska testowego (noindex i/lub robots.txt) — a usunięcie tej blokady przy uruchomieniu zapisano jako zadanie.
• Porównano indeksowanie środowiska testowego z punktem odniesienia: tytuły, metaopisy, adresy kanoniczne, hreflang, dane strukturalne, meta robots, linki wewnętrzne, szybkość.
• Adresy kanoniczne w środowisku testowym wskazują adresy produkcyjne, nie testowe.
• Przetestowano każde przekierowanie stary→nowy (w jednym skoku prowadzi do właściwej strony).
• Tagi analityczne/weryfikacyjne są obecne; formularze i ścieżki konwersji przetestowano.
• Potwierdzono, że zapora/ochrona DoS nie blokuje Googlebota.

Dzień uruchomienia

• Usunięto wszystkie blokady indeksowania środowiska testowego (noindex, robots.txt) — zweryfikowano na produkcji.
• Aktywowano wszystkie przekierowania 301.
• Zaktualizowano bieżące produkcyjne mapy witryny XML, tak aby zawierały wyłącznie nowe kanoniczne adresy URL, i ponownie przesłano je w GSC.
• Jeśli było to przydatne, przesłano oddzielną tymczasową mapę starych adresów URL na potrzeby wykrywania przekierowań lub monitorowania, z przypisanym właścicielem i warunkiem usunięcia.
• Wyrywkowo sprawdzono przekierowania za pomocą URL Inspection w GSC.
• Przesłano zgłoszenie w narzędziu Change of Address (tylko przenosiny całej domeny).
• Przesłano przeniesione adresy URL do Binga przez IndexNow.
• Potwierdzono wydajność serwera na potrzeby intensywniejszego indeksowania po uruchomieniu.

Po uruchomieniu

• Ponownie zbiorczo zindeksowano listę starych adresów URL; każdy URL zwraca 301 do właściwej działającej strony.
• Zaktualizowano linki wewnętrzne, aby wskazywały bezpośrednio nowe adresy URL (bez nieaktualnych linków do starych adresów).
• Monitorowano w GSC: Page indexing, Performance według strony, Crawl stats, ręczne działania.
• Przez pierwszy miesiąc co tydzień zapisywano pozycje.
• Skontaktowano się z właścicielami najważniejszych zewnętrznych linków w celu ich aktualizacji.
• Zaplanowano utrzymanie przekierowań przez lata (nie tylko przez 180 dni działania narzędzia).
• Jeśli ruch spadł i nie wrócił: najpierw sprawdzono usunięty hreflang, przypadkowy noindex, błędne adresy kanoniczne i niewłaściwe przekierowania.

Listy kontrolne według typu

Typ 1 — zmiana domeny / rebranding

• Sprawdzono historię wcześniejszego użycia nowej domeny (archive.org); zabezpieczono odnowienia starej domeny.
• Potwierdzono zweryfikowaną własność kwalifikujących się starych i nowych usług GSC bez ścieżki: usług typu Domena lub usług z prefiksem URL na poziomie głównym, a nie prefiksów URL ograniczonych do ścieżki.
• Działa przekierowanie 301 ze starej strony głównej → nowej strony głównej (wymagane przez narzędzie).
• W całej witrynie zaktualizowano adresy kanoniczne, linki wewnętrzne i mapy witryny do nowej domeny.
• Przesłano Change of Address osobno dla każdej subdomeny oraz wariantu www/bez www.
• Plik disavow przeniesiono do nowej usługi; zmiany nie połączono z redesignem/restrukturyzacją.

Typ 2 — HTTP → HTTPS

• Prawidłowy certyfikat (2048-bitowy RSA/EC), ocena Qualys A/A+; przekierowania 301 każdego URL z http→https (bez zbiorczego kierowania na stronę główną).
• Wykryto i naprawiono mieszaną zawartość (względne adresy URL/względne względem protokołu; CSP upgrade-insecure-requests).
• Wszystkie adresy kanoniczne, mapy witryny, robots.txt i hreflang zaktualizowano do HTTPS; ustawiono flagę Secure dla plików cookie.
• HSTS dodano dopiero po potwierdzeniu stabilności TLS (najpierw niska wartość max-age).
• Narzędzia Change of Address nie użyto (zamiast tego zastosuj wytyczne dotyczące przenoszenia witryny).

Typ 3 — zmiana platformy / CMS

• Mapę adresów URL stary→nowy utworzono przed ostatecznym wyborem platformy.
• Zebrano reguły przekierowań z CMS + CDN + konfiguracji serwera + GSC (nie zgub reguł .htaccess).
• Wymuszono konwencję końcowego ukośnika; odbudowano i zweryfikowano dane strukturalne.
• Przetestowano renderowanie JavaScript (jeśli headless/SPA); zmierzono renderowanie mobilne i szybkość strony.
• Ponownie wdrożono GA4/GSC/menedżera tagów na nowej platformie.

Typ 4 — zmiana struktury adresów URL / restrukturyzacja

• Utworzono kompletną mapę stary→nowy; wdrożono przekierowania 301 dla każdego URL.
• Zaktualizowano WSZYSTKIE linki wewnętrzne (nawigacja, okruszki, stopka, treść, widżety powiązanych wpisów).
• Zaktualizowano rel=canonical do nowych adresów URL; mapy witryny zawierają tylko nowe adresy URL.
• Narzędzia Change of Address nie użyto (restrukturyzacja w tej samej domenie: tylko przekierowania + aktualizacja map witryny).
• Zindeksowano nową witrynę, aby potwierdzić, że żaden link wewnętrzny nie wskazuje już przekierowywanych starych adresów URL.

Typ 5 — redesign witryny (te same adresy URL)

• Elementy on-page (tytuły, opisy, H1, adresy kanoniczne, dane strukturalne) zapisano ze starej witryny i porównano po uruchomieniu.
• Zachowano wartościowe linki wewnętrzne podczas przeprojektowania nawigacji.
• Zmierzono Core Web Vitals przed zmianą i po niej.
• Zmiany treści są celowe (bez przypadkowego zubożenia); analityka nadal działa.

Typ 6 — subdomena ↔ podfolder

• Zindeksowano subdomenę; utworzono pełną mapę blog.example.com/post/ → example.com/blog/post/.
• Wdrożono przekierowania 301 z każdego URL subdomeny do jego odpowiednika w podfolderze; linki wewnętrzne zaktualizowano tak, aby wskazywały bezpośrednio adresy podfolderu.
• Narzędzia Change of Address nie użyto przy przenosinach w obrębie tej samej domeny głównej.
• Monitorowano obie usługi GSC (widoczność subdomeny spada, domeny głównej rośnie); ponownie skonfigurowano analitykę.

Typ 7 — konsolidacja / scalenie domen

• Przeprowadzono audyt każdej scalanej witryny (indeksowanie, pozycje, linki zwrotne, GSC).
• Usunięto duplikaty nakładających się treści; przed przekierowaniem wybrano stronę kanoniczną dla każdego tematu.
• Wdrożono przekierowania 301 poszczególnych adresów URL do najbardziej odpowiedniej strony (nigdy zbiorczo na stronę główną).
• Narzędzia Change of Address nie użyto (brak przeniesienia 1:1 do zasygnalizowania); zaplanowano wydłużoną stabilizację.
• Zachowano usługę GSC dla każdej scalanej witryny; monitorowano widoczność każdej z nich oraz domeny głównej.

Modele myślowe

1. Ryzyko = zakres zmiany × liczba zmian wprowadzanych jednocześnie. Najpierw sklasyfikuj wszystkie występujące typy. Redesign przy tych samych adresach URL to jedna zmiana niskiego ryzyka; zmiana domeny + restrukturyzacja URL + zmiana platformy to trzy nakładające się typy wysokiego ryzyka. Jeśli możesz etapować zmianę, zrób to — zmieniaj po jednej rzeczy naraz.

2. Przekierowania wykonują pracę; wszystko inne jedynie wysyła sygnały. Przekierowania 301 są mechanizmem przenoszącym pozycje. Narzędzie Change of Address, przesłanie map witryny, aktualizacja linków wewnętrznych i adresy kanoniczne to sygnały pomocnicze, które pomagają wyszukiwarkom szybciej i sprawniej przetworzyć przenosiny. Najpierw zbuduj przekierowania; resztę traktuj jako przyspieszenie, nie zamiennik.

3. Mapowanie 1:1 jest lepsze niż przekierowanie wszystkiego na stronę główną. Każdy stary URL przypisz do jednego najbardziej odpowiedniego nowego URL. Stos przekierowań na stronę główną jest traktowany jak miękkie błędy 404 — bez korzyści, a do tego tracisz wartość linków na poziomie strony, którą próbujesz zachować. Brak odpowiednika? Użyj prawidłowego 410/404, nie strony głównej.

4. Okres działania narzędzia nie jest czasem życia przekierowania. Narzędzie Change of Address przekazuje sygnały przez 180 dni. Przekierowania powinny działać o lata dłużej — utrzymuj je tak długo, jak stare adresy URL generują ruch lub mają linki. To dwa harmonogramy, a dłuższy z nich (przekierowania) utrwala przenosiny.

5. Spadek jest normalny; spadek, który się utrzymuje, oznacza błąd. Spodziewaj się przejściowych wahań i powrotu do normy w ciągu kilku tygodni do paru miesięcy. Jeśli ruch nie wraca, nie obwiniaj “the move” (tłumaczenie: „przenosin”) — poszukaj typowych winowajców: pozostawionej blokady środowiska testowego, usuniętego hreflang, przypadkowego noindex, błędnych adresów kanonicznych lub przekierowań skierowanych na niewłaściwe strony.

6. Przy wyborze strony kanonicznej linki wewnętrzne są równie ważne jak przekierowania. Możesz perfekcyjnie przekierować wszystko, a Google nadal może indeksować stary URL, jeśli nawigacja, stopka i linki w treści — oraz linki zewnętrzne — wciąż na niego wskazują. Zaktualizuj linki wewnętrzne bezpośrednio do nowych adresów URL i poproś o aktualizację najważniejszych linków zewnętrznych.

Ściągawka z migracji

Który typ przekierowania zastosować

Które narzędzie / sygnał dla której migracji

Odpowiedniki w Bingu

Najważniejsze fakty

• Przekierowania 301 nie powodują utraty PageRank — ten mit obalono około 2016 r.
• Łańcuchy przekierowań: utrzymuj poniżej około 3–5 skoków (Googlebot podąża za około 10).
• 180 dni = okres działania Change of Address, nie termin wyłączenia przekierowań. Utrzymuj je w praktyce bezterminowo.
• Czas ponownego indeksowania: “a few weeks” (tłumaczenie: „kilka tygodni”) dla średniej witryny; dłużej dla dużych.
• Najczęstsza przyczyna trwałego spadku: brakujące/błędne tagi w nowej witrynie (hreflang, noindex, adresy kanoniczne), a nie same przenosiny.

Jaki to typ migracji — i czy ma zastosowanie Change of Address?

Przejdź przez drzewo raz dla największej zmiany, a następnie ponownie dla każdej dodatkowej zmiany wdrażanej w tym samym wydaniu. Zmiana platformy, która zmienia też ścieżki i domenę, to trzy migracje, nie jedna.

Procedura: ruch spadł po uruchomieniu i nie wraca

Użyj tej procedury, gdy oczekiwane wahania po uruchomieniu nie ustępują. Zacznij od problemów z dostępem w całej witrynie i przechodź do konfliktów sygnałów na poziomie URL; nie obwiniaj “the move” (tłumaczenie: „przenosin”), dopóki nie wykluczysz błędów wdrożenia.

Krok 1 — Potwierdź, że spadek jest rzeczywisty, i określ jego zakres. Porównaj te same strony, zapytania, rynki i definicje analityczne zarejestrowane przed uruchomieniem. Jeśli zniknęło tylko raportowanie, najpierw napraw pomiar. Jeśli stare adresy URL tracą widoczność, a odpowiadające im nowe ją zyskują, nadal monitoruj normalne przejście. Jeśli oba zestawy tracą widoczność, przejdź do kroku 2.

Krok 2 — Sprawdź blokadę indeksowania lub dostępu robotów obejmującą całe uruchomienie. Pobierz produkcję jako robot i sprawdź robots.txt, meta robots, X-Robots-Tag, uwierzytelnianie, odpowiedzi zapory, DNS i kody stanu. Jeśli wdrożono testowe noindex, Disallow: /, barierę logowania lub blokadę robotów, usuń ją i natychmiast ponownie zindeksuj witrynę. Jeśli produkcja jest dostępna i indeksowalna, kontynuuj.

Krok 3 — Ponownie przetestuj kompletną mapę przekierowań stary→nowy. Sprawdź pełny wykaz starych adresów URL, zaczynając od stron z największą liczbą linków i najwyższym ruchem. Jeśli adresy kończą się błędami 404, niepowiązanymi celami, pętlami lub łańcuchami, napraw mapowanie i uprość każdą trasę do końcowego odpowiedniego URL. Jeśli przekierowania działają prawidłowo w jednym skoku, kontynuuj.

Krok 4 — Porównaj nowe strony z punktem odniesienia. Porównaj adresy kanoniczne, hreflang, tytuły, nagłówki, treść, dane strukturalne, linki wewnętrzne i HTML widoczny po renderowaniu. Jeśli tag zniknął w całym szablonie albo wskazuje środowisko testowe lub stare adresy URL, napraw szablon przed pojedynczymi stronami. Jeśli zgodność jest zachowana, kontynuuj.

Krok 5 — Sprawdź sygnały konsolidacji. Potwierdź, że nowe adresy URL są samokanoniczne, linki wewnętrzne i nawigacja wskazują je bezpośrednio, a bieżące produkcyjne mapy witryny zawierają tylko nowe kanoniczne adresy URL. Jeśli do monitorowania przesłano oddzielną mapę starych adresów URL, potwierdź, że nadal jest przydatna, i usuń ją, gdy przestanie być. W URL Inspection sprawdź próbkę adresów kanonicznych wybranych przez Google. Jeśli Google nadal wybiera stare lub niepowiązane adresy URL, usuń sprzeczne linki, adresy kanoniczne i wpisy w mapach witryny, a następnie poczekaj na ponowne indeksowanie.

Krok 6 — Sprawdź wydajność i dane serwera. Przejrzyj statystyki indeksowania i logi dostępu pod kątem kodów odpowiedzi Googlebota oraz jego aktywności na nowym hoście. Jeśli podczas wzmożonego indeksowania po przenosinach rosną błędy, opóźnienia, ograniczenia częstotliwości lub wyzwania zapory, przywróć wydajność albo dostęp. Jeśli indeksowanie przebiega prawidłowo, eskaluj pozostałe grupy stron według typu migracji i szablonu.

Krok 7 — Użyj planu wycofania tylko przy potwierdzonej regresji wdrożenia. Wycofaj zmianę, gdy spełniony jest uzgodniony wcześniej warunek, a porównanie indeksowania wiąże spadek z odwracalnym błędem szablonu, platformy lub konfiguracji. Nie wycofuj wyłącznie z powodu wahań pierwszego dnia; druga nieplanowana zmiana dokłada wyszukiwarkom kolejną migrację do przetworzenia.

Mity migracyjne, które powodują realne awarie

“Permanent redirects lose link credit.” (tłumaczenie: „Stałe przekierowania powodują utratę wartości linków.”) Dlaczego to błąd: Google twierdzi, że stałe przekierowania nie powodują utraty PageRank. Praktyczne ryzyko to niewłaściwy cel, łańcuch, pętla lub ślepa uliczka — nie samo 301. Zamiast tego: przypisz każdy stary URL bezpośrednio do najbliższego odpowiednika i przetestuj końcową odpowiedź.

“Change of Address moves the site for me.” (tłumaczenie: „Change of Address przenosi witrynę za mnie.”) Dlaczego to błąd: narzędzie jest opcjonalnym sygnałem pomocniczym przy ścisłym przeniesieniu całej domeny. Nie tworzy przekierowań i nie obsługuje przejścia na HTTPS, restrukturyzacji ścieżek, częściowych przenosin ani łączenia domen. Zamiast tego: najpierw zbuduj mapę przekierowań, a narzędzia używaj tylko wtedy, gdy pasuje do jego zakresu.

“Any traffic drop proves the migration failed.” (tłumaczenie: „Każdy spadek ruchu dowodzi niepowodzenia migracji.”) Dlaczego to błąd: przejściowe wahania pozycji, indeksowania oraz — gdy używa się oddzielnej mapy starych adresów URL — przechodzenia między mapami są oczekiwane, gdy wyszukiwarki przetwarzają przenosiny. Zamiast tego: uzgodnij punkty odniesienia i kryteria wycofania przed uruchomieniem, a następnie diagnozuj spadek trwały lub wyjaśniony strukturalnie, zamiast reagować na zwykły szum.

“Redirects can come down after a few months.” (tłumaczenie: „Przekierowania można usunąć po kilku miesiącach.”) Dlaczego to błąd: wytyczna Google dotycząca jednego roku to dolna granica przetwarzania, a nie data wygaśnięcia zakładek, linków zwrotnych czy użytkowników. Zamiast tego: utrzymuj przekierowania tak długo, jak stare adresy URL mają ruch lub linki — zwykle bezterminowo — i zachowaj kontrolę nad starą domeną.

Narzędzia do mapowania i weryfikacji migracji

• Redirect Map Builder — wklej zestawy starych i nowych adresów URL, aby utworzyć proponowaną mapę przekierowań 301 z poziomami pewności, niedopasowanymi wierszami, listą 410, spłaszczaniem łańcuchów, ręcznymi korektami i eksportem dla platform. Każda sugestia nadal wymaga redakcyjnego sprawdzenia równoważności przed uruchomieniem.
• Redirect Chain Mapper — prześledź każdy skok i zobacz stan, zmiany hosta/ścieżki, meta refresh oraz reguły porządkowania. Używaj na próbkach środowiska testowego i przy awariach po uruchomieniu, gdy reguły ukośnika, protokołu lub domeny mogą się nakładać.
• Redirect Checker — szybko potwierdź końcowy stan, skoki i cel dla pojedynczego URL lub małej partii. Dla pełnego wykazu starych adresów URL użyj pełnego crawlera; kontrole wyrywkowe nie potwierdzą całej mapy.
• Crawler całej witryny — zapisuje punkt odniesienia sprzed migracji, testuje pełną listę przekierowań i porównuje tytuły, adresy kanoniczne, hreflang, dyrektywy, linki, schema oraz renderowanie.
• Google Search Console — korzystaj z Page Indexing, Performance, Sitemaps, Crawl Stats, URL Inspection oraz — tylko przy kwalifikującym się przeniesieniu całej domeny — Change of Address.
• Logi dostępu serwera — potwierdzają, czy roboty wyszukiwarek docierają do nowego hosta, jakie odpowiedzi otrzymują i czy stare adresy URL są nadal żądane przed wyłączeniem infrastruktury.

Udowodnij, że migrację wdrożono zgodnie z mapą

Pełny test przekierowań starych adresów URL

• Test do wykonania: Zindeksuj kompletny wykaz starych adresów URL z fazy 2 w środowisku produkcyjnym i zbadaj błędy za pomocą Redirect Chain Mapper lub Redirect Checker.
• Oczekiwany wynik: Każdy przeniesiony URL zwraca jeden serwerowy skok 301 lub 308 do zamierzonego odpowiednika; celowo usunięte adresy zwracają zaplanowany 404 lub 410.
• Interpretacja niepowodzenia: Odpowiedź 200 pod starym URL, łańcuch, pętla, niepowiązany cel lub nieplanowany 404 oznacza, że mapa przekierowań albo kolejność reguł nie zostały wdrożone zgodnie z zatwierdzeniem.
• Okno monitorowania: Natychmiast po uruchomieniu, następnie ponownie przy wdrażaniu poprawek oraz w początkowym okresie monitorowania, gdy stare adresy URL są nadal intensywnie indeksowane.
• Warunek wycofania: Systemowa reguła mapowania kieruje istotną chronioną sekcję do niewłaściwych miejsc albo czyni ją niedostępną i nie da się jej bezpiecznie poprawić na miejscu.

Test indeksowalności i kanoniczności nowych stron

• Test do wykonania: Zindeksuj zestaw nowych adresów URL pod kątem stanu, dyrektyw robots i adresów kanonicznych; następnie użyj URL Inspection na reprezentatywnych stronach o dużej wartości.
• Oczekiwany wynik: Nowe strony zwracają 200, nie są zablokowane ani oznaczone noindex i deklarują zamierzony nowy adres kanoniczny; po ponownym indeksowaniu Google raportuje zamierzony adres kanoniczny dla próbek.
• Interpretacja niepowodzenia: Dyrektywa środowiska testowego obejmująca całą witrynę, stary/testowy adres kanoniczny, wyzwanie uwierzytelnienia lub inny adres kanoniczny wybrany przez Google wskazuje na sprzeczną konfigurację uruchomienia.
• Okno monitorowania: Sygnały techniczne są natychmiastowe; wybór adresu kanonicznego przez Google i zmiany w indeksie wymagają ponownego indeksowania i w średniej witrynie mogą potrwać tygodnie, a w dużej dłużej.
• Warunek wycofania: Produkcyjna blokada indeksowania/dostępu robotów albo błąd kanoniczny szablonu wpływa na chroniony zestaw i nie można go szybko usunąć bez wycofania wydania.

Test celów linków i map witryny

• Test do wykonania: Zindeksuj linki wewnętrzne i przeanalizuj przesłane mapy witryny, porównując każdy cel z zatwierdzonym zestawem nowych kanonicznych adresów URL.
• Oczekiwany wynik: Nawigacja i linki wewnętrzne wskazują bezpośrednio nowe adresy URL, a bieżące produkcyjne mapy witryny zawierają wyłącznie kanoniczne nowe adresy URL z poprawnymi odpowiedziami. Każda opcjonalna mapa starych adresów URL jest oddzielna, tymczasowa i powiązana z warunkiem usunięcia.
• Interpretacja niepowodzenia: Stare linki wewnętrzne, mieszane wykazy starych/nowych adresów w mapach albo mapa starych adresów URL utrzymana po tym, jak przestała dostarczać użytecznych danych, mogą spowolnić lub zaciemnić przejście ze starych adresów na nowe.
• Okno monitorowania: Natychmiast w wyrenderowanej witrynie i plikach map; potwierdź przetworzenie przesłanej mapy w okresie monitorowania po uruchomieniu.
• Warunek wycofania: Regresja nawigacji lub generatora map obejmująca cały szablon kieruje roboty z powrotem do starych, testowych lub niekanonicznych adresów URL i nie można jej bezpiecznie poprawić bez wyłączenia.

Zasoby warte Twojego czasu

Moje powiązane publikacje

• A Website Migration Takes More Than A Checklist To Be Successful — mój kompletny przewodnik po migracji, z listą typowych błędów i listą kontrolną monitorowania po uruchomieniu.
• Redirects for SEO: A Beginner’s Guide — typy przekierowań, łańcuchy i czas ich utrzymywania.
• Is It OK to Remove 301 Redirects After a Year? We Tested It — własny eksperyment stojący za zaleceniem “keep redirects long-term” (tłumaczenie: „utrzymuj przekierowania długoterminowo”).
• Canonicalization: A Beginner’s Guide — jak Google wybiera stronę kanoniczną, co ma znaczenie, gdy po przenosinach stare adresy URL konkurują z nowymi.
• The Beginner’s Guide to Technical SEO — miejsce migracji w szerszym kontekście.

Oficjalne

• Site move with URL changes — główna procedura migracyjna Google.
• Change of Address tool — obsługiwany przez Google zakres przenosin, wymagania dotyczące usług i wskazówki o przekierowaniach.
• Website Migration with Bing — procedura Binga i wytyczne dotyczące czasu utrzymywania przekierowań.

Od innych autorów

• r/TechSEO — miejsce analizowania nietypowych przypadków migracji i spadków po uruchomieniu.
• Google’s Mueller on Keys to a Successful Site Migration (Search Engine Journal) — omawia wskazówki Muellera dotyczące mapowania URL, linków wewnętrznych i tego, dlaczego same przekierowania nie wystarczą.
• Google: Clean Migration Takes Time, a Hacky Migration Just Takes Much Longer (Search Engine Roundtable) — rady Muellera o łączeniu witryn i kosztach chodzenia na skróty.
• When Migrating From HTTP to HTTPS, Google Says to Use 301 Redirects (Search Engine Land) — Mueller zaleca przekierowania 301 dla każdego URL przy przejściu na HTTPS zamiast zbiorczych przekierowań.
• Website Migration with Bing (Bing Webmaster Blog) — ośmiostopniowa procedura migracji Binga, zalecenia dotyczące utrzymywania przekierowań (1–2 lata) i monitorowania logów po migracji.
• Moving Domains: Avoiding the Pitfalls (Bing Webmaster Blog) — wskazówki Binga dotyczące sprawdzania historii nowej domeny i nieużywania adresu kanonicznego zamiast przekierowania.
• Enable HTTPS on Your Servers (web.dev) — podstawowe źródło dotyczące certyfikatów TLS, mieszanej zawartości i konfiguracji HSTS podczas migracji HTTP→HTTPS.

Google zaleca utrzymywanie przekierowań związanych z przenoszeniem witryny tak długo, jak to możliwe, zwykle przez co najmniej rok. Dowód potwierdzający to twierdzenie Google recommends keeping site-move redirects as long as possible, generally for at least one year. Zakres: Google Search's minimum site-move guidance; continuing user traffic or links can justify retaining redirects longer. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Site move with URL changes Według Google należy spodziewać się przejściowych wahań pozycji, a przeniesienie większości stron średniej witryny w indeksie może potrwać kilka tygodni. Dowód potwierdzający to twierdzenie Google says to expect temporary ranking fluctuations during a site move; most pages on a medium-sized site can take a few weeks to move in Google's index, and larger sites take longer. Zakres: Google Search's general expectations for moves with URL changes; actual timing varies by site and does not promise recovery by a fixed date. Poziom ufności: wysoki · Zweryfikowano: 2026-07-14 Google Search Central: Site move with URL changes Jeśli to możliwe, Google zaleca zmienianie jednej istotnej rzeczy naraz.

Sprawdź się: migracje witryn

Pięć pytań o typy migracji, przekierowania i diagnozę po uruchomieniu. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.

Dziennik zmian