Przeniesienie strony WordPress na inny serwer bez przestoju

Przygotowanie przed migracją z inwentarzem i obniżeniem TTL

Przeprowadzka zaczyna się dzień albo dwa przed kopiowaniem plików. Spisz, co działa na starym serwerze: wersję PHP i rozszerzenia (imagick, intl, sodium, zip), limity pamięci, zadania cron, konta pocztowe w tej samej domenie, przekierowania w pliku .htaccess albo w konfiguracji serwera, certyfikat SSL. Sprawdź, gdzie jest obsługiwana strefa DNS i kto ma do niej dostęp, bo bez tego przełączenia nie zrobisz. Najważniejszy krok przygotowania to obniżenie TTL rekordów A i AAAA (oraz CNAME dla www) do 300 sekund co najmniej dobę przed migracją. Resolwery w sieci zapamiętują stary adres na tyle sekund, ile wynosi TTL, więc przy TTL równym 86 400 część odwiedzających trafia na stary serwer jeszcze przez dobę.

• Wersja PHP na nowym serwerze taka sama albo zgodna z wtyczkami, nie od razu najnowsza.
• Lista zadań cron i skryptów uruchamianych poza WordPressem.
• Rekordy MX, SPF, DKIM i DMARC zapisane przed jakąkolwiek zmianą strefy.
• Dostęp do rejestratora domeny i panelu DNS sprawdzony, a nie tylko obiecany.

Pełna kopia plików i bazy danych

Zrób dwie rzeczy osobno: zrzut bazy danych i archiwum plików. Bazę najwygodniej wyeksportować poleceniem wp db export albo mysqldump z opcją single-transaction, która nie blokuje tabel InnoDB w trakcie zrzutu. Pliki pakujesz w całości (wp-content, wp-config.php, .htaccess, pliki weryfikacyjne w katalogu głównym), a na nowy serwer przenosisz je przez rsync albo scp, nie przez wtyczkę działającą w przeglądarce, która przy dużych katalogach uploads przerywa pracę na limicie czasu PHP. Sprawdź, czy archiwum da się rozpakować, a zrzut bazy ma na końcu komunikat o zakończeniu. Kopia, której nikt nie otworzył, nie jest kopią. Więcej o tym, jak planować kopie i ile je trzymać, piszemy w tekście o tym, jak działa kopia zapasowa WordPress.

• Zrzut bazy z kodowaniem utf8mb4, bez zmiany sortowania tabel.
• Pliki z zachowaniem uprawnień: katalogi 755, pliki 644, wp-config.php 640 albo 600.
• Katalogi cache i kopii tworzonych przez wtyczki pominięte, bo tylko zwiększają archiwum.

Konfiguracja nowego serwera i wp-config.php

Na nowym serwerze zakładasz bazę i osobnego użytkownika z uprawnieniami tylko do niej, importujesz zrzut i wgrywasz pliki. W wp-config.php zmieniasz dane dostępowe do bazy (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) i sprawdzasz prefiks tabel, który musi się zgadzać z bazą. To dobry moment, żeby wygenerować nowe klucze i sole: wyloguje to wszystkich użytkowników, ale unieważni sesje skopiowane ze starego serwera. Ustaw też DISABLE_WP_CRON na true i dodaj prawdziwe zadanie cron serwera, które co pięć minut wywołuje wp cron event run. Dzięki temu zaplanowane zadania (wysyłka maili, odnawianie subskrypcji WooCommerce, kopie) nie zależą od tego, czy ktoś akurat odwiedził stronę.

• Wersja PHP i rozszerzenia jak w inwentarzu, OPcache włączony.
• memory_limit i max_execution_time dopasowane do wtyczek, a nie ustawione na maksimum.
• Serwer WWW z obsługą HTTP/2 lub HTTP/3 i kompresją Brotli albo gzip.

Zamiana adresów w bazie bez uszkodzenia danych

Jeśli domena się nie zmienia, zamiana adresów nie jest potrzebna. Jeśli zmienia się domena, protokół albo katalog, nigdy nie rób zamiany zwykłym zapytaniem SQL ani w edytorze tekstu na pliku zrzutu. WordPress i wiele wtyczek zapisuje ustawienia w postaci serializowanej, w której obok tekstu zapisana jest jego długość. Zmiana adresu na dłuższy lub krótszy psuje taki zapis i ustawienia widgetów, kreatora stron albo motywu po cichu znikają. Poprawna droga to polecenie wp search-replace, które rozpakowuje dane serializowane, zamienia tekst i zapisuje je z nową długością. Najpierw uruchom je z opcją dry-run, żeby zobaczyć, ile wierszy zmieni, a dopiero potem naprawdę. Pomiń kolumnę guid w tabeli wpisów, bo to identyfikator, a nie link.

Test strony na nowym serwerze przed zmianą DNS

