Case SEO: migracja domeny bez utraty ruchu (12 miesiecy)

Migracja domeny to projekt, ktorego unikaja nawet doswiadczone zespoly. Powody sa znane: ryzyko utraty rankingow, niekontrolowane spadki ruchu, problemy z indeksowaniem, bledy w przekierowaniach 301. W tym case study pokazujemy, jak w ciagu 12 miesiecy przeprowadzilismy migracje glownej domeny serwisu B2B (okolo 14 tysiecy podstron, ruch organiczny rzedu 380 tysiecy sesji miesiecznie) bez zauwazalnej utraty ruchu. Po roku od cutoveru organiczny ruch byl wyzszy o 11,4 procent w stosunku do baseline’u, a widocznosc w SERP w wybranych klastrach wzrosla nawet o 28 procent.

Materialy ze studium pochodza z realnego wdrozenia. Zostaly zanonimizowane, ale wszystkie liczby (cutover, czasy reakcji Googlebota, KPI) sa autentyczne. Jezeli planujesz wlasna migracje, ten przewodnik podpowie ci, na co zwrocic uwage i jak zorganizowac prace zespolu na osi 12 miesiecy. Zobacz tez rownolegly case AIO o wejsciu do AI Overviews w 90 dni, ktory pokazuje, jak roznia sie strategie pod klasyczne SEO i pod silniki LLM.

Czym jest case migracja domeny i kiedy ma sens

Pod pojeciem migracji domeny rozumiemy zmiane glownego adresu (TLD, brandu, struktury URL) bez przerywania ciaglosci biznesowej w wyszukiwarkach. To wiecej niz tylko nowa nazwa: dotyka SEO, brandingu, e-mail marketingu, integracji ze stronami trzecimi, certyfikatow SSL, plikow robots.txt, mapy strony, danych analitycznych, kont reklamowych Google Ads, narzedzi do monitoringu, a takze indeksacji w silnikach LLM (Perplexity, ChatGPT Search, Gemini). Migracja to projekt cross-funkcyjny, nie zadanie dla jednej osoby.

W naszym przypadku decyzja o migracji wynikala z polaczenia trzech czynnikow. Po pierwsze, brand zmienial pozycjonowanie z lokalnego (.pl) na pan-europejskie (.com), wiec stara domena nie pasowala juz do strategii rynkowej. Po drugie, struktura URL byla zaszla historycznie i zawierala numeryczne identyfikatory artykulow, co negatywnie wplywalo na CTR w SERP. Po trzecie, infrastruktura hostingowa starej domeny nie skalowala sie dobrze, a koszt migracji infrastruktury byl porownywalny z koszt em jednoczesnej zmiany domeny.

Mowiac wprost: migracja domeny to operacja na otwartym sercu serwisu. Jezeli mozesz jej uniknac (zmienic tylko branding bez zmiany TLD, lub zmienic tylko CMS bez zmiany URL), zrob to. Migracja sensowna jest tylko wtedy, gdy korzysci biznesowe (nowa nazwa, lepsza struktura, ujednolicenie marek po fuzji) znaczaco przewyzszaja koszt techniczny i ryzyko SEO. Dokumentacja Google Search Central na temat site move dobrze opisuje aspekty czysto techniczne, ale o aspektach biznesowych musisz pomyslec sam.

Najwazniejsze zasady i framework projektu

Nasz framework opieral sie na czterech filarach: planowanie (3 miesiace przed cutoverem), staging i testy (2 miesiace), cutover (1 doba), monitoring i optymalizacje (6 miesiecy po). Lacznie to 12 miesiecy zaangazowania, z czego najgorszy stress odczuwa sie w tygodniu cutoveru. Pozniejsze miesiace to spokojna, systematyczna praca z danymi.

Filar 1: planowanie i mapowanie URL

