Migracja WordPress na nowy hosting - kompletny poradnik krok po kroku

Powodem do migracji może być brak obsługiwanej wersji PHP, powtarzające się ograniczenia zasobów, trudności z odtworzeniem kopii albo zakres wsparcia niedopasowany do strony. Sam niski wynik testu szybkości nie przesądza, że winny jest hosting. Ciężki motyw lub wolna integracja mogą działać podobnie po przeprowadzce. Najpierw sprawdź, co faktycznie ogranicza stronę i czy obecny operator potrafi to rozwiązać.

Porównaj pojemność plików i poczty, rozmiar bazy, dostępne wersje środowiska, harmonogramy oraz zasady kopii. Zapytaj nowego operatora, czy przenosi także skrzynki, zadania i niestandardową konfigurację. Bezpłatna migracja hostingu nie musi obejmować naprawy niezgodnej wtyczki. Zakres płatnej pomocy opisuje migracja WordPressa; ten poradnik dotyczy przebiegu prac, nie wyceny.

Zapisz aktualne ustawienia DNS, publiczne adresy strony, sposób obsługi HTTPS i lokalizację poczty. Sprawdź również zadania cykliczne, połączenia z CRM lub ERP, wysyłkę wiadomości, ograniczenia adresów IP i źródła plików przechowywanych poza WordPressem. Migracja plików aplikacji nie przenosi automatycznie tych zależności.

Nowe środowisko musi obsługiwać używane rozszerzenia PHP i dodatki. WordPress rekomenduje PHP 8.3 lub nowsze, MySQL 8.0 lub MariaDB 10.11 i HTTPS. Są to zalecenia środowiska, a nie potwierdzenie zgodności konkretnego motywu. Nie łącz przeprowadzki z nieprzetestowaną zmianą wersji wszystkiego naraz.

Plan cofnięcia powinien wskazywać, kto przywraca ruch, gdzie jest ostatnia dobra kopia i co zrobić z zapisami powstałymi po przełączeniu. Sam powrót starego rekordu DNS nie odzyska nowych zamówień z drugiego serwera.

Kopia powinna zawierać bazę danych oraz potrzebne pliki, w tym media, motywy, wtyczki i konfigurację. Sprawdź, czy narzędzie nie pomija dużych katalogów albo własnych tabel. Zachowaj informację o momencie wykonania eksportu. W aktywnym sklepie baza z rana i pliki z wieczora mogą przedstawiać inny stan.

Przechowuj kopię poza publicznym katalogiem strony i ogranicz dostęp. Nie zostawiaj pliku backup.sql ani archiwum do pobrania przez każdego, kto pozna adres. Nie przesyłaj hasła do bazy w zwykłej wiadomości razem z eksportem.

Najlepszym potwierdzeniem kopii jest odtworzenie w odizolowanym środowisku. Sprawdź panel, treści i media. Sam komunikat ukończonego eksportu nie dowodzi kompletności. Jeśli korzystasz z tej wtyczki, zobacz kopie w UpdraftPlus.

Możesz skorzystać z migracji operatora, wtyczki albo ręcznego przeniesienia przez administratora. Wybór zależy od dostępu do serwera, rozmiaru danych, nietypowych tabel i tego, czy strona może na krótko wstrzymać zapisy. Nie ma jednej granicy rozmiaru, po której każda wtyczka przestaje działać.

All-in-One WP Migration pokazuje ograniczenia importu związane ze środowiskiem; opisuje je instrukcja producenta. Nie traktuj 512 MB jako stałego limitu wszystkich wersji. Według oferty Unlimited Extension, sprawdzonej 12.09.2026, licencja Standard kosztuje 69 USD rocznie i obejmuje do 50 witryn. To abonament, nie dawna opłata jednorazowa.

Duplicator korzysta z archiwum i instalatora. Dokumentacja instalatora opisuje ochronę dostępu i końcowe sprzątanie. Instalację kieruj do przygotowanego miejsca docelowego, po potwierdzeniu, że nie nadpiszesz cudzej witryny. Migrację ręczną wybierz, gdy potrafisz sprawdzić eksport, uprawnienia, konfigurację bazy i reguły serwera.

Na nowym hostingu utwórz właściwą bazę i konto z zakresem potrzebnym tej instalacji. Dane połączenia mogą być inne niż u poprzedniego operatora. Nie zakładaj, że host bazy zawsze ma wartość localhost. Hasła i pliki konfiguracyjne udostępniaj wyłącznie przez uzgodniony bezpieczny kanał.

Dokumentacja migracji WordPressa mówi: "If database name or user changes, edit wp-config.php to have the correct values." Oznacza to dostosowanie połączenia, a nie obowiązkową zmianę adresu publicznego.

