Migracja WordPressa to nie tylko skopiowanie plików na nowy serwer. Może zakończyć się białą stroną, błędem połączenia z bazą, niedziałającymi formularzami, błędami 404 albo spadkiem widoczności w Google. Największe ryzyko pojawia się wtedy, gdy nie ma pełnego backupu, testów przed zmianą DNS i planu szybkiego powrotu do starego środowiska.
Ryzyka SEO – co może zniknąć z Google?
Najpierw rozdziel dwa scenariusze. Przy zmianie hostingu bez zmiany domeny publiczne adresy pozostają takie same, więc nie trzeba tworzyć przekierowań 301. Trzeba jednak zachować dostępność strony, poprawne kody HTTP, adresy kanoniczne, mapę XML, plik robots.txt oraz ustawienia indeksowania.
Zmiana domeny, protokołu, subdomeny albo struktury adresów jest trudniejsza. Wymaga przygotowania mapy starych i nowych URL-i oraz przekierowań prowadzących do możliwie najlepiej dopasowanych stron. Przekierowanie wszystkich adresów na stronę główną nie zastępuje poprawnej migracji.
Najczęstsze problemy SEO po migracji to:
- brak przekierowania 301 ze starych adresów, co prowadzi do błędów 404,
- pozostawione stare adresy w linkowaniu wewnętrznym, menu lub treści wpisów,
- utrata mapy witryny XML albo błędny adres mapy w Google Search Console,
- pozostawiona blokada
noindexze środowiska testowego, - nieaktualne adresy kanoniczne i zasoby ładowane przez HTTP po przejściu na HTTPS,
- utrata weryfikacji domeny lub blokada robotów wyszukiwarek przez firewall.
Przy zmianie samego serwera najważniejsze jest zachowanie adresów i ciągłości działania. Przy zmianie domeny trzeba jeszcze zaktualizować linki, kanoniczne adresy URL, mapę XML i konfigurację narzędzi analitycznych. W tym drugim przypadku warto zweryfikować obie domeny w Google Search Console i monitorować błędy 404.
Najczęstsze awarie techniczne po migracji
WordPress zależy od wielu elementów środowiska: wersji PHP, bazy MySQL lub MariaDB, rozszerzeń PHP, konfiguracji serwera, uprawnień plików, pamięci podręcznej i wtyczek. Dlatego strona może działać poprawnie na starym hostingu, a po przeniesieniu przestać się uruchamiać.
| Problem | Przyczyna | Jak naprawić |
|---|---|---|
| Biała strona lub błąd krytyczny | Niezgodna wersja PHP, brak rozszerzenia, konflikt wtyczki albo zbyt niski limit pamięci | Sprawdź logi PHP, dopasuj wersję PHP i zwiększ limit pamięci, jeśli pozwala na to konfiguracja serwera |
| Błąd połączenia z bazą danych | Nieprawidłowe wartości DB_NAME, DB_USER, DB_PASSWORD lub DB_HOST |
Porównaj dane w wp-config.php z konfiguracją nowej bazy i sprawdź uprawnienia użytkownika |
| Podstrony zwracają 404 | Nieodtworzone reguły bezpośrednich odnośników lub błędna konfiguracja serwera | Zapisz ponownie ustawienia bezpośrednich odnośników i sprawdź reguły serwera, na przykład .htaccess |
| Brak zdjęć lub plików | Niepełne skopiowanie katalogu wp-content/uploads albo błędne uprawnienia |
Porównaj zawartość katalogów, uzupełnij brakujące pliki i sprawdź właściciela oraz prawa dostępu |
| Nieprawidłowe adresy po zmianie domeny | Niewłaściwa zamiana adresów w bazie, szczególnie w danych serializowanych | Użyj narzędzia rozumiejącego serializację, na przykład wp search-replace z opcją --dry-run |
| Formularze i maile nie działają | Błędna konfiguracja SMTP, brak rekordów SPF lub DKIM albo blokada wysyłki na nowym serwerze | Wykonaj rzeczywisty test formularza, sprawdź konfigurację SMTP oraz rekordy DNS poczty |
| Ostrzeżenie o niezabezpieczonej zawartości | Część skryptów, obrazów lub arkuszy nadal ładuje się przez http:// |
Włącz poprawny certyfikat SSL i zaktualizuj odwołania do zasobów na HTTPS |
Szczególnej uwagi wymagają dane serializowane, używane przez WordPress, motywy i wtyczki. Prosta operacja SQL z funkcją REPLACE() może zmienić długość zapisanych wartości i uszkodzić strukturę danych. Przy zmianie domeny bezpieczniej użyć WP-CLI, wykonać najpierw próbę --dry-run i sprawdzić raport przed właściwą zamianą.
Nie należy też zakładać, że migracja obejmuje pocztę. Skrzynki e-mail, rekordy MX oraz konfiguracja SPF, DKIM i DMARC są osobnym elementem infrastruktury. Strona może działać, a jednocześnie nie wysyłać resetów haseł, wiadomości z formularzy lub potwierdzeń zamówień.
Jak zabezpieczyć migrację WordPressa?
Najbezpieczniej przygotować kopię nowego środowiska i sprawdzić ją przed przełączeniem DNS. Plik hosts pozwala skierować ruch tylko z własnego komputera na nowy serwer, podczas gdy pozostali użytkownicy nadal korzystają ze starej instalacji. Dzięki temu można sprawdzić stronę bez publicznej zmiany adresu.
Przed migracją przygotuj następujące elementy:
- pełny backup plików i bazy danych przechowywany poza przenoszonym serwerem,
- dostęp do starego i nowego hostingu, SSH lub SFTP, bazy danych oraz panelu DNS,
- sprawdzone wersje PHP, bazy danych, rozszerzeń PHP i limity pamięci na nowym serwerze,
- listę formularzy, integracji, zadań CRON, webhooków, usług SMTP, CDN i systemów analitycznych,
- mapę przekierowań, jeśli zmieniają się domena albo adresy URL,
- środowisko testowe zabezpieczone przed przypadkowym indeksowaniem.
Backup powinien być nie tylko utworzony, ale też możliwy do odtworzenia. Przy ważnej stronie dobrze wcześniej wykonać próbne przywrócenie kopii. Nie łącz migracji z wymianą motywu, dużą aktualizacją wtyczek i zmianą wersji PHP, chyba że jest to konieczne. Gdy kilka elementów zmienia się jednocześnie, znalezienie źródła awarii staje się znacznie trudniejsze.
Plan rollbacku powinien określać, jak ponownie skierować ruch na stary serwer, gdzie znajduje się ostatnia poprawna kopia, kto podejmuje decyzję o wycofaniu zmian i jak długo stare środowisko pozostanie aktywne. Nie wyłączaj go natychmiast po zmianie DNS. Część użytkowników może jeszcze trafiać na poprzedni adres IP z powodu pamięci DNS.
Co sprawdzić po przełączeniu DNS?
Sama strona główna nie wystarcza do potwierdzenia, że migracja się udała. Po zmianie DNS sprawdź przede wszystkim:
- logowanie do panelu, reset hasła, role użytkowników i zapis edytowanej treści,
- najważniejsze podstrony, menu, wyszukiwarkę, multimedia i bezpośrednie odnośniki,
- formularze, dostarczanie wiadomości oraz odpowiedzi na właściwe adresy e-mail,
- kody HTTP, przekierowania, robots.txt, znaczniki kanoniczne, mapę XML i ustawienia noindex,
- certyfikat SSL, przekierowanie z HTTP na HTTPS i błędy mieszanej zawartości,
- logi PHP, obciążenie serwera, cache, WP-Cron, zadania systemowe i backupy,
- analitykę, Google Tag Manager, mechanizm zgód i weryfikację w Search Console.
W sklepie WooCommerce trzeba jeszcze wykonać kontrolowane zamówienie testowe i sprawdzić koszyk, płatność, podatki, dostawę, stany magazynowe, wiadomości transakcyjne oraz integracje z kurierem lub systemem księgowym. Największym zagrożeniem jest utrata zamówień złożonych w czasie, gdy część użytkowników nadal trafia na stary serwer.
Notatka ekspercka: migracja to proces, a nie jednorazowy strzał. Pośpiech zwiększa ryzyko, a droga powrotna powinna być przygotowana przed zmianą DNS, nie dopiero po awarii. Najbezpieczniejszy układ to pełny backup, test na pliku hosts, kontrolowane przełączenie i monitoring obu środowisk przez czas potrzebny do potwierdzenia stabilności.
