Migracja strony bez utraty pozycji: plan krok po kroku

Co to jest migracja strony w rozumieniu Google

Migracja strony to każda zmiana, po której adres URL treści przestaje pasować do tego, co Google ma zapisane w indeksie: zmiana domeny, przejście z HTTP na HTTPS, zmiana struktury adresów po wdrożeniu nowego systemu CMS albo przeniesienie na nowy hosting ze zmianą technologii. Google opisuje te przypadki w dokumentacji Przeniesienie witryny i inne zmiany i w każdym z nich stosuje podobny mechanizm: musi rozpoznać, że stary adres i nowy adres to ta sama treść, i przenieść na nowy adres wszystko, co wie o starym.

Ryzyko nie leży w samej zmianie, tylko w brakach: adresie bez przekierowania, przekierowaniu w złe miejsce, zapomnianej regule noindex albo mapie witryny, która wciąż wskazuje stare adresy. Google wprost pisze, że przenoszenie zazwyczaj małej lub średniej witryny zajmuje kilka tygodni, a w tym czasie widoczność treści w wyszukiwarce może się okresowo zmieniać, co jest normalne i się ustabilizuje. Ten artykuł zamienia dokumentację Google w listę zadań, którą można odhaczać po kolei.

Jeśli migracja obejmuje też przenosiny na nowy hosting bez zmiany adresów, opisujemy to osobno w usłudze migracji domeny i hostingu, która zajmuje się techniczną stroną przeprowadzki serwera.

Dokumentacja Google o przenoszeniu witryny ze zmianą adresów

Google udostępnia oficjalny przewodnik pod adresem developers.google.com/search/docs, dział o przenoszeniu witryny ze zmianą adresów URL, który dotyczy każdej migracji zmieniającej adresy: nowej domeny, nowej struktury ścieżek albo połączenia kilku witryn w jedną. Dokument dzieli proces na trzy etapy: przygotowanie mapowania adresów, wdrożenie przekierowań i aktualizację adnotacji, a na końcu monitoring.

Etap 1: mapowanie adresów

Zanim zacznie się przekierowywać cokolwiek, trzeba mieć pełną listę starych adresów i dokładnie wiedzieć, na jaki nowy adres każdy z nich się przenosi. Google zaleca to wprost jako pierwszy krok przygotowania nowej witryny, obok konfiguracji systemu CMS i przeniesienia obrazów oraz plików do pobrania, które mogą już generować ruch z wyszukiwarki Google.

Etap 2: przekierowania i adnotacje

Po aktywowaniu przekierowań trzeba sprawdzić dwie rzeczy naraz: czy adnotacje rel="canonical" w nowej witrynie wskazują nowe adresy i czy nie zostały w kodzie reguły noindex robots meta z wersji testowej. To jeden z najczęstszych błędów migracji: strona działa, przekierowania działają, ale nowa wersja wciąż ma noindex, więc Google w ogóle jej nie indeksuje.

Etap 3: mapa witryny i robots.txt

Google pisze wprost: należy „Prześlij nową mapę witryny w Search Console”, bo to pomaga znaleźć nowe adresy, a starą mapę witryny można usunąć dopiero, gdy Google zacznie korzystać z nowej. Obok tego trzeba skonfigurować plik robots.txt nowej witryny i upewnić się, że reguły w nim „prawidłowo wskazują części, których indeksowanie chcesz blokować”, bo część witryn blokuje całą domenę na czas prac programistycznych i zapomina odblokować ją po starcie.

Przekierowania 301 i łańcuchy przekierowań

Przekierowanie 301 to sygnał dla przeglądarki i dla Googlebota, że treść pod starym adresem przeniosła się na stałe pod nowy adres. Google zaleca trwałe przekierowania po stronie serwera ze starych adresów URL do nowych, zgodnie z mapowaniem, czyli jeden stary adres na jeden konkretny nowy odpowiednik, a nie skrót przez stronę pośrednią.

