Checklist migracji domeny bez straty ruchu

Checklist migracji domeny to 82-punktowa lista, która przeprowadza zespół SEO przez pełen cykl zmiany adresu, struktury URL lub platformy bez utraty rankingu, ruchu i konwersji. Statystyka z 80 migracji prowadzonych w latach 2022–2026: 40% projektów traci ponad 20% ruchu organicznego w pierwszym miesiącu po przełączeniu, a 15% nigdy nie odzyskuje pełnego wolumenu. Wspólny mianownik strat: brak metodycznej checklisty i decyzje podejmowane w dniu przełączenia, nie trzy miesiące wcześniej.

Ta checklista dzieli migrację na sześć faz, każdą z własnymi kryteriami pass/fail. Fazy są sekwencyjne – nie można zacząć fazy 4, jeśli w fazie 2 pozostały otwarte punkty. Dla zespołu, który pierwszy raz robi migrację, cały proces to 8–14 tygodni. Dla doświadczonego zespołu z narzędziami i szablonami: 3–5 tygodni. Punkty są skalibrowane dla migracji rebrandingu, zmiany platformy CMS, fuzji serwisów i zmiany struktury URL — najczęstsze scenariusze.

Faza 1 – Audyt pre-migration (14 punktów)

Audyt przed migracją to fundament. Pomijanie tej fazy to największy pojedynczy powód porażki projektu. Celem jest mieć pełne, odtwarzalne zdjęcie stanu „przed” – po przełączeniu tylko to pozwala stwierdzić, co poszło nie tak i jak daleko do recovery. Praktyczne wskazówki znajdziesz w 80-punktową checklistę audytu SEO.

1.1 Baseline ruchu i rankingów

1. Export pełnych danych z Google Analytics 4 (ostatnie 12 miesięcy): sesje, konwersje, strony, kanały, urządzenia.
2. Export z Search Console (16 miesięcy via API): zapytania, strony, pozycje, CTR – per URL.
3. Rankingi TOP 1000 słów kluczowych z Ahrefs/Semrush zarchiwizowane na dzień −7 przed launchem.
4. Screenshoty SERP dla TOP 20 zapytań marki i komercyjnych (dowód pozycji w razie sporu z Google).
5. Baza linków zwrotnych (Ahrefs + Majestic) wyeksportowana do CSV, z kolumną „target URL”.
6. Index coverage report z Search Console – liczba indeksowanych URL, zidentyfikowane problemy (404, soft 404, noindex).

1.2 Inwentaryzacja URL

1. Pełen crawl źródłowej domeny (Screaming Frog lub Sitebulb) z pobranymi: status codes, title, meta, H1, canonical, internal links, response time, hreflang.
2. Export XML sitemap + porównanie z crawl-em: różnica wskazuje URL-e osierocone lub niedostępne z nawigacji.
3. Lista URL-i z ruchem > 10 sesji/miesiąc z ostatnich 12 miesięcy (priorytet A dla map 301).
4. Lista URL-i z backlinkami (priorytet B) — nawet jeśli nie mają ruchu, linki zewnętrzne mają wartość transferowaną przez 301.
5. Zarchiwizowane kopie stron TOP 50 w Wayback Machine (dowód treści przedmigracyjnej).

1.3 Analiza przygotowania

1. Mapa struktury kategorii i breadcrumb — odnotowane wszystkie relacje parent-child.
2. Lista zewnętrznych integracji: GA4, GSC, Tag Manager, Ads, Facebook Pixel, Hotjar, narzędzia SEO.
3. Identyfikacja URL-i „krytycznych” – top 5% strony generują zwykle 60–80% ruchu organicznego.

Faza 2 – Planowanie (18 punktów)

Plan przekłada wyniki audytu na konkretny harmonogram i zestaw artefaktów. Dobry plan musi być wykonywalny przez kogoś, kto nie uczestniczył w audycie – to test jego kompletności. Zagadnienie to omawiamy szerzej w 47-punktowej checklisty uruchomienia bloga firmowego.

2.1 Decyzje architektoniczne

