Case: migracja 50k URL bez straty rankingu

Migracja 50 000 URL bez utraty rankingu to jedno z najtrudniejszych zadań w SEO technicznym. W tym case study opisujemy migrację portalu e-commerce z 50 247 stronami – zmiana domeny, przebudowa architektury kategorii i przejście z HTTP na HTTPS jednocześnie. Wynik po 6 miesiącach: ruch organiczny wzrósł o 14% ponad poziom sprzed migracji, a 97% fraz z top 10 utrzymało lub poprawiło pozycje. To nie był szczęśliwy przypadek – to wynik 4-tygodniowego planowania, 847 przekierowań 301, 23 stron audytu i ciągłego monitoringu przez 180 dni po przełączeniu.

Kontekst projektu – co migrowaliśmy i dlaczego

Klient to średni sklep internetowy z elektroniką – 50 247 URL, w tym 35 000 produktów, 8 000 kategorii i podkategorii, 4 000 stron filtrów i 3 247 stron CMS (blog, FAQ, landing pages). Ruch organiczny: 180 000 sesji/miesiąc z 12 000 fraz w top 10 Google.

Trzy powody migracji jednocześnie

Klient potrzebował trzech zmian, z których każda osobno to projekt migracyjny. Decyzja o połączeniu ich w jedną migrację wynikała z rachunku ryzyka: trzy osobne migracje to trzy potencjalne spadki ruchu i 3-6 miesięcy rekonwalescencji po każdej. Jedna migracja to jeden spadek (jeśli w ogóle) i jeden okres rekonwalescencji.

1. Zmiana domeny – z brandowej ale trudnej do zapamiętania domeny na krótszą i bardziej marketingową. Mieliśmy pełen plan migracji domeny bez strat SEO, który aplikowaliśmy jako bazę procesu.
2. Przebudowa architektury kategorii – płaska struktura (wszystko pod główną kategorią) na hierarchiczną (3 poziomy: dział → kategoria → podkategoria). Zmiana URL z /produkty/nazwa na /dział/kategoria/nazwa. 85% URL zmieniło ścieżkę.
3. Przejście na HTTPS – klient miał jeszcze HTTP (tak, w 2025). Przy okazji migracji domeny i architektury – wdrożenie SSL było naturalnym krokiem. Dodatkowa zmiana protokołu w każdym URL.

Ryzyko: co mogło pójść nie tak

Przy migracji 50 000 URL główne ryzyka to:

• Utrata 20-40% ruchu organicznego na 3-6 miesięcy (typowy spadek przy źle przeprowadzonej migracji)
• Masowe wypadnięcie z indeksu jeśli Googlebot nie podąży za przekierowaniami lub natrafi na łańcuchy 301
• Kanibalizacja jeśli stare i nowe URL indeksują się jednocześnie
• Utrata backlinków jeśli linki zewnętrzne prowadzą do starych URL, które nie przekierowują poprawnie
• Spadek konwersji jeśli użytkownicy trafiają na przekierowania zamiast na docelowe strony

Szacowaliśmy potencjalny spadek na 15-25% ruchu w pierwszym miesiącu z pełną rekonwalescencją w 3-4 miesiące. Faktyczny spadek wyniósł 8% w tygodniu 2 z powrotem do baseline w tygodniu 6 – znacząco lepiej niż pesymistyczny scenariusz.

Faza planowania – 4 tygodnie przed przełączeniem

Planowanie to 80% sukcesu migracji. Przy 50 000 URL margines błędu jest bliski zeru – jeden zły regex w regułach przekierowań może złamać 5 000 URL naraz.

Tydzień 1: pełny crawl i inventaryzacja

Screaming Frog crawl starej domeny z pełnym eksportem: URL, status code, title, meta description, H1, canonical, hreflang, internal links, external links, word count. 50 247 URL w CSV. Równolegle eksport z Search Console: top 5 000 URL po impresach, top 5 000 po kliknięciach. Eksport z GA4: top 5 000 landing pages po sesjach i konwersjach. Eksport z Ahrefs: profil linków zwrotnych (12 000 backlinków z 3 400 domen).

