Migracja domeny krok po kroku — plan bez strat

Migracja domeny to najbardziej ryzykowna operacja w SEO — 60% migracji przechodzi bez dużych strat, 25% traci 20–40% organic traffic na 3–6 miesięcy, 15% traci > 50% i nigdy nie wraca. Różnica między sukcesem a porażką to nie talent zespołu, ale metodyczne planowanie — 80% sukcesu decyduje się w pre-launch checklist, nie w post-launch fixes.

Ten przewodnik to kompletny plan migracji domeny, stosowany w 40+ projektach w latach 2021–2026 — od małych stron 100-URL do enterprise 200k+ URL. Z realnymi timelines, checklistami i post-mortem wnioskami z projektów, które nie poszły zgodnie z planem. Szczegóły omawiamy w przewodniku seo 2026.

Kiedy migracja jest uzasadniona

Dobre powody

• Rebrand firmy (zmiana nazwy, zmiana brand identity).
• Fuzja/akwizycja firm (konsolidacja).
• Migracja z subdomain do main domain (blog.example.com → example.com/blog/).
• Zmiana TLD – .pl → .com dla international expansion (z solid plan).
• Ucieczka od skompromitowanej domeny — penalty, złe historia, toxic backlinks.

Złe powody

• „Nowa domena pomoże nam rankingować” – nie, new domain start = 0 authority, 6–12 miesięcy rebuild.
• „Chcemy krótszej domeny” – minor UX benefit, huge SEO cost, zwykle nie warto.
• Nic nie działa w SEO, spróbujmy z nową domeną” — migracja nie naprawi content/technical issues, tylko je zresetuje gorzej.

Pięć faz migracji

Faza 1: Pre-migration audit (2–4 tygodnie)

1. Pełny crawl obecnej strony (Screaming Frog, Sitebulb) — export wszystkie URL, status codes, titles, meta.
2. Export backlinks profile (Ahrefs/Semrush) – lista linkujących do ciebie domen i konkretnych URL-ów.
3. Google Search Console: top pages, top queries, impressions, CTR za 12 miesięcy.
4. GA4: traffic per URL, konwersja per URL, assisted konwersje.
5. Inventory custom elements: 301 redirects już istniejące, hreflang, Schema, rel=canonical.
6. Dokumentacja stack technicznego (hosting, CMS, plugins, DNS).

Faza 2: URL mapping i redirect plan (2–3 tygodnie)

1. URL-to-URL mapping dla KAŻDEGO URL-a z crawlu (włącznie z 404, redirects już istniejące).
2. Strategia: 1:1 mapping preferred, many-to-one jeśli konsolidacja, 404 tylko dla deprecated content.
3. Priorytetyzacja: top 100 traffic pages → manual mapping; reszta → rules.
4. Weryfikacja: każdy URL w mapie musi mieć target, każdy target musi istnieć na nowej domenie.
5. Dokumentacja w arkuszu z owner per section.

Faza 3: Technical preparation (2–4 tygodnie)

1. Staging environment nowej strony – pełna kopia z testami.
2. Redirect rules przygotowane i przetestowane.
3. Internal links zaktualizowane na nowej stronie (bez linków do starej domeny).
4. sitemaps dla nowej domeny.
5. robots.txt przygotowany (open dla nowej, noindex dla starej w cut-over).
6. Schema.org zaktualizowana (url, sameAs).
7. Analytics (GA4, GTM) ready dla nowej domeny.
8. Search Console property dla nowej domeny dodana i zweryfikowana.

Faza 4: Launch (1–2 dni)

1. Wybierz low-traffic window (weekend rano).
2. Deploy nowa strona na nowej domenie.
3. Aktywuj 301 redirects na starej domenie (wszystkie URL → nowe).
4. Submit nową sitemap w Search Console.
5. Use Change of Address tool w GSC (tylko dla full domain migration).
6. Smoke test: 50 random URL-ów ze starej → sprawdź redirect do properły new URL.
7. Monitor server logs i Search Console pierwsze 24h.

Faza 5: Post-migration monitoring (4–12 tygodni)

1. Daily pierwsze 2 tygodnie: Search Console crawl errors, 404, redirect errors.
2. Weekly: organic traffic trends (expected dip 15–30% w week 1–4).
3. Backlinks outreach: top 50 źródeł linkujących — poproś o update link do nowej domeny (nie polegaj tylko na redirects).
4. Rebuild rankings śledzenie na nowej domenie.
5. Audit internal linking 4 tygodnie po launch (Screaming Frog).
6. GSC Change of Address status check.

Redirect plan – najważniejszy dokument

Redirect plan to arkusz, od którego wszystko zależy. Każdy URL ze starej strony musi być zmapowany do target URL na nowej. Zagadnienie to omawiamy szerzej w redesign i zmiana CMS bez strat SEO.

Zasady mappingu

• 1:1 preferred – każdy stary URL ma jedno docelowe miejsce.
• Many-to-one dla konsolidacji – kilka starych stron → jedna nowa (używaj tylko gdy logicznie uzasadnione).
• 301 (permanent) nie 302 – 301 przekazuje PageRank, 302 jest tymczasowe.
• Brak redirect chains – URL A → URL B → URL C = tracisz PageRank każdy hop. Mapuj bezpośrednio A → C.
• Brak redirect loops — oczywiste, ale zdarza się przy manual errors.
• Deep pages priority — nie tylko homepage, wszystkie URL muszą mieć plan.