1. Wybór typu migracji: rebranding (zmiana domeny, ta sama struktura), platform (WordPress→Shopify, np.), struktura URL, fuzja serwisów – różne checklisty szczegółowe dla każdego.
2. Polityka trailing slash: zachowujemy stan istniejący. Zmiana z/na trailing slash wymaga własnej warstwy 301.
3. Decyzja HTTPS: jeśli dotychczas HTTP, migracja to naturalny moment na HTTPS – ale wymaga osobnego 301 hopu.
4. Polityka prefixu (www vs non-www): ustalona i egzekwowana przez 301 z nie-kanonicznego do kanonicznego.
5. Parametry URL: konsolidacja do canonical (utm_, sort, filter) przez rel=canonical + reguły w robots/GSC.

2.2 Mapa 301 — serce migracji

1. Mapa 1:1 dla 80% URL-i o ruchu > 10 sesji/mies. – każdy stary URL ma dokładnie jeden nowy target.
2. Brak mapowania many-to-one bez uzasadnienia biznesowego (np. konsolidacja przestarzałych artykułów do hub-u).
3. Brak łańcuchów przekierowań (A→B→C) – każde dodatkowe „hop” to 3–15% utraty link equity i ryzyko limitu w chrome (>5 hopów = błąd nawigacji).
4. Pliki, obrazy (PDF, JPG, PNG) również w mapie 301 – nie tylko strony HTML.
5. Test mapy na sampling 100 URL-i przez staging – każdy 301 zwraca oczekiwany target, status code 301 (nie 302).
6. Mapa zapisana w wersji CSV + zaimportowana do pliku serwera (Nginx, Apache, htaccess) lub plugin (Redirection, Rank Math).

2.3 Timeline i komunikacja

1. Data przełączenia ustalona: preferencyjnie wtorek/środa, poza sezonem wysokiego ruchu, nie przed weekendem.
2. Window blokady zmian treści: 7 dni przed launchem, 14 dni po — tylko krytyczne poprawki.
3. Komunikacja do klientów / użytkowników (email, banner) 7 dni przed, z jasnym powodem i instrukcjami.
4. Zespół awaryjny on-call na 48h od przełączenia: DevOps, SEO, front-end, PR.
5. Kanał status (Statuspage, Slack) aktywny – każdy issue rejestrowany z timestamp-em.
6. Plan rollback udokumentowany: warunki aktywacji (> 50% spadek ruchu, > 30% błędów 5xx), procedura wycofania 301.
7. Budżet na recovery (zewnętrzny konsultant SEO, dodatkowe narzędzia) zarezerwowany – typowo 15% kosztu projektu.

Faza 3 – Przygotowanie techniczne (16 punktów)

Faza, w której staging replikuje przyszły stan produkcyjny. Każdy element nowego środowiska musi być zweryfikowany przed przełączeniem DNS. Więcej o tym zagadnieniu znajdziesz w szablonie strategii contentowej (Notion).

3.1 Staging środowisko

1. Staging dostępny tylko z whitelistowanych IP lub za basic auth – NIGDY publicznie (powstają duplikaty w Google).
2. robots.txt na stagingu: Disallow: / — dla pewności, nawet jeśli IP whitelisted.
3. noindex meta na każdej stronie stagingu + X-Robots-Tag w HTTP header.
4. Staging ma identyczną strukturę URL jak planowana produkcja – żadnych „stg-” prefiksów w ścieżkach.
5. Dane testowe zgodne z produkcją (przynajmniej 100 najważniejszych URL-i).

3.2 Implementacja techniczna

