Migracja SEO

Rodzaje migracji strony i poziom ryzyka dla SEO

Słowo „migracja” obejmuje bardzo różne zmiany, od przeniesienia na nowy serwer po połączenie dwóch serwisów pod nową domeną, i każda wymaga innego zakresu pracy. Ryzyko rośnie z liczbą adresów, które się zmieniają, i z liczbą rzeczy zmienianych jednocześnie.

Google w dokumentacji o przenoszeniu witryny ze zmianą adresów zaleca zmieniać jedną rzecz naraz, na przykład najpierw domenę, a dopiero później układ strony. W pomocy do narzędzia zmiany adresu dodaje, że łączenie przeprowadzki z przebudową treści lub struktury adresów może skończyć się utratą ruchu, a kilku serwisów nie należy scalać w jednym kroku, tylko przenosić je po kolei i czekać na stabilizację ruchu. Jeśli biznes wymaga zmiany wszystkiego naraz, planuję dłuższy monitoring i z góry ustalam, po czym poznamy, który element zawinił.

Harmonogram migracji SEO – co robię na każdym etapie

Najwięcej pracy przy dobrej migracji dzieje się przed startem, a nie w dniu przełączenia. Przy typowym projekcie zaczynam kilka tygodni wcześniej, a monitoring trwa 90 dni, przy czym przekierowania i nadzór nad nimi zostają na dłużej.

Najlepszy moment, żeby mnie zaangażować, to etap projektowania nowej struktury, zanim ktoś ustali adresy. Wtedy jeszcze da się zachować stare adresy tam, gdzie nie ma powodu ich zmieniać, a każdy adres, który się nie zmienia, to jedno przekierowanie mniej do utrzymania.

Inwentaryzacja adresów – skąd biorę pełną listę URL-i

Mapa przekierowań jest tak dobra, jak lista adresów, z której powstała, a lista podstron z CMS-u to zwykle tylko jej część. Najcenniejsze adresy często nie występują w menu ani w sitemapie: stare artykuły z linkami zewnętrznymi, archiwalne kampanie, pliki PDF, adresy z parametrami z dawnych reklam.

Google w dokumentacji o przenoszeniu witryny wymienia jako źródła mapy witryny, logi serwera, analitykę, raport linków w Search Console i sam CMS, i przypomina, żeby uwzględnić też obrazy, wideo oraz pliki JavaScript i CSS. Ja łączę te źródła w jedną tabelę:

• Crawl obecnej wersji z renderowaniem JavaScriptu, łącznie z obrazami i plikami.
• Wszystkie mapy witryny, także stare, o których nikt nie pamięta, i pliki zgłoszone kiedyś w Search Console.
• Search Console: adresy z wyświetleniami i kliknięciami z całego dostępnego w raporcie okresu, raport linków, raport Strony.
• GA4: strony docelowe z ruchem z wszystkich kanałów, nie tylko z wyszukiwarki, bo newsletter i reklamy też mają swoje adresy.
• Narzędzie do analizy linków (Ahrefs): adresy, do których prowadzą linki zewnętrzne, w tym te zwracające dziś 404.
• Logi serwera przy dużych serwisach: adresy, które Googlebot nadal odwiedza.
• Eksport z CMS-u lub bazy produktów: pełna lista produktów, kategorii, wpisów i ich identyfikatorów, która ułatwia automatyczne dopasowanie.

Po złączeniu i usunięciu duplikatów każdy adres dostaje dane: ruch organiczny, liczbę domen linkujących, pozycje i konwersje. Na tej podstawie dzielę adresy na grupy. Dla grupy z ruchem lub linkami każdy wiersz mapy sprawdzam ręcznie, a dla długiego ogona, na przykład tysięcy produktów, dopasowuję adresy automatycznie po identyfikatorze lub SKU i sprawdzam próbki.

Mapa przekierowań 301 – reguły, według których przypisuję adresy

Każdy stary adres z wartością powinien prowadzić jednym przekierowaniem stałym do najbliższego odpowiednika treści, a adresy, których celowo nie przenosisz, powinny zwracać 404 lub 410. Google w tej samej dokumentacji zaznacza, że przekierowania nie powodują utraty PageRank, więc problemem nie jest samo przekierowanie, tylko złe miejsce docelowe.