Przykład mappingu

Old URL	New URL	Type	Priority
oldsite.pl/	newsite.pl/	301 1:1	Critical
oldsite.pl/blog/	newsite.pl/blog/	301 1:1	Critical
oldsite.pl/blog/jak-zaczac-seo/	newsite.pl/blog/jak-zaczac-seo/	301 1:1	High
oldsite.pl/old-product-A/	newsite.pl/new-product-B/	301 many-to-one	Medium
oldsite.pl/deprecated-page/	newsite.pl/blog/	301 to parent	Low
oldsite.pl/?session=12345	410 Gone	Kill	N/A

Narzędzia implementacji redirects

Server-level (preferred)

• Apache: .htaccess z RewriteRule.
• Nginx: server { rewrite ... permanent; } w config.
• Cloudflare: Bulk Redirects (up to 100k rules).
• Vercel: redirects() w next.config.js.

CMS-level

• WordPress: Redirection plugin (do 10k rules), rank math redirects.
• Shopify: native URL Redirects (limit depending on plan).
• Drupal: path_redirect module.

Dla big scale (> 10k redirects)

Używaj Cloudflare Bulk Redirects lub podobne edge-level rules. CMS-level plugins mogą spowolnić serwer przy każdej requestu. Więcej o tym zagadnieniu znajdziesz w przewodniku SEO 2026.

Content migration

Co migrujesz

• Wszystkie posty i strony z URL.
• Media (obrazy, PDFs, video) z path update.
• Comments jeśli mają wartość (ważne dla blogów).
• Author profiles i Schema Person.
• Categories, tags, taxonomies.
• Custom fields, Schema data.

Czego NIE migrujesz

• Thin content (< 300 słów) → konsolidacja lub delete z 410.
• Duplikaty – wybierz najlepszy, pozostałe 301 do tego.
• Legacy category pages bez content.
• Spam comments.
• Broken media files.

Technical migration content

• Export content z CMS (SQL dump, XML, WP export).
• Database import do new CMS z URL transformation.
• Media transfer (rsync, S3 copy).
• Internal links update – wszystkie http://oldsite.pl/... → https://newsite.pl/... w content.
• Schema.org updates (url, sameAs, canonicalUrl).

Backlinks – outreach strategy

301 redirects przekazują 85–95% PageRank wg Google statements, ale w praktyce przejście nie jest immediate. Outreach do top backlink sources skraca recovery time.

Priorytetyzacja

1. Top 50 linkujących DR 50+ — personal outreach z prośbą o update URL.
2. Wzmianki bez linków — poproś o przekształcenie wzmianki na link do nowej domeny.
3. Toxic backlinks — nie prośba, zostaw dla 301 (migracja to okazja disavow, gdy reviewasz profile).

Email template outreach

Temat: Link do naszej strony – quick update
Cześć [Imię],
Dzięki za wspomnienie [TwojaMarka] w Twoim artykule o [temat]. Chciałem dać Ci znać, że w [data] migrujemy do nowej domeny – [nowa.pl]. Stary URL redirectuje do nowego, ale direct link z bezpośrednim URL działa szybciej.
Czy możesz zaktualizować link z [stara.pl/article/] na [nowa.pl/article/]? Zajmie 10 sekund.
Dzięki! – [Imię]

Conversion rate outreach: 25–45% w naszych projektach. Warte.

Przykład praktyczny: migracja .pl → .com, e-commerce

Klient: sklep odzieżowy, oldsite.pl → newsite.com (expansion na international), 3 500 SKU + 180 blog posts = 3 680 URL-ów, organic traffic 85 tys./mies., przychód 420 tys. PLN/mies.

Timeline

• Tydzień 1–2: Pre-migration audit (crawl, backlinks, GSC data, GA4 data).
• Tydzień 3–5: URL mapping (automation + 1500 manual review top traffic URLs).
• Tydzień 6–8: Technical preparation (staging, redirects, internal linking update).
• Tydzień 9: Launch weekend.
• Tydzień 10–22: Post-migration monitoring i outreach.

Redirect plan

• 3 680 URL-ów, 100% zmapowane.
• 3 412 redirect 1:1 (93%).
• 215 many-to-one (konsolidacja duplikatów i thin pages).
• 53 410 Gone (deprecated deep URLs).

Implementacja

• Cloudflare Bulk Redirects (3 627 reguł, 410 w Worker).
• WordPress na newsite.com + Redirection plugin jako backup.
• Internal linking: 100% aktualizacja content (automated + manual review).

Wyniki

• Tydzień 1–2: traffic dip 25% (expected – Google processing migration).
• Tydzień 3–4: dip 18%, 404 errors w Search Console zidentyfikowane i fixed (missed 23 redirects).
• Tydzień 6–8: traffic powrócił do 85% baseline.
• Tydzień 12: 105% baseline (growth thanks to new international reach).
• Tydzień 22: 128% baseline.
• Przychód: krótkotrwała strata ~35k PLN (tygodnie 1–4), potem recovery + nowe rynki.

Pełen framework audytowy: audyt SEO 2026.

Pułapki i częste błędy

