Migracja strony bez utraty widoczności: przewodnik 2026

Migracja strony to moment, w którym serwis, budowany latami, w jeden wieczór zmienia adresy, szablon, serwer albo domenę. Jeśli coś pójdzie źle, wykres ruchu z Google spada w ciągu kilku dni, a odbudowa trwa tygodniami. Dobra wiadomość jest taka, że większość strat po migracji nie wynika z decyzji algorytmu, tylko z błędów, które da się przewidzieć: brakujących przekierowań, zapomnianego noindex, zgubionych tytułów i linków wewnętrznych wskazujących stare adresy. Migracja strony pod kątem SEO jest więc przede wszystkim projektem porządkowym, a nie technicznym popisem.

Ten przewodnik prowadzi przez cały proces: od wyboru rodzaju migracji, przez inwentaryzację i mapę przekierowań, po kontrolę w pierwszych dniach i ocenę, czy spadek jest normalny. Opieramy się na dokumentacji Google o przenoszeniu witryny ze zmianą adresów URL i na praktyce wdrożeń. Liczby bez wskazanego źródła traktuj jako redakcyjną regułę kciuka. Jeśli przenosisz sklep internetowy, przeczytaj też nasz osobny tekst o tym, jak przenieść sklep na nowy silnik bez utraty widoczności, bo katalog produktów, filtry i feed dokładają własną warstwę ryzyka.

Rodzaje migracji i ryzyko każdej z nich

Słowo „migracja” obejmuje bardzo różne projekty. Ryzyko rośnie wraz z liczbą rzeczy, które zmieniają się jednocześnie. Google pisze o tym wprost w pomocy do narzędzia zmiany adresu: jeśli razem z domeną zmienisz treść i strukturę adresów, prawdopodobnie zobaczysz spadek ruchu, bo wyszukiwarka musi na nowo poznać poszczególne strony.

Najważniejsza zasada planowania: nie łącz zmian, które nie muszą iść razem. Jeśli zmieniasz domenę, zostaw na pierwszy etap tę samą strukturę adresów i ten sam szablon. Redesign zrób kilka tygodni później, gdy indeks przejdzie na nowy host. Rozdzielenie zmian ma też drugą zaletę: gdy ruch spadnie, wiesz, która z nich go zabrała.

Osobną kategorią jest przeniesienie serwisu za CDN albo na nową infrastrukturę. Adresy się nie zmieniają, ale Google w listopadzie 2026 roku ostrzegł, że migracja na CDN może przeciążyć serwer źródłowy i zablokować Googlebota, jeśli ochrona przed botami jest ustawiona zbyt szeroko. Taki projekt też wymaga kontroli po wdrożeniu, choć nie potrzebuje mapy przekierowań.

Inwentaryzacja przed startem: adresy, ruch, linki, dane

Nie da się przekierować adresu, o którego istnieniu nie wiesz. Dlatego pierwszy etap to pełna lista starych URL-i z danymi, które pokażą, co jest cenne. Żadne pojedyncze źródło nie daje kompletu, więc połącz kilka:

• crawl całego serwisu z zapisem kodu odpowiedzi, tytułu, opisu, nagłówka H1, adresu kanonicznego i liczby linków wewnętrznych,
• wszystkie mapy witryny, także te stare, które wiszą jeszcze w Search Console,
• eksport stron z raportu Skuteczność w Google Search Console za ostatnie 12–16 miesięcy,
• eksport stron docelowych z analityki, z konwersjami,
• listę stron z linkami zewnętrznymi z narzędzia do analizy linków,
• logi serwera, jeśli są dostępne, bo pokazują adresy odwiedzane przez Googlebota, do których crawler nie dotarł.

Po scaleniu każdy adres dostaje kilka kolumn: kliknięcia z Google, sesje, konwersje, liczba domen linkujących, status (aktywny, przekierowany, usunięty). Ten arkusz stanie się podstawą mapy przekierowań i listy kontrolnej. Przy okazji zapisz stan wyjściowy: liczbę zindeksowanych stron, ruch organiczny z ostatnich tygodni i pozycje dla 50–100 najważniejszych fraz. Bez punktu odniesienia nie ocenisz potem, czy migracja się udała.