Google odradza kierowanie wielu starych adresów na jedną niepowiązaną stronę, na przykład stronę główną. Przy łańcuchach zaleca, żeby było ich jak najmniej: najlepiej bez pośredników, a jeśli się nie da, około trzech skoków i mniej niż pięć, przy czym Googlebot podąża za maksymalnie dziesięcioma. W mojej mapie każdy wiersz ma kolumnę „typ decyzji” i krótkie uzasadnienie, żeby po miesiącach dało się odtworzyć, dlaczego dany adres trafił właśnie tam.

Typy przekierowań i jak traktuje je Google

Tabela opiera się na dokumentacji Google o przekierowaniach (aktualizacja z kwietnia 2026 roku). W praktyce najczęstszy błąd, który znajduję, to przekierowania 302 ustawione domyślnie przez wtyczkę lub framework i nigdy niezmienione na stałe.

Jak technicznie wdrażam przekierowania i testuję mapę

Przekierowania wdrażam tam, gdzie zadziałają najszybciej i najpewniej: na serwerze, w CDN-ie albo w routingu aplikacji, a nie w JavaScripcie po stronie przeglądarki. Wybór miejsca zależy od liczby reguł i od tego, kto będzie je utrzymywał.

• Reguły wzorcowe (na przykład cały katalog /blog/2019/... na /blog/...) zapisuję jako wyrażenia w konfiguracji serwera lub frameworka, bo jedna reguła obsługuje tysiące adresów.
• Mapy jeden do jednego przy dużej liczbie adresów trzymam w pliku lub bazie i odczytuję w warstwie routingu, zamiast tworzyć tysiące osobnych reguł, które spowalniają każde żądanie.
• W Next.js krótkie listy trafiają do konfiguracji przekierowań, a duże mapy obsługuję w warstwie pośredniej z wyszukiwaniem w strukturze typu słownik. Opisuję to szerzej przy usłudze migracji do Next.js.
• Normalizacja adresów: wielkość liter, ukośnik na końcu, stare rozszerzenia .html i .php, kodowanie polskich znaków. Te warianty obsługuję regułami ogólnymi przed mapą szczegółową.

Mapę testuję automatycznie. Skrypt pobiera każdy stary adres z mapy, sprawdza kod odpowiedzi, liczbę skoków, adres docelowy i kod odpowiedzi strony docelowej, a wynik porównuje z oczekiwanym. Test przechodzi tylko wtedy, gdy każdy wiersz kończy się jednym przekierowaniem 301 lub 308 na stronę zwracającą 200, a adresy usunięte zwracają 404 lub 410. Ten sam test uruchamiam na stagingu, w dniu startu na produkcji i potem cyklicznie w okresie monitoringu.

Testy na stagingu – co porównuję między starą a nową wersją

Na stagingu porównuję starą i nową wersję szablon po szablonie, bo spadki po migracji rzadko wynikają z samych przekierowań, a częściej z tego, że nowa strona po cichu straciła treść, linki lub sygnały. Robię dwa crawle i zestawiam je adres do adresu według mapy.

Lista kontrolna przed startem

Staging zabezpieczam hasłem, a nie tylko tagiem noindex, bo hasło nie przeniesie się przypadkiem na produkcję razem z szablonem. Google w dokumentacji o zmianie hostingu bez zmiany adresów przypomina, żeby przed przełączeniem usunąć tymczasowe blokady w robots.txt i tagi noindex pozostawione z budowy nowej wersji. To jedna z najczęstszych przyczyn zniknięcia strony z wyników po starcie. Szczegóły problemów z renderowaniem opisuję w artykule o JavaScript SEO.

Dzień startu migracji – moja lista kroków

Dzień startu powinien być nudny: wszystko, co da się przetestować wcześniej, jest już przetestowane, a w dniu przełączenia sprawdzam tylko, czy produkcja zachowuje się tak jak staging. Start planuję na okres mniejszego ruchu, co Google również zaleca przy ruchu sezonowym.