Pułapka 1: brak pre-migration crawl

„Wiemy co mamy, po co crawl”. Po migracji okazuje się, że zapomnieliście o 400 URL, których nie ma w nowej strukturze. 404 fala.

Pułapka 2: tylko homepage redirect

Wszystkie stare URL → redirect do new homepage. Tracisz deep linki. Minus 70–90% organic traffic per migrated content. Klasyczny disaster.

Pułapka 3: redirect chains

Stary URL → redirect do intermediate URL → redirect do final URL. Każdy hop = ~5% PageRank loss. Target: direct redirect bez chain.

Pułapka 4: opuszczone redirects po roku

Marketing decyduje, że rok po migracji redirects już nie są potrzebne. Wyłączają. 404 fala na links z Wayback Machine, archive, emails, forum posts. Redirects trzymaj na zawsze.

Pułapka 5: brak staging

Migracja bezpośrednio na produkcję. Odkrywacie bug w checkout 4h po launchu. Rollback niemożliwy bo DNS already propagated. Zawsze staging + smoke tests.

Pułapka 6: launch w piątek po południu

Dev team idzie na weekend, problem pojawia się w sobotę, nikt nie reaguje 48h. Launch w okno, które daje czas na obsługę (poniedziałek rano dla enterprise, weekend dla small site).

Pułapka 7: ignorowanie user-facing changes

Klienci dostają invoices z oldsite.pl linkami, forum post mają linki, emaile marketing mają linki. Komunikacja zewnętrzna równie ważna jak technical migration.

Plan rollback — when things go wrong

Masz 24–48h na rollback, zanim Google zacznie re-indexować new domain jako primary. Po tym punkcie rollback jest już „forward migration #2″.

Triggery rollback

• Traffic drop > 50% w pierwszym tygodniu (nie 20–30% dip który jest normal).
• Crytyczne UX bug, który psuje konwersję.
• Security incident na nowej domenie.
• Server infrastructure fail.

Rollback procedure

1. Przywróć starą stronę z backup (wszystko pre-migration).
2. Revert DNS changes (sitcky — może trwać 24–48h propagation).
3. Disable redirects na starej domenie.
4. GSC: change of address reverse (jeśli użyte).
5. Komunikacja: dlaczego rollback, kiedy re-try migration.

Post-mortem i lessons learned — framework

3 miesiące po migracji rób strukturalne post-mortem, niezależnie czy projekt się powiódł. Cztery pytania, na które szukasz odpowiedzi:

Pytanie 1: Co zaskoczyło?

• Które URL-e miały większy spadek niż przewidywany? Dlaczego?
• Gdzie outreach miał wyższy/niższy conversion rate?
• Który sygnał wracał wolniej niż expected (CTR, rankings, impressions)?

Pytanie 2: Co zadziałało lepiej niż expected?

• Które automatyzacje zaoszczędziły najwięcej czasu?
• Która komunikacja do klientów zmniejszyła churn?
• Który redirect tool okazał się bardziej elastyczny?

Pytanie 3: Gdzie straciliśmy najwięcej czasu?

• Manual URL mapping – czy dało się zautomatyzować lepiej?
• Staging environment debugging — czy dry-run wyłapałby to?
• Internal linking audit – narzędzia czy proces?

Pytanie 4: Co zrobimy inaczej następnym razem?

• Zapis do checklist master dla przyszłych projektów.
• Update internal playbook.
• Prezentacja team-wide z 3 kluczowymi lekcjami.

Trzeci case: mikrobrand, 180 URL, solo founder

Nie każda migracja to enterprise. Klient: solo consultant, blog + landing pages, 180 URL, 6,5 tys. organic/mies., budżet 6 tys. PLN. Zakres: rebrand domenowy po decyzji o pozycjonowaniu się pod personal brand zamiast nazwy firmy.

Jak skondensowaliśmy proces do 3 tygodni

• Tydzień 1: audyt (Screaming Frog free do 500 URL), manual URL mapping w Sheets, kontakt z 20 najważniejszymi linkującymi.
• Tydzień 2: staging na WP, plugin Redirection dla 180 rules, aktualizacja internal linków przez WP-CLI search-replace.
• Tydzień 3: launch w sobotę, GSC Change of Address, monitoring przez 2 tygodnie z 15 min daily check.

Wynik

• Dip 18% w tygodniu 1, recovery do 95% w tygodniu 6.
• 14 z 20 outreach maili zakończyło się aktualizacją linka (70% success rate — wyższe niż w enterprise, bo personal outreach).
• Po 4 miesiącach 118% baseline, głównie dzięki lepszemu match między brand a treścią.

Lekcje z mikroprojektu

• Personal outreach bije automation przy < 50 domenach. Mail napisany samodzielnie konwertuje 3–4x lepiej niż sekwencja z szablonu.
• WP-CLI to superpower — komenda wp search-replace 'oldsite.pl' 'newsite.pl' --dry-run zaoszczędziła 6 godzin manualnej roboty.
• GSC Change of Address działa szybciej dla małych stron – Google przetwarza migrację w 7–14 dni zamiast 30+ dla enterprise.
• Backup przed każdą zmianą DNS – solo founder nie ma DevOps, więc snapshot hostingowy uratował 2h w przypadku literówki w rekordzie MX.

Kalkulator ryzyka migracji

