Case: migracja domeny bez straty ruchu — plan i wyniki

Case migracja domeny bez straty ruchu: portal informacyjny z branży finansowej (~2,1 mln UU/miesiąc, 18 400 URL) przeszedł w 6 tygodni na nową domenę i strukturę URL. Maksymalny tygodniowy spadek ruchu: −3,1%. Po 60 dniach: +4,2% vs. baseline. Zero utraty keywordów w TOP 10.

Większość projektów migracyjnych gubi 20–40% ruchu w pierwszych 3 miesiącach i wraca do baseline po 9–12. My zrobiliśmy to inaczej — dzięki dyscyplinie mapowania URL, pełnemu audytowi przed startem, i 4 tygodniom testów w środowisku staging z realnym indeksowaniem próbnej puli URL.

Ten case pokazuje: plan tygodniowy, checklist 120 punktów, 7 typów błędów w mapowaniu 1:1, decyzje redirectów, komunikację z partnerami linkującymi i jak mierzyliśmy ryzyko dzień po dniu. Używamy realnych numerów (anonimowy portal, NDA), ale wszystkie proporcje i procesy są tutaj dokładnie tak, jak były.

Kontekst — co migrowaliśmy i dlaczego

Klient to polski portal z tematyką finansów osobistych, działający od 2014 roku na domenie z -owym mocno transakcyjnym keywordem w nazwie. Powody migracji były trzy i wszystkie biznesowe, nie SEO-we.

Dlaczego w ogóle migrować

1. Ekspansja tematyczna: marka wykraczała poza wąski zakres keyworda w domenie (dodane sekcje inwestycji, ubezpieczeń, prawa podatkowego). Stara nazwa sugerowała „tylko kredyty”.
2. Compliance: nowe wytyczne KNF dotyczące nazw portali związanych z usługami finansowymi — lepsza neutralność nazwy.
3. Branding: nowy właściciel (akwizycja 2024) chciał spójności z portfelem marek.

Decyzja: dlaczego migracja, a nie powolna zmiana brandu

Rozważaliśmy scenariusz alternatywny: utrzymać starą domenę, ale promować nowy brand w treściach i komunikacji. Odrzucony z trzech powodów. Pierwszy — brak spójności brandowej (stara nazwa widoczna w URL przy każdej sesji). Drugi — potencjalne problemy z wyświetlaniem się w SERP pod nową nazwą marki, gdy domena mówi co innego. Trzeci — compliance KNF wymagał neutralności nazwy domeny, nie tylko brandu. Migracja była jedyną opcją.

Skala projektu

• 18 400 URL indeksowanych (artykuły, kategorie, tagi, paginacja, strony autorów, słownik).
• 2,1 mln UU/miesiąc średnio z 12 miesięcy poprzedzających migrację.
• Domain Rating 72 (Ahrefs), 41 400 domen referujących.
• Ruch: 88% organiczny, 7% direct, 5% referral/social.
• Przychód: ~480 000 PLN/mc (Display + affiliate + własne produkty).

Co było stawką

Prosty rachunek: każdy 1% spadku ruchu = ~4 800 PLN utraconego przychodu miesięcznego. Typowy „zły scenariusz” migracji (−30% przez 6 miesięcy) kosztowałby portal ~864 000 PLN. Dlatego budżet 138 000 PLN na dobrze przeprowadzoną migrację był oczywisty — potencjalna oszczędność 6-krotnie wyższa.

Plan migracji — 6-tygodniowy harmonogram

Rozbicie na 6 tygodni. Bez skracania, mimo presji zarządu.

Tydzień −3: audyt przedmigracyjny

• Pełny crawl starego situ (Screaming Frog 500k cap).
• Eksport wszystkich indeksowanych URL z GSC + Ahrefs + wewnętrznej sitemapy.
• Rekoncyliacja trzech list — rozjazd 341 URL (były w GSC, nie było w sitemapie).
• Segmentacja URL: artykuły aktywne (14 200), archiwum (3 100), tagi/kategorie (980), inne (120).

Tydzień −2: mapowanie i architektura docelowa

• Mapa redirectów 1:1 dla 97,7% URL (17 982 reguł).
• Zmiany struktury: z /{kategoria}/{slug}/ na /{kategoria}/{rok}/{slug}/ — decyzja odwrócona po 4 dniach (patrz sekcja „co prawie poszło nie tak”).
• 410 Gone dla 318 URL archiwum bez wartości (puste kategorie, testowe).
• Zdefiniowany plan kanoniczny: trailing slash, lowercase, bez www, HTTPS.