Efekt: pełna mapa istniejącego serwisu z danymi o ruchu, rankingach i linkach dla każdego URL. To fundament mapy przekierowań.

Tydzień 2: mapa przekierowań

Najbardziej pracochłonny krok. Dla każdego z 50 247 URL musieliśmy zdefiniować docelowy URL na nowej domenie z nową architekturą. Podejście: 95% URL mapowane automatycznie regexem (wzorce: /stara-kategoria/produkt → /nowa-kategoria/podkategoria/produkt), 5% mapowane ręcznie (URL z niestandardowymi ścieżkami, landing pages, strony CMS).

Narzędzia: Python skrypt z pandas do automatycznego mapowania + ręczny arkusz Google Sheets dla 2 500 wyjątków. Każde przekierowanie zweryfikowane: (1) docelowy URL istnieje na nowej stronie, (2) brak łańcuchów (max 1 hop), (3) brak pętli przekierowań.

Kluczowa decyzja: użycie przekierowań 301 (stałych) zamiast 302 (tymczasowych). 301 przekazuje 90-99% link equity na nowy URL. 302 nie przekazuje – to najczęstszy błąd przy migracjach.

Tydzień 3: staging i testy

Nowa strona postawiona na subdomenie staging z pełną nową architekturą. Screaming Frog crawl stagingu: weryfikacja, że wszystkie docelowe URL istnieją i zwracają status 200. Porównanie crawl starej strony vs staging: 1:1 mapowanie na bazie mapy przekierowań.

Testy przekierowań: skrypt w Node.js uruchamiający HTTP request na każdy z 50 247 starych URL i weryfikujący, że przekierowanie prowadzi do poprawnego docelowego URL ze statusem 301. Wykryto 347 błędów (0,7%) – naprawione przed przełączeniem. Bez tego testu 347 URL wylądowałoby na stronach 404 – utrata ruchu i link equity.

Tydzień 4: przygotowanie i komunikacja

Komunikacja z klientem: dokumentacja ryzyk, timeline, plan monitoringu, punkty decyzyjne („jeśli spadek ruchu > 30% w dniu 3, wracamy do starej strony”). Przygotowanie sitemapów XML dla nowej architektury. Konfiguracja Google Search Console dla nowej domeny. Przygotowanie skryptów monitorujących (crawl co 6 godzin przez pierwsze 72 godziny). Zaktualizowanie profili w katalogach i portalach z nowym adresem (cytowania NAP). Powiadomienie głównych partnerów linkujących o zmianie domeny.

Dzień przełączenia – co się działo godzina po godzinie

Przełączenie odbyło się w środę o 6:00 rano – statystycznie najniższy ruch tygodniowo, z pełnym dniem roboczym na monitoring i reakcję.

6:00-8:00 – przełączenie DNS i przekierowania

DNS zmieniony na nowy serwer. Przekierowania 301 aktywowane na starym serwerze. Propagacja DNS: 2-4 godziny. W tym czasie część użytkowników widzi starą stronę (przekierowania działają), część nową. Screaming Frog crawl starej domeny: weryfikacja, że każdy URL zwraca 301 na poprawny cel.

8:00-12:00 – weryfikacja i zgłoszenie do Google

Sitemap XML nowej domeny przesłany w Search Console. Change of Address tool w GSC aktywowany (informuje Google o zmianie domeny). Ręczna inspekcja 50 kluczowych URL w GSC: żądanie indeksacji nowych URL. Monitoring: Screaming Frog crawl nowej domeny – 49 900 URL zwraca 200 (347 naprawione wcześniej = 0% nowych błędów).

12:00-18:00 – pierwszy monitoring organiczny

Search Console zaczyna pokazywać dane z nowej domeny. Impresje: spadek 15% (normalne – Google jeszcze nie przekierował pełnego indeksu). Pozycje: stabilne na 90% fraz, fluktuacje na 10% (normalne w pierwszych 24h). GA4: ruch na nowej domenie rośnie w miarę propagacji DNS.

18:00-6:00 (noc) – automatyczny monitoring