Przed podjęciem decyzji policz subiektywny risk score — im wyższy, tym więcej zasobów powinieneś alokować na audyt i monitoring.

Punkty ryzyka (dodawaj)

• +3 jeśli migrujesz > 5 000 URL.
• +2 jeśli równocześnie zmieniasz CMS.
• +2 jeśli równocześnie zmieniasz URL strukturę.
• +3 jeśli jest to zmiana TLD (.pl → .com).
• +2 jeśli masz > 30% traffic z deep pages (długi ogon).
• +2 jeśli masz wersje językowe z hreflang.
• +1 za każdy zewnętrzny system (CRM, marketing automation, helpdesk) zintegrowany przez URL.
• +2 jeśli nie masz QA/DevOps na etacie.

Interpretacja score

• 0–3 punktów: low risk. Standard 4–6 tyg. plan, solo SEO + dev wystarczą.
• 4–7 punktów: medium risk. 8–12 tyg., team 3–4 osoby, staging obowiązkowy.
• 8–12 punktów: high risk. 3–6 mies., zewnętrzna agencja lub senior kontraktor, dry-run obowiązkowy, rollback plan szczegółowo przećwiczony.
• 13+ punktów: critical. Fazuj migrację, rozważ przesunięcie o 6 mies. i wzmocnienie teamu, pilnuj KPI biznesowych (nie tylko SEO).

Narzędzia

• Crawlers: Screaming Frog, Sitebulb.
• Backlinks: Ahrefs, Semrush, Majestic.
• Redirect management: Cloudflare Bulk Redirects, Redirection (WP), Yoast Premium redirects.
• Testing: Little Warden, ContentKing, SiteImprove dla enterprise monitoring.
• Server logs: Screaming Frog Log File Analyser, Semrush Log Analyzer.
• Search Console: Change of Address tool, URL Inspection, Coverage report.
• Backup: BlogVault, UpdraftPlus, platform-level snapshots.

FAQ – najczęstsze pytania

Ile czasu trwa pełna migracja?

Małe strony (< 500 URL): 4–6 tygodni. Średnie (500–5000 URL): 8–12 tygodni. Duże (5000–50k URL): 3–6 miesięcy. Enterprise (50k+ URL): 6–12 miesięcy z fazowaniem. Najdłuższe fazy: audit + mapping (40% time) + post-migration monitoring (30%). Sam launch to 1–2 dni.

Czy warto używać Change of Address tool w GSC?

Tak, dla full domain migration (oldsite.pl → newsite.pl). Narzędzie sygnalizuje Google migration intent i przyspiesza transfer signals. Jednak nie zastępuje 301 redirects – oba są needed. Tool NIE działa dla partial migrations (tylko subsection) ani migrations HTTP → HTTPS (automatyczne).

Jak długo trzymać 301 redirects?

Google oficjalnie potwierdza, że 301 powinien być minimum 12 miesięcy. Praktyka: trzymaj wiecznie. Powody: (1) legacy links z archive, email, offline materials wciąż używane po latach, (2) usunięcie = natychmiastowe 404, (3) koszt trzymania redirect rule zero. W 40+ projektach w naszym portfolio nigdy nie zdarzyło się usunąć 301.

Ile PageRank tracę w migracji?

Z 301 redirects Google przekazuje 85–95% PageRank (Google John Mueller confirmation 2022). W praktyce: well-executed migration = 5–15% strata, poorly executed = 30–70%. Różnica to głównie quality of URL mapping, redirect chains, internal linking update, outreach. Po 6 miesiącach od migracji większość projektów osiąga 95–105% pre-migration signals.

Czy rebrand + migracja to dobry moment na zmianę URL struktury?

Tak i nie. Plus: jeden większy projekt zamiast dwóch. Minus: double risk (jedna z ryzykownych zmian zawiedzie). Rekomendacja: jeśli obecna URL struktura działa, nie zmieniaj podczas domain migration. Jeśli musisz – migration jest acceptable window, ale dokument podwójnie i monitor intensywniej. Zobacz migrację struktury URL.

Kiedy powiedzieć klientom / użytkownikom o migracji?

Pre-launch: newsletter, blog post, social 2 tygodnie przed. Launch day: email z explainer. Post-launch 1–2 tygodnie: social reminders, emails do low-zaangażowanie subs. Nie ogłaszaj przed pre-migration – customers mogą mieć negative reaction. Ogłaszaj już z rozwiązaniem („migrujemy do X, wszystkie linki działają, nic nie musisz robić”).

Jak przygotować SEO team na migrację?

Brief w fazie planning: co, dlaczego, timeline, expected impact. Każdy członek teamu wie swoją rolę (SEO: audit + mapping; Dev: redirects + staging; Content: internal links + communication; Marketing: outreach + customer notifications). Rollback criteria i procedure spisane. Daily standups w tygodniu launchu, weekly checkpoints w monitoring phase. Post-mortem po 3 miesiącach żeby udokumentować lessons learned.

Czy migracja na HTTPS to też „migracja domeny”?

