Migracja strony a SEO – jak zmienić stronę bez utraty widoczności w Google?

Google również zaleca przygotowanie mapowania starych i nowych URL-i, dokładne przetestowanie nowej witryny, wdrożenie odpowiednich przekierowań i późniejsze monitorowanie obu wersji serwisu.^[1]

Czym jest migracja strony z perspektywy SEO?

Nie każda migracja wygląda tak samo. Google rozróżnia przede wszystkim zmiany, w których zmieniają się adresy URL, oraz zmiany infrastrukturalne wykonywane przy zachowaniu dotychczasowych adresów.^[1][2]

Do pierwszej grupy należą między innymi:

• zmiana domeny;
• przejście z HTTP na HTTPS;
• zmiana struktury adresów;
• zmiana nazw katalogów lub slugów;
• przeniesienie treści między domenami;
• połączenie kilku serwisów w jeden.

W takich przypadkach trzeba powiedzieć użytkownikom i wyszukiwarce, gdzie znajduje się nowa wersja dawnego zasobu. Najczęściej służą do tego trwałe przekierowania.

Inaczej wygląda zmiana hostingu czy infrastruktury, gdy wszystkie publiczne URL-e pozostają takie same. Google ma dla takiej sytuacji osobne zalecenia i zwraca uwagę przede wszystkim na poprawne przygotowanie serwera, zmianę DNS oraz monitorowanie ruchu i aktywności Googlebota.^[2]

Podobnie zmiana CMS nie musi automatycznie oznaczać zmiany adresów. Można przenieść stronę z jednego systemu na drugi i zachować dotychczasową strukturę URL.

Nie zmieniaj wszystkiego jednocześnie, jeśli nie musisz

Jeżeli projekt na to pozwala, Google zaleca wprowadzać duże zmiany kolejno, zamiast jednocześnie zmieniać domenę, CMS i cały layout strony.^[1]

Ma to bardzo praktyczne znaczenie. Jeżeli po uruchomieniu nowej strony spadnie widoczność, znacznie łatwiej znaleźć przyczynę, kiedy wiadomo, co dokładnie się zmieniło.

Dlaczego strona może stracić widoczność po migracji?

Sam fakt migracji nie oznacza, że witryna musi stracić wypracowane pozycje. Ryzyko pojawia się wtedy, gdy przy okazji zmiany tracimy elementy, które wcześniej pomagały Google znaleźć, interpretować i oceniać konkretne strony.

Do częstych problemów należą:

• wartościowy stary URL zwracający po migracji 404 mimo istnienia nowego odpowiednika;
• przekierowanie wielu różnych stron do strony głównej;
• pozostawienie canonicali wskazujących starą domenę lub staging;
• przypadkowy noindex na stronie produkcyjnej;
• blokada nowych zasobów w robots.txt;
• linkowanie wewnętrzne nadal prowadzące przez stare URL-e;
• zmiana lub usunięcie wartościowych treści;
• błędne hreflangi;
• problemy z renderowaniem nowej wersji strony;
• łańcuchy lub pętle przekierowań.

Google ostrzega między innymi przed niepowiązanymi tematycznie przekierowaniami, pozostawieniem noindex po wdrożeniu oraz niespójnymi canonicalami.^[1]

Problemem może być również nowa technologia. Google wykonuje JavaScript, ale treść, którą wyszukiwarka ma zindeksować, musi ostatecznie znaleźć się w wyrenderowanym HTML. Dlatego po przejściu np. na aplikację silniej opartą na JavaScript warto sprawdzić nie tylko to, jak stronę widzi zwykła przeglądarka, ale także wyrenderowaną wersję dostępną w narzędziach Google.^[9]

Etap 1. Inwentaryzacja strony przed migracją

Jednym z najdroższych błędów jest rozpoczęcie mapowania dopiero po wyłączeniu starego serwisu.

Przed migracją warto stworzyć możliwie pełną listę adresów występujących w obecnej witrynie. Sam crawl strony może nie wystarczyć. Nie znajdzie przecież URL-a, do którego obecnie nie prowadzi żaden link wewnętrzny, ale który nadal generuje wejścia z Google albo posiada wartościowe backlinki.

Dlatego listę najlepiej budować z kilku źródeł.

Crawl serwisu

