Case study: migracja domeny bez utraty ruchu — checklist, timeline, wyniki

Migracja domeny to jedna z najbardziej ryzykownych operacji, jakie można wykonać na stronie z ugruntowaną pozycją w Google. Jedno przeoczone przekierowanie, jedna pominięta strona kanoniczna, jedna źle zaimplementowana reguła w pliku .htaccess — i spadek ruchu organicznego o 30-60% w ciągu dwóch tygodni. W branży SEO krąży przekonanie, że „jakaś utrata ruchu jest nieunikniona”. Twierdzę, że to mit wynikający z niedbale prowadzonych projektów. W tym case study pokażę, jak zmigrowaliśmy sklep e-commerce B2C (8500 URL-i, ~480 000 sesji organicznych miesięcznie) ze starej domeny na nową bez żadnej mierzalnej utraty ruchu po 90 dniach.

Case jest fikcyjny — ale metodologia, timeline i decyzje są dokładnie tymi, które stosujemy w realnych projektach migracyjnych. Wszystkie liczby zostały dobrane tak, by odzwierciedlać typowy sklep średniej wielkości w Polsce. Jeśli planujesz własną migrację, potraktuj ten tekst jak szczegółowy szablon operacyjny — nie ogólnik, tylko konkretny plan z wymienionymi narzędziami, regułami i punktami kontrolnymi.

Kontekst projektu: dlaczego w ogóle migrujemy domenę

Klient — nazwijmy go SkleSmart — prowadził od 2016 roku sklep e-commerce z elektroniką użytkową (małe AGD, audio, akcesoria komputerowe). Domena starasklep.pl była zbudowana wokół marki, której właściciel przejął w 2023 roku nowy inwestor. Decyzja biznesowa była jednoznaczna: zmiana nazwy spółki, rebranding, nowa domena nowasklep.pl. Termin: koniec kwartału. Budżet: ograniczony, ale z rezerwą na monitoring i ewentualne korekty.

Dane wyjściowe wyglądały następująco:

• 8500 URL-i indeksowalnych (6200 kart produktowych, 180 kategorii i subkategorii, 1900 artykułów blogowych, 220 stron pomocniczych).
• ~480 000 sesji organicznych miesięcznie (Google Analytics 4, ostatnie 6 miesięcy, średnia).
• ~3,1 mln wyświetleń i 92 000 kliknięć miesięcznie w Google Search Console.
• DR 52 (Ahrefs), ~14 200 linkujących domen.
• Roczny przychód z kanału organicznego: ~8,4 mln zł netto.

Ryzyko biznesowe utraty nawet 20% ruchu organicznego na 60 dni oznaczało prognozowaną stratę przychodu rzędu 280 000 zł. Właściciel wiedział to doskonale i dlatego dał nam jasny mandat: zerowa tolerancja dla spadków. Albo migracja przebiegnie technicznie bezbłędnie, albo nie robimy jej w ogóle.

To jest ta część rozmowy, której nigdy nie powinno zabraknąć. Zanim w ogóle zaczniesz planować migrację, musisz mieć klarowną odpowiedź na trzy pytania: Po co to robimy? Co konkretnie wolno nam stracić? Co się stanie, jeśli coś pójdzie nie tak? Bez tych odpowiedzi każdy projekt migracyjny staje się polem minowym bez mapy.

Założenia techniczne projektu

Oto założenia, które przyjęliśmy na starcie — wszystkie zostały zaakceptowane przez klienta w formie pisemnej (to ważne, bo chroni obie strony w razie sporów):

• Struktura URL 1:1 — każdy stary adres dostanie dokładnie jeden nowy odpowiednik (żadnego „posprzątania przy okazji”).
• Zero zmian w strukturze kategorii podczas migracji — rebranding wizualny zostanie wdrożony dopiero w D+14, gdy migracja domeny będzie potwierdzona jako stabilna.
• Migracja w piątek wieczorem (okno 20:00-02:00), bo to najniższy ruch tygodnia w tej niszy (sprawdzone w GA4).
• Redirect 301 na poziomie serwera (nie meta refresh, nie JS redirect), konfiguracja w nginx przed warstwą aplikacji.
• Hreflang, canonical, robots.txt, sitemap.xml — wszystko przygotowane w wersji testowej na środowisku staging na 10 dni przed migracją.
• Brak zmian w template’ach podczas weekendu migracyjnego — identyczny HTML, identyczne CSS, wszystko 1:1.

Ostatni punkt jest kluczowy i niedoceniany. Migracja domeny i redesign to dwa osobne projekty. Łączenie ich to proszenie się o katastrofę, bo w razie spadku ruchu nie wiesz, co było przyczyną: nowa domena czy nowy template. Rozdziel te rzeczy w czasie — minimum 21 dni odstępu.

Pre-migration audit: 21 dni przed D-day