Jeśli domena i ścieżki URL pozostają takie same, nie wykonuj automatycznie search-replace. Gdy rzeczywiście zmieniasz adres, użyj narzędzia obsługującego serializację, po wykonaniu kopii i próby bez zapisu. WP-CLI udostępnia --dry-run oraz ograniczenie tabel. Opcja --all-tables obejmuje również inne prefiksy we wspólnej bazie, więc nie jest bezpiecznym domyślnym wyborem. Zwykłe SQL REPLACE może uszkodzić dane serializowane.

Stronę można sprawdzić pod docelową domeną, kierując ją lokalnie na nowy adres IP. Dzięki temu przeglądarka używa właściwej nazwy hosta, a pozostali użytkownicy nadal trafiają na starą stronę. Warto zlecić przygotowanie takiego testu administratorowi, jeżeli nie masz doświadczenia z lokalnym mapowaniem domen.

Administrator może sprawdzić odpowiedź HTTPS poleceniem poniżej. Zamień example.com na własną domenę, a dokumentacyjny adres 203.0.113.10 na IP nowego hostingu. Polecenie pobiera nagłówki i treść do terminala; nie zmienia publicznego DNS ani plików strony.

curl --resolve example.com:443:203.0.113.10 --include https://example.com/

Opcja --resolve zachowuje nazwę domeny dla HTTPS i weryfikacji certyfikatu, co wyjaśnia dokumentacja curl. Sprawdź kod odpowiedzi, Location przy przekierowaniu i treść strony. Powtórz dla ważnej podstrony oraz osobno wariantu www, jeśli go używasz. Ten test nie sprawdza działania interfejsu przeglądarki ani wszystkich zasobów. Nie dodawaj -k, aby ukryć błąd certyfikatu.

Nowy serwer musi poprawnie obsługiwać certyfikat dla tej nazwy. Nie pomijaj ostrzeżenia HTTPS, bo po przełączeniu zobaczą je również klienci. Certyfikat można przygotować odpowiednią metodą weryfikacji domeny albo bezpiecznie przenieść, zależnie od jego rodzaju i konfiguracji. Pomocny jest poradnik SSL w WordPressie.

Przetestuj menu, podstrony, media, panel i przekierowania. Kopię zabezpiecz przed publicznym dostępem i odłącz od rzeczywistych wysyłek, płatności oraz integracji. Test formularza lub checkout wykonuj w kontrolowanym trybie. Uzgodnij odbiorcę i oznaczenie testowej wiadomości; na kopii wykorzystaj skrzynkę testową lub przechwycenie wysyłki.

Na stronie informacyjnej można uzgodnić krótkie wstrzymanie edycji. W sklepie dochodzą zamówienia, stany, konta i płatności, więc zwykłe skopiowanie bazy nie wystarcza. Ustal jedno miejsce przyjmujące zapisy oraz końcową synchronizację albo zaplanowaną przerwę w sprzedaży. Nie pozwól, aby dwa serwery niezależnie przetwarzały ten sam proces.

Sprawdź zadania cykliczne i kolejki. Duplikat zadania może ponownie wysłać wiadomość lub przekazać dane do systemu zewnętrznego. Na kopii pozostają wyłączone do ustalonego momentu przejęcia obsługi. Jeśli potrzebujesz pomocy z takim zakresem, zobacz migracje i integracje WooCommerce.

Poczta może pozostać u dotychczasowego operatora. Wtedy zachowaj jej rekordy MX i potrzebne TXT. Przy migracji skrzynek osobno zaplanuj skopiowanie wiadomości, zmianę konfiguracji urządzeń oraz końcowe wyrównanie. Przeniesienie WordPressa nie jest dowodem przeniesienia poczty.

Przed zmianą sprawdź rekordy A, AAAA, CNAME oraz wariant www. Nie zostawiaj starego IPv6, gdy IPv4 prowadzi już do nowego serwera. Przy zmianie serwerów nazw sprawdź także DNSSEC. Zachowaj rekordy usług, które nie są przenoszone.

Google opisuje zmianę hostingu bez zmiany URL jako przygotowanie, test, przełączenie i monitoring. Mniejszy TTL ustawiony wcześniej może przyspieszyć odświeżanie, ale nie usuwa rekordów już zapisanych w pamięci resolverów. Nie obiecuj jednej godziny propagacji dla wszystkich użytkowników.

Po przełączeniu sprawdź odpowiedzi HTTP, HTTPS, canonical, robots i brak testowego noindex. Zachowaj weryfikację Search Console. Usuń publiczne instalatory i archiwa zgodnie z instrukcją Duplicatora. Stary hosting wyłącz dopiero po potwierdzeniu ruchu, zapisów i poczty. Przy błędzie 500 skorzystaj z osobnej procedury diagnostycznej.

Potrzebujesz wsparcia? W kontakcie wystarczy adres strony i opis planowanych przenosin lub błędu. Dane dostawców i rozmiar kopii można doprecyzować później. Zakres pracy nad stroną znajdziesz w usługach WordPress.

Jeśli przenosisz stronę, bo przestała odpowiadać firmie, porównaj koszt migracji z ceną nowej strony internetowej od 3 500 zł netto.