Warto też zrobić kopię renderowanego HTML kluczowych stron. Gdy po wdrożeniu ktoś zapyta, czy stary szablon miał dane strukturalne albo jak brzmiał tytuł strony usługowej, odpowiedź będzie w archiwum, a nie w pamięci zespołu.

Mapa przekierowań: jak ją zbudować i przetestować

Mapa przekierowań to tabela par: stary adres i nowy adres. Google zaleca trwałe przekierowania po stronie serwera, czyli kody 301 lub 308, i podkreśla, że przekierowania stałe nie powodują utraty PageRanku. Kilka zasad, które decydują o jakości mapy:

1. Jeden do jednego, nie wszystko na stronę główną. Każdy stary adres powinien prowadzić do najbliższego tematycznie odpowiednika. Masowe przekierowanie na stronę główną Google zwykle traktuje jak miękki błąd 404, a sygnały tych stron przepadają.
2. Bez łańcuchów. Jeśli serwis przeszedł już wcześniej migrację, stare przekierowania trzeba zaktualizować tak, by prowadziły od razu do adresu docelowego, a nie przez dwa lub trzy kroki.
3. Świadome usunięcia. Strona, która nie ma odpowiednika i nie ma wartości, może zwrócić 404 lub 410. To lepsze niż przekierowanie do treści, która nie odpowiada na tę samą potrzebę.
4. Reguły tam, gdzie działa wzorzec, pozycje ręczne tam, gdzie się kończy. Reguła z wyrażeniem regularnym obsłuży tysiące wpisów blogowych, ale strony usług i kategorie zwykle wymagają ręcznego dopasowania.

Test mapy robi się przed przełączeniem, na środowisku testowym. Wystarczy lista starych adresów puszczona przez crawler w trybie listy albo prosty skrypt sprawdzający kod odpowiedzi i adres końcowy. Oczekiwany wynik to jeden skok 301 i odpowiedź 200 na adresie docelowym. Wszystko inne, czyli 302, łańcuch, pętla, 404 po przekierowaniu, trafia do poprawki. Szczegółowy proces budowy mapy rozwiniemy w osobnym tekście klastra, a już teraz warto pamiętać o zasadzie, że najcenniejsze 10 procent adresów sprawdza się ręcznie, nawet jeśli test automatyczny przeszedł.

Elementy, które muszą przetrwać zmianę bez modyfikacji

Najczęstszy powód spadków po udanym technicznie wdrożeniu to zmiana treści przy okazji migracji. Nowy szablon przycina teksty kategorii, zmienia tytuły na generowane automatycznie, gubi linki w stopce. Dla Google to sygnał, że strona jest inna niż ta, która rankowała. Na czas migracji zamroź poniższe elementy:

• tytuły i meta opisy stron, które przynoszą ruch,
• nagłówki H1 i główną treść, łącznie z sekcjami FAQ,
• linkowanie wewnętrzne: menu, okruszki, linki kontekstowe w treści, moduły „powiązane”,
• dane strukturalne (Article, Product, Organization, BreadcrumbList, LocalBusiness),
• atrybuty alt i adresy obrazów, jeśli ruch z grafiki ma znaczenie,
• tagi hreflang w serwisach wielojęzycznych, z nowymi adresami po obu stronach pary,
• strony autorów, informacje o firmie i inne elementy, które budują zaufanie.

Ostatni punkt bywa niedoceniany. Biogramy autorów, strona „o nas” i dane kontaktowe to sygnały, które opisujemy w tekście o tym, jak agencje budują sygnały EEAT w praktyce. Redesign, który chowa autorów albo usuwa stronę zespołu, zabiera z serwisu część kontekstu, z którego korzystają zarówno ludzie, jak i wyszukiwarki.

Wszystkie nowe adresy powinny mieć wskazujący na siebie tag rel="canonical". Po wdrożeniu sprawdź, czy kanoniczne nie wskazują przypadkiem starej domeny albo adresów ze środowiska testowego. To jeden z błędów, który potrafi zatrzymać indeksowanie nowych stron na tygodnie.