Audyt przedmigracyjny rozpoczęliśmy dokładnie 21 dni przed planowanym terminem. Harmonogram wyglądał tak:

Etap 1: Inwentaryzacja URL-i (dni 1-3)

Najważniejsza czynność całej migracji. Każdy przeoczony URL to potencjalny 404 po migracji i utrata linku zewnętrznego, rankingów lub — w najgorszym scenariuszu — koszyka klienta w trakcie transakcji. Wykorzystaliśmy cztery źródła jednocześnie:

1. Screaming Frog SEO Spider z ustawionym User-Agentem Googlebota, JavaScript rendering włączonym, limit crawlu podniesiony na 50 000 URL-i. Crawl całego serwisu wraz z zewnętrznymi linkami wychodzącymi, obrazkami, plikami PDF i plikami statycznymi.
2. Google Search Console — eksport raportu „Zaindeksowane strony” (ostatnie 16 miesięcy), raportu „Pokrycie” z wyłączonymi, raportu „Wykluczone” z przyczynami. To ujawnia URL-e, których crawler może nie znaleźć (np. zaindeksowane z linków zewnętrznych, a nie z wewnętrznej struktury).
3. Logi serwera z ostatnich 90 dni — analiza w Logstash + Kibana, filtr po User-Agencie Google, Bing, Yandex. To pokazuje, co boty realnie odwiedzają (nie to, co im oferujemy, tylko to, co same chcą).
4. Eksport z Ahrefs „Top pages” i „Best by backlinks” — 5000 najlepszych URL-i po ruchu i linkach. Krytyczne dla złapania URL-i, które mają silne linki zewnętrzne, ale mogły wypaść z wewnętrznej struktury serwisu.

Po dedupe wyszło nam 8527 unikalnych URL-i kanonicznych. Plus 1840 URL-i z parametrami (filtry, sortowanie, paginacja), które nie miały być indeksowane, ale i tak wymagały reguł redirect, żeby nie generować 404 u użytkowników wracających ze starych zakładek. Plus 320 URL-i historycznych (starsze produkty, 301-kowane wcześniej), które również musiały zostać uwzględnione w łańcuchu przekierowań.

Łączna tabela w arkuszu Google: 10 687 wierszy. Kolumny: old_url, new_url, priority, traffic_90d, backlinks, status_code_expected, notes. Dokument udostępniony klientowi do review — właściciel sklepu musiał potwierdzić każdą parę URL-i dla top 200 produktów i wszystkich kategorii.

Etap 2: Benchmark ruchu i pozycji (dni 4-7)

Żeby po migracji mierzyć utratę (lub jej brak), musisz mieć bardzo dokładne „przed”. Przygotowaliśmy trzy benchmarki:

1. Benchmark ruchu GA4: 90 dni wstecz, dane agregowane dziennie, podział na źródła (organic, direct, referral, social, paid, email). Kluczowe metryki: sesje, użytkownicy, transakcje, przychód, bounce rate, engagement rate, sesje z landingiem == top 100 URL-i.
2. Benchmark pozycji: Senuto + Ahrefs, 4500 śledzonych fraz (wszystkie z widocznością, które generowały minimum 1 klik miesięcznie w GSC). Scrape przed migracją, potem codziennie przez D+30 i co 3 dni do D+90.
3. Benchmark Core Web Vitals: PageSpeed Insights API, run dla top 50 URL-i, field data z CrUX. LCP, CLS, INP, TTFB. Potrzebne, by po migracji stwierdzić, czy spadek ruchu (jeśli wystąpi) to problem indeksacji, czy problem wydajności nowego serwera.

Jeśli interesuje Cię głębsze ujęcie tematu benchmarkowania pozycji podczas migracji, rozpisaliśmy je w osobnym materiale monitoring pozycji w SEO — znajdziesz tam konfigurację alertów i progów, które wyłapują spadki zanim przerodzą się w kryzys.

Etap 3: Audyt techniczny nowej domeny (dni 8-14)

Nowa domena nowasklep.pl została zakupiona 18 miesięcy wcześniej (to świadomy ruch — domena „ogrzewana” przez rok z lądującą stroną i kilkoma artykułami blogowymi, żeby nie była w oczach Google „świeżynką”). Mimo to audyt obejmował:

• DNS: poprawne rekordy A, AAAA, MX, CNAME. TTL obniżony do 300 sekund na 72h przed migracją (żeby propagacja przy ewentualnym rollbacku była szybka).
• SSL: certyfikat z pokryciem na wszystkie subdomeny, test w SSL Labs (ocena A+), HSTS włączony ale z max-age=86400 na tydzień po migracji, potem zwiększony do 31536000.
• Serwery: load balancer przed dwoma serwerami aplikacyjnymi (redundancja w razie awarii w trakcie execution day), nginx jako reverse proxy z buforem 8k, fastCGI cache dla stron statycznych.
• Monitoring: Uptime Robot z checkiem co 60 sekund na 40 kluczowych URL-i (strona główna, top 20 kategorii, top 15 produktów, logowanie, koszyk, checkout), alerty Slack + SMS.
• Logi: rotacja dzienna, retention 90 dni, tail do centralnego systemu logowania.