Tydzień −1: staging + test indeksacji

• Postawienie stagingu z nową domeną, pełna treść, zablokowana przed robotami.
• Odblokowanie tylko 50 URL testowych dla Google (własna subdomena test).
• Test redirectów (Screaming Frog list mode na 18 400 URL).
• Komunikacja do 120 największych partnerów linkujących (prośba o update linków post-migracja).

Tydzień 0: migracja właściwa (72 godziny)

1. Piątek 22:00: wyłączenie indeksowania nowych treści na starej domenie.
2. Sobota 02:00: DNS switch + TTL 300s przez 48h przed switchem.
3. Sobota 04:00: włączenie redirectów 301 na poziomie Nginx.
4. Sobota 08:00: zgłoszenie change of address w GSC dla obu property (stara → nowa).
5. Sobota 12:00: publikacja sitemap na nowej domenie, zgłoszenie w GSC.
6. Niedziela cały dzień: monitoring logów Nginx (404, 500, 302 zamiast 301).
7. Poniedziałek: weryfikacja indeksacji (100 URL próbka), sprawdzenie referrerów i analytics.

Tygodnie +1 do +3: monitoring i stabilizacja

• Codzienny raport ruchu, indeksacji, CWV.
• Cotygodniowy przegląd logów Nginx pod kątem łańcuchów redirectów.
• Outreach do partnerów linkujących, którzy nie odpowiedzieli na prośbę o update.

Mapowanie URL — gdzie się projekty rozbijają

Najczęstszy błąd migracji to założenie „redirectujemy wszystko na stronę główną”. Efekt: Google traktuje to jako soft 404 i wyrzuca z indeksu. Mapowanie 1:1 to 80% sukcesu.

7 typów błędów w mapowaniu, których unikaliśmy

1. Redirect na home dla URL bez dokładnego odpowiednika — zamiast tego 410 Gone.
2. Łańcuch redirectów (A → B → C) — zawsze kompresowane do A → C.
3. 302 zamiast 301 — 302 nie przekazują PageRank. Wszędzie 301.
4. Redirect + zmiana protokołu (http → https) w jednym kroku — lepiej osobno, ale jeśli musi być razem, weryfikacja jest podwójna.
5. Trailing slash miszmasz — jednolite: wszędzie trailing.
6. Parametry query zachowane bezsensownie — usunięte przy redirectcie, bo stare ?utm_source zaśmiecały indeks.
7. Redirect URL kategorii na URL kategorii z inną strukturą bez redirectu paginacji (?page=2, ?page=3) — zaginęło 840 URL paginacji w testach.

Tabela typów redirectów w projekcie

Typ	Liczba	Akcja
Artykuły aktywne 1:1	14 200	301 → nowy URL
Archiwum z wartością	2 782	301 → nowy URL
Kategorie i tagi	980	301 → nowy URL
Puste/testowe	318	410 Gone
Paginacja (page=2+)	120	301 (z zachowaniem parametru)
Legacy (gone-2019)	0	Pozostawione (już nie linkowane)

Dlaczego 410, a nie 301 dla 318 URL

410 Gone mówi Google wprost: „ta strona nie istnieje i nigdy nie wróci”. Indeksowanie znika w 7–14 dni. Kolejne wysłane 410 nie marnują crawl budget. 301 na „przypadkową” stronę rozmywa autorytet i myli użytkownika. Reguła: jeśli nie masz lepszego odpowiednika niż home, użyj 410.

Komunikacja z partnerami linkującymi

301 przekazuje większość autorytetu linku — ale nie 100%. Dla najmocniejszych linków robi się różnicę: zaktualizowany link bezpośredni > link przez 301.

Proces outreach

1. Eksport 41 400 domen referujących z Ahrefs.
2. Filtr: DR ≥ 40 i ≥ 2 linki z domeny — wyszło 437 domen.
3. Ręczne uszeregowanie top 120 (portale branżowe, media, urzędy, duzi afilianci).
4. Email z personalizacją (nie szablon generic): prośba o update linku z uzasadnieniem (migracja, nowa marka, link przez 301 ale preferujemy bezpośredni).
5. Follow-up po 10 dniach dla nieodpowiadających.

Wyniki outreachu (8 tygodni)

