Większość katastrof ruchu nie pochodzi z aktualizacji Google — zespoły fundują je sobie same przy zmianie platformy. Migracja na ślepo może kosztować 30–70% ruchu organicznego, a odzyskiwanie trwa miesiącami. Zrobiona podręcznikowo — daje mały, krótki dołek, po którym często następuje wzrost (Next.js zwykle wygrywa na renderowaniu i szybkości).
Zasada zero: zmieniaj jedną zmienną naraz
Najbardziej ryzykowne migracje zmieniają platformę, strukturę URL, design i treść jednocześnie — gdy ruch spada, nikt nie umie wskazać, która zmiana go położyła. Rozłóż w czasie: migruj platformę z zamrożonymi URL-ami i treścią, potwierdź stabilność przez kilka tygodni, potem rozwijaj design i treść już na nowym stacku.
Przed: zbuduj inwentarz
Nie zachowasz tego, czego nie zmierzyłeś. Zbierz per URL:
- Pełny crawl starej witryny (Screaming Frog albo skrypt po starej sitemapie).
- Top strony z Search Console (12 miesięcy kliknięć) i top strony konwersji z analityki — te dostają ręczną uwagę.
- Najczęściej linkowane strony (GSC → Links albo Ahrefs) — zgubienie przekierowania na stronie z 200 domenami linkującymi spala lata autorytetu.
- Obecne title, description, canonicale, hreflang, dane strukturalne — baza parytetu.
Mapa przekierowań to jest ta migracja
Jeśli URL-e w ogóle się zmieniają, każdy stary URL dostaje jednoskokowy 308/301 do dokładnego nowego odpowiednika — nie do strony głównej (masowe przekierowania na główną Google traktuje jak soft 404):
// next.config.mjs — najpierw reguły-wzorce, jawna mapa dla wyjątków
async redirects() {
return [
{ source: "/shop/:category/:slug", destination: "/products/:slug", permanent: true },
...explicitMap.map(({ from, to }) => ({ source: from, destination: to, permanent: true })),
];
}
Łańcuchy są zakazane: jeśli stara witryna już miała przekierowania, skieruj ich źródła też prosto na finalne URL-e. Wszystko z tematu o przekierowaniach obowiązuje tu podwójnie.
Staging: kontrola parytetu, nie „na oko"
- Trzymaj staging poza indeksem: HTTP auth jest najbezpieczniejszy (przypadkowy
noindexz configu wyjechał na produkcję niejeden raz). - Zdiffuj stare vs nowe dla top stron skryptem: title, description, canonical, hreflang, H1, JSON-LD, kod odpowiedzi. Parytet renderowania też:
curlpo HTML-u stagingu i potwierdź, że treść jest renderowana serwerowo. - Przetestuj mapę przekierowań na pełnym inwentarzu starych URL-i przed startem, nie na próbce.
Dzień startu i tygodnie po nim
- Zgłoś nową sitemapę w Search Console; przekierowania ze starych URL-i serwuj bezterminowo (lata, nie tygodnie).
- Obserwuj logi serwera pod kątem 404 od Googlebota — każdy to dziura w mapie przekierowań; w pierwszym tygodniu naprawiaj codziennie.
- Spodziewaj się skoku crawlu i wahań pozycji przez 2–6 tygodni — Google ponownie ocenia witrynę; nie cofaj w panice.
- Progi alarmowe: utrzymujący się spadek >20% na stronach przychodowych po trzecim tygodniu zasługuje na śledztwo (konfiguracja monitoringu), nie na nadzieję.
Checklista:
- Inwentarz URL-i z oznaczonymi top stronami GSC i najczęściej linkowanymi
- Jednoskokowa mapa przekierowań pokrywająca 100% starych URL-i, przetestowana przed startem
- Staging za autoryzacją; parytet meta/schem/renderowania zdiffowany per top strona
- Platforma migrowana z zamrożonymi URL-ami i treścią; design później
- Po starcie: codzienny przegląd 404 Googlebota, przekierowania żyją latami