Harmonogram wdrożenia i moment przełączenia

Google radzi przenosić witrynę w okresie mniejszego ruchu, jeśli serwis ma wyraźną sezonowość. Sklep z ofertą świąteczną nie powinien migrować w listopadzie, a serwis B2B lepiej przełączyć w piątek wieczorem niż w poniedziałek rano. Typowy harmonogram wygląda tak:

W dniu przełączenia kolejność ma znaczenie. Najpierw włącz przekierowania, potem podmień plik robots.txt na wersję produkcyjną, usuń reguły noindex używane na stagingu i prześlij nowe mapy witryny w Search Console. Google sugeruje, by przez pewien czas trzymać tam dwie mapy: ze starymi i z nowymi adresami. Liczba zindeksowanych stron w starej mapie powinna z czasem spadać do zera, a w nowej rosnąć. Ostrzeżenia o przekierowaniach w starej mapie są w tej sytuacji normalne. Jak poprawnie przygotować samą mapę, opisujemy w tekście o tym, co umieścić w sitemap XML.

Przy zmianie domeny dochodzi jeszcze narzędzie zmiany adresu w Search Console. Używa się go dopiero po wdrożeniu przekierowań 301, i tylko przy przeniesieniu domeny lub subdomeny. Przejście z HTTP na HTTPS albo z www na wersję bez www nie wymaga tego narzędzia. Według angielskiej wersji pomocy Google komunikat o trwającej przeprowadzce widać w Search Console przez 180 dni, a przekierowania trzeba utrzymać co najmniej tyle, dłużej, jeśli stare adresy wciąż dostają ruch. W ogólnym przewodniku po przenoszeniu witryny Google mówi o co najmniej roku. Rozsądna praktyka to zostawić przekierowania na stałe i opłacać starą domenę przez lata, żeby nikt jej nie przejął.

Nie zapominaj też o miejscach poza stroną. Zmiana domeny oznacza aktualizację adresu w Profilu Firmy Google, w katalogach branżowych, w profilach społecznościowych i w podpisach mailowych. Firmy lokalne powinny sprawdzić to w pierwszej kolejności, bo Profil Firmy Google z nieaktualnym adresem strony prowadzi użytkownika przez przekierowanie albo, co gorsza, na nieistniejącą domenę.

Pierwsze 72 godziny: co monitorować

Po migracji Google przez pewien czas crawluje serwis intensywniej niż zwykle. Każde żądanie do starego adresu trafia przez przekierowanie na nowy, a nowe adresy są jednocześnie pobierane bezpośrednio. Serwer musi to wytrzymać, dlatego pierwszym punktem kontroli są błędy 5xx i czasy odpowiedzi. Potem kolejno:

1. Przekierowania na produkcji. Puść ponownie listę starych adresów. Wyniki na stagingu nie gwarantują, że produkcja ma te same reguły, bo konfiguracja serwera bywa inna.
2. Robots.txt i noindex. Sprawdź plik robots.txt na nowym hoście i kod źródłowy kilkunastu kluczowych stron. Zapomniany zakaz indeksowania z czasów developmentu to klasyk, który potrafi wyczyścić indeks w kilka dni.
3. Adresy kanoniczne i hreflang. Muszą wskazywać nowe adresy produkcyjne.
4. Narzędzie do sprawdzania adresów URL. Przetestuj kilka typów stron: stronę główną, kategorię, artykuł, stronę usługową. Zobacz, czy Google renderuje treść i widzi właściwy adres kanoniczny.
5. Analityka. Kod śledzący, zdarzenia i konwersje często znikają razem ze starym szablonem. Spadek ruchu w analityce bez spadku w Search Console oznacza problem z pomiarem, nie z widocznością.
6. Linki wewnętrzne. Crawl nowej wersji powinien pokazać zero linków do adresów przekierowanych. Każdy taki link to zbędny skok dla robota i dla użytkownika.

Raport Stan w indeksie w Search Console pokaże z opóźnieniem spadek liczby stron na starej wersji i wzrost na nowej. To normalny obraz. Niepokojący jest dopiero wzrost stron wykluczonych na nowej domenie albo rosnąca liczba błędów 404 wśród adresów, które miały być przekierowane.

