Branżowy benchmark spadku ruchu organicznego po migracji sklepu to 15–30% w pierwszych trzech miesiącach, z odbudową do pierwotnego poziomu przez kolejne 6–12. Dla sklepu robiącego kilka–kilkanaście milionów złotych obrotu rocznie to nie jest statystyka — to kwartał albo dwa poniżej planu, policzalne w utraconej marży.
W naszych migracjach średni spadek to mniej niż 3%. Ta różnica nie bierze się z lepszych narzędzi ani z magii — bierze się z kolejności działań. Poniżej pokazujemy, dlaczego migracje kasują ruch organiczny, oraz konkretny proces SEO-first, którym trzymamy stratę poniżej 3%. Na końcu znajdziesz listę pytań, którymi sprawdzisz własnego wykonawcę, zanim podpiszesz umowę.
Dlaczego migracja kasuje ruch organiczny — sześć mechanizmów
Ruch organiczny nie znika w dniu przełączenia z powodu abstrakcyjnej „zmiany platformy”. Znika z powodu sześciu konkretnych, technicznych mechanizmów. Każdy z nich jest do uniknięcia — pod warunkiem, że zajmiesz się nim przed wdrożeniem, a nie po.
1. Stare adresy URL zaczynają zwracać 404
Każda platforma buduje adresy inaczej. To, co w PrestaShop było /123-nazwa-produktu.html, w Shopify staje się /products/nazwa-produktu. Jeśli stary adres nie dostaje przekierowania 301 na nowy, zwraca 404. Google po kilku wizytach usuwa go z indeksu, a razem z nim znika cała historyczna moc linków — zewnętrznych i wewnętrznych — którą ta strona zdobywała latami. To pojedyncza, największa przyczyna spadków.
2. Przekierowania są, ale zrobione źle
Sama obecność 301 nie wystarczy. Łańcuchy przekierowań (301 → 301 → 200), pętle, albo — klasyk — przekierowanie wszystkich starych adresów na stronę główną zamiast na odpowiadającą podstronę. To ostatnie Google traktuje jak „soft 404” i nie przekazuje mocy. Mapa przekierowań musi być jeden-do-jednego: konkretny stary URL na konkretny nowy o tej samej intencji.
3. Metadane i dane strukturalne wracają do ustawień domyślnych
Nowa platforma generuje własne znaczniki title, meta description i H1 — zwykle szablonowe. Znikają dopracowane tytuły, canonicale zaczynają wskazywać na złe adresy, a schema.org (Product, Offer, BreadcrumbList, Review) nie zostaje odtworzona. Efekt: tracisz rich results w wynikach wyszukiwania — gwiazdki, ceny, dostępność. Pozycja może zostać ta sama, a CTR spada, bo twój wynik nagle wygląda ubożej niż konkurencja.
4. Zmienia się sposób renderowania i wydajność
Migracja na headless albo aplikację jednostronicową często przenosi renderowanie na stronę klienta (JavaScript). Jeśli treść nie jest renderowana po stronie serwera, Googlebot przy pierwszym przejściu widzi pustą stronę. Do tego dochodzą Core Web Vitals: wolniejszy TTFB i LCP to realny problem — TTFB powyżej 500 ms koreluje z 5–10% spadkiem konwersji, a wolniejsze strony Google indeksuje rzadziej.
5. Marnuje się crawl budget
Po przełączeniu Googlebot trafia na tysiące przekierowań, stron 404 i duplikatów. Przy katalogu liczącym dziesiątki tysięcy adresów bot przepala budżet crawlowania na ponowne odwiedzanie śmieci, zamiast indeksować nowe strony. Im większy sklep, tym dłużej nowe adresy czekają na indeksację — a strona bez indeksu nie generuje ruchu.
6. Przejściowa niestabilność indeksu
Nawet idealna migracja wywołuje 2–6 tygodni „przemeblowania”: Google od nowa crawluje, renderuje i ocenia strony. Pozycje falują. Największe ryzyko na tym etapie to panika — zespół zaczyna zmieniać rzeczy w trakcie, przez co proces oceny startuje od zera. Dobry proces nie eliminuje tej fazy, ale skraca ją i wypłaszcza jej amplitudę.
SEO-first znaczy: SEO decyduje pierwsze, nie naprawia ostatnie
Większość agencji prowadzi migrację najpierw technicznie. Najpierw powstaje sklep, dane się przenoszą, a SEO wchodzi na końcu — jako warstwa naprawcza, kiedy spadek już widać w Google Search Console. W tej kolejności mapa przekierowań powstaje pod presją i po fakcie, a metadane oraz schema są „do dorobienia w wolnej chwili”.
Odwracamy tę kolejność. Każdy sprint zaczyna się od decyzji SEO, dopiero potem technicznej. Struktura URL nowego sklepu jest projektowana, zanim powstanie pierwsza linia kodu frontendu — a nie odkrywana po wdrożeniu. To jedna zmiana w procesie, ale to ona odpowiada za różnicę między spadkiem 15–30% a spadkiem poniżej 3%.
SEO-first nie znaczy „zamroź wszystko, jak było”. Czasem stara struktura URL jest zła i warto ją poprawić — płaska hierarchia kategorii, duplikaty parametrów, adresy z ID zamiast słów kluczowych. Różnica polega na tym, że w podejściu SEO-first każda taka zmiana jest świadomą decyzją z przypisanym przekierowaniem, a nie przypadkowym efektem ubocznym nowej platformy. Zmieniasz to, co chcesz zmienić, i wiesz dokładnie, gdzie prowadzi każdy stary adres.
Jeśli wykonawca traktuje SEO jako etap po wdrożeniu, spadek 15–30% nie jest ryzykiem — jest wpisany w plan. Pytanie tylko, kiedy go zobaczysz.
Proces SEO-first krok po kroku
Poniżej realny przebieg — ten sam dla migracji PrestaShop → Shopify Plus i dla przepisania legacy PHP na Symfony. Różni się długość, nie kolejność.
Krok 1 — Audyt i SEO baseline (tydzień 1–2)
Pełny audyt obecnego sklepu: struktura URL, strony indeksowalne, linkowanie wewnętrzne, schema markup, Core Web Vitals. Do tego baseline ruchu z Google Search Console i Ahrefs. Powstaje dokument „Co zachowujemy bezwzględnie” — lista 200–500 najważniejszych adresów pod względem ruchu i konwersji. Bez tej listy migrację prowadzi się po omacku.
Krok 2 — Architektura informacji i mapowanie URL (tydzień 2–4)
Projektujemy strukturę nowego sklepu z mapowaniem jeden-do-jednego dla wszystkich indeksowanych stron. Kluczowy szczegół: każdy URL waliduje specjalista SEO, nie tylko developer. Mapa przekierowań powstaje właśnie tu — przed wdrożeniem — i trafia do testów regresji, a nie do backlogu „na po launchu”.
Krok 3 — Development z testami SEO po każdym sprincie (tydzień 4–18)
Iteracyjny development z walidacją na stagingu. Po każdym dwutygodniowym sprincie uruchamiamy automatyczne testy SEO: poprawność mapowania przekierowań, obecność schema markup, Core Web Vitals, indexability. Do tego manualny przegląd przez speca SEO. Regres wykryty na stagingu w tygodniu 8 kosztuje godzinę pracy; ten sam regres wykryty na produkcji po launchu kosztuje pozycje.
Krok 4 — Cutover w oknie małego ruchu (weekend)
Migracja produkcyjna w okno najmniejszego ruchu — typowo niedziela w nocy — z gotowym planem rollbacku i monitoringiem 24/7 przez pierwsze 72 godziny. Przełączenie odbywa się bez przerwy w sprzedaży: klienci kupują przez cały proces. Wgrywanie zmian w piątek po południu albo w szczycie sprzedażowym to niepotrzebne ryzyko, które eliminujesz samym wyborem terminu.
Krok 5 — Monitoring 90 dni po wdrożeniu (w cenie)
Po cutoverze zaczyna się faza, w której większość ruchu jest do wygrania albo do stracenia. Przez 90 dni idą tygodniowe raporty ruchu organicznego, monitoring 404, weryfikacja indeksacji nowych stron i alerty na regresy Core Web Vitals. Przyjęliśmy próg: spadek powyżej 5% w pierwszych 30 dniach naprawiamy bez dodatkowych kosztów. W praktyce w około 95% naszych migracji żaden post-launch fix nie był potrzebny — bo problem rozwiązano na etapie projektowania, nie gaszenia pożaru.
Parallel run czy big-bang cutover?
Samo przełączenie ruchu ze starego systemu na nowy da się zrobić na dwa sposoby, a wybór między nimi ma bezpośredni wpływ na ryzyko SEO.
Big-bang cutover to jednorazowe przełączenie całości w jednym oknie. Szybszy, tańszy i prostszy — sprawdza się przy mniejszych katalogach oraz migracjach typu SaaS → SaaS, gdzie stary system jest przewidywalny i dobrze udokumentowany. Ryzyko jest wtedy na tyle niskie, że utrzymywanie dwóch środowisk równolegle nie ma uzasadnienia.
Parallel run oznacza, że stary i nowy system działają obok siebie przez jakiś czas. Pozwala zwalidować dane, przekierowania i wydajność na prawdziwym produkcyjnym ruchu, zanim odetniesz stary sklep. Jest droższy i bardziej złożony — trzeba utrzymać dwie infrastruktury i zsynchronizować między nimi dane, które zmieniają się w czasie: stany magazynowe, zamówienia, konta klientów. Ale przy legacy bez dokumentacji i katalogu liczonym w dziesiątkach tysięcy adresów to jedyny sposób, żeby wychwycić zależności, o których nikt już nie pamięta, zanim uderzą w produkcję.
Zasada jest prosta: im więcej niewiadomych w starym systemie i im większy katalog, tym mocniej przechyla się to w stronę parallel run. Zła rekomendacja kosztuje w obie strony — niepotrzebny parallel run przy czystej migracji SaaS przepala budżet, a big-bang tam, gdzie potrzebny był parallel run, przepala ruch. To jest dokładnie ta decyzja, którą chcesz usłyszeć uzasadnioną, a nie domyślną.
Dowód: tysiące adresów i niemal wszystkie pozycje zachowane
Najtrudniejszy scenariusz, jaki prowadzimy, to migracja legacy. Bogart Meble działał dwanaście lat na custom kodzie w PHP 5.4 — bez dokumentacji, z zapytaniami do bazy trwającymi po kilka sekund. Przepisaliśmy sklep na Symfony 6.4 wzorcem Strangler Fig, moduł po module, w około 16 tygodni.
Z perspektywy SEO liczą się trzy decyzje:
- Mapowanie 301 dla wszystkich adresów URL — jeden-do-jednego, z zachowaniem identycznej struktury semantycznej, a nie zbiorcze przekierowanie na kategorie.
- Parallel run przez 2 tygodnie — stary i nowy system działały równolegle, co pozwoliło zwalidować dane i przekierowania na produkcyjnym ruchu przed ostatecznym przełączeniem.
- Przełączenie DNS poza godzinami szczytu, z monitoringiem pozycji od pierwszej godziny po cutoverze.
Wynik: niemal wszystkie pozycje w Google zachowane, spadek ruchu organicznego w pierwszym miesiącu utrzymany poniżej naszego progu 3%, bez przestoju i bez utraconych zamówień. Przy okazji LCP strony produktu spadł z kilku sekund do poniżej sekundy, a konwersja po trzech miesiącach wyraźnie wzrosła — bo szybsza strona sprzedaje lepiej, niezależnie od pozycji.
Drugi przykład pokazuje, że zmiana platformy nie jest wrogiem ruchu, jeśli jest dobrze zmapowana. Topeshop migrował z PrestaShop na Shopify Plus wraz z integracją marketplace'ów i zanotował +58% konwersji. Ta sama zasada: najpierw przenieś jeden-do-jednego to, co już działa w SEO, dopiero potem dokładaj wzrost.
Jak sprawdzić własnego wykonawcę
Nie musisz znać się na SEO, żeby ocenić, czy wykonawca prowadzi migrację bezpiecznie. Wystarczy kilka pytań i porównanie odpowiedzi z tym, jak wygląda proces SEO-first kontra typowa migracja „najpierw technicznie”.
| Etap | Migracja SEO-first | Migracja „najpierw technicznie” |
|---|---|---|
| Mapa przekierowań 301 | Powstaje w tygodniu 2–4, przed frontendem | Po wdrożeniu, gdy spadek już widać |
| Kto waliduje URL | Specjalista SEO, nie tylko developer | Nikt albo developer „przy okazji” |
| Testy SEO | Po każdym sprincie, automatyczne i manualne | Rzut oka przed launchem |
| Termin cutoveru | Okno małego ruchu, plan rollbacku, 72 h monitoringu | „Wgramy w piątek po południu” |
| Monitoring pozycji | 90 dni w cenie, alert na regres powyżej 5% | Klient sam zauważa spadek w GSC |
| Typowy spadek ruchu | Poniżej 3% | 15–30%, odbudowa 6–12 miesięcy |
Jedno pytanie waży najwięcej: kiedy powstaje mapa przekierowań 301? Jeśli odpowiedź brzmi „zajmiemy się tym po wdrożeniu” albo „wygenerujemy automatycznie na końcu” — masz swoją odpowiedź, niezależnie od reszty oferty.
Podsumowanie
Migracja nie traci ruchu z powodu zmiany platformy — traci go z powodu braku mapy przekierowań, utraconych metadanych i wydajności gorszej niż wcześniej. Wszystkie trzy są do uniknięcia, jeśli SEO decyduje pierwsze, a nie naprawia ostatnie. Benchmark 15–30% opisuje migracje prowadzone technicznie; spadek poniżej 3% jest osiągalny, kiedy struktura URL, przekierowania i monitoring są zaplanowane przed wdrożeniem, nie po nim.
Jeśli planujesz migrację i chcesz wiedzieć, ile ruchu realnie ryzykujesz, zacznij od audytu sklepu — to on tworzy listę „co zachowujemy bezwzględnie”. Zobacz też, jak wygląda nasz proces migracji sklepu oraz konkretne realizacje, a jeśli masz pytania do swojego przypadku, napisz do nas.