Technicznie tak, Google traktuje HTTP i HTTPS jako różne strony, ale ma dedykowany, automatyczny proces. Nie potrzebujesz Change of Address ani ręcznego mappingu URL. Wystarczy 301 z HTTP na HTTPS, aktualne wpisy w GSC (dodaj HTTPS property), sitemapa z HTTPS URL-ami. Straty w rankingach typowo 0–5% i zanikają w 2–4 tygodnie. Potraktuj to jako tech debt fix, nie fullblown migrację.

Czy warto migrować tylko blog do subdomeny?

Zwykle nie. Subdomena (blog.example.com) jest traktowana jako oddzielna strona, tracisz topical authority zbudowane na głównej domenie. Jeśli musisz (brand hygiene lub technical constraint), zastosuj reverse proxy tak, żeby blog był widoczny jako example.com/blog/. W ten sposób zachowujesz equity i nie ryzykujesz fragmentacji linków.

Jak zintegrować migrację z WordPress multisite?

WP multisite dodaje trzy warstwy komplikacji: wspólna tabela wp_users, plugin propagation, mapping domen na poziomie network. Praktyka, która działa: (1) tworzysz nowy multisite z pustym content, (2) migrujesz per site z użyciem WP-CLI search-replace i db export, (3) domena mapping update w wp_blogs, (4) redirect rules na Cloudflare przed siatką, a nie w .htaccess każdej instancji. Przy 20+ sajtach unikniesz godzin konfiguracji.

Jakie sygnały redirect przenosi – anatomia transferu

W 2026 roku rozumienie, co dokładnie przenosi 301, jest ważniejsze niż kiedykolwiek — Google SGE i odpowiedzi AI opierają się na sygnałach trust, które migracja może rozbić albo wzmocnić. Nie wszystkie sygnały są równe.

Sygnały bezpośrednio przenoszone przez 301

• PageRank / link equity — 85–95% wg potwierdzeń Google z lat 2018–2023.
• Anchor text starych linków zewnętrznych (co oznacza, że nadal liczy się relewantność).
• URL-level freshness — historyczne sygnały crawl frequency częściowo.
• Canonical clustering – jeśli stary URL był canonical, nowy URL przejmuje tę rolę po ~4 tygodniach.

Sygnały, które nie przenoszą się automatycznie

• User behavior signals – CTR, dwell time, pogo-stick rate. Google musi je zbudować od zera dla nowej URL, nawet jeśli treść jest identyczna. Recovery 4–8 tygodni.
• Domain age i historical trust przy zmianie domeny — stare sygnały znikają, jeśli przechodzisz na brand-new TLD.
• HSTS preload — nowa domena musi sama się wpisać na listę.
• Core Web Vitals field data – CrUX resetuje się, pełen 28-dniowy rolling window odbudowuje się po 4 tygodniach.

Jak przyspieszyć transfer sygnałów

• Użyj tych samych Schema.org JSON-LD (Organization, WebSite, BreadcrumbList) na obu domenach, ze zaktualizowanymi URL.
• Dodaj sameAs w Organization schema na nowej domenie, wskazujący social i starą domenę — pomaga Google Knowledge Graph zmapować tożsamość.
• Złóż sitemapę HTML (nie tylko XML) i linkuj z homepage – ułatwia crawl discovery 3x szybciej.
• Zwiększ Crawl Rate tymczasowo w GSC (jeśli opcja dostępna) przez pierwsze 14 dni po migracji.
• Uruchom audyt SEO natychmiast po dipie traffic (tydzień 2–3), żeby wyłapać brakujące redirecty, zanim staną się trwałe.

Migracja SME vs enterprise – jak skaluje się złożoność

Migracja 300 URL-i i migracja 50 000 URL-i to dwa różne projekty. Skaluje się nie tylko liczba redirectów, lecz także liczba interesariuszy, ryzyk, testów i zależności technicznych. Poniżej matryca różnic, na którą opieramy wycenę i plan.

Porównanie parametrów

Parametr	SME (do 500 URL)	Mid-market (500–5k URL)	Enterprise (50k+ URL)
Czas projektu	4–6 tygodni	8–12 tygodni	6–12 miesięcy
Team	1 SEO + 1 dev	2 SEO + 2 dev + PM	5 SEO + 4 dev + 2 PM + QA + DevOps
Budżet zewnętrzny	8–20 tys. PLN	40–120 tys. PLN	300 tys.–2 mln PLN
Staging	1 × pełna kopia	2 × staging (feature + pre-prod)	3 × staging + blue/green deploy
Testy	Manual smoke test	Semi-automated crawl diff	CI ciąg procesów + regression + load test
Redirect storage	Redirection plugin	Cloudflare Bulk Redirects	Edge Worker + load balancer rules
Okno cut-over	Weekend rano	Noc wt–pt, rolling cutover	Fazowany launch, cohorty URL
Rollback window	24h	72h	7 dni z warstwowym rollbackiem
Komunikacja	Mail + social	Mail + PR + sales enablement	Dedykowana strona statusu, PR, investor relations

Kiedy „skokowa” migracja, a kiedy fazowana