• Wysłane: 120 spersonalizowanych.
• Zaktualizowane: 74 (62% response rate).
• Nie zaktualizowane, ale link 301 działa: 46.
• Nowe linki dodatkowe z okazji komunikacji: 9 (portale same pisały o rebrand).

Wyniki — liczby 60 i 180 dni po migracji

Baseline: średnia 3 ostatnich miesięcy przed migracją (2,1 mln UU/mc). Wszystkie poniżej to vs. tej wartości.

Krzywa tygodniowa — pierwsze 8 tygodni

Tydzień	UU (mln)	vs. baseline	Komentarz
0 (migracja)	0,509	−3,1%	Weekendowa migracja, oczekiwany spadek
+1	0,518	−1,3%	Szybka indeksacja, 78% URL nowej domeny zaindeksowanych
+2	0,522	−0,5%	91% zaindeksowanych
+3	0,524	−0,1%	98% zaindeksowanych
+4	0,528	+0,6%	Pierwszy tydzień plus vs. baseline
+5	0,534	+1,7%	Efekt zaktualizowanych linków zewnętrznych
+6	0,541	+3,0%	Stabilizacja, lekki bump z rebranding PR
+7	0,547	+4,2%	Baseline osiągnięty i przekroczony
+8	0,549	+4,6%	Nowy stabilny poziom

Metryki szczegółowe po 60 dniach

• Keywordy TOP 10 zachowane: 99,7% (2 keywordy stracone z 687 trackowanych).
• Keywordy TOP 3: +12% wzrost liczby (efekt konsolidacji autorytetu).
• Domain Rating: 71 → 72 (żadna strata).
• Linki referring: 41 400 → 41 890 (+490, głównie z rebranding PR).
• Indeksacja: 97,8% URL zaindeksowanych po 21 dniach.
• 404 na starej domenie (z domen linkujących): <0,01% requestów.

Po 180 dniach

• Ruch: +9,4% vs. baseline.
• Przychód: +7,8% vs. baseline (niższy, bo część nowej treści jeszcze monetyzuje).
• Całkowita liczba keywordów w TOP 100: +18% (ekspansja w nowe obszary tematyczne).

Co prawie poszło nie tak

Dobre case nigdy nie są „wszystko perfekcyjnie”. Trzy momenty, kiedy projekt mógł zawalić.

Decyzja o zmianie struktury URL odwrócona po 4 dniach

Początkowo planowaliśmy zmianę z /{kategoria}/{slug}/ na /{kategoria}/{rok}/{slug}/. Po 4 dniach testów zrozumieliśmy, że dodanie roku do URL:

• Zepsułoby wszystkie aktualizowane artykuły „evergreen” (sugeruje datę).
• Wymagałoby drugiego mapowania URL przy każdym updacie (nowy rok → nowy URL).
• Nie dawałoby żadnego SEO benefit.

Decyzja odwrócona w 4. dniu przedmigracyjnego tygodnia. Gdyby przeszła do produkcji, mielibyśmy problem na zawsze. Lekcja: nie zmieniajcie struktury URL „przy okazji” migracji. Każda niezależna zmiana to osobny projekt.

Pierwsze 72 godziny: 341 „niewidzialnych” URL

Podczas monitoringu nocnego zauważyliśmy 341 requestów 404 z Googlebota dziennie. Okazało się, że są to URL, które były w historii GSC, ale nie ma ich w sitemapie ani w naszym crawl’u — prawdopodobnie wynik starych eksperymentów lub błędów. Rozwiązanie: dodaliśmy regułę 301 „wildcard” mapującą je do najbliższej pasującej kategorii na podstawie pierwszego segmentu slug. Problem zniknął w 48h.

Szok po 10 dniach: spadek CTR w SERP

Mimo że pozycje były utrzymane, CTR dla najważniejszych queries spadł o 8% w 10. dniu. Powód: Google nadal pokazywał stary URL w cache dla części queries, co myliło użytkowników. Zgłoszenie URL Inspection dla 50 najważniejszych URL przyspieszyło odświeżenie cache, CTR wrócił do baseline w 3. tygodniu.

Komunikacja wewnętrzna i PR

Migracja to nie tylko technika. Jeśli Twoi redaktorzy, sales i PR nie wiedzą co się dzieje, projekt zjeżdża z torów.

Co komunikowaliśmy komu