Etap 4: Plik mapowania redirectów (dni 15-21)

Z 10 687 wierszy arkusza zbudowaliśmy plik redirects.conf dla nginx. Reguły były pogrupowane według wzorców:

• Reguły wzorcowe (regex): dla produktów, kategorii, artykułów blogowych — bo ich URL-e zmieniały tylko domenę, ścieżka była identyczna. To pokryło ~94% URL-i jedną regułą.
• Reguły 1:1 (explicit): dla ~650 URL-i, które wymagały mapowania innego niż proste podmienienie domeny (np. kilka starych artykułów miało dłuższe slugi przycięte w nowej wersji, strony pomocnicze zmieniły strukturę).
• Reguły dla parametrów: filtry, sortowania, paginacja. Decyzja: zachować parametry w pierwszych 14 dniach po migracji, potem stopniowo usuwać (osobny redirect na URL bez parametrów).

Plik został przetestowany na środowisku staging — każdy z 10 687 URL-i otrzymał automatyczny test HTTP z expect: 301 → 200 na poprawnym nowym URL. Test w skrypcie Python (requests + concurrent.futures), czas wykonania ~18 minut. Wynik pierwszego runu: 47 błędów (36 z literówkami w mapowaniu, 8 z zapomnianymi slashami, 3 z realnie błędnymi URL-ami). Poprawione, ponowny run: 0 błędów.

Strategia redirectów: zasady, które działają

Jeśli miałbym wyciągnąć jeden wniosek z kilkunastu prowadzonych migracji, to ten: jakość mapy redirectów decyduje o 80% sukcesu. Pozostałe 20% to monitoring i szybka reakcja. Oto zasady, które stosujemy:

Zasada 1: Tylko 301, nigdy 302 ani meta refresh

Kod 301 „Moved Permanently” jest jedynym, który Google traktuje jako sygnał trwałej zmiany. Kod 302 „Found” to przekierowanie tymczasowe — jeśli użyjesz go do migracji, Google może przez tygodnie trzymać w indeksie starą domenę, a linki zewnętrzne nie będą „przechodzić” sygnału pełnej siły. Meta refresh i przekierowania JavaScript (window.location.href) są jeszcze gorsze — Google czasem je uszanuje, czasem nie, a crawl budget zużywa dwa razy tyle co przy 301.

Zasada 2: Jedno hop, nigdy łańcuchy

Jeśli stary URL A przekierowywał już wcześniej na stary URL B (np. reorganizacja kategorii dwa lata temu), podczas migracji musisz kierować A bezpośrednio na nowy URL C — NIE na B, który znowu będzie redirectował na C. Łańcuchy redirectów (A → B → C) marnują crawl budget, wydłużają czas ładowania (każdy hop to ~100-300ms) i Google w pewnym momencie (zwykle przy 5+ hopach) po prostu przestaje podążać.

Zasada 3: Priorytetyzacja wg ruchu i linków

Top 200 URL-i generujących 80% ruchu dostaje osobne, ręcznie zweryfikowane mapowanie. Każdy z tych URL-i jest przetestowany osobno, każdy ma logowany status przez 90 dni, każdy jest sprawdzany co tydzień w GSC na „problemy indeksowania”.

Zasada 4: Sitemap.xml z oboma domenami

Przez pierwsze 30 dni po migracji utrzymujemy sitemapę dostępną pod starą domeną (starasklep.pl/sitemap.xml), ale zawierającą wyłącznie nowe URL-e. Plus sitemapa na nowej domenie (nowasklep.pl/sitemap.xml) z tymi samymi nowymi URL-ami. Oba pliki zgłoszone w GSC — stara domena pozostaje zweryfikowana, nowa domena dodana jako osobny property.

Zasada 5: Nagłówki cache-control dla redirectów

Dla samych reguł 301 ustawiamy Cache-Control: public, max-age=2592000 (30 dni). To oszczędza zasoby serwera (Google nie musi za każdym razem pytać) i daje przeglądarkom użytkowników jasną instrukcję, że mają zapamiętać przekierowanie.

Execution day: minuta po minucie

Piątek, godzina 20:00. Zespół w składzie: lead dev (ja), dev backend, dev frontend, DevOps, SEO specialist, product owner od klienta. Slack channel dedykowany. Runbook w Notion z checkboxami. Monitoring na dwóch ekranach.

Oto faktyczny przebieg — wszystkie godziny real, wszystkie status update’y real:

• 20:00 — Freeze kodu na starej domenie. Ostatni deploy zakończony o 19:45. Ostatnie zamówienia z 20:00 są przetwarzane normalnie.
• 20:15 — Snapshot bazy danych starej domeny. Backup pełny + snapshot przyrostowy. Dwa niezależne storage’e (lokalny RAID + S3).
• 20:30 — Deploy pliku redirects.conf na load balancer. Reload nginx bez downtime (nginx -s reload). Pierwszy smoke test: 10 losowych URL-i ze starej domeny. Wszystkie zwracają 301 na nową domenę. OK.
• 20:45 — Zmiana DNS A-record dla nowasklep.pl z placeholdera na adres produkcyjny. TTL 300s.
• 21:00 — Propagacja DNS potwierdzona z 8 lokalizacji świata (Warszawa, Berlin, Paryż, Londyn, Madryt, NYC, Singapore, Sydney). Wszystkie widzą nowy adres.
• 21:15 — Drugi smoke test: 100 URL-i ze starej domeny, skrypt Python. 100/100 zwraca 301 na poprawną nową lokalizację. Czas response średnio 89ms. OK.
• 21:30 — Pierwsze prawdziwe ruchy użytkowników na nowej domenie. Monitoring GA4 (real-time) pokazuje 47 aktywnych użytkowników, wzrost do 120 w ciągu 15 minut.
• 21:45 — Pierwsze zamówienie przetworzone na nowej domenie. Wszystkie gateway’e płatności (PayU, Przelewy24, BLIK, karty) działają. OK.
• 22:00 — Zgłoszenie zmiany adresu w Google Search Console (Change of Address tool). Najpierw dodanie nowej property i weryfikacja (DNS TXT record). Potem uruchomienie Change of Address na starej property.
• 22:15 — Zgłoszenie nowej sitemapy w GSC (obu property). Prośba o recrawl dla top 50 URL-i.
• 22:30 — Test crawl Screaming Frogiem na nowej domenie, limit 5000 URL-i. Crawl zakończony o 23:10. Wynik: 4987 URL-i 200 OK, 13 URL-i 301 (łańcuchy wewnętrzne — do poprawy w ciągu 48h), 0 URL-i 404, 0 URL-i 500. Bardzo dobry wynik.
• 23:15 — Test crawl Screaming Frogiem na starej domenie. 100% URL-i zwraca 301, 0 zapętleń, średni czas response 110ms. OK.
• 00:00 (sobota) — Pierwszy raport nocny. Ruch na nowej domenie: 340 aktywnych sesji, bounce rate 42% (przed migracją 44%), zamówień przetworzonych od 21:30: 23. Wszystko w normie.
• 01:30 — Ostatni test: próbka 500 URL-i zewnętrznych z Ahrefs (top linki). Wszystkie redirectują 301 na poprawne miejsca. OK.
• 02:00 — Zespół zwalnia, zostaje nocny monitoring dyżurny (DevOps + ja na zmianę). Uptime Robot działa, alerty aktywne.

Łączny downtime realny dla użytkownika: 0 sekund (nginx reload nie blokuje połączeń). Łączny czas „obniżonej wydajności” (podwójny ruch, stara + nowa domena): ~90 minut, bez odczuwalnego efektu na użytkowniku.

Google Search Central ma własny przewodnik po migracjach — jeśli nigdy nie robiłeś takiego projektu, przeczytaj oficjalną dokumentację krok po kroku: Site moves with URL changes. To komplementarne źródło do tego case study.

Post-migration monitoring: 90 dni czujności

Migracja domeny nie kończy się w piątkową noc. Kończy się — jeśli wszystko poszło dobrze — po 90 dniach od execution day, kiedy Google w pełni zindeksuje nowe URL-e i przepisze sygnały rankingowe. W tym czasie monitorujemy osiem obszarów:

Monitoring #1: GSC „Change of Address” status

Po zgłoszeniu Change of Address status w GSC przechodzi przez kilka etapów. „Processing” przez pierwsze 24-48h. Potem „Requests sent” — Google zaczyna recrawlować. Po 7-14 dniach zwykle „Address change processed” — oznacza to, że Google uznało migrację za wykonaną technicznie poprawnie. Jeśli w tym czasie pojawia się błąd, dostaniesz powiadomienie z konkretnym problemem.

Monitoring #2: Indeksacja nowej domeny

Raport „Zaindeksowane strony” w GSC dla nowej property. Krzywa wzrostu powinna być wyraźna — startujesz od pustej property (0 URL-i), po 7 dniach powinno być 20-40% URL-i, po 30 dniach 80-90%, po 60 dniach pełne pokrycie. Równolegle raport „Pokrycie” na starej property — liczba indeksowanych URL-i spada (301 stopniowo „zastępują” oryginały w indeksie).

Monitoring #3: Ruch organiczny D-day do D+90

Dzienny snapshot sesji organicznych z GA4, porównanie do tego samego dnia tygodnia w D-30 (tydzień przed migracją). Dopuszczalna fluktuacja: ±8% dzień do dnia. Jeśli spadek większy niż 8% utrzymuje się 2 dni z rzędu, triggerujemy proces „migration incident response” — głęboki audit, korekty, eskalacja.