• Skokowa (big bang): cały stary serwis zmienia adres jednej nocy. Dobre dla SME i mid-market. Minimalizuje okres, w którym Google widzi dwie wersje. Wymaga niezawodnej infrastruktury i redirectów.
• Fazowana: migrujesz sekcje (blog, sklep, obsługa klienta) w odstępach 2–4 tygodni. Dobre dla enterprise, gdy zespoły nie są w stanie dostarczyć wszystkiego naraz. Minus: 3–6 miesięcy życia w hybrydowej strukturze, trudniejszy śledzenie.
• Z brandingiem równoległym: nowa domena + stara aktywna przez 3 miesiące, z canonicalem ze starej na nową. Stosowane przy spornych rebrandach M&A. Uwaga: Google często i tak ignoruje canonical cross-domain, jeśli treść różni się typograficznie.

Team i role – kto za co odpowiada

Migracja bez jasnych właścicieli ról zamienia się w domino opóźnień. Standard, który wymuszamy w umowie od 2023 roku, to RACI przypisane do każdej z pięciu faz i ośmiu obszarów technicznych.

Role i widełki wynagrodzeń w Polsce (2026)

• Migration Lead / Senior SEO: 18–28 tys. PLN brutto B2B, odpowiada za strategię, URL mapping, koordynację. Obowiązkowy w każdej migracji > 1 000 URL.
• Technical SEO: 12–18 tys. PLN, robi audyt techniczny, schema, hreflang, testy renderu.
• Content SEO: 10–15 tys. PLN, mapuje content, pilnuje kanibalizacji, prowadzi konsolidację thin content.
• Backend dev (PHP/Node/Python): 16–24 tys. PLN, implementuje redirecty, routing, CMS migration scripts.
• DevOps / SRE: 18–26 tys. PLN, DNS, CDN, load balancer, rollback plan.
• QA: 10–14 tys. PLN, crawl diff, smoke testy, regression, lighthouse.
• Analytics engineer: 14–20 tys. PLN, GA4 property clone, GTM container copy, BigQuery export.
• Project Manager: 12–18 tys. PLN, RACI, Gantt, status weekly, risk log.

RACI – skrócona

Zadanie	R	A	C	I
URL mapping	Technical SEO	Migration Lead	Content SEO, Dev	PM, CMO
Redirect deploy	Backend dev	DevOps	Technical SEO	PM
DNS cut-over	DevOps	Migration Lead	Backend dev	CMO, Board
Content audit	Content SEO	Migration Lead	Editorial	PM
Analytics migration	Analytics engineer	Head of Data	Migration Lead	PM
Outreach do backlinków	Digital PR	Content SEO	Legal (NDA)	PM
Rollback decision	Migration Lead	CTO	CMO, Board	Team

30/60/90-dniowy roadmap wdrożeniowy

Użyj tego planu jako szablonu kick-off dla każdej migracji z deadline do 90 dni po decyzji biznesowej. Enterprise projekty wydłużają każdą fazę proporcjonalnie.

Dni 1–30: dyskowerowanie i planowanie

• Dni 1–5: kick-off, brief biznesowy, goals, KPI (organic traffic, przychód, leads), zdefiniowanie ryzyk i krytycznych URL-i.
• Dni 6–12: pełny crawl Screaming Frog i Sitebulb, export logów serwera (30 dni), Ahrefs + Semrush backlink profile.
• Dni 13–20: budowa URL mapping sheet z priorytetami (top 100 ręcznie, reszta regex).
• Dni 21–26: decyzja o hostingu, CMS, CDN, brief pod Schema.org i hreflang.
• Dni 27–30: sign-off mapa URL i plan redirect, mrożenie zmian content do czasu migracji.

Dni 31–60: budowa i testy

• Dni 31–40: staging nowego serwisu, migracja content (1:1 + konsolidacja), aktualizacja internal linków.
• Dni 41–48: implementacja redirect rules (Cloudflare + CMS backup), testy na stagingu z diff tool (np. Visual Ping, SiteTrue).
• Dni 49–54: analytics property clone (GA4, GTM, BigQuery streaming), Search Console property dodana, sitemaps przygotowane.
• Dni 55–58: dry-run migracji na kopii DNS (subdomena beta.newsite.pl) – pełna ścieżka od DNS po GSC.
• Dni 59–60: go/no-go, rollback plan review, komunikacja do użytkowników.

Dni 61–90: launch i stabilizacja

• Dzień 61: launch window (sobota 6:00–10:00), DNS cut-over, submit sitemap, uruchomienie Change of Address.
• Dni 62–65: daily stand-up + monitoring 4xx/5xx w logach, hotfix brakujących redirectów (typowo 1–3%).
• Dni 66–75: backlinks outreach top 50 domen, aktualizacja internal linków wewnątrz content, korekta hreflang.
• Dni 76–85: audit post-migration (Screaming Frog diff crawl), porównanie rankingów z baseline.
• Dni 86–90: raport dla zarządu, lessons learned, plan dalszego wzrostu treści na nowej domenie.

Budżet migracji – struktura kosztów

Migracje enterprise rzadko mieszczą się w jednej fakturze. Budżet dobrze rozpisać na cztery koszyki, żeby kontroler finansowy rozumiał, co jest inwestycją, a co OPEX-em utrzymaniowym. Pełen obraz tematu znajdziesz w kompletnym przewodniku seo 2026.

Struktura kosztów dla mid-marketu (5 000 URL, 120 tys. PLN budżet)

