Checklista po migracji strony WordPress na nowy hosting

Migracja „się udała”. Strona się otwiera. Klient mówi „działa, super”. I w tym właśnie momencie większość problemów zaczyna tylko czekać, żeby się ujawnić, przy pierwszym zamówieniu w WooCommerce, przy aktualizacji wtyczki albo przy wejściu Google bota, który zobaczy coś zupełnie innego, niż powinien.

Przeprowadziliśmy dziesiątki migracji. Małe blogi, rozbudowane sklepy, portale oparte na multisite, strony z latami długu technologicznego i pluginami, które pamiętają WordPressa 4.x. Za każdym razem lista rzeczy do sprawdzenia po migracji jest mniej więcej taka sama. I za każdym razem coś z tej listy, jeśli się ją pominie, wraca jako problem za tydzień.

Poniżej zebraliśmy to, co faktycznie sprawdzamy po przeniesieniu strony na nowy serwer.

1. DNS i propagacja – zanim cokolwiek innego

Zanim zaczniesz cokolwiek klikać w panelu, upewnij się, że wiesz, co właściwie testujesz. Jeśli DNS jeszcze nie propagował się w pełni, możesz przez cache przeglądarki lub lokalny resolver oglądać starą stronę i myśleć, że nowa działa poprawnie.

Używaj dig albo zewnętrznych narzędzi (whatsmydns.net, dnschecker.org), żeby sprawdzić, czy rekordy A wskazują już na nowy serwer. Jeśli testujesz przez plik hosts – pamiętaj, że inne urządzenia i narzędzia zewnętrzne tego nie widzą.

TTL rekordu ustawiony na 3600 to godzina czekania. Jeśli ktoś zapomniał go obniżyć przed migracją, tak to działa.

2. Certyfikat SSL i wymuszanie HTTPS

Sprawdź, czy certyfikat jest ważny, czy jest wystawiony dla właściwej domeny (w tym dla www) i czy HTTPS jest wymuszane poprawnie.

Typowe problemy po migracji:

• certyfikat Let’s Encrypt nie został jeszcze wystawiony na nowym serwerze
• przekierowanie z HTTP na HTTPS jest skonfigurowane w .htaccess albo w Nginx, ale nie działa z powodu nowej konfiguracji vhosta
• WordPress ma w ustawieniach http:// zamiast https://, co powoduje mixed content

W wp-config.php warto sprawdzić, czy nie ma zahardkodowanych wartości, które kłócą się z nowym środowiskiem. Czasem też FORCE_SSL_ADMIN jest ustawione, a certyfikat jeszcze nie gotowy — wtedy panel admina staje się niedostępny.

3. Adresy URL w bazie danych

To jeden z częstszych źródeł problemów po migracji, szczególnie gdy zmienia się domena albo protokół.

Sprawdź siteurl i home w tabeli wp_options. Możesz to zrobić przez WP-CLI:

bash

wp option get siteurl
wp option get home

Jeśli migracja wiązała się ze zmianą domeny, konieczne jest przeszukanie i zamiana adresów w całej bazie — wraz z serializowanymi danymi. Do tego używamy wp search-replace z flagą --dry-run najpierw, żeby zobaczyć skalę zmian:

bash

wp search-replace 'https://stara-domena.pl' 'https://nowa-domena.pl' --dry-run

Bez --dry-run zmiany są nieodwracalne. Backup przed tym krokiem to nie opcja.

Serializowane dane potrafią się rozpaść przy ręcznych zamianach w SQL. WP-CLI obsługuje to poprawnie, phpMyAdmin – niekoniecznie.

4. Pliki, uprawnienia, struktura katalogów

Porównaj strukturę plików ze źródłem. Przy migracji przez rsync, FTP z klientem GUI albo przez menedżer plików w panelu hostingu, każde z tych narzędzi może opuścić ukryte pliki (.htaccess, .env, pliki zaczynające się od .).

Uprawnienia katalogów i plików mają znaczenie:

• katalogi: 755
• pliki: 644
• wp-config.php: 600 lub 640