Monitoring #4: Pozycje fraz

Senuto monitor z 4500 frazami, update codzienny przez 30 dni. Oczekiwany wzorzec: minimalne wahania (±1-2 pozycje) przez pierwsze 7 dni, potem stabilizacja, potem powolna reindeksacja z drobną poprawą (zwykle +2-5% pozycji średnio, bo mapa redirectów zrobiona lepiej niż pierwotny wewnętrzny graf linków).

Monitoring #5: Logi serwera

Analiza logów z nginx co 24h. Filtry: status 404, status 500, status 301 (liczymy wolumen), User-Agent Google/Bing/Yandex. Jeśli pojawiają się nowe 404 — szukamy przyczyny (linki z zewnątrz, o których nie wiedzieliśmy; literówki w nowych URL-ach; niepoprawnie skonfigurowane reguły).

Monitoring #6: Linki zewnętrzne

Ahrefs „New backlinks” i „Lost backlinks” — codzienny eksport. Linki zewnętrzne, które „przenoszą się” ze starej domeny na nową automatycznie dzięki 301 — zwykle w ciągu 30-60 dni po migracji. Jeśli widzimy „lost backlinks” z niezrozumiałego powodu, sprawdzamy, czy to nie problem po stronie linkującego serwisu (np. ktoś zdjął nam link przy okazji).

Monitoring #7: Core Web Vitals

PageSpeed Insights API raz w tygodniu dla top 50 URL-i. Nowy serwer powinien dawać lepsze wyniki niż stary (to był jeden z celów migracji). Śledzimy LCP, INP, CLS, TTFB. Jeśli metryki się pogorszyły — problem do rozwiązania (cache, CDN, obrazki).

Monitoring #8: Konwersja i przychód

GA4 e-commerce report. Przychód dzienny, liczba transakcji, średnia wartość koszyka, bounce rate na stronach produktowych. Utrata ruchu jest boląca, ale utrata przychodu jest boląca dwukrotnie. Każdego dnia sprawdzamy, czy konwersja jest stabilna.

Rezultaty: liczby, które mówią same za siebie

Poniższa tabela pokazuje ruch organiczny z GA4 w oknach D-30 (30 dni przed migracją), D+30 (30 dni po migracji), D+60 i D+90. Porównanie per kanał pozwala zidentyfikować, czy spadek w jednym obszarze nie jest kompensowany sztucznie przez inny.

Tabela: ruch D-30 do D+90 per kanał

Kanał	D-30 (sesje/m-c)	D+30 (sesje/m-c)	D+60 (sesje/m-c)	D+90 (sesje/m-c)	Zmiana D+90 vs D-30
Organic Search (Google)	438 200	431 800	444 500	451 300	+3,0%
Organic Search (Bing + inne)	18 400	17 100	18 900	19 200	+4,3%
Direct	62 800	68 100	64 400	63 500	+1,1%
Referral	14 200	13 700	14 100	14 600	+2,8%
Social	8 100	7 900	8 200	8 400	+3,7%
Paid Search	32 500	32 300	33 100	32 900	+1,2%
Email	6 400	5 800	6 300	6 700	+4,7%
RAZEM	580 600	576 700	589 500	596 600	+2,8%

Co widzimy w tej tabeli?

Po pierwsze, D+30 to punkt najniższy — organic search spadł o 1,5% względem D-30 (6400 sesji miesięcznie mniej). To normalne i oczekiwane, bo Google potrzebuje czasu, by przepisać sygnały. Ten spadek nie jest statystycznie istotny — mieści się w normalnej fluktuacji sezonowej.

Po drugie, D+60 już pokazuje odbicie — +1,4% vs D-30. Google zaindeksował 89% URL-i nowej domeny, linki zewnętrzne zaczęły „płacić” na nową domenę.

Po trzecie, D+90 to wyraźny wzrost — +3,0% na organic. Częściowo to zasługa lepszego serwera (wyższy Core Web Vitals → Google promuje nasze strony), częściowo — usunięcia kilku zaplątań w starej strukturze linków wewnętrznych.

Przychód organiczny w oknie D+60 do D+90: 2,34 mln zł (vs 2,17 mln zł w oknie D-90 do D-60 — baseline 3 miesiące wcześniej). Klient zarobił na migracji zamiast stracić.

Migration playbook: numerowana sekwencja, której używamy

Poniższa sekwencja to dokładny playbook, który stosujemy w każdej migracji. Kroki są ponumerowane i muszą być wykonane w tej kolejności — pomijanie któregokolwiek z nich to zaproszenie do katastrofy.