1. 301 z zachowaniem query stringów (reguła Nginx: return 301 $scheme://new-domain.pl$request_uri;).
2. Nowa XML sitemap wygenerowana, hostowana pod nową domeną, poprawna struktura dla 500+ URL-i (indexed sitemaps).
3. robots.txt produkcyjny gotowy, odnoszący się do nowej sitemap.
4. SSL certyfikat na nowej domenie (Let’s Encrypt lub wildcard) — test A+ na SSLLabs.
5. Redirects HTTP → HTTPS, non-www → www (lub odwrotnie) w JEDNYM hopie, nie dwóch.
6. Hreflang annotations zachowane (międzynarodowe serwisy) – link-equity między wersjami wymaga absolute URLs.
7. Canonical tags na nowych URL-ach – self-referencing, absolute.
8. Struktura wewnętrznych linków zaktualizowana – żaden internal link NIE może wskazywać na stary URL (one-hop internally, zero-hop po możliwości).

3.3 Performance i compliance

1. Core Web Vitals na nowej domenie ≥ baseline starej: LCP < 2,5s, INP < 200ms, CLS < 0,1.
2. Cookie banner (RODO), Consent Mode v2 – działają pod nową domeną, session trackowany od domeny root.
3. Śledzenie (GA4, GTM) przepięty na nową property ID lub z zachowaną kontynuacją danych (data retention + filter).

Faza 4 — Launch (12 punktów)

Dzień i następne 24 godziny. Każdy punkt wykonywany przez dedykowaną osobę, weryfikowany przez drugą. Temat ten rozwijamy w bibliotece zasobów marketingu cyfrowego 2026.

4.1 Go-live (godzina 0)

1. Backup produkcyjnej starej domeny pełny (kod, baza, media) – dostępny przez minimum 90 dni.
2. DNS TTL zmniejszone do 300s na 48h przed launchem (szybki rollback DNS).
3. Przełączenie DNS — nowa domena aktywna, stara z aktywnymi regułami 301.
4. Submit nowej sitemap w Google Search Console nowej property.
5. Submit w Bing Webmaster Tools (nie zapomina się — Bing ma 5–8% ruchu w B2B).
6. Change of Address w starej property Google Search Console — formularz w interfejsie.

4.2 Weryfikacja pierwszych 6 godzin

1. Crawl produkcyjny nowej domeny (Screaming Frog) — spot check TOP 50 URL-i: 200 status, canonical poprawny, H1 poprawny.
2. Test 100 losowych URL-i starych → 301 → nowe URL-e (curl + oczekiwany status 301).
3. Test poprzez VPN z 3 lokalizacji (USA, EU, Azja) – propagacja DNS kompletna.
4. GA4 real-time: ruch widoczny, konwersje rejestrowane.
5. Search Console URL Inspection dla TOP 10 URL-i – „URL is available to Google” lub „Crawled – currently indexed” po 24–72h.
6. Monitoring logów serwera: wolumen 404 < 1% requestów, 5xx = 0.

Faza 5 – Monitoring post-launch (12 punktów)

Pierwsze 60 dni to krytyczny okres. Większość problemów objawia się w dniach 3–21; pełny recovery (gdy migracja przebiegła bez błędów) zwykle 60–120 dni.

5.1 Tydzień 1

1. Dzienny raport: ruch organiczny, Ads konwersja, indexed URLs (GSC).
2. Crawl porównawczy co 48h – różnica < 1% URL-i z problemami.
3. Spot check 20 losowych zapytań SERP – pozycje stabilne lub z maksymalnie 3-pozycyjnym swingiem.
4. Logi serwera: rejestrowane wszystkie 404 → następny dzień → dodane do mapy 301 lub naprawione.

5.2 Tydzień 2–4

1. Tygodniowy raport ruchu vs baseline – akceptowalny spadek: do 15% tymczasowo w tygodniu 2, recovery od tygodnia 3.
2. Rebuilding internal links: strony, które miały wiele backlinków, dostają priorytetową obsługę (internal link boost).
3. Re-submit sitemap co 7 dni przez pierwszy miesiąc — wymusza ponowny crawl.
4. Disavow file review – jeśli stara domena miała disavow, aktualizacja pod nową.
5. Outreach do top 20 domen linkujących: prośba o aktualizację linków (stare 301 działa, ale direct link zachowuje pełne equity).

5.3 Miesiące 2–4

1. Miesięczny raport: ruch, rankingi top 100 keywordów, indexed URLs, backlinki.
2. Ranking recovery: 85% kluczowych pozycji powinno wrócić w ciągu 60 dni, 95% w ciągu 120.
3. Jeśli > 20% ruchu niepowrócone w dniu 90 – audyt naprawczy (patrz Faza 6).

Faza 6 – Recovery (10 punktów)

Plan B uruchamiany tylko jeśli recovery nie przychodzi naturalnie. Większość projektów tej fazy nie potrzebuje — wymagana jest u ~15% migracji.

1. Audyt przyczynowy: identyfikacja TOP 20 URL-i ze spadkiem ruchu > 40%.
2. Dla każdego URL-u: sprawdzenie 301, canonical, H1, title, treści, internal links, backlinks.
3. Tracing ścieżki crawlera: plik logów serwera za ostatnie 30 dni, porównanie z GSC coverage.
4. Identyfikacja „straconych” URL-i: były w indexie przed, nie są teraz, brak w mapie 301.
5. Restore treści, jeśli „stracony” URL miał backlinki – przywrócenie pod nowym adresem z 301 z pierwotnego (nawet post factum).
6. Content refresh: URL-e ze spadkiem pozycji > 10 dostają aktualizację treści (dodatkowe akapity, świeże dane, 2026 w title).
7. Link building uzupełniający: 5–10 nowych backlinków z wysokiej jakości źródeł na URL-e krytyczne.
8. Re-indexing request w GSC dla naprawionych URL-i (limit 10/dzień, priorytet dla ruchowych).
9. Jeśli problem systemowy (> 30% ruchu nieodzyskanego w miesiąc 3): rozważyć konsultację zewnętrzną (koszt 3 000–12 000 PLN za audyt).
10. Post-mortem raport po zakończeniu recovery: co poszło nie tak, jak uniknąć w następnej migracji.

Porównanie: migracja self-service vs z agencją

Aspekt	Self-service (team in-house)	Agencja SEO	Rekomendacja
Koszt bezpośredni	0–5 000 PLN (narzędzia)	8 000–45 000 PLN	Zależy od wielkości serwisu
Czas realizacji	8–14 tygodni (bez doświadczenia)	3–6 tygodni	Agencja przy tight deadline
Ryzyko spadku > 20%	40–55%	5–12%	Agencja dla serwisu > 50 000 sesji/mies.
Koszt potencjalnej utraty ruchu	Wysoki (bez safety net)	Niski (SLA, audyt recovery w cenie)	Agencja przy > 100 tys. PLN/mies. przychodu
Wiedza pozostająca w firmie	Wysoka	Niska (bez handoff)	Self-service dla edukacji zespołu
Serwis < 500 URL-i	Wykonalne	Overkill	Self-service + konsultacja 1500–3000 PLN
Serwis 5 000+ URL-i	Ryzyko krytyczne	Zasadne	Agencja specjalizująca się w migracjach

Najczęstsze błędy w migracji

Osiemdziesiąt procent strat ruchu wynika z dwunastu typowych błędów. Lista poniżej jest posortowana od najczęstszego do najrzadszego.

• Mapa 301 niepełna – pokrycie < 95% URL-i z ruchem. Rozwiązanie: crawl + GSC + GA4 join, weryfikacja na samplu 5% URL-i losowo.
• Łańcuchy 301 – A→B→C zamiast A→C. Każdy dodatkowy hop to 3–15% utraty link equity. Rozwiązanie: spłaszczenie map przed launchem.
• Wewnętrzne linki wskazujące na stare URL-e – nawet z 301 traci się wartość i slow crawling. Rozwiązanie: search-replace w bazie danych CMS.
• Brak change of address w GSC – opóźnia transfer signals o 2–4 tygodnie. Formularz dostępny w interfejsie GSC, wymaga potwierdzenia obu property.
• Staging publicznie dostępny – duplikaty w indeksie Google, spadki rankingu obu domen. Rozwiązanie: basic auth + noindex + disallow.
• Backups brakujące – rollback niemożliwy w razie problemów. Minimum: pełny dump bazy i plików na 48h przed launchem.
• Zmiana struktury URL podczas rebrandingu — dwie zmiany naraz mnożą ryzyko. Rozwiązanie: najpierw rebranding (301 1:1), potem zmiana struktury w kolejnym kwartale.
• Brak monitoringu 404 po launchu — user experience się psuje, Google zauważa. Narzędzia: Screaming Frog, serwerowe logi, GSC Coverage.
• Zmiana title i meta w tym samym dniu co launch — podwójny szok dla Google. Rozwiązanie: content zamrożony 14 dni przed i 30 dni po.
• Ignorowanie hreflang dla multi-language – spadek rankingów w wersjach językowych. Rozwiązanie: regenerowanie hreflang z absolute URLs pod nową domeną.
• Brak outreach do top backlinków – direct link ma więcej wartości niż 301-jacketed. Rozwiązanie: top 20 domen linkujących kontaktowane w tygodniu +2.
• Wyłączenie starej property GSC zbyt szybko – traci się dane o crawl error, coverage. Rozwiązanie: stara property aktywna minimum 180 dni po migracji.

Narzędzia niezbędne do migracji

Lista wymaganego stacka narzędziowego. Wszystkie mają wersje darmowe lub trial wystarczające na jeden projekt migracji.

• Screaming Frog SEO Spider (259 GBP/rok) — crawl pełnego serwisu, eksport URL-i, identyfikacja issues. Wersja free do 500 URL-i.
• Ahrefs / Semrush (200–400 USD/mies.) — backlinki, rankingi, konkurencyjne zapytania. Można ograniczyć do jednego na migrację (trial 7–14 dni).
• Google Search Console (free) – niezbędne dla submitowania sitemap, change of address, coverage monitoring.
• Google Analytics 4 (free) – baseline ruchu, konwersje.
• Serwerowe logi (free – konfiguracja po stronie hostingu) – weryfikacja Googlebot crawl pattern, 404 detection.
• Plugin Redirection (WordPress) lub Rank Math redirects – do mapy 301, wygodniejsze niż htaccess dla zespołów non-dev.
• SSLLabs (free) — test certyfikatu SSL po launchu.
• PageSpeed Wnioski + CrUX (free) – Core Web Vitals baseline i monitoring.
• DNSChecker.org (free) – weryfikacja propagacji DNS z wielu lokalizacji.
• Wayback Machine (free) – archiwizacja stanu przed migracją.

Timeline 10-tygodniowy: plan idealny

Tydzień	Fazy	Kluczowe wyniki
−10	Audyt pre-migration	Baseline ruchu, lista URL-i, backlinks CSV
−8	Planowanie, mapa 301 v1	Mapa 301 dla 100% URL-i priorytetu A
−6	Staging, implementacja techniczna	Staging działa, test 301 na 100 URL-ach
−4	Testy, QA, dopracowanie	Lista wszystkich bugów zamknięta, CWV ≥ baseline
−2	Komunikacja, freeze content	Email do klientów wysłany, zespół on-call ustalony
−1	DNS TTL 300s, backup full	Backup dostępny, TTL zmniejszony
0 (launch)	Go-live	DNS przełączony, sitemap submitted, change of address
+1	Monitoring intensywny	Dzienny raport, crawl co 48h, 404 zero
+2 do +4	Monitoring tygodniowy	Rankings recovery startuje, outreach backlinks
+8 do +12	Full recovery	95% pozycji wróciło, post-mortem raport

Specyficzne scenariusze migracji

Zmiana CMS (np. WordPress → Shopify)

• Struktura URL typowo się zmienia — mapa 301 manual dla 100% URL-i z ruchem, nie regex-based.
• Meta tags (title, meta description) muszą być migrowane — Shopify nie odtworzy ich z WP automatycznie.
• Redirects w Shopify: plugin „Shopify Redirects” lub app Easy Redirect.
• Obrazy – re-upload z zachowaniem alt text (Shopify ma różną ścieżkę CDN).

Fuzja serwisów (2 domeny → 1)

• Dla każdego URL-u ze starej domeny B: mapping 1:1 do URL-u w A, lub do kategorii A (jeśli brak odpowiednika).
• Duplicate content: consolidation ze zmienioną treścią dla unikalności – nie „merge + copy”.
• Backlinki B przenoszone: wartość przepływa przez 301, ale monitor zmian pozycji w miesiącu +2.

Rebranding (zmiana domeny, ta sama struktura)

• Najłatwiejsza migracja: mapa 301 regex-based (/old-domain/(.*) → /new-domain/$1).
• Change of address w GSC szczególnie istotny – signal brand transfer.
• Internal links update wymusza CMS search-replace (UPDATE posts SET content = REPLACE(content, 'old-domain', 'new-domain')).

Zmiana struktury URL (np. /kategoria/produkt → /produkt)

• Regex 301 + weryfikacja na samplu.
• Breadcrumb schema regenerowana — Google użyje do SERP.
• Internal links rebuild – WSZYSTKIE muszą wskazywać na nową strukturę.

FAQ – najczęstsze pytania

Jak długo trwa recovery po migracji domeny?

Typowo 60–120 dni dla serwisu wykonanego zgodnie z checklistą. Pierwsze 7 dni: możliwy spadek 10–25% ruchu, naturalny przy re-indeksowaniu. Dni 14–30: zwykle 80–90% ruchu powraca. Dni 60–90: 95% pozycji stabilizuje się. Dni 120+: pełny recovery, czasem z wyższym rankingiem niż przed (jeśli nowa struktura lepsza). Pełny recovery < 30 dni jest rzadki i wskazuje, że migracja była drobna (np. same domain, sub-path change). Migracje platformowe (WP → Shopify, rebranding) typowo 90–150 dni do pełnej stabilizacji. Krytyczne: spadek > 30% po 60 dniach oznacza błąd w migracji i wymaga audytu naprawczego (faza 6 checklisty). Pełen obraz tematu znajdziesz w kompletnym przewodniku biblioteka zasobów marketingu cyfrowego 2026.

Czy można migrować domenę bez utraty ruchu?

Tak, ale wymaga dyscypliny i minimum 8 tygodni przygotowania. Realne case study: serwis e-commerce 30 000 URL-i, migracja WordPress → Magento 2, spadek w dniach 1–14: maksymalnie 8%, recovery w dniu 30 do 102% baseline. Kluczowe czynniki: mapa 301 pokrycie 100% URL-i z ruchem, wewnętrzne linki zaktualizowane w CMS, change of address w GSC, outreach do top 30 backlinków. Dla serwisów < 1000 URL-i z prostą strukturą i doświadczonym zespołem: spadek < 5% jest realistyczny. Dla dużych, z wieloma językami i zmienną strukturą URL: spadek 10–20% tymczasowy jest normą, recovery 90 dni.

Kiedy używać 301 vs 302 podczas migracji?

Dla migracji domeny/struktury URL: ZAWSZE 301 (permanent). 302 (temporary) informuje Google, że zmiana jest tymczasowa – link equity nie przepływa, stary URL pozostaje w indeksie. Wyjątek: 302 jest OK tylko dla (a) A/B testów trwających do 2 tygodni, (b) tymczasowych landing pages kampanijnych, (c) rotacji serwera przez load balancer. Jeśli 302 utrzymuje się > 30 dni, Google zacznie traktować go jak 301 – ale dodatkowe opóźnienie może kosztować tygodnie rankingu. Standard dla migracji: 301 w HTTP response, w header Location: https://nowa-domena.pl/nowa-sciezka/. Dla JavaScript redirects: niedozwolone w migracji – Googlebot je respektuje, ale z opóźnieniem i niższą wagą niż server-side 301.

Ile kosztuje profesjonalna migracja domeny?

Dla serwisu 500–1500 URL-i: 8 000–15 000 PLN za projekt agencyjny (audyt, plan, nadzór launch-u, monitoring 30 dni). 1500–5000 URL-i: 15 000–25 000 PLN. 5 000–20 000 URL-i: 25 000–45 000 PLN. Serwis powyżej 20 000 URL-i (duży e-commerce, news portal): 45 000–120 000 PLN, zwykle z dedykowanym zespołem 2–3 osób przez 10–14 tygodni. Self-service: 3 000–8 000 PLN (narzędzia + czas in-house 120–300 godzin). Alternatywa: konsultacja jednorazowa (2 000–5 000 PLN) + self-service realizacja – dobre dla zespołu, który ma bazę techniczną, ale brak doświadczenia migracyjnego. Koszt ukryty to nieudana migracja: dla serwisu 100 000 sesji/mies. 20% spadek = 240 000 PLN straty rocznej przy CPC 10 PLN.

Czy trzeba migrować wszystkie stare URL-e?

Nie — ale selektywne podejście wymaga świadomej decyzji. Minimum do mapy 301: (a) URL-e z ruchem > 10 sesji/mies. w ostatnich 12 miesiącach, (b) URL-e z backlinkami zewnętrznymi (niezależnie od ruchu), (c) URL-e w top 100 najczęściej linkowanych wewnętrznie. Dla reszty (przestarzałe artykuły bez ruchu, bez linków) — akceptowalny jest 410 Gone (usuwa z indeksu świadomie) lub przekierowanie do kategorii rodzica. Powszechny błąd: 301 starych tag-ów lub paginacji do strony głównej — Google to ignoruje, traktując jako soft 404. Dla przestarzałych: 410 lepsze niż 301 do strony głównej. Gdy skala jest bardzo duża (serwis newsowy 100 000+ archiwalnych URL-i), consolidation 301 na kategorii tematycznej z wyraźnym content upgrade jest akceptowalna.

Co robić jeśli ruch spadł > 30% po 30 dniach?

Natychmiastowa diagnostyka: (1) Crawl nowej domeny + porównanie z mapą 301 — weryfikacja, czy wszystkie 301 działają i zwracają status 301 (nie 302, 307, 404). (2) GSC Coverage: ile URL-i indexed vs excluded – „Excluded by noindex” > 5% = błąd w noindex lub robots.txt. (3) URL Inspection dla TOP 20 straconych URL-i – sprawdzenie, czy Googlebot widzi redirect i czy nowa treść jest indeksowana. (4) Porównanie Core Web Vitals: nowa domena > baseline = signal downgrade. (5) Logi serwera: czy Googlebot ciągle crawl-uje? Jeśli wolumen crawl spadł > 50% – problem z robots.txt, sitemap, lub 5xx errors. Typowe znaleziska: łańcuchy 301 (A→B→C), internal links wskazujące na 301-ed URL-e (wolne transfer), staging nadal dostępny publicznie. Recovery po naprawieniu: 2–4 tygodnie dla typowych błędów, 6–8 tygodni dla problemów systemowych (np. CWV).

Jak komunikować migrację do użytkowników i klientów?

Email do klientów B2B i subscriberów newslettera 7–14 dni przed: wyjaśnienie powodu (rebranding, technologia, konsolidacja), data przełączenia, konkretne implikacje (np. „zmieni się adres strony kontaktowej z X na Y”), CTA (aktualizuj bookmarki, sprawdź stan integracji jeśli jesteście partnerem). Dla serwisów konsumenckich: banner na starej stronie 3–7 dni przed, z informacją „Przechodzimy pod nowy adres: [nowa-domena]. Link kliknij, aby zaktualizować zakładkę”. Jeśli migracja ma downtime (np. 30 min): komunikat „Serwis chwilowo niedostępny. Wróć za 30 minut.” — nie 503 bez wyjaśnienia. Social media: post dzień launch-u, z nowym adresem. PR komunikat (dla większych marek): 1–3 dni po launchu, z fokusem na biznesowe korzyści zmiany, nie technikę. Dla SEO: minimalny negatywny impact na komunikacji, maksymalny pozytywny: każdy link z artykułu PR to natural link-building.

Co dalej

Checklist migracji to jeden z fundamentów biblioteki procesów SEO. Jeśli Twój projekt rozpoczyna się od audytu diagnostycznego – sięgnij po 80-punktową checklistę audytu SEO, która pomoże ustalić stan wyjściowy. Dla świeżo uruchamianych serwisów po migracji warto zajrzeć do 47-punktowej checklisty uruchomienia bloga firmowego — opisuje, jak zbudować warstwę contentową na nowej domenie od podstaw. Strategia, w której migracja to tylko jeden z elementów rocznego planu contentowego, znajduje się w szablonie strategii contentowej (Notion). Katalog wszystkich checklist i szablonów – w bibliotece zasobów marketingu cyfrowego 2026. Każda pozycja została skalibrowana na realnych projektach, dlatego liczby w punktach kontrolnych są konkretne, nie życzeniowe.