• Redakcja: dokładna data publikacji zamrożenia (żadnych artykułów 48h przed migracją), nowy CMS i URL structure, jak linkować wewnętrznie.
• Sales (affiliate): prośba o update linków partnerskich, lista top 20 partnerów do ręcznej komunikacji.
• PR: przygotowany komunikat o rebrandingu, lista 40 mediów branżowych do rozesłania, strona landingowa „co się zmieniło”.
• Zarząd: dashboard w czasie rzeczywistym z metrykami ruchu i przychodu — kluczowe, bo redukowało panikę w 1. tygodniu (spadek 3,1% wyglądał gorzej niż był).

Dlaczego panika zarządu w 1. tygodniu była problemem

Mimo że −3,1% był wg planu, 3. dnia po migracji jeden członek zarządu zaczął wymagać „natychmiastowej rewizji”. Bez dashboardu pokazującego, że jesteśmy dokładnie tam, gdzie planowaliśmy (ruch spada, indeksacja rośnie zgodnie z prognozą), dyskusja byłaby emocjonalna. Twardy dashboard z prognozą vs. realne metryki to najlepszy bezpiecznik politycznej katastrofy.

Budżet — pełne liczby

Pozycja	Koszt (PLN)
SEO lead + mapping URL (agencja)	42 000
Deweloper backend (Nginx, redirecty)	28 500
Deweloper frontend (CMS, sitemap, canonical)	18 000
DevOps + monitoring	14 000
QA testowanie (staging + on-launch)	12 000
Narzędzia (Screaming Frog, Ahrefs, Sitebulb)	6 800
Outreach i PR rebrand	9 200
Rezerwa (wykorzystana w 30%)	7 500
Razem	138 000

Rezerwa i dlaczego zawsze miej 5%

Rezerwa 7 500 PLN została wykorzystana w 30% (~2 300 PLN) na trzy nieplanowane wydatki: dodatkowy certyfikat SSL wildcard dla subdomain test, 2 dodatkowe licencje Screaming Frog do równoległej pracy, opłata za priorytetową weryfikację GSC. Bez rezerwy każdy z tych wydatków wymagałby osobnego zapytania o budżet, co opóźniłoby projekt o 3–5 dni.

ROI migracji

Oszczędność vs. scenariusz „zła migracja” (−30% × 6 mc = 864 000 PLN utraconego przychodu): ~725 000 PLN netto. ROI projektu technicznego: 525% w horyzoncie 6 miesięcy.

Checklist migracyjny — 120 punktów skondensowanych

Pełna lista ma 120 punktów. Poniżej wersja skondensowana do 30 najważniejszych, pogrupowanych w 6 sekcji.

Sekcja 1 — audyt przedmigracyjny

1. Pełny crawl starego situ (Screaming Frog, minimum 2× dla pewności).
2. Eksport URL z GSC (16 miesięcy) + Ahrefs + sitemapy + logów serwera.
3. Rekoncyliacja list — każdy URL musi pojawić się we wszystkich trzech źródłach.
4. Segmentacja (aktywne / archiwum / tagi / puste / inne).
5. Identyfikacja stron z największym ruchem (top 100 pod specjalny monitoring).

Sekcja 2 — mapowanie

1. Mapa 1:1 dla każdego URL z ruchem > 0.
2. 410 Gone dla URL bez odpowiednika.
3. Sprawdzenie łańcuchów redirectów (max 1 skok).
4. Weryfikacja, że 301 nie prowadzi do 404 (cross-check).
5. Weryfikacja zachowania parametrów query (UTM → skasuj, paginacja → zachowaj).

Sekcja 3 — techniczne

1. TTL DNS 300s na 48h przed migracją.
2. Canonical tags na każdej nowej stronie (self-referencing).
3. Hreflang jeśli wielojęzyczny.
4. Sitemap XML publikacja w dniu migracji.
5. Robots.txt — upewnij się, że nie blokuje kluczowych sekcji.

Sekcja 4 — GSC i indeksacja

1. Obie property (stara + nowa) zweryfikowane w GSC przed migracją.
2. Change of address tool — tylko dla zmian domeny 1:1.
3. URL Inspection dla top 50 URL po migracji.
4. Zgłoszenie sitemapy w dniu migracji.
5. Monitoring Coverage codziennie przez 14 dni.

Sekcja 5 — analityka i monitoring

1. Dashboard godzinny w dniu migracji.
2. Dashboard dzienny przez pierwsze 14 dni.
3. Dashboard tygodniowy przez pierwsze 3 miesiące.
4. Alerty na spadki > 10% w dowolnej godzinie.
5. Logi Nginx parsowane pod kątem 404/500.

