Migracja WordPressa (hosting, domena, przebudowa szablonu albo zmiana struktury permalinków) często wygląda jak pilna realizacja: sztywny deadline, presja przychodu i ryzyko organiczne. Pozycji nie „ratuje sam hosting” — chronisz je spójnością adresów, sensowną mapą przekierowań i tym, że krytyczne szablony po wdrożeniu nadal serwują ten sam sens treści i linkowania wewnętrznego co przed migracją.
Jeśli Google widzi inny zestaw URL-i albo ten sam content pod wieloma adresami bez kontroli — tracisz kontynuację sygnałów. Migracja to więc dokumentacja i testy, nie tylko dump bazy.
Przed migracją: inwentaryzacja i baseline
- Pełny lub próbkowany crawl (np. Screaming Frog, Sitebulb) + eksport mapy URL-i z CMS i Google Search Console.
- Oznacz landingi o najwyższym priorytecie: przychód bezpośredni, leady, indeksowane frazy — osobna lista „nie może spaść”.
- Zbierz duplikaty i warianty: HTTP/HTTPS, www/bez www, trailing slash, ścieżki z parametrami UTM i paginacja — decyzja, który URL jest kanoniczny.
- Zrób baseline renderów (title, meta description, H1, fragment treści nad foldem) dla szablonów money page — potem porównanie 1:1 po wdrożeniu.
- Spisz dotychczasowe reguły w `.htaccess` / nginx / Cloudflare — migracja to często moment, gdzie zapomniane reguły znikają „przy okazji”.
Arkusz mapowania: stary URL → docelowy URL → typ odpowiedzi
Mapowanie trzymaj w arkuszu lub narzędziu typu redirect manager — nie w głowie developera. Dla każdego starego adresu potrzebujesz jawnej decyzji: stałe przekierowanie (301), konsolidacja pod silniejszy URL, kontrolowane 404/410 albo pozostawienie bez zmian, jeśli struktura się nie zmienia.
- 301: zmiana trwała adresu lub scalenie kilku słabszych podstron w jedną.
- 410: świadome usunięcie treści — ale tylko gdy naprawdę nie ma substytutu i nie ma wartościowych linków zewnętrznych do utrzymania przez 301.
- Unikaj „na później” pod kątem SEO — odkładanie przekierowań po indeksacji to ryzyko soft 404 i utraty sygnału.
Przekierowania 301 — jeden skok, bez łańcuchów i pętli
Jeden stabilny 301 ze starego URL na finalny jest lepszy niż łańcuch A→B→C i znacznie lepszy niż zostawianie 302 „na czas przejściowy”. Łańcuchy spowalniają crawl, utrudniają debug i często maskują błędy w mapie.
Typowe błędy przy wdrażaniu reguł
- Zbyt szerokie regexy — przekierowują za dużo lub wchodzą w konflikt z podstronami API lub preview.
- Reguły kolejkowane w złej kolejności — pierwsza pasująca reguła wygrywa; dokumentuj kolejność.
- Podwójne kanoniczne adresy — np. migracja na HTTPS bez twardego przekierowania z HTTP.
Canonical, HTTPS, www i slash końcowy
Ustal jeden preferowany host i format ścieżki; resztę obsłuż przekierowaniami na poziomie serwera. Tag canonical jest dodatkiem do polityki adresów, nie zamiennikiem dla chaosu w redirectach — szczególnie przy zmianie struktury katalogów lub slugów.
robots.txt, XML sitemap i Search Console
- Po migracji zaktualizuj mapę witryny — tylko kanoniczne, indeksowalne URL-e; rozważ osobne mapy dla dużych archiwów.
- Sprawdź, czy robots.txt nie blokuje krytycznych ścieżek ani renderowania zasobów potrzebnych Google do zrozumienia strony.
- W Google Search Console: poprawny wpis usługi, przesłanie mapy, raport pokrycia indeksu i Inspekcja adresów URL dla próbek landingów.
Parzystość treści i szablonów
„Ta sama” podstrona po migracji musi mieć ten sam strategiczny układ nagłówków, treść transakcyjną i elementy zaufania — nie tylko „podobny wygląd”. Jeśli ścinasz treść, zmieniasz FAQ albo usuwasz bloki schema, ryzykujesz drift snippetów i CTR z SERP.
Dane strukturalne i szablony WooCommerce
Po zmianie motywu lub wtyczki SEO sprawdź JSON-LD i znaczniki Product/Breadcrumb — drobny błąd w szablonie potrafi podwoić błędy w Rich Results albo zmienić sposób prezentacji cen i dostępności.
Baza danych: serializacja PHP i podmiana URL-i
Masowy search-replace domeny w bazie bez narzędzi uwzględniających serializację może uszkodzić opcje motywu i widgetów — wtedy witryna działa „na pół”, a layout się sypie. Stosuj sprawdzone ścieżki (WP-CLI z dry-run, skrypty naprawcze), zawsze z backupem i testem na kopii.
Staging bez wycieku do indeksu
Staging powinien być chroniony hasłem lub VPN, mieć noindex na poziomie meta/X-Robots-Tag oraz nie linkować jawnego duplikatu produkcji w menu publicznym. Publiczny staging z pełną kopią treści to zaproszenie do duplicate content i śmieciowych snippetów w SERP.
DNS, TTL i okno przełączenia
- Obniż TTL z wyprzedzeniem, aby skrócić propagację przy zmianie rekordów A/AAAA.
- Trzymaj checklistę cut-over: kolejność przełączenia, rollback plan, monitoring uptime i certyfikatów TLS.
- Sprawdź rekordy pocztowe (MX) — zmiana hostingu często „przypadkiem” dotyka maili i formularzy kontaktowych.
Po wdrożeniu: walidacja techniczna
- Testuj próbkę przekierowań narzędziem lub nagłówkami HTTP — oczekuj pojedynczego 301 na docelowy kod 200.
- Monitoruj logi 404 i serwera na landingach priorytetowych przez pierwsze dni i tygodnie.
- Sprawdź linkowanie wewnętrzne i menu — nie polegaj wyłącznie na redirectach; zaktualizuj linki w treściach tam, gdzie to możliwe.
- Dla migracji międzynarodowych utrzymuj spójny hreflang i mapowanie par językowych po zmianie ścieżek.
Wydajność i Core Web Vitals po przeprowadzce
Nowy hosting, CDN lub stack PHP może polepszyć albo pogorszyć LCP i TTFB — warto zestawić pomiary field/lab przed i po oraz mieć budżet na hotfix, jeśli szablon na nowym środowisku generuje cięższy HTML lub inne cache.
Migracja kończy się wtedy, gdy nie tylko „działa”, ale SERP i użytkownicy widzą ten sam sens strony — szybciej lub stabilniej, nie przypadkiem gorzej.
Powiązane — przejęcie projektu i filary
- Usługi programistyczne WordPress
- Core Web Vitals — po migracji sprawdź też wydajność
- Odbiór utkniętego projektu — audyt wejściowy
- Zakres programistyczny WordPress
- WordPress vs custom — czy migracja na inny stack
FAQ
Najczęściej zadawane pytania
- Nie musi — kluczowa jest ciągłość adresów i treści, stabilny render oraz brak regresji technicznych. Zły efekt zwykle biorą znikające przekierowania, duplikaty, nowe błędy 5xx albo gorszy czas odpowiedzi origin.
- Jeśli masz wersje językowe, utrzymuj spójne mapowanie par i aktualizuj adnotacje oraz XML zgodnie z nową strukturą — pojedynczy błąd w parze PL/EN potrafi zmienić targeting geograficzny.
- Gdy migracja jest powiązana ze sztywnym terminem kampanii lub cut-over w jednym oknie — czas przestaje być jedynie „tematem IT”.
- Krótkie fluktuacje bywają normą przy przebudowie crawl budgetu; groźne są utrzymujące się skoki 404, utrata pokrycia indeksu lub spadek istotnych zapytań po kilku tygodniach bez wyjaśnienia — wtedy wracasz do mapy URL-i i logów.
- Wtyczka pomaga zarządzać listą, ale nie zastępuje architektury na poziomie serwera ani dokumentacji reguł — przy dużych projektach rozważ hybrydę: krytyczne reguły na nginx/Apache, reszta w narzędziu z audytem.
- Zaktualizuj definicje celów, parametry kampanii i widoki — migracja bez zmiany tagów potrafi zerować porównania okresów i fałszować decyzje marketingowe.