• Audyt + URL mapping (25%): 30 tys. PLN – 6 tyg. pracy Senior SEO + Technical SEO.
• Development + staging (35%): 42 tys. PLN – migracja CMS, redirect engine, testy, DevOps.
• Launch + monitoring (20%): 24 tys. PLN – tygodnie 9–16, daily ops, fixes.
• Outreach + komunikacja (10%): 12 tys. PLN – digital PR, copywriting, mailing, social.
• Reserve (10%): 12 tys. PLN – niezbędny bufor na nieplanowane fixes (95% migracji go konsumuje).

Ukryte koszty, które warto przewidzieć

• Przedłużenie licencji Screaming Frog / Sitebulb + Log File Analyser – 2–3 tys. PLN.
• Plan biznes Ahrefs lub Semrush dla backlinks — ok. 1,5 tys. PLN / mies. przez 3 miesiące.
• Cloudflare Pro/Business dla Bulk Redirects + analytics — 100–500 USD/mies. w okresie migracji.
• Tymczasowy hosting dla stagingu produkcyjnego — 1–3 tys. PLN/mies.
• Dodatkowy retainer SEO agencji 6 mies. po launchu — 8–20 tys. PLN/mies.

Integracja z Search Console, GA4 i CRM

Migracja to największy test dojrzałości stacku analitycznego. Jeśli nie połączysz danych ze starej i nowej domeny, nie będziesz w stanie udowodnić, że migracja się udała (lub nie).

Search Console – checklista

1. Dodaj Domain property dla nowej domeny (DNS TXT verification) minimum 30 dni przed launchem.
2. Zweryfikuj subdomeny (www, blog, shop) jako oddzielne URL-prefix properties.
3. Uruchom Change of Address w dniu cut-over (nie wcześniej).
4. Export danych GSC do BigQuery dla starej domeny minimum 16 miesięcy wstecz (rolling window Google).
5. Monitor Coverage, Enhancements, Core Web Vitals codziennie w tygodniu 1–4 po migracji.

GA4 — plan właściwości

• Wariant A – dwie właściwości łączone: stara GA4 property zostaje read-only, nowa property od dnia 0. Łącz dane w Looker Studio na poziomie wizualizacji.
• Wariant B – jedna property, dwa data streams: dokładasz stream dla nowej domeny do istniejącej property. Zachowujesz historyczne eventy i ciągłość atrybucji. Polecany dla mid-market.
• Wariant C – nowa property + BigQuery union: surowe dane łączone w BQ poprzez UNION ALL. Jedyne podejście enterprise-grade, które pozwala spójnie raportować przychód i konwersje.

CRM i marketing automation

• Zaktualizuj wszystkie formularze i UTM templates – 70% firm zapomina o instancji HubSpot/Pipedrive.
• Sprawdź webhooki i integracje Zapier/n8n, które wskazują na konkretne URL-e (np. lead source mapping).
• Jeżeli masz integrację z WordPressem przez REST API, zaktualizuj endpointy w CRM i automacjach (typowe pole: site_url w konfiguracji).
• Rozwiąż problem ciasteczek: przy zmianie domeny gubisz cookies GA, hotjar, Fullstory. Zaplanuj re-identyfikację użytkowników poprzez login lub newsletter double opt-in.

Drugi case: migracja SaaS B2B na własną domenę

Klient: platforma SaaS marketing automation, 1 240 URL (blog + docs + pricing + case studies), 42 tys. wizyt organicznych/mies., 180 MQL/mies. z organicu. Migracja z legacy domain (akwizycja) do głównej domeny grupy.

Dlaczego to było trudniejsze niż e-commerce

• Docs (450 URL) miały identyczne canonical URL-e na obu domenach — konieczność deduplikacji kanibalizacji przed launchem.
• Gated content (23 raporty PDF) zablokowany za formularzem – każdy form miał hardcoded URL, konieczny refactor.
• Webinary na starej domenie osadzone przez iframe u klientów – migracja wymusiła keep-alive old domain przez 12 miesięcy z redirectami soft.
• Integracja z HubSpot śledzenie: wszystkie formularze z legacy domain miały inne portalId.

Timeline 16 tygodni

• Tydz. 1–3: audyt + mapping, zidentyfikowane 142 duplikaty docs do konsolidacji.
• Tydz. 4–7: refactor formularzy, keep-alive domena legacy, staging.
• Tydz. 8–10: implementacja redirectów (Cloudflare + Next.js rewrites), testy.
• Tydz. 11: launch, monitoring.
• Tydz. 12–16: outreach, ranking recovery, Q&A.

Wyniki po 6 miesiącach

• Traffic: dip 31% w tydz. 1–3 (większy niż expected bo docs rankings), recovery do 88% w tydz. 12, 124% w tydz. 26.
• MQL z organicu: 165 w miesiącu 1 (spadek z 180), 205 w miesiącu 6.
• Koszt projektu: 185 tys. PLN netto, ROI zwrócił się w 4 miesiące dzięki wyższej autorytetywności głównej domeny.

Automatyzacja migracji w n8n i skryptach

Im większa migracja, tym bardziej ręczna robota boli. Cztery części migracji dają się solidnie zautomatyzować bez utraty kontroli – mapping, monitoring, outreach, reporting.

URL mapping w skrypcie

• Eksport crawl Screaming Frog do CSV (kolumny: URL, Status, Title, H1, Indexable).
• Skrypt Python z pandas dopasowuje URL stare → nowe na podstawie slug similarity (fuzzy match ratio > 85%).
• Reszta flagowana do manual review w Google Sheets z kolumną status.
• Export do JSON lub CSV dla Cloudflare Bulk Redirects.

