Zmiana hostingu to jedna z tych operacji, które w teorii trwają godzinę, a w praktyce potrafią rozłożyć serwis na tydzień. Sam transfer plików i bazy nie jest trudny. Trudna jest kolejność: co robimy przed przełączeniem DNS, co dokładnie sprawdzamy w oknie migracji, a co monitorujemy dopiero po tygodniu. Poniżej plan, który zakłada, że adresy URL nie zmieniają się, a jedyną zmienną jest serwer.
Przygotowanie przed migracją
Zacznij od inwentaryzacji, bo większość awarii po przenosinach nie wynika z utraty danych, lecz z brakującego elementu środowiska. Zapisz wersję PHP, wersję MySQL lub MariaDB, listę aktywnych wtyczek z numerami wersji, rozszerzenia PHP wymagane przez sklep lub formularze, wielkość katalogu wp-content/uploads oraz obecny rozmiar bazy. Jeżeli obecny serwer korzysta z LiteSpeed albo Nginx z własną regułą cache, odnotuj to osobno, bo docelowa konfiguracja będzie inna i warstwa cache to najczęstsze źródło zjawiska „u mnie działa, a na produkcji nie”.
Druga rzecz to mapa integracji zewnętrznych. Wpisy DNS to nie tylko rekord A. W tej samej strefie żyją MX dla poczty, TXT dla SPF i DKIM, rekordy weryfikacyjne narzędzi analitycznych, czasem CNAME dla CDN. Przepisanie samego A i zapomnienie o MX oznacza, że przez kilkanaście godzin serwis chodzi, a poczta firmowa milczy.
Ustal też okno czasowe. Najbezpieczniejsze jest to, w którym serwis ma najmniej ruchu, ale jednocześnie masz pełny dostęp do wsparcia obu hostingów. Przenosiny w piątek o 22:00 wyglądają rozsądnie do momentu, w którym trzeba eskalować zgłoszenie.
| Element | Co zapisać | Dlaczego |
|---|---|---|
| PHP | Wersja i rozszerzenia | Różnica wersji wywala starsze wtyczki |
| Baza | Silnik, wersja, rozmiar, collation | Niezgodne kodowanie psuje polskie znaki |
| Cache | Warstwa serwerowa i wtyczka | Stary cache maskuje błędy w nowym środowisku |
| DNS | A, AAAA, MX, TXT, CNAME | Pominięty rekord wyłącza pocztę lub CDN |
| Crony | Zadania systemowe i WP Cron | Po migracji często zostają wyłączone |
Kopia zapasowa i środowisko testowe
Kopia zapasowa przed migracją ma jeden warunek: musi być odtwarzalna, a nie tylko istniejąca. Zrób pełny zrzut bazy przez mysqldump oraz archiwum katalogu WordPressa, a potem faktycznie rozpakuj te pliki na nowym serwerze. Dopóki nie odtworzysz kopii, nie masz kopii, masz plik.
Na nowym hostingu postaw wersję testową pod adresem tymczasowym albo, lepiej, pod własnym hostem w pliku hosts na komputerze. Ta druga metoda ma istotną zaletę: serwis działa pod docelową domeną, więc nie trzeba podmieniać adresów w bazie dwa razy, a wszystkie linki wewnętrzne i zasoby zachowują się tak jak na produkcji. Subdomena testowa wymusza zwykle masową zamianę adresów, a każda taka zamiana to ryzyko rozjechanych pól serializowanych.
Środowisko testowe musi być zamknięte dla robotów. Wystarczy uwierzytelnianie HTTP na poziomie serwera. Sam noindex nie zawsze wystarczy, bo jeśli wersja testowa złapie linki, przez kilka tygodni będziesz oglądał w wynikach dwie kopie tego samego serwisu.
Przenosiny plików i bazy danych
Pliki najszybciej przenosi się bezpośrednio między serwerami przez rsync po SSH, bez pośrednictwa lokalnego dysku. Przy kilkudziesięciu gigabajtach biblioteki mediów różnica to godziny. Jeżeli oba hostingi dają tylko FTP, przenieś najpierw całość poza katalogiem uploads, a media dociągnij osobno, bo to one generują większość wolumenu i najczęściej przerywają transfer.
Bazę przenosisz zrzutem i importem, ale zwróć uwagę na trzy detale. Pierwszy: kodowanie. Docelowa baza powinna mieć to samo collation, inaczej polskie znaki zamienią się w znaki zapytania i zobaczysz to dopiero w treści starszych wpisów. Drugi: prefiks tabel, który musi zgadzać się z tym w wp-config.php. Trzeci: użytkownik bazy i jego uprawnienia, bo część hostingów nadaje domyślnie węższy zestaw niż wymaga aktualizacja WordPressa.
Po imporcie zrób szybki test spójności: liczba wpisów, liczba komentarzy, liczba załączników. Trzy zapytania SELECT COUNT(*) po obu stronach zajmują minutę i wyłapują przerwany import lepiej niż klikanie po kokpicie.
DNS, czas życia wpisów i okno przełączenia
Najważniejszy krok wykonuje się dzień wcześniej: obniż TTL rekordów do 300 sekund. Domyślne 3600 lub 14400 oznacza, że część użytkowników i robotów będzie trafiać na stary serwer jeszcze wiele godzin po przełączeniu. Przy niskim TTL propagacja jest kwestią minut, a ewentualny powrót do starego serwera równie szybki. Po udanej migracji i kilku dniach stabilności TTL można podnieść.
W samym oknie przełączenia utrzymaj stary serwer w gotowości. Nie usuwaj tam niczego przez co najmniej dwa tygodnie i nie wyłączaj konta hostingowego, dopóki nie zobaczysz, że nowy serwer obsługuje cały ruch. Przez okres propagacji część odwiedzin nadal ląduje pod starym adresem IP, więc oba środowiska muszą odpowiadać poprawnie. Jeżeli w tym czasie użytkownicy mogą dodawać zamówienia albo komentarze, zablokuj zapisy na starym serwerze, bo inaczej powstaną dwie rozbieżne bazy.
Jeśli razem z serwerem zmienia się także adresacja URL, to już inna operacja i wymaga mapy przekierowań jeden do jednego. Google opisuje oba warianty osobno w dokumentacji dotyczącej przenosin serwisu bez zmiany adresów i warto się jej trzymać, bo mieszanie obu scenariuszy w jednym oknie czasowym praktycznie uniemożliwia diagnostykę.
Weryfikacja po migracji: kody odpowiedzi i indeksacja
Zaraz po przełączeniu przejdź na listę kontrolną odpowiedzi serwera. Sprawdź, czy strona główna, wybrane wpisy, archiwa kategorii, sitemapa i robots.txt zwracają 200. Sprawdź, czy nieistniejący adres zwraca 404, a nie 200 z pustym szablonem, bo miękkie 404 to najczęstsza pozostałość po źle skonfigurowanym nowym serwerze. Sprawdź wreszcie, czy wersja bez www i z www oraz wariant HTTP prowadzą jednym przekierowaniem 301 do wersji kanonicznej, a nie łańcuchem dwóch albo trzech skoków.
Warto tu operować pojęciami precyzyjnie, bo „strona nie jest zaindeksowana” może oznaczać pięć różnych stanów. Jeżeli różnica między wykryciem, zaindeksowaniem i budżetem crawlowania nie jest dla Ciebie oczywista, zacznij od naszego zestawienia, w którym pojęcia technicznego SEO wyjaśnione są bez żargonu, a potem wróć do raportów w Search Console. Bez tego łatwo uznać naturalne opóźnienie ponownego crawlowania za skutek migracji.
Na koniec certyfikat. Nowy serwer wystawia nowy certyfikat TLS i zdarza się, że pierwsze żądania po przełączeniu trafiają na certyfikat tymczasowy albo na łańcuch bez pośredniego urzędu. W przeglądarce wygląda to poprawnie, a w narzędziach konsolowych i u części robotów już nie.
Wydajność na nowym serwerze
Nowy hosting nie jest szybszy tylko dlatego, że jest nowy. Po migracji zmierz czas do pierwszego bajtu z kilku lokalizacji, sprawdź, czy kompresja odpowiedzi działa, czy nagłówki Cache-Control dla plików statycznych są ustawione i czy warstwa obiektowa cache, jeśli była, faktycznie została włączona. Bardzo często po przenosinach zostaje aktywna wtyczka cache, ale bez zaplecza serwerowego, więc każde żądanie idzie do PHP.
To także dobry moment, żeby zamiast pięciu wtyczek optymalizacyjnych zbudować konfigurację zgodną z realnymi wskaźnikami. Opisaliśmy ten porządek w praktycznym przewodniku o tym, jak ustawić cache, obrazy i fonty w WordPressie bez wtyczek typu all in one. Migracja daje czystą kartę i łatwiej wtedy odróżnić efekt konfiguracji od efektu nowego sprzętu.
- Zmierz TTFB przed i po, na tych samych adresach i w tej samej porze dnia.
- Porównaj liczbę zapytań do bazy na najcięższym szablonie.
- Sprawdź limity:
memory_limit,max_execution_time, liczba procesów PHP. - Potwierdź, że zadania cykliczne uruchamiają się systemowo, a nie przy okazji wejścia użytkownika.
Monitoring przez pierwsze dwa tygodnie
Pierwsze 48 godzin obserwuj logi serwera, nie raporty zewnętrzne. Interesują Cię nagłe skoki kodów 5xx, timeouty i błędy PHP, których wcześniej nie było. Równolegle ustaw prosty monitoring dostępności z interwałem minutowym, bo krótkie przerwy po przełączeniu DNS bywają niewidoczne w danych dziennych.
Od trzeciego dnia przejdź na dane wyszukiwarki. Porównuj liczbę zaindeksowanych adresów, statystyki crawlowania i pozycje najważniejszych zapytań w oknie tygodniowym, nie dobowym. Samodzielny crawl serwisu też jest wskazany, choć jeżeli planujesz pobierać przy tej okazji dane z cudzych serwisów, sprawdź wcześniej, co realnie wolno, bo scrapowanie danych do SEO ma w Polsce swoje granice prawne. Własny serwis możesz crawlować bez ograniczeń i to on jest tu przedmiotem badania.
Dopiero po dwóch tygodniach stabilnych odczytów wyłącz stary hosting, podnieś TTL i zamknij temat. Jeżeli w tym czasie widzisz spadek pozycji, w pierwszej kolejności wyklucz przyczyny techniczne z listy wyżej, a nie zakładaj kary. Migracja bez zmiany adresów rzadko kosztuje widoczność sama z siebie. Kosztuje ją niedopatrzenie: zablokowany robots.txt, zapomniany noindex ze środowiska testowego albo pół tysiąca miękkich 404.
FAQ
Czy migracja hostingu obniża pozycje w Google?
Sama zmiana serwera przy niezmienionych adresach URL nie jest czynnikiem rankingowym. Spadki po przenosinach niemal zawsze mają przyczynę techniczną: blokadę w robots.txt, pozostawiony noindex, błędy 5xx w okresie propagacji albo wyraźnie gorszy czas odpowiedzi nowego serwera.
Ile trwa propagacja DNS?
Zależy od TTL ustawionego przed zmianą. Przy TTL 300 sekund większość klientów przechodzi na nowy adres w kilka minut, a ogon pojedynczych resolwerów zamyka się w ciągu kilku godzin. Przy domyślnym TTL 4 godzin ten sam proces zajmuje pełny dzień.
Czy trzeba informować Google o zmianie hostingu?
Nie ma takiego obowiązku ani dedykowanego zgłoszenia, gdy adresy pozostają te same. Wystarczy pilnować, aby sitemapa była dostępna, a serwer zwracał prawidłowe kody odpowiedzi. Narzędzie zmiany adresu dotyczy przenosin domeny, nie serwera.
Co zrobić, jeśli po imporcie bazy polskie znaki są uszkodzone?
Wróć do zrzutu i zaimportuj go ponownie z jawnie wskazanym kodowaniem zgodnym ze źródłem, zwykle utf8mb4. Naprawa znaków zapytania w treści po fakcie jest możliwa, ale zawsze częściowa, dlatego szybciej jest powtórzić import niż czyścić dane.
Kiedy bezpiecznie wyłączyć stary hosting?
Po co najmniej dwóch tygodniach od przełączenia, gdy logi nowego serwera pokazują pełny ruch, statystyki crawlowania są stabilne, a poczta i integracje zewnętrzne działają. Do tego czasu stare konto pełni rolę planu awaryjnego.