Skrypt monitorujący co 2 godziny crawluje 100 kluczowych URL (top po ruchu) i weryfikuje status code, canonical, indeksowalność. Alert mailowy przy wykryciu anomalii. Noc przeszła bez alertów – pierwszy dobry znak.

Pierwsze 90 dni po migracji – timeline wyników

Migracja to nie jednorazowe zdarzenie – to proces rozłożony na miesiące. Google potrzebuje czasu na przeindeksowanie, przekierowanie equity i ustabilizowanie rankingów.

Tydzień 1: spadek 8%, panika kontrolowana

Ruch organiczny: 165 600 sesji/tydzień vs 180 000 pre-migration (spadek 8%). Impresje w GSC: spadek 12%. Pozycje: 94% fraz stabilnych, 6% spadek o 2-5 pozycji. Indeksacja nowej domeny: 38 000 z 50 247 URL (76%) – reszta w kolejce. Działanie: żądanie indeksacji dla top 500 URL ręcznie w GSC, sitemap ping, weryfikacja przekierowań na frazach ze spadkami.

Tydzień 2-3: stabilizacja

Ruch: powrót do 172 000 sesji/tydzień (96% baseline). Indeksacja: 47 000 URL (93%). Pozycje: 96% fraz stabilnych lub lepszych. Backlinki: Ahrefs pokazuje 11 400 z 12 000 backlinków przekierowanych poprawnie (95%). 600 backlinków z domen, które nie podążyły za 301 – skontaktowaliśmy się z webmasterami top 50 domen (odpowiadających za 85% equity tych 600 backlinków) o aktualizację linków. 35 z 50 zaktualizowało w ciągu 2 tygodni, co odzyskało szacunkowo 70% utraconego equity z tych linków.

Miesiąc 2: powrót do baseline

Ruch: 182 000 sesji/tydzień (101% baseline). Indeksacja: 49 800 URL (99%). Wszystkie frazy z top 10 wrócały do pozycji sprzed migracji lub lepszych. Nowa architektura kategorii zaczęła generować efekt: strony kategorii z lepszą strukturą URL rankują wyżej na frazy generyczne.

Miesiąc 3-6: wzrost ponad baseline

Ruch po 6 miesiącach: 205 200 sesji/tydzień (+14% vs pre-migration). Źródła wzrostu: (1) lepsza architektura kategorii poprawiła ranking 340 fraz kategoriowych o średnio 3 pozycje, (2) HTTPS wyeliminował ostrzeżenia przeglądarki, co poprawiło CTR o 5%, (3) czystsza struktura URL poprawiła crawl budget – Google indeksował nowe produkty 2× szybciej.

Metryka	Pre-migration	Tydzień 1	Miesiąc 1	Miesiąc 3	Miesiąc 6
Ruch organiczny (sesje/tyg.)	180 000	165 600	178 000	192 000	205 200
Frazy w top 10	12 000	11 280	11 760	12 600	13 200
Indeksacja	50 247	38 000	48 500	49 800	50 100
Konwersje/tyg.	2 400	2 160	2 350	2 520	2 760

Co zadecydowało o sukcesie – 5 kluczowych czynników

1. Kompletna mapa przekierowań z testami

Każdy z 50 247 URL miał zdefiniowany cel przekierowania i był przetestowany automatycznie przed przełączeniem. Zero domysłów, zero „zobaczymy”. 347 błędów wykrytych w testach i naprawionych to 347 URL, które w przeciwnym razie zwróciłyby 404. Przy średnim ruchu 3-4 sesje/dzień per URL to łącznie ~1 200 utraconych sesji dziennie – uniknięte dzięki jednej decyzji o automatycznym testowaniu. Koszt napisania skryptu testowego: 6 godzin developera. Wartość uniknięta: 1 200 sesji × 30 dni × wartość konwersji = szacunkowo 15 000-20 000 zł w pierwszym miesiącu.

2. Staging jako wierzytelne środowisko testowe

Nowa strona postawiona na stagingu z pełną architekturą i treścią pozwoliła na crawl porównawczy. Screaming Frog old vs new site comparison ujawnił 23 problemy: brakujące meta tagi po migracji, zmienione canonicale, utracone hreflang tagi. Wszystkie naprawione przed przełączeniem.