1. Zamrożenie treści w starym CMS-ie na czas przełączenia, żeby nie powstały adresy spoza mapy.
2. Wdrożenie nowej wersji i przekierowań, zdjęcie hasła, noindex i blokad z robots.txt.
3. Automatyczny test całej mapy przekierowań na produkcji i ręczna kontrola najważniejszych adresów narzędziem Sprawdzanie adresu URL.
4. Zgłoszenie nowej mapy witryny w Search Console. Starą mapę z dawnymi adresami zostawiam do monitorowania, bo Google opisuje ją jako pomocną w śledzeniu przeprowadzki, a ostrzeżenia o przekierowaniach w niej są wtedy oczekiwane.
5. Przy zmianie domeny: narzędzie zmiany adresu w Search Console dla starej domeny i wszystkich jej zweryfikowanych wariantów.
6. Ustawienie szybkości indeksowania na decyzję Googlebota w obu usługach i sprawdzenie, czy nowy serwer wytrzyma zwiększony ruch robota, przed którym Google ostrzega po przeprowadzce.
7. Pełny crawl nowej wersji i porównanie z crawlem ze stagingu.
8. Aktualizacja adresów w kampaniach reklamowych, profilach firmy, newsletterach i u partnerów, którzy linkują najczęściej używane strony.

Przy zmianie samego hostingu, bez zmiany adresów, Google radzi obniżyć TTL rekordów DNS do kilku godzin co najmniej tydzień przed przeprowadzką i nie wyłączać starego serwera, dopóki logi pokazują na nim ruch. Ten wariant też traktuję jako migrację, bo firewall nowego serwera blokujący Googlebota potrafi narobić tyle samo szkody co brakujące przekierowania.

Monitoring po migracji – co mierzę i kiedy reaguję

Po starcie najważniejsze jest to, żeby błąd wykryć w ciągu dni, a nie po miesiącu w raporcie ruchu. Google uprzedza, że w trakcie przeprowadzki pozycje mogą się tymczasowo wahać, a przeniesienie średniego serwisu zajmuje kilka tygodni, dużego dłużej. Dlatego odróżniam normalne wahania od sygnałów, że coś jest zepsute.

Google podaje, że przeprowadzka jest zakończona dopiero wtedy, gdy Googlebot odwiedzi każdy stary i nowy adres co najmniej raz, i że nie ma stałej częstotliwości takich wizyt. Dlatego rzadko odwiedzane adresy długiego ogona mogą przechodzić tygodniami. W okresie 90 dni monitoringu śledzę pozycje 50 najważniejszych fraz i co tydzień raportuję stan indeksowania, a każdy nowy błąd 404 z wartością od razu dopisuję do mapy.

Zmiana domeny i rebranding – czego wymaga narzędzie zmiany adresu

Narzędzie zmiany adresu w Search Console działa tylko przy przenoszeniu domeny lub subdomeny na inną domenę i ma kilka warunków, które trzeba spełnić przed startem. Nie służy do przejścia na HTTPS, zmiany www na wersję bez www ani zmiany ścieżek w tej samej domenie.

• Musisz być właścicielem starej i nowej usługi w Search Console na tym samym koncie Google.
• Strona główna starej domeny musi przekierowywać na stronę główną nowej przekierowaniem 301.
• Wniosek obejmuje wszystkie warianty starej domeny (z www i bez, subdomeny), które trzeba zweryfikować, nawet jeśli nie są używane.
• Według pomocy Search Console powiadomienie o przeprowadzce i przenoszenie sygnałów trwają 180 dni, a przekierowania trzeba utrzymać co najmniej tyle, dłużej, jeśli Google wciąż kieruje na nie ruch. Starą domenę Google radzi utrzymać zarejestrowaną co najmniej rok.
• Przeprowadzek nie można łączyć w łańcuch: po przeniesieniu A na B nie da się od razu przenieść B na C.

Przy rebrandingu dochodzi warstwa, o której mało kto myśli: dane o marce poza stroną. Aktualizuję dane strukturalne Organization z odwołaniem do dawnej nazwy, profile firmy, wizytówkę Google, katalogi branżowe i profile społecznościowe, a największych wydawców linkujących proszę o zmianę adresu, zaczynając od linków z największym ruchem, jak radzi Google. Robię to także po to, żeby modele AI łączyły starą i nową nazwę z tą samą firmą. Jak sprawdzić, czy to działa, opisuję przy audycie widoczności w AI, a spójność encji w danych strukturalnych przy wdrażaniu Schema.org.

Migracja sklepu internetowego i przejście na Next.js – specyfika