Na serwerze z suEXEC i PHP-FPM działającym jako użytkownik strony — pliki należące do root lub innego użytkownika mogą być nieczytelne. Widzieliśmy migracje gdzie strona „działała”, ale upload mediów był zepsuty od pierwszego dnia, bo katalog wp-content/uploads miał złe uprawnienia lub złego właściciela.

5. Konfiguracja PHP

Nowy hosting może mieć inną domyślną wersję PHP. To bywa niewinne — albo kończy się białym ekranem i błędami 500 w logach.

Sprawdź:

• wersja PHP (zalecane 8.1 lub 8.2 dla aktualnego WordPressa)
• memory_limit — przy rozbudowanych stronach 256M to minimum
• upload_max_filesize i post_max_size
• max_execution_time
• max_input_vars — szczególnie ważne przy formularzach i stronach produktów WooCommerce z wieloma wariantami

Zdarza się, że stara strona działała na PHP 7.4, a na nowym serwerze domyślnie jest 8.2. Kilka pluginów może nie przeżyć tej różnicy w ciszy, bez widocznego błędu, ale z niepoprawnym działaniem. Query Monitor pomaga wyłapać deprecated notices i fatale ukryte przez konfigurację error_reporting.

6. Baza danych – połączenie i integralność

Sprawdź wp-config.php – dane do bazy (host, nazwa, użytkownik, hasło) muszą być aktualne dla nowego środowiska.

Jeśli baza była eksportowana przez phpMyAdmin i miała kilkaset MB, sprawdź, czy import przebiegł kompletnie. phpMyAdmin ma limity rozmiaru przesyłanego pliku i lubi milczeć przy nieudanym imporcie. Bezpieczniejsze jest użycie WP-CLI lub bezpośrednio mysql w konsoli:

bash

mysql -u użytkownik -p nazwa_bazy < backup.sql

Po imporcie warto uruchomić:

bash

wp db check

I sprawdzić, czy liczba tabel zgadza się z oryginałem.

7. Linki bezwzględne, media i zasoby

Otwórz stronę w przeglądarce i sprawdź konsolę JS oraz zakładkę Network. Szukaj zasobów ładowanych z http:// zamiast https://, albo z nieistniejących już adresów.

Obrazy w treściach CMSa często są zapisane jako bezwzględne URL-e, po zmianie domeny będą wskazywać na starą lokalizację. Jeśli stara strona dalej działa (np. podczas okresu przejściowego) — błąd będzie niewidoczny, ale zasoby będą ładować się ze starego serwera.

Sprawdź też, czy katalog wp-content/uploads został w całości przeniesiony. Przy dużych stronach łatwo o pominięcie podkatalogów albo przerwanie transferu.

8. Maile – formularz, WooCommerce, powiadomienia

To prawie zawsze zawodzi po migracji i prawie zawsze jest odkrywane za późno.

Nowy serwer ma inny adres IP. Jeśli WordPress wysyła maile przez mail() bez skonfigurowanego SMTP — maile mogą lądować w spamie albo w ogóle nie wychodzić, jeśli serwer nie ma poprawnie skonfigurowanego SPF/DKIM dla domeny.

Skonfiguruj SMTP — czy to przez dedykowany plugin (WP Mail SMTP, FluentSMTP), czy bezpośrednio przez zewnętrzną usługę (Mailgun, SendGrid, Brevo). Wyślij testowego maila po migracji. Sprawdź, czy powiadomienia o zamówieniach WooCommerce dochodzą. Sprawdź formularz kontaktowy.

Pięć minut na test maila oszczędza tydzień tłumaczenia klientowi, dlaczego zamówienia z ostatnich dni nie miały potwierdzeń.

9. Cache – co jest skonfigurowane i czy w ogóle działa

Na nowym serwerze konfiguracja cache zaczyna się od zera, chyba że przeniesiono też konfigurację serwera.

Sprawdź:

• czy plugin cache (LiteSpeed Cache, W3 Total Cache, WP Rocket) jest poprawnie skonfigurowany pod nowe środowisko
• czy nie ma konfliktu między cache pluginu a cache na poziomie serwera (Nginx FastCGI cache, OPcache, Redis object cache)
• czy cache nie serwuje strony zalogowanym użytkownikom, to klasyczny błąd po „przekopiowaniu” ustawień