3. Monitoring 24/7 przez 72 godziny

Automatyczne crawle co 2-6 godzin przez pierwsze 3 dni dały pewność, że nic się nie zepsuło. Jeden alert w godzinie 14 pierwszego dnia: 12 URL zwracało 302 zamiast 301 (błąd konfiguracji serwera). Naprawione w 20 minut. Bez automatycznego monitoringu ten błąd mógłby pozostać niezauważony przez dni – z każdą godziną tracąc link equity na tych 12 URL.

4. Komunikacja z partnerami linkowymi

Top 50 domen linkujących (90% equity zewnętrznego) otrzymało e-mail z informacją o zmianie domeny i prośbą o aktualizację linków. 35 z 50 zaktualizowało w ciągu 2 tygodni. To przyspieszyło transfer equity o szacunkowo 3-4 tygodnie vs czekanie na naturalną propagację 301.

5. Zachowanie starego serwera przez 12 miesięcy

Stary serwer z przekierowaniami 301 pozostał aktywny 12 miesięcy po migracji. To kluczowe – Googlebot potrzebuje czasu na pełne przeindeksowanie. Wyłączenie starego serwera zbyt wcześnie (np. po miesiącu) spowodowałoby masowe 404 dla URL, które Google jeszcze indeksuje ze starą domeną. W naszym przypadku po 6 miesiącach wciąż 2% requestów Googlebota trafiało na starą domenę – gdyby serwer nie działał, byłoby to 1 000 URL dziennie zwracających 404. Koszt: ~200 zł/miesiąc za serwer – marginalna cena za bezpieczeństwo.

Szczegóły techniczne mapy przekierowań

Mapa przekierowań to serce każdej migracji. Przy 50 000 URL nie da się jej zrobić ręcznie – potrzebna jest automatyzacja z ręczną weryfikacją wyjątków. Nasz proces składał się z czterech warstw mapowania, każda obsługująca inną kategorię URL.

Warstwa 1: automatyczne mapowanie produktów (35 000 URL)

Produkty miały spójną strukturę URL: /produkty/slug-produktu. Nowa struktura: /dzial/kategoria/slug-produktu. Skrypt Python łączył dane z bazy sklepu (tabela produktów z kolumną kategoria) z eksportem crawla (stare URL). Dla każdego produktu: pobierz kategorię z bazy, zamapuj na nową hierarchię, wygeneruj nowy URL, zapisz parę stary→nowy.

Cały skrypt zajął 4 godziny pisania i 2 godziny debugowania. Trafność automatycznego mapowania: 98,2%. Pozostałe 1,8% (630 produktów) to przypadki, w których produkt zmienił kategorię między starą a nową strukturą – mapowane ręcznie na bazie najlepszego dopasowania.

Warstwa 2: mapowanie kategorii i filtrów (12 000 URL)

Kategorie przeszły największą transformację – z płaskiej struktury na 3-poziomową hierarchię. 8 000 kategorii i 4 000 stron filtrów wymagało indywidualnego mapowania na bazie tabeli odpowiedniości przygotowanej przez zespół UX klienta. Każda stara kategoria miała przypisaną nową ścieżkę w hierarchii.

Dodatkowa komplikacja: 1 200 stron filtrów (kombinacje parametrów: marka + cena + rozmiar) nie miało odpowiedników w nowej architekturze – klient zrezygnował z indeksowalnych filtrów. Te URL przekierowaliśmy na najbliższą kategorię nadrzędną z parametrem UTM do śledzenia (żeby mierzyć, ile ruchu tracą te redirecty vs kategoria).

Warstwa 3: strony CMS (3 247 URL)

Blog, FAQ, landing pages, regulaminy – każda mapowana ręcznie, bo nie było spójnego wzorca. Trzy osoby przejrzały 3 247 URL w ciągu 3 dni roboczych. Każdy URL skategoryzowany: zachować (redirect 1:1), połączyć (kilka starych → jeden nowy), usunąć (redirect na najbliższy odpowiednik). 2 800 to redirecty 1:1, 350 to połączenia, 97 to usunięcia z redirectem na kategorię nadrzędną.

Warstwa 4: implementacja na serwerze