Pozwala zebrać adresy dostępne poprzez aktualną strukturę linkowania oraz sprawdzić ich statusy, canonicale, nagłówki, indeksowalność i głębokość w strukturze.

Google Search Console

Pozwala znaleźć strony generujące kliknięcia i wyświetlenia oraz porównać ich dotychczasową widoczność.

Google Analytics 4

Pomaga znaleźć landing pages, które rzeczywiście otrzymują ruch i generują konwersje. Raport Pozyskiwanie ruchu pozwala analizować między innymi wizyty pochodzące z organicznych źródeł.^[8]

XML Sitemap

Jest kolejnym źródłem adresów deklarowanych przez serwis.

Dane o backlinkach

Ahrefs, Semrush lub inne narzędzie może pomóc znaleźć stare URL-e posiadające linki zewnętrzne.

Logi serwera

W większych projektach mogą dodatkowo ujawnić adresy nadal odwiedzane przez Googlebota.

Takie łączenie danych zaleca również Screaming Frog w swoim workflow migracyjnym: oprócz crawla wskazuje między innymi Analytics, Search Console, sitemapy, dane backlinkowe oraz logi jako źródła przydatne przy budowaniu listy starych URL-i.^[10]

Co warto zachować jako punkt odniesienia?

Przed wdrożeniem warto również zapisać dane, do których wrócimy później:

• kliknięcia i wyświetlenia z Google;
• najważniejsze zapytania;
• organiczne landing pages;
• konwersje i przychody z ruchu organicznego;
• liczbę indeksowanych stron;
• crawl starej witryny;
• obecne przekierowania;
• dane o najważniejszych backlinkach.

Nie chodzi o to, żeby później oczekiwać identycznych wyników dzień po migracji. Chodzi o możliwość odpowiedzi na pytanie, co konkretnie zmieniło się w porównaniu ze stanem sprzed wdrożenia.

Jakie narzędzia przydają się przy migracji SEO?

Nie istnieje jedno narzędzie, które samodzielnie przeprowadzi audyt całej migracji. Każde pokazuje inny fragment sytuacji.

Screaming Frog – przed i po migracji

Screaming Frog jest szczególnie przydatny dlatego, że można wykonać crawl starego serwisu, crawl stagingu i następnie porównać oba zbiory danych. Funkcja Crawl Comparison pozwala porównywać m.in. zmiany struktury, crawl depth, title, meta descriptions, internal linking i zawartość pomiędzy dwoma crawlami.^[10]

Screaming Frog SEO Spider

Screaming Frog opisuje List Mode właśnie jako sposób na testowanie list URL-i podczas migracji i umożliwia śledzenie redirectów aż do końcowego adresu.^[10]

Etap 2. Staging – co sprawdzić przed publikacją?

Środowisko testowe powinno pozwolić sprawdzić nową stronę zanim zobaczą ją użytkownicy i roboty wyszukiwarek.

Przed publikacją warto porównać ze starym serwisem przede wszystkim:

• liczbę i strukturę istotnych URL-i;
• statusy HTTP;
• title i H1;
• canonicale;
• meta robots;
• linkowanie wewnętrzne;
• breadcrumbs;
• hreflangi;
• dane strukturalne;
• treść głównych landing pages;
• sposób renderowania.

Jeśli staging jest publicznie dostępny, trzeba też chronić go przed przypadkową indeksacją.

Nie należy jednak traktować robots.txt i noindex jako tego samego mechanizmu.

robots.txt: kontroluje możliwość crawlowania.

noindex: informuje wyszukiwarkę, że dana strona nie powinna być indeksowana.

Co więcej, żeby Google mogło zobaczyć noindex, robot musi mieć możliwość pobrania strony. Jeśli URL jest zablokowany w robots.txt, Googlebot może nie odczytać znacznika noindex.^[4]

Dlatego dla prywatnego stagingu lepszym zabezpieczeniem jest ograniczenie dostępu, np. uwierzytelnieniem na poziomie serwera, zamiast polegania wyłącznie na regułach dla robotów.

Etap 3. Mapa URL – najważniejszy dokument migracji

Jeżeli zmieniają się adresy, każdy istotny stary URL powinien otrzymać określoną decyzję.

Nie chodzi o stworzenie jednej reguły:

wszystko → nowa strona główna

ale o ustalenie relacji pomiędzy konkretnymi zasobami.

Google rekomenduje przygotowanie mapowania bieżących adresów do ich nowych odpowiedników i zastosowanie trwałych przekierowań serwerowych, kiedy treść faktycznie została przeniesiona.^[1][3]

301 czy 308?

Dla trwałego przeniesienia adresu Google zaleca, jeśli to możliwe, permanentne przekierowanie po stronie serwera. Kody 301 i 308 oznaczają trwałą zmianę lokalizacji.^[3]

W typowej migracji strony najczęściej spotkamy 301.

308 pełni podobną funkcję z perspektywy trwałości przekierowania, ale na poziomie HTTP różni się m.in. zachowaniem metody żądania.

Nie ma potrzeby zamieniać działających 301 na 308 tylko „dla SEO”.

Google zaznacza też, że trwałe przekierowania, w tym 301, nie powodują utraty PageRank.^[1]

Nie przerabiaj tego jednak na stwierdzenie:

„301 gwarantuje zachowanie 100% SEO”.

Przekierowanie może być poprawne, a strona jednocześnie może stracić wartościową treść, linkowanie czy zmienić intencję.

Co z 302 i 307?

302 i 307 to przekierowania tymczasowe. Są właściwe, gdy zmiana rzeczywiście ma być czasowa.

Google rekomenduje permanentny redirect, jeśli adres ma zostać trwale zmieniony.^[3]

Dlatego 302 nie powinno być domyślnym wyborem w stałej migracji tylko dlatego, że również przekierowuje użytkownika.

404 czy 410?

Jeżeli strona została trwale usunięta i nie ma odpowiednika o podobnej zawartości, 404 i 410 są prawidłowymi odpowiedziami.

Google wymienia oba statusy jako poprawne rozwiązanie dla nieistniejącego zasobu bez strony zastępczej.^[5]

Nie trzeba na siłę szukać przekierowania dla każdego historycznego URL-a.

Jeżeli nie istnieje logiczny odpowiednik, poprawny 404/410 jest lepszy niż sztuczne skierowanie użytkownika do przypadkowej kategorii czy strony głównej.

Dlaczego nie warto przekierowywać wszystkiego na stronę główną?

To jeden z najczęstszych skrótów podczas źle przygotowanych migracji.

Załóżmy, że poprzedni serwis miał 500 artykułów.

W nowej wersji zachowano 100,
a dla pozostałych wdrożono:

stary artykuł
→ /

Technicznie redirect działa.

Merytorycznie strona główna nie jest jednak odpowiednikiem 400 różnych poradników.

Google w dokumentacji migracji ostrzega, że przekierowywanie wielu starych adresów do jednego niepowiązanego URL-a, np. homepage, może zostać potraktowane jako soft 404.^[1]

Jeżeli natomiast kilka starych artykułów zostało naprawdę scalonych w jeden nowy, rozbudowany materiał, przekierowanie ich do skonsolidowanego URL-a jest uzasadnione.

Łańcuchy przekierowań – im krócej, tym lepiej

Przy wieloletnich serwisach łatwo stworzyć układ:

URL A
→ URL B
→ URL C
→ URL D

zwłaszcza jeśli każda kolejna migracja dokłada nową warstwę 301.

Googlebot potrafi podążać za łańcuchem do 10 przekierowań, ale Google zaleca kierowanie od razu do finalnego adresu.

Jeśli chainu nie da się uniknąć, dokumentacja zaleca utrzymywać go możliwie krótkim – idealnie nie więcej niż trzy przekierowania i poniżej pięciu.^[1]

W praktyce przy nowej migracji warto więc przebudować:

stary URL
→ poprzedni URL
→ jeszcze nowszy URL

na:

stary URL
→ aktualny URL.

To właśnie można łatwo zweryfikować w Screaming Frog za pomocą List Mode i raportu przekierowań.

Etap 4. Canonical, linkowanie wewnętrzne i sitemap powinny mówić to samo

Migracja jest znacznie łatwiejsza do interpretacji, kiedy najważniejsze sygnały techniczne są ze sobą spójne.

Przykładowo dla nowego URL-a chcemy uzyskać układ:

stary URL
↓ 301
nowy URL

a na nowej stronie:

• canonical wskazujący nowy adres;
• linki wewnętrzne prowadzące bezpośrednio do niego;
• nowy URL w sitemapie.

Google określa przekierowania i rel=”canonical” jako silne sygnały podczas wyboru strony kanonicznej, a umieszczenie URL-a w sitemapie jako sygnał słabszy.

Google wskazuje również, że kilka zgodnych metod może się wzajemnie wzmacniać.^[6]

Canonical po migracji

Przy migracji ze zmianą adresów Google rekomenduje zaktualizowanie canonicali nowych stron, tak aby korzystały z nowych URL-i.^[1]

Typowy błąd wygląda tak:

nowa strona działa pod:

nowadomena.pl/usluga/

ale w kodzie nadal pozostaje:

canonical
→ staging.domena.pl/usluga/

albo:

canonical
→ staradomena.pl/usluga/

Warto też pamiętać, że canonical nie jest bezwzględną komendą.

Google bierze wskazanie pod uwagę, ale może ostatecznie wybrać inny reprezentatywny URL.^[6]

Zaktualizuj linkowanie wewnętrzne

Po migracji linki wewnętrzne powinny prowadzić bezpośrednio do nowych URL-i, zamiast wykorzystywać stare adresy i polegać na 301.

Google wymienia aktualizację linków wewnętrznych jako jeden z elementów przygotowania i wdrażania migracji.^[1]

Czyli zamiast:

artykuł
→ stary URL
→ 301
→ nowy URL

powinno być:

artykuł
→ nowy URL.

301 pozostaje wtedy przede wszystkim zabezpieczeniem dla starych wejść, bookmarków, linków zewnętrznych i adresów zapisanych przez wyszukiwarki. Przed migracją warto zweryfikować stan serwisu w ramach audytu SEO.

Co zrobić z XML Sitemap?

Po migracji należy przygotować sitemapę zawierającą nowe, preferowane adresy.

Google zaleca umieszczać w sitemapie URL-e, które chcemy pokazywać w wyszukiwarce, czyli preferowane strony kanoniczne.^[7]

Jeśli używany jest <lastmod>, data powinna odpowiadać rzeczywiście istotnej zmianie strony.

Google jako znaczące zmiany podaje np. aktualizację głównej treści, danych strukturalnych lub linków, a nie samo automatyczne przestawienie daty przez CMS.^[7]

Aktualna dokumentacja migracji Google zawiera dwa przydatne scenariusze pracy z sitemapami: po zgłoszeniu nowej mapy wskazuje, że stara może zostać usunięta, a w sekcji dotyczącej monitorowania opisuje również możliwość obserwowania starej i nowej mapy w Search Console, aby śledzić przechodzenie indeksacji między URL-ami.^[1]

Co z hreflang przy migracji serwisu wielojęzycznego?

Jeżeli zmieniają się URL-e wersji językowych, trzeba zaktualizować również ich wzajemne odniesienia hreflang.

Google przypomina o tym bezpośrednio w dokumentacji migracji: adnotacje powinny prowadzić do nowych URL-i.^[1]

W praktyce warto sprawdzić cały klaster:

• PL → EN;
• EN → PL;
• self-reference;
• x-default, jeśli jest wykorzystywany;
• canonical każdego wariantu.

Nie wystarczy zmienić jeden element w polskiej wersji i pozostawić stare URL-e w angielskiej.

Etap 5. Checklista dnia wdrożenia

W dniu migracji nie warto działać na zasadzie:

„strona się otwiera, więc wszystko działa”.

W przypadku migracji opartej mocniej na JavaScript warto w URL Inspection lub innych narzędziach Google porównać także wyrenderowaną stronę.^[9][12]

Kiedy użyć Change of Address w Google Search Console?

Narzędzie Change of Address ma konkretną funkcję i nie powinno być uruchamiane przy każdej zmianie strony.

Google zaleca użycie go przy przenoszeniu witryny z jednej domeny lub subdomeny do innej.

Narzędzie uruchamia się dopiero po wykonaniu migracji i wdrożeniu przekierowań.^[11]

Nie używamy go natomiast przy:

• przejściu HTTP → HTTPS;
• zwykłej zmianie ścieżek wewnątrz tej samej domeny;
• samej zmianie hostingu.^[11]