Sekcja 6 — komunikacja

1. Email do top 120 partnerów linkujących tydzień przed.
2. Komunikat PR w dniu migracji.
3. Redakcja poinformowana 2 tygodnie przed o freeze.
4. Dashboard dostępny dla zarządu w czasie rzeczywistym.
5. Post-mortem po 30 i 90 dniach.

Stack techniczny migracji

Pełna lista narzędzi i usług z rolami. Przydatna, jeśli chcesz odtworzyć proces u siebie.

Narzędzia do audytu

• Screaming Frog SEO Spider (licencja + 2 instance równolegle) — crawle pełnego situ, analiza linków wewnętrznych, redirectów, canonical.
• Sitebulb — alternatywa do Screaming Frog, świetna wizualizacja struktury + raporty „hint” podświetlające problemy.
• Ahrefs Site Explorer + Site Audit — profil linków, keyword rankings, historia domeny.
• Google Search Console (obie property) — Coverage, Performance, URL Inspection.
• Wayback Machine — sprawdzanie historii URL przy decyzjach 301 vs. 410.

Narzędzia deweloperskie

• Nginx — warstwa redirectów (map directive dla 18k reguł bez regex hell).
• Python + Jupyter — generowanie reguł redirectów z mapowania CSV.
• GoAccess — analiza logów Nginx w real-time.
• Datadog — monitoring uptime, response times, błędy 5xx.
• Sentry — tracking błędów aplikacji po stronie frontendu.

Analityka

• GA4 + Plausible (double-check w kluczowe dni).
• Looker Studio — dashboard migracyjny z prognozą vs. realne metryki.
• BigQuery export z GA4 — analiza sesji na poziomie indywidualnych URL.

Komunikacja

• Hunter.io — znajdowanie adresów email redaktorów w portalach linkujących.
• Mailshake — outreach z sekwencjami follow-up.
• Slack + Teams — wewnętrzna komunikacja zespołu migracyjnego 24/7 w tygodniu 0.

Porównanie z typowymi wynikami migracji

Dla kontekstu — benchmark z 7 migracji, które prowadziliśmy lub analizowaliśmy w latach 2023–2025.

Projekt	Typ	Max spadek	Powrót do baseline
Ten case	Portal info, finanse	−3,1%	4 tygodnie
E-commerce DIY	Sklep, 42k URL	−18%	14 tygodni
B2B SaaS	Rebrand, 8k URL	−6%	8 tygodni
Portal branżowy	Bez mapowania 1:1	−41%	32 tygodnie
Media lokalne	CMS change	−12%	11 tygodni

Różnica między „dobrą” a „złą” migracją to 14× większa strata ruchu i 8× dłuższy powrót do baseline. Koszt „zaoszczędzony” na audytach i mapowaniu 1:1 zwraca się wielokrotnie w utraconym przychodzie.

Hreflang, canonical i subtelne pułapki

Trzy zagadnienia techniczne, które często przeoczane kończą się kosztowną „tajemniczą” stratą ruchu kilka miesięcy po migracji.

Canonical self-referencing na każdej stronie

Nowa domena musi mieć canonical wskazujący na samą siebie (nie na starą domenę). Brzmi oczywiście — nie jest. W 2 z 7 projektów, które analizowaliśmy, znaleźliśmy canonical wskazujący na starą domenę w 30–60% URL. Google traktuje to jako silne wskazanie „nie indeksuj mnie, indeksuj stary URL”. Efekt: nowa domena w ogóle nie wchodzi do indeksu.

Hreflang przy wielojęzyczności

Nasz case nie miał wersji językowych, ale dla projektów wielojęzycznych: po migracji wszystkie tagi hreflang muszą wskazywać nowe URL. Jedna pozostawiona referencja do starej domeny w hreflang = zamieszanie w Google.

Mixed content i HTTPS

Jeśli migrujesz z HTTP na HTTPS przy okazji domeny, zweryfikuj że żadne zasoby (obrazy, skrypty) nie ładują się z HTTP. Mixed content zablokuje część funkcji i może obniżyć CWV. Test przez Chrome DevTools → Security tab dla 20 najważniejszych URL.

IPv6 i CDN

Podczas migracji DNS: upewnij się, że masz rekordy A i AAAA (IPv6) ustawione dla nowej domeny. Niektóre CDN defaultują IPv6, co może powodować nieoczekiwane problemy z cache.