50 247 reguł przekierowań zaimplementowanych jako nginx redirect map – plik tekstowy z parami stary_url nowy_url, ładowany do pamięci serwera. Wydajność: zero zauważalnego wpływu na czas odpowiedzi (nginx obsługuje mapy 100k+ bez problemu). Alternatywa rozważana i odrzucona: .htaccess z mod_rewrite (Apache) – zbyt wolne przy 50 000 reguł, każdy request parsuje cały plik.

Monitoring post-migracyjny – co śledziliśmy i jak

Monitoring po migracji to nie jednorazowe sprawdzenie – to ciągły proces przez minimum 6 miesięcy. Nasz monitoring obejmował trzy warstwy z różną częstotliwością.

Monitoring techniczny (co 6 godzin, pierwsze 72h; potem codziennie)

• Crawl 100 kluczowych URL – status code, czas odpowiedzi, canonical, robots
• Sprawdzenie sitemap XML – czy Google pobiera nowy sitemap
• Log serwera – ile requestów Googlebot na starą vs nową domenę
• Uptime monitoring – stary i nowy serwer działają

Monitoring SEO (codziennie, pierwsze 30 dni; potem cotygodniowo)

• Search Console: impresje, kliknięcia, CTR, pozycje per strona i per zapytanie
• Indeksacja: ile URL z nowej domeny jest w indeksie (Coverage report)
• Position tracking (Semrush): 500 kluczowych fraz per dzień
• Backlinki (Ahrefs): ile starych backlinków podąża za 301

Monitoring biznesowy (cotygodniowo)

• GA4: ruch organiczny, konwersje, przychód z organic
• Porównanie: tydzień vs odpowiadający tydzień pre-migration (sezonowość!)
• Alert: spadek konwersji > 15% na dowolnej kategorii produktowej

Łączny czas monitoringu: 15-20 godzin w pierwszym tygodniu, 5-8 godzin/tydzień w miesiącu 1, 2-3 godziny/tydzień w miesiącach 2-6. Ten czas jest często pomijany w budżetach migracyjnych – a bez niego problemy wykrywane są za późno, gdy Google już zdążył zdeindeksować strony z błędami.

Lekcje na przyszłość – co zrobilibyśmy inaczej

Mimo sukcesu migracji, retrospektywa ujawniła kilka obszarów do poprawy w przyszłych projektach tego typu.

Więcej czasu na testy A/B nowej architektury

Nową architekturę kategorii zaprojektowaliśmy na bazie keyword research i analizy konkurencji. Ale nie przetestowaliśmy jej z użytkownikami przed wdrożeniem. W pierwszym miesiącu po migracji bounce rate na stronach kategorii wzrósł o 8% – użytkownicy nie znajdowali produktów w nowej hierarchii. Poprawki UX w miesiącu 2 naprawiły problem, ale mogliśmy go uniknąć testem A/B na stagingu.

Wcześniejsze powiadomienie Googlebota

Change of Address w Search Console aktywowaliśmy w dzień przełączenia. Lepszą praktyką byłoby dodanie nowej domeny do GSC tydzień wcześniej i przesłanie sitemapy (pustej strony z komunikatem „wkrótce”) – to daje Googlebotowi head start w discovery nowej domeny.

Dedykowany kanał komunikacji z klientem

W dniu przełączenia klient był niespokojny i bombardował nas pytaniami mailem, Slackiem i telefonicznie. Następnym razem: dedykowany kanał Slack z automatycznymi aktualizacjami co godzinę (status, metryki, decyzje). Klient widzi postęp w real-time, nie musi pytać. Oszczędza czas obydwu stron i redukuje stres.

Narzędzia użyte w migracji

Narzędzie	Zastosowanie	Etap
Screaming Frog	Crawl pre/post, porównanie, monitoring	Planowanie + monitoring
Python + pandas	Automatyczne mapowanie 47 000 URL	Planowanie
Google Sheets	Ręczne mapowanie 2 500 wyjątków	Planowanie
Node.js skrypt	Testy przekierowań, monitoring 24/7	Testy + monitoring
Google Search Console	Change of Address, monitoring indeksacji	Przełączenie + monitoring
GA4	Monitoring ruchu i konwersji	Monitoring
Ahrefs	Monitoring backlinków i przekierowań	Monitoring
Cloudflare	DNS, SSL, reguły przekierowań	Przełączenie