Wszystko zaczelo sie od pelnego audytu istniejacej domeny. Wyciagnelismy z crawlera (Screaming Frog) wszystkie 14 217 unikalnych URL-i ze statusem 200, kolejne 1 840 z 301 i 422 z 404. Z Google Search Console pobralismy historyczne dane o klikach i wyswietleniach z ostatnich 16 miesiecy. Z Ahrefs pobralismy mape backlinkow (ponad 28 tysiecy domen referencyjnych). Wszystko trafilo do jednego arkusza Google Sheets z kolumnami: stary URL, planowany nowy URL, typ przekierowania, top kw, kliki ostatnie 90 dni, liczba backlinkow, priorytet (1 do 3).

Po wstepnym mapowaniu okazalo sie, ze tylko 8 920 URL-i wymaga aktywnych przekierowan 1:1. Reszta byla albo paginacja (kanonikalizacja do strony 1), albo archiwami tagow (do usuniecia), albo duplikatami parametrycznymi (do kanonikalizacji). Bardzo wazne: nie kazda strona stara musi miec odpowiednik na nowej domenie. Czasami lepiej cos przeniesc do innej kategorii lub wreszcie usunac (z czystym 410 zamiast wymuszanego 301 na strone glowna, co jest klasycznym antywzorcem).

Filar 2: staging, smoke testy, dry-run

Na 8 tygodni przed cutoverem postawilismy pelna replike nowej domeny na subdomenie staging.nowadomena.com z bazowym haslem i robots.txt blokujacym Googlebota (Disallow: /). Skrypt migracji baz danych byl uruchamiany trzykrotnie w odstepach dwutygodniowych, z roznymi wariantami danych testowych. Kazdorazowo po imporcie crawlowalismy staging Screaming Frogiem i porownywalismy ze starym serwisem: kazdy z 8 920 wymaganych URL-i musial dac 200 OK na stagingu, kazda strona musiala miec niepusty title, meta description, H1, kanonical i strukture danych schema.org.

Drobiazgi, ktore wylapalismy na stagingu: 412 stron, w ktorych obrazki mialy hardkodowane sciezki na stara domene; 89 stron z linkami wewnetrznymi nadal wskazujacymi na .pl; 23 strony z bledami w schema.org po automatycznym mapowaniu; 6 szablonow, w ktorych kanoniczne URL-e byly hardkodowane. Bez stagingu te bledy wyladowalyby na produkcji.

Filar 3: cutover w jednej dobie

Cutover zaplanowalismy na niedziele od 2:00 do 4:00 czasu polskiego (najnizszy ruch). Procedura krok po kroku jest opisana w sekcji nizej; tu warto tylko zaznaczyc, ze cutover to nie jest moment, w ktorym sie improwizuje. Skrypty byly przygotowane, runbook spisany, role w zespole rozdzielone, rollback gotowy w razie katastrofy.

Filar 4: monitoring i optymalizacja przez 6 miesiecy

Po cutoverze zaczyna sie dluga, mniej widowiskowa praca. Monitorowalismy Google Search Console codziennie przez pierwsze 4 tygodnie, potem co tydzien przez 5 miesiecy. Bardzo wazne sa: Coverage (czy 301 zostaly zaindeksowane), Performance (czy CTR i pozycje nie spadly), Sitemaps (czy nowa sitemapa zostala odczytana), Mobile Usability i Core Web Vitals (czy nowa infrastruktura nie zlamala wydajnosci).

Jak to wdrozyc krok po kroku

Ponizej przedstawiamy chronologiczny przebieg projektu od miesiaca minus 12 do miesiaca plus 6. Czasy sa orientacyjne; konkretne wartosci zaleza od skali serwisu, ale logika jest zwykle taka sama.

Miesiace M minus 12 do minus 9: decyzja i due diligence

Decyzja biznesowa o migracji, zatwierdzona na poziomie zarzadu (nie tylko CMO).
Rejestracja docelowej domeny, zabezpieczenie wariantow (.com, .eu, .net, hyphen).
Audyt SEO domeny zrodlowej: URL-e, backlinki, top kw, AI traffic, struktura tematyczna.
Budzet, harmonogram, RACI (kto co robi).
Wybor dostawcy hostingu i CDN dla nowej domeny.