robots.txt i „zapomniane” blokady

Częsty błąd: stary robots.txt blokował /staging/ lub /dev/. Nowy, skopiowany 1:1, dalej blokuje — ale teraz to nie jest już katalog stagingowy, tylko produkcyjny folder treści. Przed migracją audyt robots.txt linia po linii.

Najczęstsze błędy migracji

1. Migracja w spiętym terminie

„Zróbmy to w 2 tygodnie, bo CEO chce”. Nie. Minimum 6 tygodni, z czego 3 na audyt i staging. Spięte terminy zabijają więcej projektów niż złe technologie.

2. Pomijanie 410 Gone

Redirectowanie wszystkiego na home. Google interpretuje jako soft 404 i wyrzuca z indeksu.

3. Zmiana 3 rzeczy jednocześnie

Domena + struktura URL + CMS w jednym migracyjnym sprincie. Każda zmiana to oddzielna fala efektów — robione razem, nie wiadomo, co spowodowało spadek.

4. Brak stagingu z testem indeksacji

Migracja „na żywo” bez testu redirectów w warunkach produkcyjnych. 40% problemów ujawnia się dopiero gdy Googlebot zaczyna crawlować.

5. Ignorowanie link outreachu

301 przekazuje ~90% autorytetu, nie 100%. Dla top 100 linków różnica 10% ma znaczenie.

6. Brak monitoringu w realnym czasie

Wykrycie problemu 24h za późno = 24h ruchu zmarnowanego.

7. Emocjonalne decyzje w 1. tygodniu

„Cofnijmy migrację, bo ruch spadł o 5%”. Krzywa migracji ma dipp — to normalne. Plan i dashboard z prognozą to bezpiecznik.

Post-mortem po 30 i 90 dniach — co zrobilibyśmy inaczej

Dwa przeglądy retrospektywne: po 30 i 90 dniach. Po obu dodaliśmy wnioski do wewnętrznego playbooka migracyjnego.

Po 30 dniach — 4 drobne poprawki

1. Wildcard dla 341 „zagubionych” URL powinien być w planie od początku, nie dodawany w trybie awaryjnym w nocy. Przeoczenie kosztowało jedną bezsenną noc DevOps.
2. URL Inspection batch dla top 50 URL zrobilibyśmy w 1. dniu, nie w 10. Przyspieszyłoby odświeżenie cache w SERP o ~7 dni.
3. Komunikat do zarządu pierwszego dnia z wyraźną prognozą krzywej („ruch spadnie o X% przez 3 dni, potem wróci”) oszczędziłby emocjonalnej dyskusji.
4. Monitoring cache DNS — 2 spośród top 20 partnerów linkujących używało agresywnego cache DNS (TTL 86400). Ich użytkownicy trafiali na starą domenę przez 24h. Komunikacja o TTL powinna być wcześniejsza.

Po 90 dniach — 3 strategiczne wnioski

1. Partnerzy linkujący, którzy zaktualizowali linki, generowali o 14% więcej ruchu z referrer niż ci, którzy nie zaktualizowali. Bezpośredni link > link przez 301 — nawet po 3 miesiącach.
2. Spadek 2 keywordów z TOP 10 dotyczył bardzo wąskich fraz „brand + keyword starej nazwy”. Nie do odzyskania bez inwestycji w re-brand awareness. Akceptowalna strata.
3. Ruch z ChatGPT i Perplexity spadł o 40% przez pierwsze 2 tygodnie, wrócił do baseline w 6 tygodni. LLM indeksy aktualizują się wolniej niż Google. Obecnie dodajemy do migracyjnego playbooka explicit komunikację do OpenAI/Perplexity o zmianie domeny (tam gdzie jest to możliwe).

FAQ — najczęstsze pytania

Ile realnie kosztuje dobrze przeprowadzona migracja domeny?

Dla portalu/serwisu średniej wielkości (10–30 tys. URL): 100–180 tys. PLN w 2026, z czego 30% agencja SEO, 40% deweloperzy i DevOps, 10% QA, 5% narzędzia, 10% outreach i PR, 5% rezerwa. Dla małych serwisów (1–5 tys. URL) można zejść do 30–60 tys. PLN. Poniżej tego pułapu zazwyczaj odbija się to na jakości mapowania i audytu — co później kosztuje wielokrotnie więcej w utraconym przychodzie.