Nową kopię sprawdzasz, zanim zobaczy ją ktokolwiek poza Tobą. Najprostszy sposób to wpis w pliku hosts na swoim komputerze, który kieruje domenę na nowy adres IP. Przeglądarka otwiera wtedy nowy serwer pod prawdziwą domeną, więc cookies, przekierowania i certyfikat zachowują się tak, jak po migracji. Certyfikat możesz wystawić wcześniej przez walidację DNS, bez czekania na zmianę rekordu A.

• Strona główna, kilka podstron i wpisów, wyszukiwarka i strona błędu 404.
• Logowanie do panelu i zapis dowolnej zmiany.
• Formularz kontaktowy z prawdziwym wysłaniem wiadomości.
• W sklepie: koszyk, zamówienie testowe, bramka płatności w trybie testowym, maile do klienta.
• Log błędów PHP po przeklikaniu strony: każde ostrzeżenie o przestarzałej funkcji to sygnał przed aktualizacją PHP.
• Pomiar LCP, INP i CLS, żeby mieć punkt odniesienia po przełączeniu.

Przełączenie DNS bez przestoju i bez utraty zamówień

Na stronie firmowej bez zamówień przestój praktycznie nie istnieje: zmieniasz rekord A, a przez kilka minut część osób widzi starą kopię, która wygląda identycznie. Problem pojawia się, gdy strona zbiera dane: zamówienia, zapisy, komentarze, zgłoszenia z formularzy. Wszystko, co trafi do starej bazy po zrobieniu zrzutu, zniknie po przełączeniu. Dlatego w sklepie robimy migrację w dwóch przebiegach. Pierwszy przebieg to pełne przeniesienie i testy. Drugi to krótkie okno w godzinach najmniejszego ruchu: włączasz tryb konserwacji albo blokadę składania zamówień na starym serwerze, robisz ponowny zrzut samej bazy, importujesz go na nowym serwerze i dopiero wtedy zmieniasz DNS. Przy TTL obniżonym wcześniej do 300 sekund okno trwa zwykle kilkanaście minut. Jeśli sklep nie może się zatrzymać nawet na tyle, stary serwer można zamienić w pośrednika (reverse proxy), który przekazuje ruch na nowy adres, dopóki wszystkie resolwery nie pobiorą nowego rekordu.

• Nie zmieniaj serwerów nazw (NS) domeny w tym samym dniu co rekordu A, chyba że musisz. Zmiana NS ma własne, długie TTL w strefie nadrzędnej.
• Nie wyłączaj starego serwera od razu. Zostaw go co najmniej na tydzień jako kopię i punkt odwrotu.
• Po zmianie DNS sprawdź z kilku sieci, na przykład z telefonu bez Wi-Fi, czy odpowiedź przychodzi z nowego IP.

Lista kontrolna po przeniesieniu strony WordPress

Pierwsza doba po migracji to czas na rzeczy, których nie widać od razu. Najczęściej psuje się wysyłka maili: stary serwer wysyłał je lokalnie, a nowy nie ma skonfigurowanej poczty albo jego adres IP nie jest w rekordzie SPF domeny. Dobra praktyka to wysyłka przez zewnętrzny serwer SMTP z uwierzytelnieniem i podpisem DKIM, niezależnie od hostingu. Drugi częsty problem to cache: wtyczka cache albo CDN trzyma strony wygenerowane jeszcze na starym serwerze, z adresami obrazów, które już nie istnieją.

• Wysyłka maili z formularzy i ze sklepu, a w nagłówkach wiadomości wynik SPF i DKIM równy pass.
• Wyczyszczony cache wtyczki, OPcache i CDN.
• Zadanie cron serwera działa, a lista zaplanowanych zadań w WordPressie nie ma zaległości.
• Kopie zapasowe działają już na nowym serwerze i zapisują się poza nim.
• Monitoring dostępności wskazuje nowy adres, a certyfikat ma odnowienie automatyczne.
• Google Search Console bez nowych błędów indeksowania, mapa strony dostępna.

Najczęstsze błędy przy migracji WordPressa

Większość awarii po przeprowadzce ma kilka powtarzalnych przyczyn. Biały ekran zaraz po imporcie to zwykle niezgodna wersja PHP albo brakujące rozszerzenie, a komunikat o błędzie połączenia z bazą to literówka w wp-config.php albo DB_HOST ustawiony na nazwę starego serwera. Pętla przekierowań pojawia się, gdy serwer stoi za proxy lub CDN, a WordPress nie wie, że połączenie jest szyfrowane: pomaga poprawne przekazanie nagłówka X-Forwarded-Proto. Brakujące obrazy to niedokończone kopiowanie katalogu uploads albo złe uprawnienia plików. Gdy strona po migracji po prostu nie wstaje, opisujemy dalsze kroki na stronie nie działa strona internetowa.

• Import bazy przez phpMyAdmin przerwany na limicie rozmiaru pliku, bez komunikatu o błędzie.
• Zamiana adresów zapytaniem SQL, która uszkodziła dane serializowane.
• Stary serwer wyłączony tego samego dnia, bez kopii i bez drogi powrotu.
• Zmiana strefy DNS bez przepisania rekordów MX, po której przestaje działać poczta firmowa.