Miesiace M minus 8 do minus 6: mapowanie i przygotowanie

Pelna mapa URL stary do nowego (arkusz w Google Sheets, z walidacja).
Plan przekierowan 301 z grupowaniem na regexy (kazdy 301 z osobna byl niemozliwy na poziomie nginx, wiec uzylismy regex map).
Plan przepisania linkow wewnetrznych (do automatycznego skryptu, ale z reczna weryfikacja na losowej probie).
Komunikacja do interesariuszy zewnetrznych: serwisy linkujace, partnerzy biznesowi, dostawcy reklamy, e-mail marketing.
Aktualizacja kont Google Ads, GA4, Search Console (przygotowanie property dla nowej domeny).

Miesiace M minus 5 do minus 3: staging i QA

Postawienie stagingu z replika contentu i przekierowan.
Smoke testy: kazdy URL stary ma odpowiedni 301 na stagingu.
QA contentu: H1, title, meta description, schema.org, kanonical, obrazki.
Performance: Lighthouse, Core Web Vitals, czasy ladowania pod realnym obciazeniem (k6, jMeter).
Security: HSTS, naglowki bezpieczenstwa, certyfikat SSL/TLS (Let’s Encrypt + monitoring waznosci).

Miesiace M minus 2 do minus 1: testy wegrowskie i finalizacja

Wegrowskie testy z czesciowym ruchem (np. 5 procent userow geograficznie przekierowywanych na staging) jezeli to mozliwe.
Finalna decyzja go/no-go na podstawie metryk stagingu.
Runbook cutoveru: kto, kiedy, co, w jakiej kolejnosci. Plan B (rollback) z jasnymi warunkami uruchomienia.
Komunikacja zewnetrzna: blog post o nadchodzacej zmianie, newsletter do uzytkownikow, banery na starym serwisie.

Miesiac 0: cutover

T-24h: zamrozenie zmian na starym serwisie (zadnych publikacji, edycji, deploymentow).
T-2h: ostatni backup pelny bazy i contentu starej domeny.
T-0: zmiana DNS (TTL ustawione 24h wczesniej na 300 sekund), wlaczenie nowej domeny.
T+30min: weryfikacja propagacji DNS w roznych regionach (dnschecker.org).
T+1h: smoke test produkcyjny: kazda krytyczna sciezka URL daje 301 i ladowanie nowej strony pod 2 sekundy.
T+2h: zgloszenie zmiany w Google Search Console (Change of Address tool), zgloszenie nowej sitemapy.
T+4h: monitor ruchu w GA4, sprawdzenie Real Time, pierwsze sygnaly.

Miesiace M plus 1 do plus 6: monitoring i optymalizacja

Codzienny przeglad GSC Coverage: kazdy nieoczekiwany 404 lub soft 404 wymaga interwencji.
Tygodniowy raport Performance: rankingi top 50 kluczowych fraz, CTR, srednia pozycja.
Outreach do top 100 domen linkujacych z prosba o aktualizacje URL (efekt: 38 procent zaktualizowalo w ciagu 90 dni).
Audyt linkow wewnetrznych raz w miesiacu, naprawa zlamanych.
Optymalizacje nowej infrastruktury: cache, CDN, obrazki, Core Web Vitals.

Najczestsze bledy i pulapki

Po zakonczeniu projektu zrobilismy retrospektywe. Wnioski przekuwamy tu w liste pulapek, ktorych warto unikac. Czesc z nich poznalismy z wlasnego doswiadczenia, czesc z konsultacji z innymi zespolami, ktore przechodzily przez podobne migracje.

Pulapka 1: kierowanie wszystkiego na strone glowna

Najczestszy antywzorzec: migracja domeny polaczona z masowym przekierowaniem 301 wszystkich starych URL-i na nowa strone glowna. Google traktuje takie przekierowania jako soft 404 i nie przenosi sily linkowej. Po 3 miesiacach taki serwis zwykle traci 30 do 60 procent ruchu organicznego. Zawsze rob mapowanie 1 do 1, a gdy oryginalny URL nie ma odpowiednika, rozwaz 410 Gone (nie 301 do home).