Etap 6. Jak monitorować stronę po migracji?

Migracja nie kończy się w chwili, gdy nowy serwis zaczyna działać.

Google podkreśla, że proces odbywa się na poziomie poszczególnych URL-i.

Przy istotnej zmianie rankingi mogą tymczasowo się wahać, a w przypadku małych i średnich witryn przeniesienie większości stron w indeksie może potrwać kilka tygodni.

Większe serwisy mogą potrzebować więcej czasu.^[1]

Dlatego monitoring warto podzielić na etapy.

Pierwsze 24 godziny

Najpierw szukamy problemów krytycznych.

To problemy, których nie należy „obserwować przez dwa tygodnie”.

Trzeba je naprawić możliwie szybko.

Pierwszy tydzień

Kontrolujemy między innymi:

• Search Console;
• najważniejsze nowe URL-e;
• 404 i soft 404;
• Google-selected canonical;
• poprawność redirectów;
• sesje organiczne w GA4;
• konwersje;
• ponowny crawl starej listy URL-i.

URL Inspection pozwala sprawdzić zindeksowaną wersję strony, wykonać test wersji live oraz zobaczyć canonical wybrany przez Google.^[12]

Pierwszy miesiąc

W dłuższym horyzoncie porównujemy:

• organiczne kliknięcia i wyświetlenia;
• strony wejścia;
• najważniejsze zapytania;
• indeksację;
• konwersje;
• sprzedaż lub leady;
• widoczność kluczowych grup landing pages.

Nie oceniaj powodzenia migracji wyłącznie na podstawie jednej metryki „średnia pozycja”.

Celem nie jest zachowanie identycznego wykresu przez każdy dzień, tylko przeniesienie wartościowego ruchu i wyników biznesowych na nową wersję serwisu.

Czy spadek widoczności po migracji jest normalny?

Wahania – tak.
Dowolnie duży spadek – nie.

Google informuje, że przy znaczących zmianach mogą wystąpić tymczasowe wahania rankingu, gdy witryna jest ponownie crawlowana i indeksowana.^[1]

Nie oznacza to jednak, że każdy spadek należy tłumaczyć migracją i czekać.

Jeżeli po wdrożeniu:

• najważniejsze URL-e zwracają 404;
• strona ma noindex;
• robots.txt blokuje całość;
• nowe strony nie mają poprawnych canonicali;
• stare URL-e nie zostały przekierowane;
• Googlebot otrzymuje błędy 5xx;

to mamy konkretny problem techniczny, a nie po prostu „normalną zmienność po migracji”.

Jak długo utrzymywać przekierowania po migracji?

W głównej dokumentacji dotyczącej migracji Google zaleca utrzymywać redirecty tak długo, jak to możliwe – generalnie co najmniej rok.

Google zaznacza też, że z punktu widzenia użytkownika można rozważyć pozostawienie ich na stałe.^[1]

W dokumentacji Change of Address pojawia się dodatkowo próg 180 dni dla samego procesu zmiany adresu w Search Console i zalecenie utrzymywania redirectów przynajmniej przez ten okres, dłużej jeśli nadal otrzymują ruch.^[11]

Ważne linki wewnętrzne i wartościowe backlinki warto natomiast aktualizować do nowego adresu zamiast bez końca kierować ruch przez przekierowanie.

Google również zaleca po migracji aktualizowanie własnych linków oraz, jeśli to możliwe, ważnych odnośników zewnętrznych.^[1]

Migracja bez zmiany URL-i też może zaszkodzić SEO

Zachowanie tych samych adresów znacznie upraszcza projekt, ale nie gwarantuje braku zmian w widoczności.

Redesign może zmienić:

• treść;
• nawigację;
• linkowanie wewnętrzne;
• breadcrumbs;
• nagłówki;
• dane strukturalne;
• sposób renderowania;
• HTML dostarczany Googlebotowi;
• prędkość działania;
• meta robots;
• canonicale.

Jeżeli nowa wersja witryny usuwa znaczną część informacji albo utrudnia robotowi dostęp do istotnej treści, ten sam URL nie zabezpieczy jej automatycznie przed zmianą wyników.

Szczególnej kontroli wymagają migracje technologiczne.