Jeśli nowy hosting to VPS z Nginx i wcześniej była konfiguracja pod Apache .htaccess z dyrektywami cache i przekierowaniami nie będzie działał. Trzeba przepisać reguły pod Nginx.

Redis jako object cache wymaga osobnej konfiguracji – wp-config.php musi mieć poprawne dane połączenia do nowego Redis instance.

10. Przekierowania i struktura permalinków

Po migracji wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany” bez żadnych zmian. To odświeża reguły rewrite w .htaccess. Bez tego, podstrony mogą zwracać 404, mimo że strona główna działa.

Jeśli strona miała zdefiniowane przekierowania 301 (czy to przez plugin, czy przez .htaccess), sprawdź, czy działają na nowym serwerze.

Przy zmianie domeny – przekierowania z oldomain.pl na newdomain.pl muszą być skonfigurowane po stronie serwera lub przez Cloudflare, jeśli stary DNS tam był zarządzany.

11. Wtyczki i motywy – test funkcjonalny

Nie wystarczy, że strona się otwiera. Przejdź przez krytyczne ścieżki użytkownika:

• dodanie produktu do koszyka i przejście do kasy
• wypełnienie formularza kontaktowego
• logowanie i panel klienta
• wyszukiwarka
• filtrowanie produktów
• strony generowane dynamicznie (blog, archiwum, kategorie)

Zwróć uwagę na błędy JavaScript w konsoli, mogą wskazywać na problemy z enqueue skryptów albo konfliktami wersji.

12. Cron WordPress i zewnętrzne crony

WordPress ma wbudowany pseudocron (wp-cron.php), który odpala się przy każdym wejściu na stronę. Na nowych, spokojnych środowiskach może nie odpalać się regularnie.

Jeśli strona wysyła mailingi, generuje raporty, odświeża dane zewnętrzne — warto skonfigurować prawdziwy cron systemowy wywołujący WP-CLI:

bash

*/15 * * * * /usr/bin/wp cron event run --due-now --path=/var/www/html --quiet

Sprawdź też, czy zadania cronowe działają po migracji. Pluginy do backupów (np. UpdraftPlus), subskrypcje WooCommerce, automatyczne aktualizacje — wszystko to opiera się na cronie.

---

13. Backup na nowym serwerze

Tak — zaraz po migracji. Jeszcze przed poinformowaniem klienta, że „wszystko gotowe”.

Konfiguracja backupów to pierwszy krok na nowym środowisku, nie ostatni. Backup powinien być offsite — nie na tym samym VPS co strona. S3, Wasabi, Backblaze B2 — cokolwiek, co fizycznie nie jest na tym samym serwerze.

Testuj przywracanie. Backup, którego nigdy nie przywracano, jest tylko teorią.

---

14. Monitoring

Nowy serwer to nowe środowisko, które może zachowywać się inaczej pod obciążeniem. Ustaw monitoring dostępności strony (UptimeRobot w darmowym planie wystarczy na start), sprawdź logi serwera przez pierwsze 24-48 godzin.

Jeśli wcześniej był skonfigurowany Fail2Ban albo reguły na poziomie Cloudflare — sprawdź, czy działają na nowym serwerze.

15. Google Search Console i indeksowanie

Jeśli zmieniała się domena, dodaj nową do Google Search Console i prześlij sitemap. Jeśli domena ta sama, ale zmienił się serwer — sprawdź, czy Google nie dostaje niespodziewanych błędów 404 lub 500.

Weryfikacja strony w GSC też może wymagać odnowienia, jeśli plik weryfikacyjny był na starym serwerze.

Checklita po migracji strony WordPress

Migracja kończy się dopiero wtedy, gdy sprawdzono wszystkie krytyczne ścieżki, nie wtedy, gdy strona się otwiera.

Minimum do odhaczenia po każdej migracji:

Kilka z tych punktów wygląda banalnie. Ale to właśnie te banalne punkty są pomijane najczęściej.