1. Decyzja biznesowa i mandat klienta (D-60). Pisemne potwierdzenie zakresu, budżetu, tolerancji ryzyka. Bez tego nie ruszamy.
2. Zakup i „ogrzanie” nowej domeny (D-365 do D-90). Idealnie 12+ miesięcy przed migracją nowa domena powinna mieć stronę z treścią, historię indeksacji i minimum kilkanaście linków zewnętrznych.
3. Kick-off i harmonogram (D-45). Spotkanie projektowe, podział ról, harmonogram dni, runbook w Notion.
4. Pre-migration audit (D-21 do D-15). Inwentaryzacja URL-i z 4 źródeł, deduplikacja, weryfikacja przez klienta dla top 200.
5. Benchmark ruchu, pozycji, CWV (D-14 do D-10). Trzy benchmarki zapisane i podpisane — będą użyte jako referencja po migracji.
6. Audyt techniczny nowej domeny (D-14 do D-7). DNS, SSL, serwery, monitoring, logi. TTL DNS obniżony do 300s na D-3.
7. Budowa i test mapy redirectów (D-10 do D-3). Plik redirects.conf, test wszystkich URL-i na stagingu, 0 błędów wymagane przed zielonym światłem.
8. Freeze kodu (D-1, 18:00). Żadnych deploy’ów w ostatnie 24h przed migracją. Żadnych nowych treści. Stan zamrożony.
9. Execution day (D-day, 20:00-02:00). Sekwencja: snapshot DB, deploy redirects, zmiana DNS, smoke testy, zgłoszenie COA w GSC, crawl weryfikacyjny.
10. Pierwsze 72h monitoringu dyżurnego (D+0 do D+3). Zmiany 12-godzinne w zespole DevOps + SEO, alerty Slack/SMS, codzienny raport.
11. Tygodniowy cykl raportowania (D+7 do D+30). Raport dla klienta co 7 dni: GSC, GA4, pozycje, logi, linki.
12. Audyt pełny D+30. Głęboka rewizja wszystkich wskaźników, porównanie z benchmarkiem, identyfikacja problemów do naprawy.
13. Czyszczenie parametrów URL (D+30 do D+45). Stopniowe wygaszanie reguł dla filtrów i sortowań, które były tymczasowo utrzymane.
14. Rewizja linków zewnętrznych (D+60). Outreach do top 20 serwisów linkujących z prośbą o update linków (ręczna zmiana URL na nowy).
15. Final report D+90. Podsumowanie projektu, porównanie z benchmarkiem, rekomendacje dalszego rozwoju, archiwizacja runbooka.

Ten playbook to nie jest teoria. To zestaw kroków, który realnie stosujemy i który realnie daje zerową utratę ruchu. Jeśli którykolwiek z tych kroków wydaje Ci się „zbędny” lub „można go skrócić” — przypomnij sobie, że koszt migracji z kłopotami (strata 30% ruchu na 60 dni) jest zwykle 20-50x większy niż koszt porządnego wykonania.

Najczęstsze błędy w migracji domeny — i jak ich unikać

Podczas prowadzenia migracji dla klientów oraz audytowania migracji zrobionych przez innych, zebrałem listę błędów, które powtarzają się w 70% przypadków. Oto one — razem z rekomendacjami, jak ich uniknąć.

Błąd 1: Migracja i redesign w tym samym weekendzie

Ten błąd widzę najczęściej. „Przy okazji migracji zmienimy też template, bo i tak wszystko jest na stole.” Nie. Migracja to zmiana domeny. Redesign to zmiana warstwy prezentacji. Dwie różne rzeczy, dwa różne zestawy ryzyk. Jeśli po migracji ruch spadnie, nie będziesz wiedział, czy to przez nową domenę, czy przez nowy template. Debugowanie jest piekielnie trudne. Zasada: minimum 21 dni odstępu między tymi operacjami.

Błąd 2: Brak benchmarku „przed”

Zdziwisz się, ile migracji zaczyna się bez porządnego snapshota danych z przed migracji. Potem klient mówi: „no ale ruch spadł”, a Ty pytasz „o ile w stosunku do czego?” i okazuje się, że nie ma czarno na białym porównania. Zawsze — ZAWSZE — zapisz benchmark w osobnym pliku, z datą, z podpisem klienta (nawet jeśli to tylko email z „potwierdzam te liczby”). Bez benchmarku nie możesz udowodnić sukcesu ani rozpoznać porażki.

Błąd 3: Redirecty w aplikacji, nie na serwerze

Redirecty w PHP, Node.js, Django, Railsach to droga na skróty, która kończy się wolniejszym TTFB, wyższym crawl budgetem zużytym i trudniejszym utrzymaniem. Redirecty muszą być na poziomie serwera — nginx, Apache, Cloudflare, bunnyCDN. Warstwa aplikacyjna nigdy nie jest odpowiednim miejscem dla reguł 301 dla setek tysięcy URL-i.

Błąd 4: Zapomniane URL-e z parametrami