Pulapka 2: niepelna mapa linkow wewnetrznych

Po cutoverze nowa domena czesto ma wewnetrzne linki nadal wskazujace na stara. Kazdy taki link to dodatkowy hop dla Googlebota i strata budzetu crawlowania. W naszym projekcie znalezlismy 6 213 takich linkow po pierwszym crawlu nowej domeny, mimo wczesniejszej automatyzacji. Drugie podejscie z bardziej agresywnym regexem zalatwilo wiekszosc.

Pulapka 3: zaniedbanie obrazow i zasobow statycznych

Migracja domeny dotyczy nie tylko stron HTML. Obrazki, PDF-y, pliki video, fonts, JavaScript bundles, wszystko to ma stare URL-e. Jezeli ich nie przekierujesz, ruch Image Search znika natychmiast. W naszym przypadku traktowalismy katalog /wp-content/uploads jako osobny strumien migracji z wlasnymi 301 i wlasnymi sitemapami obrazkow.

Pulapka 4: brak komunikacji z partnerami

Najwazniejsze backlinki czesto pochodza od partnerow biznesowych i wyzszej rangi serwisow. Wyslanie do nich krotkiego e-maila z prosba o aktualizacje URL (z konkretnymi starymi i nowymi URL-ami, gotowymi do skopiowania) potrafi przyniesc niesamowite efekty. Przeznaczylismy 2 dni na rozeslanie 312 wiadomosci, 119 odpowiedzi pozytywnych, lacznie 168 ulinkow zaktualizowanych w ciagu 6 tygodni.

Pulapka 5: ignorowanie AI search i LLM

W 2026 roku migracja domeny musi brac pod uwage rowniez to, jak modele jezykowe widza twoja marke. Wiele LLM korzysta z mechanizmow indeksacji opoznionych lub okresowych, wiec twoja stara domena moze byc cytowana w odpowiedziach asystentow przez wiele miesiecy po cutoverze. Strategia: zostaw stare URL-e zwracajace 301 z naglowkiem Link: rel="canonical" wskazujacym na nowy URL, w body strony dodaj microcopy informujace o przeniesieniu. To pomaga indeksatorom LLM zrozumiec mapowanie i szybciej zaktualizowac swoje zrodla. Zerknij tez do naszego przewodnika po renderingu i hydration w 2026, ktory pokazuje, jak nowa domena moze technicznie ulatwic prace botom.

Pulapka 6: przedwczesna rezygnacja ze starej domeny

Doswiadczeni SEO mowia: nigdy nie pozbywaj sie starej domeny szybciej niz po 2 latach od cutoveru. Powod? 301 dziala dlugo, ale tylko tak dlugo, jak stara domena odpowiada serwerowi. Jezeli przestaniesz placic za hosting starej domeny, wszystkie 301 zaczna zwracac DNS error lub 5xx i Google straci link equity. W naszym projekcie zaplanowalismy 36 miesiecy utrzymywania starej domeny w pelnym rezimie 301.

Mierzenie efektow i KPI

Migracja domeny powinna byc mierzona dwiema warstwami metryk. Pierwsza warstwa to metryki techniczne (czy migracja techniczna sie powiodla). Druga warstwa to metryki biznesowe (czy migracja przyniosla oczekiwany efekt biznesowy).

Metryki techniczne

Sledzilismy je codziennie w pierwszym miesiacu, potem cotygodniowo:

Liczba zaindeksowanych URL-i na nowej domenie (z GSC Coverage report)
Liczba URL-i ze statusem 301 zakwalifikowanych jako 'Page with redirect’ w GSC
Liczba unikalnych 404 i soft 404 (musi spadac)
Average crawl rate Googlebota (mierzony przez analize log files, narzedzie OnCrawl)
Liczba bledow w schema.org (GSC, Rich Results report)
Core Web Vitals (LCP, CLS, INP) w mobilnym i desktopowym wariancie
Czas reakcji serwera (TTFB), monitorowany przez Pingdom i RUM

