Strona WordPress to pliki (motyw, wtyczki, przesłane zdjęcia), baza danych i plik konfiguracyjny wp-config.php. Przy tej samej domenie przeniesienie nie wymaga zmiany adresów w bazie. Ryzyka są gdzie indziej: brak dostępu przed końcem starej umowy, licencje przypisane do poprzedniego wykonawcy, formularz wysyłający przez starą pocztę i certyfikat SSL, który na nowym serwerze trzeba wydać od nowa.
Co musisz dostać od obecnego hostingu albo wykonawcy
Punktem wyjścia jest jedna z dwóch rzeczy: konto administratora WordPressa z prawem instalacji wtyczek albo pełna kopia, czyli pliki z katalogu strony i zrzut bazy danych. Kopia od wykonawcy jest kompletna tylko wtedy, gdy zawiera bazę. Same pliki bez bazy nie zawierają ani treści stron, ani ustawień.
Konto administratora nie zawsze wystarcza. Instalacja może blokować dodawanie wtyczek (stała DISALLOW_FILE_MODS w wp-config.php), wtyczka do kopii może nie poradzić sobie z dużym katalogiem zdjęć albo z limitem czasu serwera, a część plików bywa poza WordPressem. Wtedy potrzebny jest też dostęp do plików (SFTP) i do bazy danych.
- Licencje. Płatne wtyczki i motywy, np. Elementor Pro, bywają aktywowane na licencji agencji. Po przenosinach działają, ale bez aktualizacji, a po odłączeniu licencji część funkcji może przestać działać. O to trzeba zapytać przed przenosinami, razem z prośbą o dostęp.
- Panel serwera. Gdy strona stoi na serwerze agencji, klient zwykle nie ma do niego dostępu, więc nie zrobi kopii przez panel hostingu. Prośbę o dostęp wysyła właściciel strony, bo to on jest stroną umowy.
- Termin. W prowadzonym przez nas przypadku umowę z firmą utrzymującą stronę wypowiedziano, zanim przyszedł dostęp. Termin końca usługi wyznacza wtedy czas na całe przenosiny.
Kopia awaryjna, zanim przyjdzie dostęp
Jeśli istnieje ryzyko, że strona zniknie przed otrzymaniem dostępu, warto zabezpieczyć jej publiczną część. Działająca strona WordPress udostępnia treści stron, wpisów i listę plików mediów przez REST API (adresy /wp-json/wp/v2/…), o ile nikt tego nie wyłączył. Z niego da się pobrać treść każdej strony i adresy oryginalnych zdjęć, a z samych stron układ, style i skrypty.
W naszym przypadku taka kopia objęła 11 stron, 272 pliki, ok. 20 MB, w tym 51 oryginałów zdjęć i treści stron pobrane z REST API. To zabezpieczenie treści, a nie kopia strony: nie zawiera bazy danych, ustawień, kont użytkowników, plików PHP ani konfiguracji formularza. Z takiej kopii stronę da się odbudować, ale nie da się jej przywrócić jednym importem.
Przeniesienie plików, bazy i konfiguracji
- Pliki. Najważniejszy jest katalog
wp-content: motyw, wtyczki i przesłane pliki. Rdzeń WordPressa można zainstalować na nowo w tej samej wersji. - Baza danych. Eksport i import z zachowaniem kodowania znaków. Pułapki kodowania, prefiksu tabel i zmiany adresu opisuje poradnik o migracji bazy danych WordPress.
- wp-config.php. Nowa nazwa bazy, użytkownik, hasło i adres serwera bazy. Prefiks tabel musi zgadzać się z tabelami w zaimportowanej bazie.
- Wersja PHP. Nowy serwer powinien mieć wersję PHP, z którą działają motyw i wtyczki. Starsze wtyczki potrafią zatrzymać stronę na nowszym PHP.
- Wtyczki zależne od serwera. Wtyczki cache i bezpieczeństwa często mają ustawienia pod konkretny serwer. Po przenosinach trzeba je sprawdzić, a pamięć podręczną wyczyścić.
Formularz kontaktowy i poczta wysyłana przez stronę
Formularz wysyła powiadomienia przez funkcję poczty serwera albo przez SMTP konkretnej skrzynki. Przy przenosinach to łatwo przeoczyć, bo formularz nadal się wysyła, tylko powiadomienia przestają dochodzić albo trafiają do spamu.
W prowadzonym przez nas przypadku na starej poczcie było konto techniczne, którego najpewniej używa formularz strony. Poczta przeszła już do nowego dostawcy, a stara przestaje działać z końcem abonamentu. Dlatego rekord SPF domeny przejściowo zawiera adresy serwera strony i starej poczty. Przy przenosinach strony formularz zostanie przestawiony na SMTP nowej poczty, a stare adresy znikną z SPF. Szczegóły tej części opisuje poradnik o migracji poczty firmowej.
Test przed zmianą DNS
Przeniesioną stronę da się sprawdzić, zanim zobaczą ją odwiedzający. Wpis w pliku hosts na własnym komputerze kieruje domenę na nowy serwer tylko dla tego komputera. Wtedy warto przejść po wszystkich stronach i sprawdzić:
- czy strony, menu i zdjęcia wyglądają tak jak na starym serwerze
- czy działa logowanie do panelu WordPress
- czy formularz wysyła i czy powiadomienie dochodzi
- czy wtyczki płatne działają i nie zgłaszają braku licencji
Certyfikat SSL na nowym serwerze wydaje się zwykle automatycznie, gdy domena już na niego wskazuje. Jeśli w strefie DNS jest rekord CAA, musi on dopuszczać wystawcę certyfikatu, którego używa nowy hosting.
Przełączenie i to, co po nim
Przełączenie strony to zmiana rekordu A domeny na adres IPv4 nowego serwera. Jeśli domena ma też rekord AAAA ze starym adresem IPv6, część odwiedzających nadal trafi na stary serwer, więc ten rekord trzeba zmienić albo usunąć. Adres z www bywa osobnym rekordem A albo rekordem CNAME wskazującym na domenę główną, jak w strefie, którą przygotowaliśmy przy naszych przenosinach. Wtedy podąża za nią sam. Poczty nie dotyczy, bo pocztą rządzi rekord MX, więc stronę i pocztę można przenosić osobno i w różnych dniach. Do czasu, aż zmiana rozejdzie się po resolverach, część odwiedzających trafia jeszcze na stary serwer. Dlatego starą stronę zostawia się bez zmian treści, aż nowa działa i przeszła sprawdzenie.
Po przełączeniu: SSL i przekierowanie z http na https, formularz, kopie zapasowe na nowym hostingu i zadania cykliczne strony.
Kontrola SEO po zmianie hostingu
Przy tej samej domenie Google nie wymaga zgłaszania zmiany adresu. Jego poradnik o zmianie hostingu zaleca obniżenie TTL rekordów przed zmianą, obserwację logów i raportów indeksowania oraz wyłączenie starego serwera dopiero, gdy ruch na nim spadnie do zera. Po przełączeniu sprawdzamy:
- statusy HTTP najważniejszych adresów: strony odpowiadają kodem 200, a dotychczasowe przekierowania 301 dalej działają; reguły z .htaccess przechodzą razem z plikami, o ile nowy serwer je obsługuje (Apache, LiteSpeed; nginx ich nie czyta), reguły z wtyczek razem z bazą, a reguły z konfiguracji starego serwera trzeba odtworzyć
- ustawienie „Proś wyszukiwarki o nieindeksowanie tej witryny” w Ustawieniach → Czytanie: kopie robocze często mają je włączone, a po przełączeniu cała strona dostaje znacznik noindex
- robots.txt, adresy canonical i mapę witryny: wszystkie wskazują właściwą domenę i https
- raport stron i statystyki indeksowania w Search Console przez kilka dni po zmianie, pod kątem błędów serwera i spadku indeksowania
Stronę przeniesiesz sam czy z kimś?
Masz konto administratora, strona nie ma płatnych wtyczek na cudzej licencji, a nowy hosting oferuje gotowe przeniesienie WordPressa. Wtedy zostaje test i zmiana DNS.
Strona jest u agencji, dostęp trzeba dopiero zdobyć, poczta i strona są u różnych dostawców, formularz wysyła przez starą pocztę albo termin wyznacza koniec umowy. Wtedy liczy się kolejność i to, żeby nic nie przestało działać w trakcie.
W ramach migracji hostingu przenosimy strony WordPress razem z pocztą i formularzami: od zdobycia dostępu i kopii awaryjnej, przez test na nowym serwerze, po przełączenie DNS i sprawdzenie formularza. Jeśli przenosiny są okazją do poprawy strony, zobacz, jak budujemy strony internetowe.
Dokumentacja do przenosin WordPressa
- WordPress: Migrating WordPress: przenosiny bez zmiany adresu i ryzyko zamiany adresów w danych serializowanych
- WordPress: wp-config.php: dane bazy, prefiks tabel i stała
DISALLOW_FILE_MODS - WordPress REST API: Pages: odczyt treści stron, z którego korzysta kopia awaryjna
- Google Search Central: zmiana hostingu: przeprowadzka bez zmiany adresów
- Let's Encrypt: CAA: rekord, który musi dopuszczać wystawcę certyfikatu
Liczby kopii awaryjnej i opis formularza pochodzą z przenosin, które prowadzimy. Strona z tego przypadku czeka jeszcze na przeniesienie, więc poradnik nie opisuje jego wyniku.