Monitoring post-migration w n8n

• Proces „Daily 4xx Sweep”: fetch GSC Coverage report → parse errors → push do Slack kanału #migracja.
• Proces „Log File Diff”: pobiera raw logs z serwera (scp/SFTP) → filtruje 4xx/5xx → agreguje top URL z error w 24h → tworzy Trello card dla dev.
• Proces „Ranking Delta”: API Ahrefs/Semrush → oblicza delta rank top 100 KW vs baseline z pre-migration → wysyła mail.

Outreach zautomatyzowany

• Generujesz listę top 200 domen linkujących z Ahrefs, enrichment przez Hunter.io dla emaili.
• Personalizacja w n8n: GPT node bierze URL artykułu linkującego, pisze 2-zdaniowy personal touch.
• Sekwencja w Mailshake/Instantly: mail 1 (intro + prośba), follow-up 1 po 5 dniach, follow-up 2 po 12 dniach.
• Monitoring otwarć i klików, webhook do Sheets – lista „updated” vs „pending”.

Migracja międzynarodowa — hreflang i GEO routing

Jeśli migracja wiąże się z dodaniem nowych krajów lub języków, hreflang staje się jednym z trzech najczęstszych źródeł strat. Trzy zasady, których nie łam:

Zasada 1 – pełna reciprocal matrix

Każda strona musi wskazywać na wszystkie swoje wersje językowe, a one z powrotem na nią. Jeśli polska wersja linkuje do angielskiej, angielska musi linkować do polskiej. Jeden brakujący link = Google ignoruje całą grupę.

Zasada 2 – sitemap hreflang zamiast HTML

Dla > 500 URL-i używaj hreflang w XML sitemap, nie w <head>. Łatwiejsze w utrzymaniu, mniej błędów, szybsze crawl discovery.

Zasada 3 – x-default dla nieznanych lokalizacji

Zawsze dodaj hreflang="x-default" wskazujący na wersję domyślną (typowo EN). Google używa tego dla wszystkich krajów, których nie zmapowałeś.

Typowe błędy podczas migracji

• 301 z oldsite.pl/en/ na newsite.pl/ – tracisz angielski klaster, 40%+ traffic EN spadek.
• Różne slugi na różnych językach bez hreflang — Google traktuje jako duplikat i wybiera jedną wersję.
• GEO routing po IP bez opcji override – Googlebot (US IP) widzi tylko EN wersję, indeksuje tylko EN.

Wewnętrzna komunikacja i change management

90% projektów, które zawodzą, ma techniczny plan OK i zerową komunikację. Migracja dotyka każdego działu, nie tylko SEO.

Interesariusze

• Sales: linki w email sygnaturach, templates, oferty, prezentacje sales deck – wszystko wymaga aktualizacji.
• Customer Success: docs i knowledge base linki w ticketach, automatycznych odpowiedziach, embeded help widgets.
• Product: linki in-app (np. „dowiedz się więcej”), onboarding emails, release notes.
• Marketing: UTM templates, paid ads landing pages, social profile linki, podpisy w mailingach.
• Legal: regulamin, polityka prywatności, zgody marketingowe – każda wzmianka o domenie.
• Finance: faktury, receipts, invoice templates – linki do obsługi płatności.

Komunikacja zewnętrzna – timeline

• T-14 dni: email do klientów z informacją „zmienia się nazwa/domena, wszystko dalej działa”.
• T-7 dni: social posts, blog post na starej domenie.
• T-1 dzień: final reminder do top subscribers.
• Launch day: banner na homepage, podziękowanie za cierpliwość.
• T+7 dni: „jak nowa strona działa, co się zmieniło” content post.

Finalna checklista 60 punktów (skrócona)

Tydzień -4 do -1

• Crawl, log analysis, backlink export, GSC/GA4 export.
• URL mapping 100% coverage, sign-off biznesu.
• Staging + visual regression tests.
• Analytics property clone.
• Komunikacja pre-launch (email, social).

Tydzień launch

• Dry-run w piątek, go/no-go w sobotę 6:00.
• DNS cut-over, sitemap submit, Change of Address.
• Smoke test 50 URL, logs monitoring, GSC URL Inspection.
• Hotfix channel na Slacku aktywny 48h.

Tydzień +1 do +4

• Daily 4xx/5xx monitoring, weekly organic traffic review.
• Outreach top 50 backlinks, konwersja 30%+ to target.
• Internal linking audit.
• Raport dla zarządu z recovery trendem.

Co dalej

Start: decyzja biznesowa (real reason dla migracji). Audit obecnej strony (2–4 tygodnie). Stwórz team z ownerami per faza. 12-tygodniowy roadmap z milestones.

Kolejne kroki: (1) redesign i zmiana CMS bez strat SEO – gdy migracja to też redesign, (2) migracja struktury URL – jeśli zmieniasz URL strukturę, (3) audyt SEO 2026 – pre-migration audit methodology.

Pełen kontekst SEO w przewodniku SEO 2026 – migracja jest operation, nie strategia. Najpierw SEO foundation, potem migracja gdy biznesowo uzasadniona.