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.

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, conversion per URL, assisted conversions.
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 tracking 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.

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.

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., revenue 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.
• Revenue: 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.

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-engagement 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.

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.