Wpływ migracji na AI search i cytowania LLM

Aspekt rzadko omawiany przy migracjach: zmiana domeny wpływa nie tylko na rankingi Google, ale też na cytowania w ChatGPT, Perplexity i innych LLM-ach. Modele językowe znają starą domenę z training data – nowa domena jest im nieznana.

Jak LLM-y reagują na zmianę domeny

ChatGPT z web search podąża za przekierowaniami 301 – cytuje nową domenę po 2-4 tygodniach od migracji (czas na reindeksację w Bing). Perplexity aktualizuje się szybciej (1-2 tygodnie), bo crawluje agresywniej. Ale ChatGPT bez web search (wersja z parametric knowledge) nadal zna starą domenę z training data – aktualizacja wymaga nowego cyklu treningowego, co może trwać 6-12 miesięcy.

Działania po migracji specyficzne dla AIO: (1) upewnij się, że przekierowania działają dla botów AI (User-Agent: PerplexityBot, ChatGPT-User), (2) zaktualizuj wzmianki o domenie w swoich treściach (artykuły linkujące do siebie, FAQ, About), (3) poproś partnerów o aktualizację linków – nie tylko dla SEO, ale też dla LLM-ów, które budują entity recognition na bazie wielu źródeł.

Monitoring cytowań AI po migracji

Dodaj monitoring cytowań w AI search do procesu post-migracyjnego. Sprawdź, czy kluczowe zapytania w Perplexity i ChatGPT nadal cytują Twoją markę (z nową domeną). Jeśli cytowania spadły – to sygnał, że LLM-y nie podążyły za przekierowaniami. Rozwiązanie: intensywna publikacja nowych treści na nowej domenie, budowanie sygnałów entity (wzmianki, linki, social media), monitorowanie powrotu cytowań. Szczegóły monitoringu opisujemy w materiale o monitoringu cytowań w ChatGPT i Perplexity.

Kosztorys migracji – ile realnie kosztuje taki projekt

Przejrzystość kosztów to element często pomijany w case studies. Nasz projekt kosztował łącznie 42 000 zł rozłożone na 10 tygodni (4 planowanie, 1 przełączenie, 5 monitoring intensywny).

Pozycja	Koszt	Uwagi
SEO specialist (80h planowanie + monitoring)	16 000 zł	200 zł/h × 80h
Developer (40h skrypty, staging, nginx)	12 000 zł	300 zł/h × 40h
Content specialist (24h mapowanie CMS)	3 600 zł	150 zł/h × 24h
QA (16h testy przekierowań)	2 400 zł	150 zł/h × 16h
Narzędzia (Screaming Frog, Ahrefs, Semrush)	2 000 zł	Pro plany przez 3 miesiące
Infrastruktura (staging, stary serwer 12 mies.)	3 600 zł	300 zł/mies. × 12
Buffer na nieprzewidziane	2 400 zł	~6% budżetu
Łącznie	42 000 zł

Dla porównania: koszt utraconego ruchu przy źle przeprowadzonej migracji (spadek 30% na 6 miesięcy) to szacunkowo 150 000-250 000 zł w utraconym przychodzie (na bazie konwersji e-commerce klienta). Inwestycja 42 000 zł w profesjonalną migrację dała ROI 4-6× tylko na unikniętych stratach – nie licząc wzrostu +14% ponad baseline.

Najczęstsze błędy przy migracjach – czego unikać