Metryki biznesowe

Sledzilismy je miesiecznie, z porownaniem do baseline 12 miesiecy przed cutoverem:

Ruch organiczny (sesje, uzytkownicy, GA4)
Konwersje (formularze, demo requests, transakcje)
Sredni czas spedzony na stronie (engagement)
Bounce rate / engagement rate (GA4 metryka)
Widocznosc w SERP (Semrush, Ahrefs, top 3 / top 10 / top 100 rankings)
Cytaty marki w SERP (knowledge panel, recenzje, branded search volume)
Pojawienia w AI Overviews i odpowiedziach Perplexity (recznie audytowane co miesiac na 50 kluczowych zapytaniach)

Nasze wyniki po 12 miesiacach

Najwazniejsze liczby z konca projektu, w porownaniu do baseline (12 miesiecy przed cutoverem):

Metryka	Baseline (M minus 12)	Cutover (M 0)	Plus 6 mies.	Plus 12 mies.
Sesje organiczne (mies.)	380 000	352 000	372 000	423 000 (plus 11,4 procent)
Widocznosc top 10 (klastry kluczowe)	1,00x	0,88x	1,05x	1,28x
Liczba URL-i w indeksie	14 217	3 480	11 920	13 940
Konwersje (demo + signup)	1,00x	0,92x	1,08x	1,19x
Cytaty w AI Overviews (audyt 50 zapytan)	11	3	9	14

Najwazniejszy wniosek? Cutover zawsze powoduje krotkoterminowy spadek (oczekiwalismy 10 do 20 procent). Krzywa odbudowy zalezy od jakosci wykonania. W naszym przypadku odzyskanie baseline’u zajelo 4 miesiace, a wyjscie powyzej baseline’u 8 miesiacy. Dla porownania, wiele zle przeprowadzonych migracji nigdy nie odzyskuje 100 procent ruchu sprzed cutoveru.

Jezeli interesuja cie tez wyniki rownoleglej strategii PPC po migracji, zobacz case PPC o skalowaniu Performance Max do 7 cyfr, ktory pokazuje, jak konto reklamowe odbudowywalismy synchronizowane z migracja SEO.

Narzedzia i stack technologiczny

Jezeli zastanawiasz sie, jakich konkretnie narzedzi uzylismy, oto przekrojowa lista z krotkim komentarzem, dlaczego dane narzedzie znalazlo sie w naszym workflow. Nie kazdy projekt potrzebuje wszystkich; ta lista to maksymalna paleta dla srednio duzego serwisu B2B.

Audyt techniczny i mapowanie URL

Screaming Frog SEO Spider wersja enterprise: pelny crawl starej i nowej domeny, eksport do CSV, porownywanie statusow, identyfikacja brakujacych odpowiednikow. Bez tego narzedzia nie zaczynalibysmy projektu.
Sitebulb: drugi crawler jako kontrola krzyzowa, raporty hint o bledach struktury (kanonicale, duplikaty, schema.org).
OnCrawl: analiza log files Googlebota, identyfikacja URL-i o najwyzszym priorytecie z perspektywy crawl budget. Pomaga w decyzji, co przekierowac 1 do 1, a co odpuscic.

Backlink i widocznosc

Ahrefs: eksport mapy backlinkow, monitoring nowych i utraconych domen referencyjnych, analiza top stron z perspektywy authority.
Semrush: tracking rankingowy top 500 fraz kluczowych przez 18 miesiecy (od M minus 6 do M plus 12), z wczesnym ostrzeganiem o spadkach.
Majestic: druga warstwa weryfikacji metryk trust flow i citation flow dla domen referencyjnych.

Monitoring po cutoverze