Przekierowania spowalniają wczytywanie strony, więc równolegle z ich wdrożeniem warto aktualizować linki wewnętrzne i linki z innych witryn, które generują ruch, tak żeby docelowo prowadziły od razu na nowy adres. Sam fakt istnienia przekierowania nie jest jednak problemem: Google zaleca „Utrzymuj przekierowania najdłużej, jak to możliwe, zwykle przez co najmniej rok”, bo tyle czasu potrzebuje, żeby przenieść sygnały rankingowe na nowe adresy, w tym ponownie zindeksować i przypisać linki z innych witryn wskazujące stare adresy.

Narzędzie Zmiana adresu w Search Console

Narzędzie Zmiana adresu w Search Console „informuje Google o wprowadzonych zmianach i ułatwia przeniesienie wyników wyszukiwania Google ze starej witryny do nowej”, ale działa tylko przy zmianie domeny lub subdomeny, na przykład z example.com na example.org. Google jest tu jednoznaczny co do momentu zgłoszenia: „Użyj tego narzędzia po przeniesieniu i przekierowaniu witryny”, nie przed migracją.

1. Zweryfikuj obie witryny w Search Console

   Stara i nowa domena, wraz z wariantami www i bez www oraz subdomenami, muszą być zweryfikowanymi usługami w tym samym koncie.

2. Wdróż i przetestuj przekierowania 301

   Narzędzie sprawdza, czy przekierowania faktycznie działają, zanim przyjmie zgłoszenie zmiany adresu.

3. Otwórz narzędzie Zmiana adresu ze starej usługi

   Zgłoszenie składa się z poziomu starej domeny, wskazując nową jako cel.

4. Poczekaj na przetworzenie

   Google przenosi sygnały stopniowo, w tempie zależnym od wielkości witryny i szybkości indeksowania.

Kontrola kanonicznych, map witryny i robots.txt przed startem

Trzy elementy najczęściej psują migrację, jeśli ktoś zapomni je zaktualizować razem z przekierowaniami: adnotacje rel="canonical", mapa witryny i plik robots.txt. Wszystkie trzy powinny wskazywać nowe adresy dokładnie w momencie startu, nie kilka dni później.

• Każdy nowy adres URL ma tag rel="canonical" wskazujący na samego siebie
• Reguły noindex z wersji testowej albo deweloperskiej zostały usunięte z nowej witryny
• Nowa mapa witryny jest przesłana w Search Console, stara zostaje usunięta dopiero po pełnym indeksowaniu nowej
• Plik robots.txt nowej witryny blokuje wyłącznie te części, które faktycznie mają być zablokowane
• Linki wewnętrzne w nowej witrynie prowadzą bezpośrednio do nowych adresów, nie przez przekierowanie
• Obrazy i pliki do pobrania (PDF, cenniki) zostały przeniesione i mają działające adresy

Dla witryn wielojęzycznych dochodzi czwarty punkt: adnotacje rel-alternate-hreflang trzeba zaktualizować razem z kanonicznymi, bo inaczej Google będzie kierował użytkowników innych wersji językowych na stare, przekierowane adresy.

Monitoring po migracji: czego szukać w Search Console

Zakończone przeniesienie witryny w rozumieniu Google oznacza, że Googlebot „musi co najmniej raz odwiedzić wszystkie adresy URL w starej i nowej witrynie”, a nie ma stałej częstotliwości indeksowania: zależy ona od wielkości witryny i szybkości serwera. To, co można zrobić w tym czasie, to obserwować konkretne raporty.

Raport Skuteczność pokazuje średnią pozycję najwyższego wyniku z Twojej witryny, więc krótkotrwały spadek tej wartości zaraz po migracji, zanim Google przeniesie wszystkie sygnały, nie musi oznaczać problemu. Google prosi wprost o cierpliwość na tym etapie i przypomina, że widoczność stabilizuje się z czasem.