Typowe błędy i sposoby ich naprawy

Większość problemów po migracji powtarza się w różnych projektach. Poniższa lista zbiera te, które najczęściej odpowiadają za trwałe straty:

• Przekierowania 302 zamiast 301. Wiele wtyczek i paneli hostingowych domyślnie ustawia przekierowanie tymczasowe. Google z czasem może potraktować je jak stałe, ale nie ma powodu czekać. Naprawa: zmiana kodu na 301 lub 308.
• Wszystko na stronę główną. Wygodne dla zespołu, kosztowne dla widoczności. Naprawa: dopasowanie odpowiedników dla adresów z ruchem i linkami, reszta jako 404 lub 410.
• Zablokowany staging, który stał się produkcją. Robots.txt z Disallow: / albo nagłówek X-Robots-Tag: noindex. Naprawa: usunięcie blokady i prośba o ponowne zindeksowanie kluczowych adresów.
• Zmienione tytuły i treść. Nowy szablon generuje tytuły z nazwy strony i nazwy firmy. Naprawa: przywrócenie tytułów z archiwum, strona po stronie, zaczynając od adresów z największym ruchem.
• Zgubione linki wewnętrzne. Nowe menu jest krótsze, moduły powiązanych wpisów zniknęły, a część stron została bez linków. Naprawa: porównanie liczby linków wewnętrznych przed i po migracji dla najważniejszych adresów.
• Zmieniona wersja mobilna. Google indeksuje wersję mobilną, więc treść schowana lub wycięta na telefonach przestaje się liczyć. Naprawa: porównanie treści desktop i mobile na tych samych adresach.
• Przekierowania usunięte po kilku miesiącach. Przy porządkach na serwerze ktoś uznaje stare reguły za zbędne. Naprawa: przywrócenie reguł i zapisanie w dokumentacji, że mają zostać na stałe.

Osobnym przypadkiem są serwisy oparte na JavaScripcie. Jeśli nowy front renderuje treść dopiero w przeglądarce, Google zwykle sobie z tym poradzi, choć z opóźnieniem, ale wiele robotów AI nie wykonuje skryptów wcale. Warto to sprawdzić przed migracją, a nie po niej. Mechanizm opisujemy w tekście o tym, dlaczego AI nie widzi treści renderowanej w JavaScripcie.

Kiedy spadek jest normalny, a kiedy to awaria

Google przyznaje, że w trakcie przenoszenia mogą wystąpić tymczasowe wahania pozycji. W dokumentacji czytamy, że przeniesienie małej lub średniej witryny zajmuje zwykle kilka tygodni, a w przypadku większych serwisów dłużej. Tempo zależy od liczby adresów i szybkości serwera. Krótki, płytki spadek w pierwszych tygodniach jest więc wpisany w proces.

Jak odróżnić wahania od awarii? Kilka praktycznych kryteriów:

Jeśli spadek dotyczy jednej sekcji, szukaj przyczyny w tej sekcji: zwykle chodzi o brakujący wzorzec przekierowania, inny szablon albo wyciętą treść. Jeśli spadek jest rozłożony, ale głęboki, sprawdź kalendarz aktualizacji Google. Migracja przypadająca na tydzień aktualizacji głównej daje dwa nakładające się sygnały i łatwo przypisać skutki niewłaściwej przyczynie. Jak czytać takie zmiany, wyjaśniamy w tekście o tym, jak działają aktualizacje główne algorytmów Google. Z tego samego powodu warto unikać przełączania serwisu w trakcie ogłoszonej aktualizacji.

Na koniec rzecz, o której rzadko się mówi: migracja to dobry moment, by sprawdzić cały serwis według listy kontrolnej technicznego SEO. Ale poprawki, które nie są konieczne do samej przeprowadzki, lepiej wdrożyć osobno, po ustabilizowaniu ruchu. Inaczej znów wrócimy do problemu z początku: zbyt wielu zmian naraz i braku odpowiedzi na pytanie, która z nich zadziałała.

FAQ