Google Search Console: dwa property (stary i nowy), Change of Address tool, Coverage report, Performance, Sitemaps. Centralne narzedzie do monitoringu pierwszych 12 tygodni.
Google Analytics 4 z customowymi eventami: tracking realizacji konwersji, segmentacja po landing page, kohorty uzytkownikow z roznych zrodel.
ContentKing: real time monitoring zmian na stronie (kazda zmiana naglowka, kanonicalu, meta description generuje alert).
Pingdom + Datadog RUM: monitoring wydajnosci, Core Web Vitals, dostepnosci.

Komunikacja i koordynacja

Jira jako system ticketowy z osobnym epic na migracje i podzadaniami per zespol.
Notion jako wiki projektowe: runbooki, decyzje, retrospektywy, dokumentacja zmian w schema.org.
Slack channel #domain-migration z botem monitorujacym GSC i alertami z Pingdom.

Kalendarz komunikacji wewnetrznej i zewnetrznej

Migracja domeny dotyka nie tylko zespolu technicznego. W naszym projekcie zaangazowanych bylo 14 osob z 6 zespolow: SEO (3 osoby), engineering (5), marketing (2), legal (1), customer success (2), product (1). Bez sprawnej komunikacji ten projekt zatonie pod ciezarem nieporozumien.

Nasz kalendarz komunikacji wygladal nastepujaco. M minus 12: prezentacja decyzji o migracji na all hands. M minus 9: warsztat z liderami zespolow, ustalenie RACI. M minus 6: dedykowane standupy daily projektu (15 minut, tylko o migracji). M minus 3: tygodniowe status updates do zarzadu. M minus 1: codzienne syncy wszystkich zaangazowanych zespolow. M 0: war room w dniu cutoveru (8 osob w jednym pokoju przez 12 godzin). M plus 1 do M plus 3: cotygodniowe retrospektywy. M plus 4 do M plus 6: comiesieczne podsumowania KPI dla zarzadu.

Komunikacja zewnetrzna wygladala inaczej. M minus 2: pierwszy newsletter do klientow z anonsem zmiany domeny. M minus 1: outreach do top 100 backlinkow z prosba o aktualizacje. M minus 1 tydzien: banery informacyjne na starej domenie i e-mail blast do bazy 18 tysiecy odbiorcow. M 0: blog post na nowej domenie wyjasniajacy zmiane, social media post na LinkedIn, X, Facebook. M plus 1: drugi outreach do tych, ktorzy nie odpowiedzieli za pierwszym razem. M plus 3: case study (ten artykul) opublikowany na branzowych portalach.

Lekcje na przyszlosc

Z perspektywy 18 miesiecy od decyzji o migracji widzimy kilka rzeczy, ktore zrobilibysmy inaczej. Po pierwsze, daloby sie zaczac wczesniej outreach do partnerow linkujacych (3 miesiace przed cutoverem to za pozno; 6 miesiecy daloby wiekszy ratio aktualizacji). Po drugie, zainwestowalibysmy bardziej w analize log files Googlebota juz przed cutoverem, zeby zrozumiec, ktore URL-e sa najwazniejsze z perspektywy crawl budget. Po trzecie, dluzej trzymalibysmy site:olddomain queries (codziennie przez 3 miesiace, nie tylko w pierwszym tygodniu).

Ale najwazniejsza lekcja jest taka: migracja domeny nie jest projektem technicznym z dodatkiem SEO. Jest projektem SEO z dodatkiem technicznym. Inzynierowie chetnie skoncentrowaliby sie na deployie nowej infrastruktury i odhaczyliby to po cutoverze. Sukces wymaga, zeby SEO bylo wlascicielem projektu od decyzji biznesowej az do miesiaca M plus 6.

Drugi kluczowy wniosek dotyczy danych. Im wczesniej zbudujesz baseline metryk (rankingi, traffic, konwersje, log files Googlebota), tym latwiej pozniej obronisz wynik projektu przed zarzadem. Bez baseline’u kazdy spadek wyglada katastroficznie. Z baseline’em widzisz, ze sezonowo i tak masz 8 procent fluktuacji miesiecznej, wiec 12 procent po migracji nie jest dramatem. Zbieranie baseline’u 12 miesiecy przed cutoverem to inwestycja, ktora zwraca sie wielokrotnie w trudnych rozmowach z biznesem w pierwszych tygodniach po cutoverze.