Google wykonuje JavaScript, ale wskazuje też na różnice i ograniczenia związane z jego crawlowaniem i renderowaniem.

Jeśli istotnej treści nie ma w finalnie wyrenderowanym HTML, Google nie będzie mogło jej zindeksować.^[9]

Najczęstsze mity o migracji SEO

Mit 1: Przekierowanie 301 traci część PageRank

Google informuje obecnie, że 301 i inne permanentne redirecty nie powodują utraty PageRank.^[1]

Nie oznacza to, że każda źle przeprowadzona migracja zachowa dotychczasową widoczność.

Redirect to tylko jeden z elementów.

Mit 2: Wszystkie stare strony trzeba gdzieś przekierować

Nie.

Jeżeli zasób nie istnieje i nie ma podobnego odpowiednika, poprawne 404 lub 410 jest właściwym rozwiązaniem.^[5]

Mit 3: Wszystkie stare URL-e można przekierować na stronę główną

Niepowiązane przekierowania mogą być potraktowane jako soft 404.^[1]

Mit 4: Przy tych samych URL-ach SEO jest bezpieczne

Adres może pozostać identyczny, a jednocześnie może zmienić się treść, indeksowalność, architektura lub sposób renderowania.

Mit 5: Wystarczy zgłosić nową sitemapę

Sitemap pomaga Google odkrywać preferowane URL-e, ale nie zastąpi mapowania, redirectów, poprawnych canonicali i linkowania wewnętrznego.^[1][6][7]

Mit 6: Change of Address stosujemy przy każdej migracji

Nie.

Narzędzie ma zastosowanie w określonych migracjach domen/subdomen i nie służy np. do zwykłej zmiany ścieżek w obrębie tej samej domeny.^[11]

Checklista migracji SEO

Przed wdrożeniem

• wykonaj pełny crawl starego serwisu;
• pobierz dane z GSC i GA4;
• zbierz aktualne sitemapy;
• znajdź URL-e posiadające backlinki;
• zapisz aktualne przekierowania;
• przygotuj mapę stary URL → nowy URL;
• zdecyduj, które strony pozostają 200;
• zdecyduj, które wymagają 301/308;
• określ strony bez odpowiednika, które powinny zwracać 404/410;
• porównaj staging z aktualną wersją;
• sprawdź canonicale;
• sprawdź robots i meta robots;
• sprawdź hreflang i dane strukturalne;
• upewnij się, że pomiar konwersji działa.

W dniu migracji

• uruchom nowe środowisko;
• włącz przekierowania;
• sprawdź statusy najważniejszych stron;
• sprawdź redirect loops i chains;
• zweryfikuj robots.txt;
• zweryfikuj brak noindex;
• sprawdź canonicale;
• wykonaj test linkowania wewnętrznego;
• sprawdź sitemap;
• sprawdź GA4/GTM;
• przetestuj formularze i checkout;
• wykonaj pełny crawl produkcji.

Po migracji

• monitoruj GSC;
• sprawdzaj kluczowe URL-e przez URL Inspection;
• kontroluj 404 i soft 404;
• porównuj organiczne landing pages;
• monitoruj konwersje;
• ponownie testuj stare URL-e;
• obserwuj canonicale wybrane przez Google;
• aktualizuj najważniejsze linki zewnętrzne;
• nie usuwaj przedwcześnie redirectów.

Podsumowanie

Bezpieczna migracja strony nie sprowadza się do przygotowania pliku z przekierowaniami.

Najważniejszy jest cały proces:

INWENTARYZACJA
→
MAPOWANIE
→
STAGING
→
WDROŻENIE
→
WALIDACJA
→
MONITORING

Każdy istotny stary URL powinien mieć określony dalszy los.

Jeżeli ma bezpośredni odpowiednik, kierujemy go do nowej lokalizacji.

Jeżeli treść została scalona, przekierowanie prowadzi do właściwego materiału docelowego.

Jeżeli strona naprawdę znika i nie ma następcy, może prawidłowo zwracać 404 lub 410.

Jednocześnie nowe URL-e powinny tworzyć spójny system z canonicalami, linkowaniem wewnętrznym i sitemapą.

Im więcej danych zbierzemy przed migracją, tym łatwiej po wdrożeniu odróżnić normalną zmianę w indeksacji od konkretnego błędu technicznego.