WordPressa przenosisz na inny hosting przez skopiowanie plików i bazy danych, połączenie ich na nowym serwerze oraz zmianę wskazania domeny. Adres strony może pozostać taki sam. Najpierw uruchamiasz i sprawdzasz kopię, a dopiero później kierujesz do niej odwiedzających.
Poniżej znajdziesz ręczną metodę dla pojedynczej strony firmowej lub bloga, z zachowaniem domeny, HTTPS i adresów podstron. Wymaga dostępu do plików, panelu hostingu i phpMyAdmin. Metoda zakłada zaplanowaną przerwę w dostępności strony dla odwiedzających. Nowe konto, pustą bazę, zabezpieczony podgląd i działające HTTPS przygotowujesz przed rozpoczęciem tej przerwy. Poczta zostaje u dotychczasowego dostawcy. Przy sklepie lub rezerwacjach dochodzi synchronizacja zamówień; sieć WordPress Multisite również wymaga planu uwzględniającego całą instalację.
Kolejność przygotowań i kontroli możesz zaznaczać w planerze migracji strony i poczty. Wybierz samą stronę albo stronę z pocztą — lista uwzględni wybrany zakres.
Migracja przez hosting, wtyczkę czy ręcznie?
Gdy chcesz po prostu zmienić dostawcę, a nie zajmować się kopiowaniem danych, zacznij od jego usługi migracji. Przekazujesz dostępy uzgodnionym kanałem, wskazujesz strony i ustalasz, kto sprawdzi wynik. Zakres ofert porównasz w zestawieniu hostingów z migracją. Osobno potwierdź przeniesienie poczty — wiadomości nie znajdują się w bazie WordPressa.
Warunki migracji Hostido opisują bezpłatne przeniesienie z jednego konta źródłowego na jedno docelowe, zależne od zgodności aplikacji; kolejne migracje na to samo konto są płatne. Jeśli ten zakres pasuje do Twojej sytuacji, możesz zobaczyć pakiety Hostido (link partnerski). Przed zakupem potwierdź zakres dla swojej instalacji.
Wtyczka migracyjna pakuje dane i pomaga odtworzyć je u nowego dostawcy. Jedną z takich metod pokazuje materiał szkoleniowy WordPressa. Przed wyborem konkretnej wtyczki porównaj rozmiar kopii z ograniczeniami jej importu i nowego hostingu.
Metoda ręczna daje kontrolę nad plikami i docelową bazą. Dalsze kroki prowadzą właśnie tą drogą. Jeśli nie masz dostępu do któregoś z tych elementów, poproś operatora o jego udostępnienie albo zleć mu kopiowanie, korzystając z opisanych niżej zasad sprawdzenia strony.
1. Przygotuj nowe konto i zbierz dane obecnej strony
Dodaj domenę do nowego konta hostingowego, ale pozostaw jej publiczne wskazanie na stary serwer. Nowy operator powinien podać katalog przeznaczony na pliki tej domeny, adres serwera do przesyłania plików i docelowy adres IP. Nie musi to być ten sam adres, którego używasz do logowania do panelu. Sprawdź dostęp do obu paneli i możliwość przesyłania plików, zanim wyznaczysz przerwę.
Zaloguj się do obecnego WordPressa i otwórz Narzędzia → Stan witryny → Informacja. Znajdziesz tam m.in. wersje środowiska oraz rozmiary katalogów i bazy. Opis ekranu stanu witryny pomoże odszukać te dane. Zapisz również adresy z Ustawienia → Ogólne i używaną strukturę bezpośrednich odnośników.
Nowy pakiet musi pomieścić pliki i bazę oraz obsługiwać PHP, bazę danych i rozszerzenia potrzebne Twojej instalacji. Wymagania WordPressa są podstawą; uwzględnij też motyw i wtyczki. Przeprowadzka będzie prostsza, gdy nie połączysz jej z wymianą motywu i dużą aktualizacją aplikacji.
| Co przygotować | Do czego będzie potrzebne |
|---|---|
| Dostęp do obu kont hostingowych i plików | Pobranie instalacji, wgranie jej kopii i sprawdzenie logów |
| Nazwa obecnej bazy i dostęp do phpMyAdmin | Eksport właściwych danych |
| Dostęp do aktywnej strefy DNS | Skierowanie domeny na nowy serwer po testach |
| Aktualne rekordy domeny oraz miejsce obsługi poczty | Zachowanie potrzebnych usług i możliwość cofnięcia zmiany |
| Miejsce na kopię poza hostingiem | Odtworzenie strony również bez dostępu do starego konta |
Zachowaj zapis rekordów DNS wraz z ich TTL, czyli czasem przechowywania odpowiedzi w pamięci podręcznej. Obniżenie TTL przed migracją może skrócić przejście na nowy adres, ale wcześniej zapisane odpowiedzi zachowują swój poprzedni czas ważności. Zmianę zaplanuj z wyprzedzeniem, zgodnie z zasadami TTL u dostawcy DNS. Pełną kolejność zmiany rekordów WWW i poczty opisuje poradnik DNS i TTL przy zmianie hostingu.
Przygotuj pustą bazę i sposób rozpoczęcia przerwy
Na nowym hostingu utwórz osobną, pustą bazę oraz użytkownika przypisanego do tej bazy. W cPanel służy do tego kreator baz, w DirectAdmin sekcja zarządzania MySQL. Zasady tworzenia bazy i nadawania użytkownikowi uprawnień do niej pokazuje instrukcja WordPressa dla paneli hostingowych. Zachowaj pełne nazwy nadane przez panel, łącznie z ewentualnym prefiksem konta.
Otwórz nową bazę w phpMyAdmin i sprawdź, że jest pusta. Jeszcze teraz ustal limit rozmiaru importu. Jeżeli Twoja kopia go przekroczy, umów import po stronie operatora przed terminem prac. Zapisz również sposób wstrzymania i wznowienia zadań cyklicznych tej strony oraz dane potrzebne do cofnięcia zmiany DNS.
Pocztę pozostawiasz w dotychczasowym miejscu. Sprawdź jednak, czy jej rekord MX nie wskazuje tej samej nazwy, której adres IP zamierzasz zmienić. W takiej konfiguracji sam brak edycji MX nie zachowa starego serwera poczty — jego wskazanie trzeba wcześniej rozdzielić z pomocą operatora. Podobnie potwierdź potrzebne ustawienia wysyłania wiadomości z nowej strony.
U obecnego operatora przygotuj możliwość włączenia krótkiej przerwy z odpowiedzią HTTP 503, zanim żądanie uruchomi WordPressa. Ma obejmować również bezpośrednie adresy formularzy, API i logowania, a nie tylko stronę główną. Ustal sposób jej włączenia i cofnięcia; jeśli potrzebny jest dostęp przez przeglądarkę dla osoby przenoszącej stronę, uzgodnij wyjątek dla jej adresu IP. Zachowaj dotychczasowe reguły przed ich zmianą. Uzgodnij też pozostawienie dotychczasowego robots.txt z kodem 200; jeśli generuje go WordPress, operator może wcześniej przygotować jego niezmienioną treść jako plik statyczny. Samą przerwę włączysz dopiero w kroku 2.
Sprawdź podgląd i HTTPS przed przerwą
Przed wgraniem WordPressa zabezpiecz katalog nowej domeny przed publicznym dostępem. Na przykład w cPanel funkcja Directory Privacy pozwala wskazać katalog, włączyć ochronę i utworzyć użytkownika z hasłem. Jeśli ochrona jest zapisana w .htaccess, jej reguły trzeba zachować przy wgrywaniu plików ze starego serwera. Operator może zamiast tego założyć ograniczenie na poziomie konfiguracji serwera.
Jeszcze przy działającej starej stronie przygotuj na nowym serwerze certyfikat dla swojej domeny i używanego wariantu www. Powinien być zaufany przez przeglądarkę także przy bezpośrednim podglądzie nowego serwera. Przy niezmienionym publicznym wskazaniu WWW operator może potwierdzić domenę np. metodą DNS-01, wykorzystującą rekord TXT. Sama zmiana pliku hosts na komputerze nie potwierdza domeny wystawcy certyfikatu.
Do sprawdzenia nowego serwera pod dotychczasowym adresem użyj lokalnego pliku hosts. Zmieniasz wskazanie tylko na swoim komputerze. Publiczny DNS nadal prowadzi do starego serwera, co wyjaśnia instrukcja podglądu przez hosts.
W Windows wykonaj kopię pliku C:\Windows\System32\drivers\etc\hosts, otwórz Notatnik jako administrator i wczytaj ten plik. W razie potrzeby ustaw wyświetlanie wszystkich plików. Dopisz własny nowy adres IP oraz nazwy domeny. Poniższy adres IP jest wyłącznie przykładowy:
203.0.113.10 example.com
203.0.113.10 www.example.comZapisz plik bez dopisywania rozszerzenia .txt i uruchom przeglądarkę ponownie. Dostępną alternatywą w Windows jest Hosts File Editor w Microsoft PowerToys: dodajesz adres IP, nazwę hosta i aktywujesz wpis. Na macOS lub Linuksie użyj instrukcji dla swojego systemu, zachowując ten sam układ wpisów.
Potwierdź, że rzeczywiście trafiasz na nowy serwer. Wgraj tylko do jego katalogu WWW plik tekstowy o unikalnej nazwie, np. migracja-7f3a-check.txt, z krótkim tekstem „nowy serwer”, a potem otwórz go pod domeną. Nie wpisuj do niego konfiguracji ani danych dostępowych. Jeśli go nie widzisz, sprawdź wskazany adres IP, nazwę domeny i katalog, do którego trafił plik.
Przy ostrzeżeniu certyfikatu popraw konfigurację, zanim rozpoczniesz przerwę na starej stronie. Nie dodawaj wyjątku bezpieczeństwa. Gdy przed stroną działa Cloudflare, lokalny podgląd może ominąć jego warstwę; po przełączeniu sprawdzisz również publiczną drogę przez Cloudflare i połączenie do nowego serwera. Zasady weryfikacji certyfikatu serwera źródłowego opisuje tryb Full (strict).
Po sprawdzeniu nowego serwera usuń na razie dodane wpisy z pliku hosts i uruchom przeglądarkę ponownie. Zachowaj ich treść do późniejszego podglądu, a plik kontrolny pozostaw na nowym koncie do końca testów. Przy rozpoczęciu przerwy musisz móc sprawdzić odpowiedź starego serwera, nie lokalnie wskazanej kopii.
Do końcowego kopiowania przejdź dopiero, gdy działają dostępy do obu kont, nowa baza jest gotowa, plik kontrolny otwiera się przez prawidłowe HTTPS, a sposób włączenia przerwy jest ustalony. Oczekiwanie na certyfikat lub pomoc przy konfiguracji nie powinno odbywać się już po wyłączeniu starej strony.
2. Wstrzymaj zmiany i wykonaj kompletną kopię
Pliki i baza muszą opisywać ten sam stan strony. Na czas końcowego kopiowania przerwij publikowanie, aktualizacje i zapisy od odwiedzających. W tej metodzie akceptujesz przerwę techniczną. Dla dużej witryny, której przesyłanie trwa długo, lepszy będzie wcześniejszy transfer roboczy i końcowa synchronizacja wykonana przez administratora.
Zablokuj nowe zapisy, także te wykonywane w tle
W zaplanowanym terminie włącz przygotowaną odpowiedź HTTP 503 Service Unavailable z informacją o przerwie. Żądania odwiedzających mają zatrzymać się przed uruchomieniem aplikacji. Taki status Google zaleca przy krótkotrwałym wyłączeniu strony. Nie zastępuj go odmową dostępu 403 ani planszą zwracaną ze statusem 200. Sprawdź również, że przygotowany robots.txt nadal zwraca kod 200 i nie dostał blokady całej witryny.
Sprawdź wynik z połączenia, którego adres IP nie został dopuszczony do aplikacji, i bez lokalnych wpisów hosts dla tej domeny. W Chrome otwórz narzędzia deweloperskie, wybierz Network / Sieć, wyłącz pamięć podręczną opcją Disable cache i odśwież stronę. Kliknij żądanie dokumentu, a w Headers / Nagłówki → General / Ogólne sprawdź kod odpowiedzi. Widok nagłówków ma pokazać 503. Powtórz kontrolę dla strony formularza i adresu logowania, bez wysyłania formularza. Sam napis „503” w treści nie potwierdza kodu odpowiedzi serwera.
WP-Cron uruchamia zadania WordPressa przy wejściach na stronę. Najpierw zachowaj kopię pliku wp-config.php. W działającej instalacji dodaj na czas prac poniższą definicję przed wczytaniem wp-settings.php. Gdy już istnieje, zmień jej wartość zamiast dopisywać drugą:
define( 'DISABLE_WP_CRON', true );To zatrzymuje automatyczne wywołania przy wejściach, nie wyłącza jednak zewnętrznego harmonogramu wywołującego WordPressa. W panelu hostingu wstrzymaj również zadania tej strony, a w używanych usługach — automatyczne publikacje i synchronizacje. Zapisz, co wyłączasz, żeby później wznowić to tylko na właściwym serwerze. Przed eksportem poczekaj również na zakończenie już trwających zadań. Jeśli nie potrafisz ustalić, skąd napływają zmiany, potrzebujesz pomocy osoby obsługującej te integracje.
Pobierz bazę i pliki
Nazwę bazy odczytaj z ustawienia DB_NAME w obecnym wp-config.php. W phpMyAdmin wybierz tę bazę, przejdź do Eksport i zapisz ją w formacie SQL. Dla bazy używanej wyłącznie przez tę instalację wybierz wszystkie tabele, także należące do wtyczek. Przy bazie wspólnej dla kilku aplikacji najpierw ustal właściwy zestaw tabel. Instrukcja eksportu bazy WordPressa opisuje wybór bazy, tabel i formatu.
Następnie pobierz cały katalog instalacji wraz z podkatalogami i plikami ukrytymi. W kopii powinny znaleźć się m.in. wp-admin, wp-includes, całe wp-content, wp-config.php i używany .htaccess. Jeśli konfiguracja wskazuje pliki lub katalog treści poza tym miejscem, dołącz je do kopii. Kopia samych plików nie obejmuje bazy danych; potrzebujesz obu części.
Do transferu użyj SFTP lub FTPS udostępnionego przez operatora. W kliencie, np. WinSCP, wybierz właściwy protokół, adres, port i konto. Przy pierwszym połączeniu potwierdź tożsamość serwera na podstawie informacji od hostingu. Po pobraniu sprawdź listę nieudanych transferów, a jeśli pobrałeś archiwum, próbnie je rozpakuj.
Zachowaj nienaruszoną kopię z datą oraz oddzielny katalog roboczy do przenosin. Zrzutu SQL, archiwum i zapasowego pliku konfiguracji nie umieszczaj w publicznym katalogu WWW — zawierają dane i dostępy. Ostatecznym sprawdzeniem kopii będzie odtworzenie i uruchomienie jej na nowym serwerze. Eksport z Narzędzia → Eksport w WordPressie przenosi wybrane treści, a nie stanowi kompletnej kopii instalacji.
3. Ustaw połączenie z przygotowaną bazą
Nowa, pusta baza i jej użytkownik są przygotowani od kroku 1. Teraz połączysz z nimi roboczą kopię WordPressa.
Otwórz roboczą kopię wp-config.php w edytorze tekstowym. Zmień wartości istniejących ustawień połączenia; nie wklejaj drugiego zestawu definicji. Dane nowego konta odczytaj z panelu lub wiadomości operatora:
| Ustawienie | Co wpisać na nowym hostingu |
|---|---|
DB_NAME | Pełną nazwę nowej bazy |
DB_USER | Użytkownika mającego uprawnienia do tej bazy |
DB_PASSWORD | Hasło tego użytkownika |
DB_HOST | Adres serwera bazy wskazany przez operatora; nie zakładaj, że zawsze jest to localhost |
W istniejących definicjach zachowaj nawiasy i średniki, a wartości zapisz między prostymi apostrofami '. Poniższe nazwy i hasło są tylko oznaczeniami pól do zastąpienia danymi nowego konta; nie dopisuj tych definicji drugi raz:
define( 'DB_NAME', 'NAZWA_NOWEJ_BAZY' );
define( 'DB_USER', 'UZYTKOWNIK_NOWEJ_BAZY' );
define( 'DB_PASSWORD', 'HASLO_Z_PANELU' );
define( 'DB_HOST', 'ADRES_BAZY_OD_OPERATORA' );W takim zapisie apostrof będący częścią hasła zastąp przez \', a każdy ukośnik odwrotny przez \\. Znak $ pozostaje zwykłym znakiem. Przykładowe hasło abc'de\f$7 zapiszesz jako:
define( 'DB_PASSWORD', 'abc\'de\\f$7' );To wyłącznie przykład składni, nie hasło do wykorzystania. Reguły dla tekstu w pojedynczych apostrofach opisuje PHP, a znaczenie ustawień połączenia — przykładowy plik WordPressa. Nie przesyłaj pliku z rzeczywistymi hasłami do publicznego walidatora.
$table_prefix pozostaw zgodny z nazwami tabel w kopii. Zachowaj też dotychczasowe adresy strony. Przy migracji bez zmiany domeny, protokołu, wariantu www i ścieżek nie potrzebujesz zamiany adresów w treści bazy. Dzięki temu linki do wpisów i obrazów zachowają dotychczasową postać.
4. Wgraj instalację i zaimportuj dane
Prześlij pliki z katalogu roboczego do katalogu nowej domeny. index.php ma znaleźć się na właściwym poziomie, a nie przypadkowo w dodatkowym folderze nazwanym „kopia”. Użyj już poprawionego wp-config.php, aby nowa instalacja nie próbowała połączyć się ze starą bazą. Nie uruchamiaj instalatora nowego WordPressa — odtwarzasz istniejącą witrynę.
Plik .htaccess może zawierać potrzebne przekierowania, ale także stare ścieżki i ustawienia konkretnego hostingu. Zachowaj jego kopię. Na nowym serwerze połącz reguły strony z lokalną konfiguracją i ochroną podglądu przygotowaną w kroku 1. Nie przenoś do nowej kopii tymczasowej odpowiedzi 503 przeznaczonej dla starej aplikacji. Przy innym rodzaju serwera, np. Nginx, konfigurację przygotowuje operator. Cache i połączenie z Redis również mają wskazywać zasoby nowego konta, nie poprzedniego.
W phpMyAdmin nowego hostingu wybierz przygotowaną pustą bazę, otwórz Import, wskaż plik SQL i uruchom import. Poczekaj na komunikat zakończenia. Sprawdź, czy pojawiły się tabele o oczekiwanym prefiksie. phpMyAdmin obsługuje także wybrane skompresowane formaty importu. Gdy plik przekracza limit panelu lub import kończy się błędem, przekaż go operatorowi bezpiecznym kanałem do importu poza tym limitem.
Nieudany import może pozostawić część tabel. Najpierw wyjaśnij komunikat błędu. Do ponownej próby przygotuj kolejną pustą bazę, nadaj użytkownikowi uprawnienia i wpisz jej nazwę w roboczym wp-config.php. Jeśli zmieniły się także pozostałe dane połączenia, zaktualizuj je zgodnie z tabelą z kroku 3. Nie importuj ponownie do częściowo wypełnionej bazy. Oryginał i kopia bezpieczeństwa pozostają nietknięte.
5. Otwórz przeniesioną stronę przez przygotowany podgląd
Włącz ponownie zapisane w kroku 1 wpisy hosts i uruchom przeglądarkę ponownie. Otwórz plik kontrolny na nowym serwerze, a następnie stronę pod dotychczasową domeną. Po zalogowaniu do ochrony katalogu powinieneś zobaczyć przeniesioną witrynę przez prawidłowe HTTPS. Publiczny DNS nadal wskazuje starą stronę z włączoną przerwą.
Jeśli zamiast kopii widzisz komunikat przerwy ze starego serwera, ponownie sprawdź lokalne wskazanie domeny. Jeśli komunikat pochodzi z nowego serwera, sprawdź, czy nie przeniosłeś do niego reguł blokady starej aplikacji. Ochronę nowej kopii przed dostępem osób postronnych pozostaw do zakończenia testów.
6. Sprawdź kopię strony na nowym serwerze
Po potwierdzeniu serwera otwórz stronę główną, zwykłą podstronę, kilka wpisów i zdjęcia. Przejdź przez menu, wyszukiwanie i używane przekierowania. Zaloguj się do panelu i porównaj ostatnie opublikowane treści z zapisaną kopią. Zapis szkicu sprawdzi działanie bazy bez publikowania testowego wpisu.
Jeżeli masz formularz kontaktowy, ustal jego odbiorców, automatyczną odpowiedź i ewentualne przekazywanie danych do innych usług. Próbę wykonaj z własnym adresem i z adresami odbiorców należącymi do osób testujących. Przed wysłaniem odłącz produkcyjne integracje formularza zgodnie z ich instrukcjami, a po sprawdzeniu przywróć właściwe ustawienia na nowej stronie. Przy formularzu połączonym z rezerwacją, sprzedażą lub systemem zewnętrznym potrzebny jest opisany dalej oddzielny test integracji.
Przed dalszym krokiem sprawdź jeszcze trzy rzeczy:
- Adresy i indeksowanie: podstrony zachowują dotychczasowe URL-e, a na nowej wersji nie zostanie testowe
noindexlub blokada całej witryny wrobots.txt. - Ustawienia środowiska: cache, SMTP i potrzebne ścieżki odnoszą się do właściwych usług. Sprawdź szczególnie ustawiony w WordPressie serwer SMTP, używany do wysyłania wiadomości; przy zmianie IP mogą być potrzebne uzgodnienia z dostawcą poczty.
- Automatyzacja: zadania pozostają zatrzymane do momentu decyzji, że nowa kopia staje się jedyną aktywną wersją.
Jeżeli podczas sprawdzania zmieniłeś wyłącznie ustawienia potrzebne nowemu hostingowi, zachowaj je. Nie zastępuj teraz tej bazy wcześniejszym zrzutem, który usunąłby poprawki. W przyjętej metodzie zapisy na starej stronie są wstrzymane od wykonania kopii.
7. Skieruj domenę na nowy serwer
Zdejmij ograniczenie dostępu z przygotowanej nowej wersji i zmień wskazania WWW w aktywnej strefie DNS. Zwykle będzie to rekord A dla IPv4, ewentualnie AAAA dla IPv6 oraz wskazanie wariantu www. Rekord A, AAAA, CNAME i MX mają różne zadania; użyj wartości przekazanych dla Twojej domeny przez nowego operatora.
Uwzględnij wszystkie istniejące wskazania WWW. Pozostawiony stary rekord AAAA może kierować część połączeń na poprzedni serwer. Jeżeli nowy hosting nie udostępnia IPv6, ustal z nim usunięcie tego konkretnego rekordu. Gdy www jest aliasem CNAME domeny głównej, może nie wymagać osobnej zmiany.
Poczta pozostaje u dotychczasowego dostawcy, zgodnie z konfiguracją sprawdzoną w kroku 1. Zmieniaj tylko ustalone wskazania WWW.
W tej metodzie nie przenosisz domeny do innego rejestratora ani całej obsługi DNS. Jeśli strefa ma także opuścić stare konto, przygotuj odrębny plan jej przeniesienia, uwzględniający używany DNSSEC. Do tego czasu konto obsługujące DNS musi pozostać aktywne.
Usuń teraz własne wpisy testowe z pliku hosts i ponownie otwórz przeglądarkę. Sprawdź stronę także przez inne połączenie, np. internet komórkowy. Dopiero taka próba pokazuje działanie publicznego DNS, a nie ustawienia wpisanego ręcznie na Twoim komputerze.
8. Wznów działanie i zamknij prace na starym koncie
Na nowym serwerze przywróć przyjmowanie wiadomości lub komentarzy, jeśli wcześniej je wyłączyłeś. Wznów zadania cykliczne w jednym miejscu. Przed uruchomieniem przejrzyj oczekujące zadania, zwłaszcza zaplanowane publikacje i wysyłki — część może wykonać się przy najbliższym uruchomieniu WP-Cron. Jeżeli przed migracją WordPress uruchamiał je przy wejściach, cofnij tymczasowe DISABLE_WP_CRON na nowej kopii. Jeśli używałeś harmonogramu systemowego, pozostaw właściwe ustawienie i uruchom harmonogram kierujący już do nowej instalacji. Stare zadania pozostają zatrzymane.
Podczas odświeżania DNS część osób może nadal trafiać na stare konto. Nie pozwól, by obie niezależne bazy przyjmowały nowe zgłoszenia. W opisywanej metodzie stara aplikacja pozostaje zablokowana; nowa jest miejscem bieżącej pracy. Gdy ciągłość składania zamówień jest wymagana bez takiej przerwy, potrzebna jest inna organizacja przełączenia.
Porównaj logi ruchu na starym i nowym serwerze, a po zmianie ponownie otwórz istotne podstrony bez lokalnego podglądu. Starą infrastrukturę wyłącz dopiero po upewnieniu się, że ruch przeszedł na nowe środowisko zgodnie z procedurą migracji hostingu bez zmiany URL-i. Sama liczba godzin od zmiany DNS nie potwierdza zakończenia migracji. Osobna checklista SEO przy zmianie hostingu porządkuje kontrole widoczności przed przełączeniem i po nim.
Usuń plik kontrolny, uruchom regularne kopie na nowym koncie i zachowaj niezależną kopię sprzed przenosin. Sprawdź też, czy stare konto nadal utrzymuje pocztę, DNS albo inne witryny. Gdy jest już niepotrzebne, zakończ jego odnowienie według warunków operatora.
Co zrobić, gdy po przeniesieniu coś nie działa?
Najpierw potwierdź, z którym serwerem się łączysz. Potem zapisz dokładny adres, komunikat i godzinę błędu. Ułatwi to znalezienie odpowiadającego mu wpisu w logach. Poniższe objawy zawężają miejsce sprawdzenia; opis najczęstszych problemów znajdziesz również w pomocy WordPressa.
| Objaw | Pierwsze sprawdzenie |
|---|---|
| Błąd połączenia z bazą | Nazwa bazy, użytkownik, hasło, adres serwera bazy i uprawnienia na nowym koncie |
| Pojawia się instalator WordPressa | Czy import trafił do wskazanej bazy i czy prefiks odpowiada tabelom; nie uruchamiaj nowej instalacji |
| Strona główna działa, a podstrony zwracają 404 | Reguły przepisywania adresów i konfiguracja bezpośrednich odnośników |
| Błąd 500 lub biała strona | Log PHP oraz zgodność wersji i rozszerzeń z motywem i wtyczkami |
| Brak zdjęć | Kompletność transferu katalogu uploads, ścieżki i uprawnienia plików |
| Ostrzeżenie HTTPS | Certyfikat podawany przez nowy serwer i objęte nim nazwy |
Przy błędach podstron na Apache lub LiteSpeed zabezpiecz .htaccess, a następnie w Ustawienia → Bezpośrednie odnośniki zapisz istniejącą strukturę bez jej zmieniania. WordPress może odtworzyć swoje reguły, ale trzeba zachować także własne przekierowania i zabezpieczenia. Opis ustawień odnośników wyjaśnia wymagania serwera. Na Nginx konfigurację sprawdza operator. Problemy z certyfikatem szerzej omawia poradnik o SSL i uruchomieniu HTTPS.
Kiedy wrócić na stary serwer i co zmienia migracja sklepu?
Jeśli nowa kopia nie przechodzi sprawdzenia przed zmianą DNS, pozostaw ruch na starym serwerze. Przy dłuższej naprawie przywróć tam wcześniejsze ustawienia dostępu i zadań. Przed następną próbą wykonasz świeżą kopię.
Po przełączeniu powrót wymaga przywrócenia zapisanych wskazań DNS oraz uruchomienia starej aplikacji. Najpierw ustal, czy na nowej powstały już wiadomości, komentarze, konta lub inne dane. Zabezpiecz je i wstrzymaj kolejne zapisy. Przywrócenie starszej bazy nie przeniesie nowych rekordów. Gdy obie wersje mają różne dane, administrator musi je uzgodnić przed ponownym otwarciem starej strony.
W sklepie lub systemie rezerwacji taki plan powstaje przed migracją: kiedy zatrzymać nowe zamówienia, jak obsłużyć trwające płatności i powiadomienia operatora, kto skopiuje końcowe dane oraz kiedy można wznowić sprzedaż. Test zamówienia odbywa się na oddzielnej, przygotowanej kopii. WooCommerce ostrzega, że testowe zamówienia mogą wysyłać e-maile i uruchamiać pozostałe integracje. Potrzebne są ich właściwe tryby testowe, przechwytywanie wiadomości również z zewnętrznego SMTP oraz odłączenie produkcyjnych usług fakturowania, magazynu i wysyłki. Dopiero po takim przygotowaniu można badać cały proces zakupu.
W WordPress Multisite trzeba uwzględnić wszystkie witryny, ich nazwy domenowe i konfigurację sieci. Przy zachowaniu adresów podstawą nadal są pliki i baza, ale pojedyncza strona główna nie wystarczy do sprawdzenia całej sieci. Ten wariant omawia instrukcja migracji Multisite.
Migracja WordPressa jest zakończona, gdy pod dotychczasową domeną działa sprawdzona nowa instalacja, a nowe dane i zadania trafiają tylko do niej. Stare konto zachowaj, jeśli nadal obsługuje pocztę, DNS lub inne witryny. Aktualizacje, nowe treści i kolejne kopie przeniesionego WordPressa wykonujesz już na nowym hostingu.