Przy sklepach i zmianach technologii największe ryzyko nie leży w adresach stron, tylko w rzeczach generowanych automatycznie: filtrach, wariantach, paginacji, danych strukturalnych i sposobie renderowania. Te elementy sprawdzam osobno, niezależnie od mapy przekierowań.

Zmiana platformy sklepu

• Struktura adresów narzucona przez platformę. Niektóre platformy wymuszają stałe prefiksy w adresach produktów i kolekcji, więc przekierowania są nieuniknione i trzeba je zaplanować dla całego katalogu.
• Warianty produktów: czy kolor i rozmiar mają osobne adresy, czy parametry, i który adres ma być kanoniczny.
• Filtry i sortowanie: nowa platforma często generuje inne adresy filtrów; ustalam, które kombinacje mają być indeksowane, a które nie, żeby nie zmarnować crawl budgetu.
• Produkty niedostępne i usunięte: reguły muszą działać od pierwszego dnia, a nie dopiero po pierwszym raporcie błędów.
• Opinie i dane Product: przeniesienie ocen, cen i dostępności do danych strukturalnych nowego szablonu.
• Adresy obrazów: zmiana ścieżek do zdjęć produktów to utrata ruchu z wyszukiwarki grafiki, jeśli nie ma przekierowań.

Przejście z WordPressa lub innego CMS-u na Next.js

Przy migracji na Next.js sprawdzam, czy metadane, canonical i hreflang powstają po stronie serwera, czy zachowana jest polityka ukośnika na końcu adresu, czy nieistniejące adresy zwracają prawdziwe 404 i czy treść nie trafiła do komponentów ładowanych dopiero w przeglądarce. Ta zmiana to też okazja do poprawy Core Web Vitals, ale tylko wtedy, gdy nowa wersja jest mierzona przed startem, a nie po nim.

Spadek ruchu po migracji – jak szukam przyczyny i odzyskuję pozycje

Jeśli migracja już się odbyła i ruch spadł, przyczyna prawie zawsze należy do jednej z kilku grup, a kolejność sprawdzania ma znaczenie, bo pierwsze punkty są najczęstsze i najszybsze do naprawienia. Odtwarzam brakujące dane o starych adresach i porównuję je z tym, co dzieje się dziś.

1. Odtworzenie listy starych adresów z archiwalnych map witryny, Search Console (dane z całego dostępnego okresu), narzędzi do analizy linków i kopii w archiwach internetowych.
2. Kody odpowiedzi tych adresów dziś: brakujące przekierowania, przekierowania 302, łańcuchy, przekierowania na stronę główną.
3. Blokady indeksowania: noindex, robots.txt, canonical wskazujący staging lub starą domenę, nagłówki X-Robots-Tag.
4. Zgodność treści: czy nowe strony mają tę samą treść, nagłówki i tytuły, czy szablon nie skrócił opisów kategorii i produktów.
5. Linkowanie wewnętrzne: czy menu i treść nie prowadzą nadal przez przekierowania albo do usuniętych adresów.
6. Renderowanie i wydajność: czy treść jest w HTML-u z serwera i czy Core Web Vitals nie pogorszyły się po zmianie technologii.

Przekierowania dodane z opóźnieniem nadal działają, choć sygnały wracają wolniej niż przy migracji przygotowanej przed startem. Jeśli od migracji minęło ponad rok i ruch się ustabilizował na niższym poziomie, zamiast ratowania migracji robię pełny audyt SEO techniczny, bo przyczyny mogą już leżeć gdzie indziej. Spadki wynikające z utraty linków zewnętrznych do usuniętych adresów nadrabiam też w ramach link buildingu.

Co wpływa na zakres i koszt migracji SEO

Koszt migracji zależy od liczby adresów wymagających ręcznej decyzji, stopnia zmiany struktury i od tego, czy przekierowania wdrażam sam. Migracja SEO zaczyna się od 3 600 zł i obejmuje 90 dni monitoringu.

Szerszy opis całego procesu z przykładami znajdziesz w artykule migracja strony bez utraty pozycji, a ogólne zasady pozycjonowania, od których migracja nie zwalnia, na stronie pozycjonowania stron i SEO technicznego. Przy serwisach wielojęzycznych pomocny będzie artykuł o hreflang i SEO międzynarodowym.