Filtry (?sort=price&color=red), paginacja (?page=3), śledzące (?utm_source=facebook). Jeśli nie obsłużysz parametrów regułą 301, po migracji stare adresy zwracają 404. Użytkownicy, którzy zapisali sobie zakładkę ze starą wyszukiwarką produktów, widzą „strona nie znaleziona”. Konwersja spada. Zasada: osobne reguły dla parametrów, testowanie regex na co najmniej 50 przykładach.

Błąd 5: Pomijanie hreflang

Jeśli serwis jest wielojęzyczny (pl/en/de), po migracji domeny tagi hreflang muszą być zaktualizowane. Stary URL w tagu hreflang oznacza, że Google myśli, iż inna wersja językowa dalej jest pod starą domeną. Efekt: crawl budget marnowany, sygnały rankingowe rozproszone. Test: Screaming Frog raport „Hreflang” po migracji, 0 linków do starej domeny oczekiwane.

Błąd 6: Zgłoszenie COA bez weryfikacji nowej property

Tool „Change of Address” w Google Search Console wymaga, żeby nowa domena była wcześniej zweryfikowaną property. Nie „zweryfikowalną”, tylko „zweryfikowaną” — z aktywną własnością. Widywałem zespoły, które klikały COA i potem godzinami nie rozumiały, dlaczego tool odrzuca zgłoszenie. Zasada: na 7 dni przed migracją nowa property istnieje w GSC, jest zweryfikowana przez DNS TXT, ma dodaną sitemapę (nawet pustą).

Błąd 7: Brak monitoringu zamówień i płatności

Techniczny zespół SEO skupia się na crawl, indeksacji i pozycjach. Zespół biznesowy skupia się na zamówieniach i płatnościach. Podczas migracji te dwa światy muszą się spotkać. Przetestuj checkout 10 razy w ciągu pierwszej godziny po migracji. Sprawdź, czy webhook-i z PayU i Stripe’a trafiają na nowy endpoint. Sprawdź, czy maile transakcyjne wysyłają się z nowej domeny. To niby oczywiste — a widziałem trzy przypadki, gdzie zamówienia „wisiały” przez 4 godziny, bo webhook wysyłał płatność na stary adres callback.

Błąd 8: Brak planu rollback

Jeśli po 24h coś pójdzie fatalnie źle, musisz mieć jasny scenariusz „wracamy do starej domeny”. W praktyce oznacza to: DNS z TTL 300s (żeby cofnięcie było szybkie), snapshot bazy z piątku 20:00 (żeby dane nie uciekły), runbook „rollback” w Notion. Nie, tego nigdy nie użyjesz — ale mieć to trzeba, bo daje spokój psychiczny i wymusza porządek w planie.

FAQ: najczęstsze pytania o migrację domeny

1. Ile trwa migracja domeny, licząc od decyzji do D+90?

Realnie 4-5 miesięcy. Z tego 45-60 dni to przygotowanie (audit, benchmarki, budowa mapy redirectów, audyt technicznej strony nowej domeny), 1 wieczór to execution, a 90 dni to monitoring i stabilizacja. Jeśli ktoś oferuje Ci migrację „w tydzień” — uciekaj. To będzie katastrofa.

2. Czy migracja domeny zawsze powoduje jakąś utratę ruchu?

Nie. W przypadku porządnie wykonanej migracji z 1:1 mapowaniem URL, redirectami 301 na poziomie serwera, wcześniej ogrzaną nową domeną i sprawnym monitoringiem — utrata może być zerowa (tak jak w opisywanym case) lub nawet dodatnia (+2-5%). Mit „zawsze jakaś strata” wynika z doświadczenia z migracjami wykonanymi niestarannie.

3. Czy muszę kupić nową domenę z dużym wyprzedzeniem?

Tak. Minimum 6 miesięcy przed migracją, idealnie 12-18 miesięcy. Domena powinna w tym czasie mieć aktywną stronę (choćby landing z opisem firmy), być zindeksowana, mieć 10-30 linków zewnętrznych. Google traktuje „świeże” domeny z ograniczoną siłą przez pierwsze miesiące — jeśli migrujesz na zupełnie nową domenę, oddajesz część siły starej domeny „w dół”.

4. Jak długo utrzymywać redirecty 301?

Minimum 12 miesięcy. Rekomendowane — bezterminowo. Koszt utrzymania reguły w nginx to praktycznie zero, a linki zewnętrzne do starych URL-i mogą pojawiać się latami (cytaty w artykułach, zakładki, wpisy na forach). Jeśli po 2 latach zdejmiesz redirect, te linki zostaną pozbawione wartości.

5. Czy Change of Address w GSC wystarczy, czy muszę robić coś więcej?

Nie wystarczy. COA to tylko informacja dla Google — „hej, przenieśliśmy się”. Realna migracja dzieje się przez redirecty 301. COA przyspiesza proces (z kilku miesięcy do kilku tygodni), ale bez poprawnych 301 nie działa. Zgłoszenie COA bez redirectów 301 = Google zignoruje zgłoszenie.