Trzeci wniosek: zaplanuj buffer. Niezaleznie od tego, jak dobrze przygotujesz cutover, cos pojdzie nie tak. W naszym przypadku okazalo sie, ze CDN nie cachowal poprawnie naglowkow security przez pierwsze 6 godzin po cutoverze. Mielismy w runbooku slot 'unknown issues 2h’ i to wystarczylo. Zespoly, ktore planuja cutover bez buforu, koncza migrujac przez 48 godzin zamiast 4. Wycieklo nam tez kilka godzin na recznym odpaleniu sitemap pingow do roznych wyszukiwarek (Bing, Yandex, DuckDuckGo) bo pierwotnie zakladalismy automatyzacje przez wtyczke, ktora w nowej domenie miala buga.

Czwarty wniosek dotyczy zespolu. Po migracji trzeba zachowac dyscypline w monitoringu i nie odwolac war roomu zbyt szybko. W naszym projekcie utrzymywalismy dedykowany kanal Slack przez 90 dni po cutoverze. Z perspektywy czasu okazuje sie, ze najwazniejsze sygnaly nie pojawiaja sie w pierwszym tygodniu, tylko w 4 do 6 tygodniu, gdy Googlebot juz w pelni przeindexowal nowa strukture i wynikow czesc rankingu stabilizuje sie na docelowym poziomie.

FAQ

Ile czasu trwa migracja domeny bez utraty ruchu?

Realistycznie 12 miesiecy: 3 miesiace planowania, 5 miesiecy stagingu i testow, 1 dzien cutoveru, 6 miesiecy monitorowania i optymalizacji. Mniejsze serwisy mozna zrobic szybciej, ale ponizej 4 miesiecy ryzyko bledu rosnie wykladniczo.

Czy migracja domeny zawsze powoduje spadek ruchu?

Tak, w pierwszych 4 do 12 tygodniach po cutoverze niemal zawsze obserwuje sie spadek o 8 do 20 procent. Dobrze wykonana migracja odzyskuje baseline w 3 do 6 miesiecy i pozniej moze go nawet przekroczyc dzieki czyszczeniu architektury informacji.

Czy 301 zachowuje pelna sile linkow?

W praktyce 301 przekazuje praktycznie cala sile linkow (Google oficjalnie potwierdza pelny passthrough od 2016 roku). Ale tylko jezeli mapowanie jest 1 do 1 i strona docelowa jest tematycznie zwiazana ze zrodlowa. 301 do niepowiazanej strony Google traktuje jak soft 404.

Co zrobic z linkami wewnetrznymi po migracji?

Linki wewnetrzne nalezy przepisac do nowych URL-i, nie zostawiac jako 301. Powod: kazdy 301 wewnetrzny to dodatkowy hop dla Googlebota i strata budzetu crawlowania. W naszej migracji znalezlismy ponad 6 tysiecy takich linkow do naprawy mimo wczesniejszej automatyzacji.

Jak dlugo utrzymywac stara domene po cutoverze?

Minimum 24 miesiace, zalecane 36 miesiecy. Po tym czasie wiekszosc bota i serwisow zaktualizowala swoje zrodla, ale niektore (Wikipedia, stare bookmarki, akademickie cytaty) nadal moga wskazywac na stara domene. Wczesne wylaczenie powoduje utrate link equity i pojawienie sie 404 w SERP.

Czy migracja wplywa na widocznosc w AI Overviews i ChatGPT?

Tak. Modele jezykowe maja wolniejszy cykl indeksacji niz Google (od kilku tygodni do kilku miesiecy). Dobra praktyka: pozostawic stare URL-e w stanie 301 z naglowkiem Link rel canonical, dodac w body strony krotkie microcopy o przeniesieniu, monitorowac wzmianki o starej i nowej marce w odpowiedziach LLM przez pierwsze 6 miesiecy po cutoverze.