Najważniejsze wnioski w pigułce
Skala problemu:
- ~60% migracji kończy się spadkiem ruchu organicznego
- 19 z 32 najczęstszych błędów występuje podczas samego wdrożenia (go-live)
- Większość katastrof po migracji to te same, powtarzalne błędy — nie pech
Planowanie i przygotowanie (6 błędów):
- Brak benchmarku przed migracją uniemożliwia odróżnienie normalnej zmienności od prawdziwej katastrofy
- Usunięcie starej bazy danych zaraz po starcie eliminuje jedyną możliwość cofnięcia zmian
- Nowa domena może dziedziczyć kary i toksyczny profil linków poprzedniego właściciela
- Zmiana domeny + CMS + design + treści naraz uniemożliwia diagnozę przyczyn spadku
Kontrola crawlowania i indeksowania (6 błędów):
- Najczęstsza katastrofa: zapomnienie o usunięciu noindex z całej witryny po uruchomieniu
- Skopiowanie robots.txt ze stagingu może blokować całą nową stronę (
Disallow: /) - Nowe CMS często nadpisują ręczne ustawienia SEO automatycznymi regułami
Przekierowania i architektura URL (6 błędów):
- Przekierowanie wszystkiego na stronę główną zamiast mapowania 1:1 marnuje equity linków
- Crawl znajduje tylko zlinkowane strony — najcenniejsze URL mogą być sierotami
- Użycie 302 zamiast 301, łańcuchy przekierowań i pętle gubią wartość SEO
Treść, metadane i zasoby (8 błędów):
- Title i meta description żyją w
<head>— zespoły QA rutynowo je pomijają - Utrata schema markup = utrata rich results i kliknięć, które generowały
- Przepisywanie treści podczas migracji zamiast like-for-like przeniesienia mnoży ryzyko
Aspekty techniczne i AI (6 błędów):
- JavaScript renderowany po stronie klienta może nie zostać wykonany przez Googlebota
- Utrata ciągłości pomiarów Analytics/GA4 uniemożliwia ocenę skutków migracji
- Brak optymalizacji pod LLM i AI search (np. brakujące dane strukturalne) obniża widoczność w nowych kanałach
Migracja strony internetowej to jedno z najbardziej ryzykownych przedsięwzięć w SEO. Około 60% migracji kończy się mierzalnym spadkiem ruchu organicznego — nie dlatego, że to loteria, ale dlatego, że te same błędy powtarzają się w kółko, w tej samej kolejności.
Agencja Pwani Consulting przeanalizowała 32 najczęstsze błędy migracyjne i zmapowała je według fazy, w której występują. Wynik? Przytłaczająca większość — 19 z 32 — dzieje się dokładnie w momencie wdrożenia (go-live). To tam koncentruje się prawdziwe ryzyko.
Dlaczego większość migracji kończy się porażką
Problem nie leży w złożoności technicznej samej w sobie, ale w przewidywalnych zaniedbaniach na każdym etapie procesu. Migracje rozpadają się w trzech fazach:
Pre-migracja (8 błędów) — planowanie i przygotowanie. Tutaj decyduje się, czy będziesz w stanie w ogóle zmierzyć skutki zmiany, czy masz plan awaryjny i czy nie wchodzisz na zdewastowaną wcześniej domenę.
Go-live — strefa największego ryzyka (19 błędów) — dzień startu to pole minowe. Crawlowanie, indeksowanie, przekierowania, treść, aspekty techniczne — wszystko może pójść nie tak jednocześnie, a każdy błąd mnoży kolejne.
Post-migracja (5 błędów) — monitoring i odzyskiwanie pozycji. Brak planu obserwacji albo paniczna reakcja w pierwszym tygodniu potrafi zmienić normalną zmienność w prawdziwą katastrofę.
Faza 1: Planowanie i przygotowanie — 6 błędów, które zdecydują o wszystkim
Brak benchmarku przed migracją
Bez punktu odniesienia nie odróżnisz naturalnego „osiadania" wyników od rzeczywistej katastrofy. Przed startem musisz zrobić snapshot: pozycje w rankingu, ruch organiczny, konwersje, pokrycie indeksu i top landing pages. Wyeksportuj najbardziej zlinkowane i najsilniejsze URL — to Twoje priorytetowe przekierowania. Bez tego lecisz na ślepo.
Brak backupów — lub zbyt szybka likwidacja starej strony
Usunięcie starej bazy danych w momencie startu oznacza wyrzucenie jedynej siatki bezpieczeństwa. Zachowaj pełne kopie zapasowe plików i bazy — możesz potrzebować porównania starego i nowego, żeby zdiagnozować problem. Nie likwiduj starego środowiska, dopóki nowe nie ustabilizuje się w sposób mierzalny. Brak backupu = brak możliwości cofnięcia, a coś zazwyczaj idzie nie tak.
Niezbadana historia nowej domeny
Przeprowadzka na nową lub zakupioną domenę może po cichu odziedziczyć kary i toksyczną przeszłość poprzedniego właściciela. „Czysta" domena brandowa kupiona z drugiej ręki potrafi nieść bagaż, który zdusi całą migrację. Przed zatwierdzeniem zleć audyt profilu linków zwrotnych i historii w Search Console.
Zmiana zbyt wielu zmiennych naraz
Domena + CMS + design + treść w jednym ruchu sprawiają, że jakikolwiek spadek staje się niemożliwy do zdiagnozowania. Jeśli redesign i zmiana domeny startują razem, a ruch spada — nie wiesz, co było powodem. Izoluj zmiany tam, gdzie możesz: najpierw platforma, potem redesign (lub odwrotnie). Mniej jednoczesnych zmiennych = szybsza diagnoza i odzyskanie.
Migracja w najgorszym możliwym momencie
Wdrożenie podczas szczytu sezonu mnoży koszt każdego błędu. Zaplanuj start na najsłabsze okno ruchu, żeby zmienność robiła najmniejszą krzywdę. Unikaj startu tuż przed dużym okresem sprzedażowym lub kampanią. Daj sobie czas na monitoring i naprawy, zanim nadejdzie szczyt.
Brak planu monitoringu po migracji — i panika zbyt wcześnie
Start nie jest linią mety, ale pierwszy tydzień to też nie moment na wyrywanie rzeczy z korzeniami. Przygotuj pisemną checklistę post-launch: ruch, rankingi, indeksacja, błędy crawlowania, przekierowania, Core Web Vitals. Monitoruj GSC i analitykę codziennie przez pierwsze kilka tygodni. Spodziewaj się 4–12 tygodni zmienności przy czystej migracji — nie wprowadzaj panikowanych zmian, które zabrudzą sygnał.
Faza 2: Go-live — 19 błędów w strefie największego ryzyka
Kontrola crawlowania i indeksowania — 6 błędów
Indeksowanie stagingu przed startem — lub pozostawienie blokady po starcie. Oba scenariusze to fail: staging w indeksie przed premierą i żywa strona wciąż zablokowana po starcie. Chroń staging hasłem lub ograniczeniem IP, nie tylko tagiem noindex. Najczęstsza katastrofa startowa: zapomnienie o USUNIĘCIU noindex z całej witryny, co czyni nową stronę niewidzialną. Uczyń „sprawdź, czy noindex został usunięty" jawnym punktem checklisty.
Uruchomienie z zablokowanym katalogiem głównym. Pojedyncza linia Disallow: / w robots.txt blokuje wyszukiwarki przed całą nową stroną. Skopiowane pliki robots.txt ze stagingu to typowy winowajca. Przejrzyj robots.txt linijka po linijce przed startem i potwierdź, że ważne sekcje są crawlowalne, nie tylko homepage.
Nieaktualizowanie robots.txt pod nową architekturę — i blokowanie JS/CSS. Nowe struktury URL wymagają nowych reguł; blokowanie zasobów całkowicie psuje renderowanie. Dodaj/usuń reguły Disallow, żeby pasowały do nowej struktury i nie marnować budżetu crawlowania. Nigdy nie blokuj JavaScriptu ani CSS — Googlebot potrzebuje ich do renderowania i zrozumienia strony. Zlinkuj sitemap z robots.txt, żeby przyspieszyć odkrywanie.
Niemigrowanie reguł noindex/nofollow na poziomie strony. Reguły na poziomie całej witryny przyciągają uwagę; dyrektywy na poziomie strony po cichu giną lub są źle aplikowane. Zrób audyt, które konkretne strony powinny pozostać noindex (loginy, cienkie/wewnętrzne strony), a które nie. Przypadkowy noindex przeniesiony na stronę zarabiającą po cichu usuwa ją z wyszukiwania. Równie dobrze usunięty noindex może odsłonić prywatne strony.
Nowa logika CMS nadpisująca ręczne ustawienia SEO. Platforma po cichu regeneruje kanoniczne, meta robots lub noindex — nadpisując ludzkie wprowadzenie. Replatformowanie (np. na Shopify, Webflow, headless stack) często auto-generuje tagi SEO według szablonu. Zautomatyzowana logika platformy może kolidować z ręcznymi ustawieniami SEO i wygrać. Sprawdzaj wyrenderowane wyjście pod kątem kanonicznych, meta robots i tytułów wygenerowanych przez CMS.
Pominięcie pełnego crawlu QA stagingu przed startem. Najtańsze miejsce na wyłapanie każdego z powyższych problemów to moment, zanim ktokolwiek zobaczy nową stronę. Przeskanuj staging Screaming Frog / Sitebulb (z włączonym renderowaniem JS) i porównaj z crawlem live. Sprawdź kody statusu, tytuły, kanoniczne, noindex, hreflang i linki wewnętrzne — różnią się tylko tam, gdzie zamierzono. Napraw na stagingu, nie w produkcji pod ruchem.
Przekierowania i architektura URL — 6 błędów
Słabe mapowanie przekierowań — zrzuty na homepage, sieroty, miękkie 404. Największy pojedynczy wyznacznik tego, czy migracja przetrwa. Zmapuj każdy stary URL 1:1 do jego najbliższego odpowiednika nowego URL — nigdy nie przekierowuj wszystkiego masowo na stronę główną. Przekierowanie na luźno powiązaną stronę produkuje miękkie 404 i marnuje equity linków. Niekompletne mapy pozostawiają osierocone strony, które tracą całą swoją wartość.
Budowanie mapy przekierowań tylko z crawla. Crawl znajduje tylko zlinkowane strony — Twoje najcenniejsze URL mogą nie być wśród nich. Pobieraj URL również z logów serwera, profilu linków zwrotnych (Ahrefs/Majestic) i starych sitemap XML. Osierocone-ale-rankujące strony i cele linków często nie żyją nigdzie w grafie linków wewnętrznych. Pomiń je w mapie, a przekierujesz je do nikąd.
Zły typ przekierowania — 302, łańcuchy, pętle i przekierowania JS. Jak przekierowujesz, ma takie samo znaczenie jak to, czy w ogóle to robisz. Używaj stałych 301 (lub 308), nie tymczasowych 302 — tymczasowe nie przekazują equity w sposób niezawodny. Przekierowuj stary → finalny cel bezpośrednio; łańcuchy powyżej ~5 skoków mogą nie być śledzone i spowalniają ładowanie. Unikaj pętli (A→B→A), które łapią crawlery, oraz przekierowań JavaScript po stronie klienta, których Google może nigdy nie wykonać.
Wprowadzanie niepotrzebnych zmian URL. Jeśli URL już rankuje, zmiana go z przyczyn kosmetycznych to czyste ryzyko spadku. Zachowaj istniejące struktury URL wszędzie, gdzie to możliwe — jeśli nie jest zepsute, nie zmieniaj. Każdy zmieniony URL wymusza ponowną ocenę i dodaje przekierowanie do utrzymania. Zmieniaj tylko tam, gdzie jest prawdziwy powód strukturalny lub UX.
Nieaktualizowanie linków wewnętrznych — i tworzenie sierot. Linki wskazujące na stare URL uruchamiają się przez przekierowania i marnują budżet crawlowania. Aktualizuj linki wewnętrzne, nawigację, breadcrumby i linki w treści bezpośrednio do nowych URL. Nie polegaj na przekierowaniach, żeby zakleić nieaktualne linki wewnętrzne. Upewnij się, że każda ważna strona jest wciąż zlinkowana skądś — sieroty wypadają z indeksu.
Usuwanie ważnych stron z nawigacji. Hierarchia to sygnał rankingowy — zakopanie strony głębiej osłabia ją. Utrzymuj kluczowe strony na podobnej głębokości/odległości kliknięć od homepage. Redesigny, które przearchitektonizują menu, mogą degradować strony bez niczyjej uwagi. Zachowaj lub popraw pozycję stron, na których Ci zależy w rankingu.
Treść, metadane i zasoby — 8 błędów
Niemigrowanie title tagów i meta descriptions. Żyją w head, nie w body strony — więc zespoły QA treści rutynowo je pomijają. Przenieś tytuły i meta opisy dokładnie; puste lub generyczne niszczą CTR i relevancję. Uważaj na stare nazwy brandowe pozostawione w tytułach po rebrandingu. Zachowaj je identyczne przy starcie, potem optymalizuj ~2 tygodnie później, gdy sytuacja się ustabilizuje.
Niemigrowanie danych strukturalnych/schema. Strać markup, a stracisz rich results, potem kliknięcia, które zarabiały. Wyeksportuj i re-implementuj Product, Article, FAQ, Breadcrumb i inne schema na nowych szablonach. Waliduj Rich Results Test po starcie — zmiany CMS często upuszczają lub psują to. Potwierdź, że JSON-LD referencyjny wskazuje nowe URL, nie stare.
Błędnie skierowane kanoniczne i duplikacja nowych kategorii. Mieszane sygnały kanoniczne i niekontrolowane strony filtrów/kategorii dezorientują indeksowanie. Gdy przekierowujesz A→B, upewnij się, że kanoniczny B wskazuje na B, nie z powrotem na A. Nowe kategorie, filtry i facetowana nawigacja mogą wyprodukować setki duplikatów URL — kanonizuj je. Audytuj pod kątem referencji starych URL pozostawionych w tagach canonical po migracji.
Nieaktualizowanie markup hreflang. Targetowanie międzynarodowe załamuje się w momencie, gdy hreflang referencyjny odnosi się do nieaktualnych URL. Aktualizuj każdy URL hreflang do jego nowego odpowiednika — nawet z 301 w miejscu. Uważaj na klastry językowe (np. fr-CA vs fr-FR) łączone lub duplikowane podczas migracji. Zepsute hreflang serwuje złą regionalną wersję w wynikach.
Przepisywanie treści podczas migracji. Zmiana copy i struktury w tym samym czasie co przeprowadzka zaciemnia przyczynę i skutek. Migruj like-for-like najpierw; Google już zaindeksował i zrozumiał starą treść. Ciężkie edycje treści przesuwają relevancję słów kluczowych i wymuszają pełny re-crawl i ponowną ocenę. Optymalizuj treść PO tym, jak strona się ustabilizuje, nie podczas przeprowadzki.
Utrata alt text obrazów i zasobów multimedialnych. Obrazy tracą kontekst SEO, gdy alt text nie jest migrowany lub jest auto-generowany przez nowy CMS. Przenieś alt text dokładnie; sprawdź, czy nowe URL obrazów są prawidłowo przekierowane z starych (jeśli zmieniły hosting/CDN). Utracone opisy obrazów obniżają relevancję strony i eliminują ruch z Google Images.
Brakujące lub zepsute Open Graph i Twitter Cards. Social media opiera się na tych metadanych do podglądów — zepsute lub brakujące OG tagi niszczą udostępnienia. Zmigruj Open Graph, Twitter Card i inne tagi społecznościowe. Testuj podglądy linków na Facebooku i Twitterze przed startem; CMS często nie przenosi ich automatycznie.
Utrata ciągłości pomiarów Analytics/GA4. Zmiana ID śledzenia lub nieprzeniesienie właściwości GA4 oznacza, że porównania rok do roku są niemożliwe. Jeśli przechodzisz z Universal Analytics na GA4 podczas migracji, utracisz ciągłość danych historycznych. Zachowaj te same właściwości/ID śledzenia lub wyraźnie dokumentuj przerwy w danych. Bez ciągłości pomiarów nie możesz ocenić wpływu migracji.
Faza 3: Post-migracja — 5 błędów w monitoringu i odzyskiwaniu
Nieprzesłanie Change of Address w Google Search Console. Narzędzie Change of Address istnieje właśnie do migracji domeny — jego pominięcie spowalnia przeniesienie sygnałów. Dla migracji domena→domena prześlij formularz Change of Address w GSC starej domeny; pomaga Google szybciej zrozumieć przeprowadzkę. Nie pomaga w migracjach protokołu (HTTP→HTTPS) ani zmianach podkatalogu/subdomeny.
Nieprzesłanie nowych sitemap i nieaktualizowanie starych. Sitemapy to najprostszy sposób, by powiedzieć Google, co indeksować teraz — nieaktualne sitemapy wysyłają roboty w złe miejsca. Prześlij nowe sitemapy XML zawierające wyłącznie nowe URL; usuń lub zaktualizuj stare sitemapy, żeby nie wskazywały przekierowań. Przyspiesza to odkrywanie i indeksowanie; potwierdź brak błędów w raporcie Sitemap w GSC.
Nieprawidłowa obsługa adresu IP i zmian serwera/CDN. Powolne propagacje DNS lub błędnie skonfigurowane CDN mogą sprawić, że nowa strona będzie niedostępna dla botów lub użytkowników. Sprawdź propagację DNS przed ogłoszeniem startu; potwierdź, że CDN/firewall nie blokuje Googlebota. Monitoruj czas dostępności i czas odpowiedzi serwera (TTFB) — wolne nowe hostowanie obniża crawl rate i rankingi.
Ignorowanie ostrzeżeń Core Web Vitals i regresji wydajności. Nowy CMS lub szablon mogą pogorszyć LCP, CLS lub INP — bezpośrednie sygnały rankingowe. Monitoruj Core Web Vitals w GSC i PageSpeed Insights po starcie; spadek wydajności boli podwójnie podczas migracji. Napraw regresje szybko; wolniejsza strona rankuje gorzej, nawet jeśli wszystko inne jest perfekcyjne.
Brak optymalizacji pod LLM i AI search. Nowe kanały — ChatGPT, Perplexity, Google SGE — polegają na danych strukturalnych i jasnym kontekście treści. Jeśli Twoja migracja nie uwzględnia schema, czytelnych nagłówków i dobrze zdefiniowanych odpowiedzi FAQ, tracisz widoczność w AI-generowanych odpowiedziach. To nie zastępuje tradycyjnego SEO, ale dodaje nowy wymiar ryzyka do zignorowania.
Podsumowanie
Migracja strony to kontrolowane ryzyko, nie loteria — jeśli znasz mapę błędów i wiesz, w której fazie każdy z nich uderza, możesz ich uniknąć. Gęsta „pomarańczowa plama" przypada na go-live — 19 z 32 pułapek — więc właśnie tam należy skupić uwagę, checklisty i testy QA. Firmy, które przeżywają migracje bez strat, nie mają szczęścia; po prostu robią te same rzeczy, w tej samej kolejności, za każdym razem.
Źródło i pełna interaktywna mapa błędów: Pwani Consulting — Site migration mistakes that quietly tank rankings , 2026