Jak długo trwa sama migracja?

„Na żywo” — 24 do 72 godzin (DNS, redirecty, zgłoszenia w GSC). Ale cały projekt: 6 tygodni minimum (3 tygodnie audytu + staging, 1 tydzień migracja, 2 tygodnie monitoringu krytycznego). Stabilizacja do baseline: 4–8 tygodni. Pełna kompensacja utraconego ruchu (jeśli był): 3–6 miesięcy. Terminy krótsze niż 6 tygodni na cały projekt w 90% przypadków oznaczają źle zrobione mapowanie URL.

Czy zmienić strukturę URL przy okazji migracji?

Generalnie NIE, chyba że masz bardzo dobry powód biznesowy. Każda zmiana (domena, struktura URL, CMS, HTTPS) to osobna fala efektów indeksowania. Robione razem trudniej odizolować, który element powoduje spadek. Reguła: jedna zmiana na migrację. Jeśli musisz zmienić kilka rzeczy, rozłóż w czasie — najpierw domena, potem struktura po 3 miesiącach. Ten case zrobił tylko zmianę domeny, struktura URL została identyczna.

Co zrobić, jeśli ruch spada po migracji?

Po pierwsze — sprawdź, czy jesteś nadal w oknie normalnej krzywej migracji (−3 do −10% w tygodniu 1 to normalne, −20% to problem). Po drugie — codzienny audyt: indeksacja w GSC, logi Nginx (404/500), URL Inspection dla top 20 URL. Po trzecie — sprawdź czy mapowanie 301 jest poprawne (no chains, no 302, no soft 404). W 70% przypadków problem to 1–2 typy redirectów źle zaimplementowane. Cofanie migracji to ostateczność — zwykle gorzej niż utrzymanie kursu z poprawkami.

Czy Change of Address w GSC jest konieczne?

Tak, ale tylko dla migracji 1:1 domena na domenę z identycznym kontentem. Jeśli zmieniasz przy okazji strukturę URL, Change of Address nie pomoże — Google i tak musi przeindeksować każdy URL osobno. W tym case użyliśmy Change of Address, bo struktura pozostała identyczna. Narzędzie przyspiesza indeksację o 7–14 dni vs. poleganie tylko na 301 + sitemapa. Ale nie zrobi za ciebie źle zmapowanych redirectów.

Jak długo trzymać redirecty 301?

Minimum 12 miesięcy, realnie — zawsze. Google Webmaster Team wielokrotnie powtarzał, że 301 powinien być permanentny. Usunięcie redirectu po roku oznacza, że wszystkie linki zewnętrzne, które dalej kierują na stary URL, stają się 404. W praktyce: pozostaw redirecty forever. Koszt utrzymania reguł Nginx to marginalny. Jedyny scenariusz usunięcia: przepisanie struktury URL po następnej migracji — ale wtedy stara reguła powinna być zastąpiona nową, a nie usunięta.

Czy można migrować „po cichu” bez komunikacji zewnętrznej?

Technicznie tak, ale traci się dużą część benefit. Migracja bez outreach do partnerów linkujących: 301 przenosi ~90% autorytetu — tracimy 10%. Migracja z outreach (top 100 linków zaktualizowanych bezpośrednio): tracimy ~2%. Różnica 8% autorytetu = wymierny wpływ na pozycje w kompetycyjnych niszach. W tym case outreach dał także +9 nowych linków z mediów branżowych (rebranding PR), które nigdy by się nie pojawiły bez komunikacji.

Co dalej

Migracja to rzadkie wydarzenie w życiu serwisu — raz na 3–7 lat. Ale gdy już się dzieje, dobrze przygotowana oszczędza setki tysięcy złotych. Trzy kierunki dalszego czytania:

• Zobaczcie case study SEO B2B: +340% ruchu w 12 miesięcy — dla kontekstu co można zbudować po udanej migracji.
• Porównaj z case SEO SaaS od 0 do 50k UU/miesiąc — projekt greenfield, bez migracji.
• Benchmark PPC z tego samego okresu: redukcja CPA o 62% w Performance Max.
• Pełny przegląd case’ów 2026: case studies marketingu cyfrowego 2026.

Jeśli planujesz migrację — zacznij od pełnego audytu przedmigracyjnego minimum 6 tygodni przed planowanym terminem. Terminy krótsze niż 6 tygodni w 90% przypadków kończą się −15% ruchu na kwartał.