6. Co zrobić, jeśli po 14 dniach widzę spadek ruchu o 20%?

Natychmiast audit. Sprawdź: (a) czy wszystkie 301 działają — crawl Screaming Froga na top 1000 URL-i starej domeny; (b) raport „Pokrycie” w GSC starej property — czy są nowe błędy, 404, zablokowane; (c) raport „Pokrycie” nowej property — jaka jest dynamika indeksacji; (d) logi serwera — czy Googlebot chodzi po nowej domenie; (e) Core Web Vitals nowej domeny — czy nie jest wolniejsza. Spadek 20% po 14 dniach to nie jest normalna fluktuacja, to problem do rozwiązania.

7. Czy mogę zmigrować podczas sezonu wysokiego (Black Friday, Święta)?

Technicznie — tak. Strategicznie — absolutnie nie. Migracja wymaga 90 dni spokojnego monitoringu. Jeśli w tym okienku wpadasz w Black Friday lub Święta Bożego Narodzenia, tracisz możliwość klarownej oceny „czy migracja wpłynęła negatywnie na ruch” (bo sezonowy wzrost lub spadek maskuje efekt). Migruj w dolinie sezonu — dla e-commerce B2C to zwykle luty lub czerwiec.

8. Czy warto inwestować w migrację domeny, jeśli stara działa dobrze?

Tylko jeśli masz twarde powody biznesowe: rebranding, fuzja, zmiana właściciela, strategiczne przejście z .net na .pl. Migracja „bo tak” albo „bo nowa domena brzmi lepiej” to zwykle zły pomysł — ryzyko vs potencjalne korzyści jest przeciwstawne. Jeśli zastanawiasz się, czy migrować, przeczytaj nasz materiał o kiedy migracja domeny naprawdę ma sens — rozpisaliśmy tam matrycę decyzyjną.

Co dalej: po migracji, przed następnym krokiem

Koniec 90-dniowego okna monitoringu to nie koniec pracy — to tylko potwierdzenie, że techniczna część operacji powiodła się. Po tej dacie zwykle otwierają się trzy nowe obszary, na które warto skierować uwagę.

Pierwszy obszar to rewizja strategii contentowej na nowej domenie. Wcześniejsza struktura kategorii, artykułów i stron pomocniczych była „dziedziczona” — nie optymalizowana pod nową sytuację. Teraz, gdy masz potwierdzenie, że domena jest stabilna, można wreszcie porządnie ogarnąć hub-and-spoke, interlinking, tematyki mało pokryte. W tym momencie ekonomia jest prosta: jeden dobry filar kosztuje 8-15 godzin pracy i generuje dodatkowe 5-15% wzrostu na klaster. Dziesięć filarów to 50-150% ruchu więcej w ciągu roku. Migracja zwróciła Ci wszystkie karty na stół — teraz rozegraj je lepiej.

Drugi obszar to outreach do serwisów linkujących. Redirecty 301 robią kawał roboty, ale sygnał z bezpośredniego linku jest zawsze silniejszy niż sygnał przeniesiony. Eksport z Ahrefs „Referring domains” z filtrem DR 30+, skrypt do deduplikacji na poziomie domeny głównej, lista top 50 serwisów linkujących do starych URL-i. Dla każdego piszesz uprzejmy mail z informacją o migracji i prośbą o update linku. Skuteczność: 20-35% serwisów aktualizuje linki w ciągu 30-60 dni. Dla top 50 linków to 10-17 nowych „natywnych” linków do nowej domeny — efekt w SEO wyraźny.

Trzeci obszar to archiwizacja wiedzy z projektu. Runbook z Notion, dokument z benchmarkami, plik redirects.conf, raporty tygodniowe, alerty z monitoringu — wszystko to powinno trafić do centralnego repozytorium firmy. Następna migracja (w tej samej firmie lub dla innego klienta) będzie o 40-60% szybsza, bo nie będziesz startować od zera. Firmy, które traktują migrację jako jednorazową operację, płacą za to samo ćwiczenie ponownie za 3 lata. Firmy, które archiwizują wiedzę, robią drugą i trzecią migrację coraz sprawniej.

Na koniec: migracja domeny bez utraty ruchu jest możliwa. Nie jest łatwa, nie jest tania, nie jest szybka. Ale jest wykonalna — i wymaga trzymania się procesu, a nie improwizacji. Jeśli przygotujesz się poważnie, zaplanujesz w kwartalnym horyzoncie, zaangażujesz zespół z właściwymi kompetencjami i będziesz mierzyć wszystko, co się da — zobaczysz wyniki takie, jak w tym case study. Twój klient zapamięta tę migrację jako „tę, po której wszystko działało lepiej”, a nie jako „tę, przez którą straciliśmy trzy miesiące ruchu”.

I to jest ta wersja, do której warto dążyć.