Poza samym Search Console warto obserwować ruch i zdarzenia w GA4 oraz wskaźniki szybkości ładowania nowej witryny: migracja często zmienia hosting albo szablon, a to wpływa na Core Web Vitals. Dobre wyniki to LCP do 2,5 sekundy, INP do 200 milisekund i CLS nie większy niż 0,1, liczone na 75. percentylu wczytań.

Typowe katastrofy migracyjne i jak ich uniknąć

Większość poważnych spadków widoczności po migracji sprowadza się do kilku powtarzalnych błędów, które da się wychwycić przed startem, jeśli ktoś przejdzie listę kontrolną punkt po punkcie.

• Noindex z wersji testowej: deweloperska kopia witryny miała zablokowane indeksowanie, a po przeniesieniu na produkcję nikt nie usunął tej reguły.
• Zablokowane zasoby w robots.txt: nowy plik robots.txt blokuje pliki CSS albo JavaScript potrzebne do poprawnego wyrenderowania strony, co utrudnia Google ocenę jej zawartości.
• Przekierowania na stronę główną: zbiorczy redirect zamiast mapowania adres po adresie, co Google może odczytać jako błąd soft 404.
• Skasowana stara mapa witryny za wcześnie: Google traci punkt odniesienia do starych adresów, zanim zdąży je wszystkie przetworzyć.
• Certyfikat TLS bez odpowiedniej konfiguracji przy przejściu na HTTPS: przeglądarki i Googlebot widzą błędy certyfikatu zamiast działającej strony.

Duże serwisy mają dodatkowe ryzyko: skok ruchu Googlebota w krótkim czasie, gdy silnik zaczyna intensywnie sprawdzać nowe adresy. Google radzi w takiej sytuacji dzielić migrację na etapy: „zalecamy przeniesienie na początku tylko jej części, aby sprawdzić, jak wpływa to na ruch i indeksowanie przez wyszukiwarki”, zamiast przełączać całą witrynę naraz.

Zagadnienia związane z tym, jak roboty inne niż Googlebot, w tym boty AI, traktują przekierowania i plik robots.txt, opisujemy osobno w tekście o robotach AI i pliku robots.txt, a to, jak mierzyć widoczność witryny w odpowiedziach generatywnych po migracji, w poradniku o pomiarze widoczności w AI.

Lista kontrolna: przed startem i po starcie migracji

Przed startem

• Pełne mapowanie starych adresów na nowe, adres po adresie
• Przekierowania 301 skonfigurowane i przetestowane na środowisku testowym
• Adnotacje rel="canonical" w nowej witrynie wskazują nowe adresy
• Reguły noindex z wersji roboczej usunięte
• Nowy plik robots.txt sprawdzony pod kątem przypadkowych blokad
• Certyfikat TLS gotowy, jeśli migracja obejmuje przejście na HTTPS

Po starcie

• Nowa mapa witryny przesłana w Search Console
• Narzędzie Zmiana adresu zgłoszone, jeśli zmienia się domena lub subdomena
• Stara mapa witryny usunięta dopiero po zindeksowaniu nowej
• Monitoring raportów Stan indeksowania, Mapy witryn i Skuteczność przez co najmniej kilka tygodni
• Przekierowania pozostają aktywne przez co najmniej rok
• Linki wewnętrzne i linki z innych własnych witryn zaktualizowane na nowe adresy

Zespół, który prowadzi taką migrację po raz pierwszy, często potrzebuje wsparcia przy samym mapowaniu adresów i konfiguracji przekierowań na serwerze, zwłaszcza przy dużych serwisach z tysiącami podstron. Nasza usługa migracji domeny i hostingu obejmuje ten etap razem z monitoringiem po starcie, a przy okazji migracji często porządkujemy też dane strukturalne i SEO techniczne całej witryny.