1. Brak mapy przekierowań – „Google sam sobie poradzi” to mit. Bez 301 Google traktuje nowe URL jako nowe strony. Utrata rankingów gwarantowana.
2. Użycie 302 zamiast 301 – przekierowanie tymczasowe (302) nie przekazuje link equity. Jeden z najczęstszych i najkosztowniejszych błędów migracyjnych.
3. Łańcuchy przekierowań – stary URL → pośredni URL → nowy URL. Każdy hop traci 5-10% equity. Przy 3+ hopach Google może nie podążyć za łańcuchem wcale. Maksymalnie 1 hop per przekierowanie.
4. Wyłączenie starego serwera za wcześnie – minimum 6 miesięcy, optymalnie 12. Googlebot crawluje wolniej niż myślisz. Szczegóły w naszym materiale o crawl budget i indeksacji.
5. Brak testów przed przełączeniem – odkrywanie błędów na produkcji to odkrywanie ich w najgorszym momencie. Staging + automatyczne testy to minimum.
6. Ignorowanie backlinków – linki zewnętrzne to 30%+ wartości SEO strony. Bez kontaktu z top partnerami linkowymi, transfer equity trwa miesiące dłużej.
7. Migracja w piątek – jeśli coś pójdzie nie tak, weekend to najgorszy czas na naprawę. Zawsze środa-czwartek, godziny poranne.

FAQ — najczęstsze pytania

Ile trwa pełna rekonwalescencja po migracji 50 000 URL?

Przy poprawnie przeprowadzonej migracji: 4-8 tygodni do powrotu do baseline ruchu organicznego. Pełna stabilizacja pozycji: 2-3 miesiące. Wzrost ponad baseline (efekt lepszej architektury, HTTPS): 3-6 miesięcy. Przy źle przeprowadzonej migracji: 6-12 miesięcy lub nigdy – zależy od skali błędów i szybkości reakcji.

Czy lepiej migrować wszystko naraz czy etapami?

Zależy od skali zmian. Jeśli planujesz zmianę domeny + architektury + HTTPS – lepiej naraz (jeden spadek, jeden okres rekonwalescencji). Jeśli zmiany są niezależne (np. HTTPS teraz, architektura za 6 miesięcy) – etapami, z minimum 3 miesiącami przerwy między migracjami. Nigdy nie migruj, gdy trwa Core Update – poczekaj 2-3 tygodnie po zakończeniu rollout.

Czy migracja wymaga specjalisty czy mogę ją zrobić samodzielnie?

Przy serwisie do 500 URL – samodzielnie z dobrą checklist (jak nasz przewodnik migracji domeny). Przy 500-5 000 URL – z konsultacją specjalisty SEO technicznego. Przy 5 000+ URL – dedykowany specjalista lub agencja z doświadczeniem w migracjach. Koszt błędu przy 50 000 URL to potencjalnie setki tysięcy złotych utraconego ruchu – oszczędność na specjaliście jest fałszywa ekonomia.

Co zrobić, jeśli po migracji ruch spadł o ponad 30%?

Natychmiastowa diagnostyka: (1) Sprawdź masowe 404 w Search Console – jeśli są, napraw przekierowania. (2) Sprawdź łańcuchy przekierowań w Screaming Frog. (3) Sprawdź canonical na nowej stronie – może wskazują na starą domenę. (4) Sprawdź robots.txt – może blokuje crawl nowej strony. (5) Jeśli problem nie jest oczywisty po 72 godzinach i spadek pogłębia się – rozważ rollback do starej domeny i ponowną migrację po naprawieniu błędów.

Jak przekierować 50 000 URL bez obciążenia serwera?

Reguły przekierowań na poziomie serwera (nginx redirect map, Apache RewriteMap z plikiem) są znacznie wydajniejsze niż plugin WordPress do przekierowań. Nginx redirect map obsługuje 50 000+ reguł bez zauważalnego wpływu na wydajność. Alternatywa: Cloudflare Workers lub Cloudflare Redirect Rules (do 2 000 reguł w darmowym planie, nieograniczone w Enterprise). Kluczowe: unikaj przekierowań na poziomie PHP/WordPress – każde wymaga inicjalizacji WordPress, co spowalnia odpowiedź o 200-500 ms.

Co dalej

Migracja to punkt zwrotny, nie koniec procesu. Po ustabilizowaniu rankingów warto przejść do optymalizacji nowej architektury, opisanej w kontekście SEO dla e-commerce 2026. Monitoring pozycji i indeksacji po migracji powinien trwać minimum 6 miesięcy – konfigurację raportów opisujemy w przewodniku po Search Console 2026.