Zmiana hostingu polega na przeniesieniu plików strony, bazy danych i konfiguracji na serwer nowego dostawcy, a następnie przekierowaniu domeny na jego adres. Przy prostej stronie na WordPressie zajmuje to 2–3 godziny pracy plus doba na propagację DNS. Cała sztuka polega na tym, żeby strona działała na nowym serwerze zanim ruszysz DNS — wtedy przełączenie jest niezauważalne dla odwiedzających.
W skrócie
- Kolejność jest odwrotna do intuicyjnej. Najpierw kopia na nowym serwerze i testy, dopiero na końcu zmiana DNS.
- Obniż TTL do 300 sekund na 24–48 godzin przed przełączeniem. To skraca okres, w którym część użytkowników widzi stary serwer.
- Testuj przez plik hosts, zanim domena wskaże nowy serwer — zobaczysz stronę produkcyjną na nowym hostingu, gdy reszta świata widzi jeszcze starą.
- Sprawdź poczta osobno. Jeśli skrzynki zostają u starego dostawcy, po przeniesieniu formularz kontaktowy potrafi przestać wysyłać maile — to najczęstszy błąd po zmianie hostingu.
- Nie wyłączaj starego hostingu przez 2–4 tygodnie. Kosztuje kilkadziesiąt złotych, a ratuje projekt, gdy coś przeoczysz.
Kiedy zmiana hostingu ma sens, a kiedy nie rozwiąże problemu
Typowe powody: strona ładuje się wolno, serwer bywa niedostępny, wsparcie techniczne odpowiada po trzech dniach, skończyło się miejsce, cena po okresie promocyjnym poszła w górę albo firma konsoliduje usługi u jednego operatora.
Zanim jednak przeniesiesz stronę, sprawdź jedną rzecz: czy wolne działanie faktycznie wynika z hostingu. W praktyce częściej odpowiada za nie ciężki motyw, kilkanaście wtyczek, brak pamięci podręcznej albo nieskompresowane zdjęcia w oryginalnej rozdzielczości. Przeniesienie takiej strony na szybszy serwer daje poprawę o kilkanaście procent, a nie kilkukrotną — i po miesiącu wracasz do punktu wyjścia.
Prosty test: sprawdź czas odpowiedzi serwera (TTFB) i porównaj go z czasem pełnego załadowania strony. Jeśli serwer odpowiada szybko, a strona i tak ładuje się długo, problem leży w kodzie i zasobach, nie w hostingu.
Krok 1. Zbierz wymagania techniczne
Zanim wybierzesz dostawcę, spisz, czego strona faktycznie potrzebuje:
- wersja PHP i włączone rozszerzenia,
- wersja MySQL lub MariaDB,
- limity: memory_limit, max_execution_time, upload_max_filesize, liczba równoczesnych procesów,
- zadania cron — kopie zapasowe, synchronizacje, wysyłka newslettera,
- dostęp SSH i WP-CLI, jeśli korzystasz z nich przy aktualizacjach,
- certyfikat SSL — czy dostawca daje Let’s Encrypt automatycznie, czy trzeba wgrywać własny,
- skrzynki pocztowe — ile, jak duże, czy zostają u obecnego dostawcy.
To najczęściej pomijany etap. Migracja na tańszy hosting, który ma starszą wersję PHP albo niższe limity, kończy się białym ekranem po przeniesieniu.
Krok 2. Wybierz dostawcę
Cena jest najmniej istotnym kryterium, bo różnice między pakietami dla typowej strony firmowej to kilkadziesiąt złotych rocznie. Znaczenie mają:
| Kryterium | Na co patrzeć |
| Wydajność | Rodzaj dysków, wersje PHP, dostępność cache po stronie serwera, limity zasobów w regulaminie (nie w reklamie) |
| Lokalizacja serwerowni | Dla polskiego ruchu serwer w Polsce lub Europie Środkowej — każdy tysiąc kilometrów to dodatkowe milisekundy |
| Wsparcie | Czas reakcji w SLA, dostępność telefonu, godziny pracy — sprawdź to przed zakupem, wysyłając pytanie techniczne |
| Kopie zapasowe | Częstotliwość, okres przechowywania, czy odtworzenie jest bezpłatne i samodzielne |
| Pomoc przy migracji | Wielu dostawców przenosi stronę bezpłatnie — warto z tego skorzystać, ale i tak zweryfikować efekt |
| Bezpieczeństwo | Ochrona przed atakami, izolacja kont, certyfikaty SSL w standardzie |
| Panel | Czy jest do niego dokumentacja i czy poradzi sobie z nim osoba, która będzie zarządzać stroną po Tobie |
Zapytaj też wprost o limity, których nie widać w cenniku: liczbę baz danych, maksymalny rozmiar pojedynczej bazy, limit wysyłanych wiadomości na godzinę i liczbę procesów PHP. To one decydują, czy strona zadziała pod obciążeniem.
Krok 3. Wykonaj kopię zapasową
Pełna kopia to trzy elementy: pliki strony, baza danych i poczta, jeśli skrzynki są powiązane z domeną. Pobierz ją na dysk lokalny — kopia leżąca wyłącznie na serwerze, który za chwilę wyłączysz, nie jest kopią zapasową.
Sprawdź jeszcze, czy da się z niej odtworzyć pojedynczy plik. To zajmuje pięć minut, a rozstrzyga, czy masz kopię, czy tylko archiwum, o którym tak myślisz. Szerzej opisaliśmy to we wpisie o rodzajach backupu i najczęstszych błędach.
Krok 4. Postaw stronę na nowym serwerze
Wgraj pliki, zaimportuj bazę, uzupełnij dane dostępowe do bazy w konfiguracji strony. Przy WordPressie sprawdź dodatkowo:
- adresy URL w ustawieniach (siteurl i home),
- działanie wtyczek, zwłaszcza cache’ujących i optymalizujących,
- odświeżenie linków bezpośrednich (zapisanie ustawień permalinków generuje nowy plik .htaccess),
- uprawnienia do katalogów, jeśli wgrywanie plików przestało działać.
Najważniejsze na tym etapie: wyłącz opcję zniechęcania wyszukiwarek do indeksowania. Jeśli stawiasz stronę jako środowisko testowe, WordPress potrafi zostawić noindex w kodzie — i taka strona idzie potem na produkcję. To jedna z niewielu rzeczy, które przy zmianie hostingu naprawdę potrafią wywalić stronę z wyników wyszukiwania.
Testuj, zanim ruszysz DNS
Zanim domena wskaże nowy serwer, dopisz jego adres IP do pliku hosts na swoim komputerze (w Windowsie: C:WindowsSystem32driversetchosts). Twoja przeglądarka będzie łączyć się z nowym hostingiem pod właściwym adresem domeny, podczas gdy wszyscy pozostali widzą jeszcze starą stronę.
Dzięki temu przetestujesz produkcyjne środowisko w realnych warunkach — z poprawnymi adresami, bez tymczasowych domen technicznych, które psują linki i wtyczki.
Krok 5. Przygotuj SSL i DNS
Wygeneruj certyfikat SSL na nowym serwerze przed przełączeniem. Certyfikaty Let’s Encrypt zwykle wymagają, żeby domena wskazywała już na dany serwer — jeśli tak jest u Twojego dostawcy, zaplanuj chwilę przerwy na wydanie certyfikatu zaraz po zmianie DNS albo poproś o wydanie metodą weryfikacji przez rekord DNS, która nie wymaga przepięcia strony.
Na 24–48 godzin przed przełączeniem obniż TTL rekordów A i CNAME do 300 sekund. TTL mówi serwerom DNS na świecie, jak długo mają pamiętać starą odpowiedź. Domyślne 3600 lub 14400 sekund oznacza, że po zmianie część użytkowników przez kilka godzin nadal trafia na stary serwer.
Jeśli poczta zostaje u dotychczasowego dostawcy, nie ruszaj rekordów MX, SPF, DKIM ani DMARC. Zmieniasz wyłącznie rekordy wskazujące na serwer WWW. Pomylenie tych dwóch rzeczy to najczęstsza przyczyna sytuacji, w której po migracji strona działa, a poczta firmowa milknie — mechanikę tych rekordów wyjaśniamy w tekście o SPF, DKIM i DMARC.
Krok 6. Przełącz i monitoruj
Zmień rekordy DNS w panelu rejestratora domeny. Propagacja trwa zwykle od kilkunastu minut do kilku godzin — przy obniżonym wcześniej TTL raczej bliżej dolnej granicy niż deklarowanych wszędzie 48 godzin.
Przez pierwsze dni obserwuj:
- dostępność strony i czas odpowiedzi serwera,
- logi błędów na nowym serwerze,
- statystyki indeksowania w Google Search Console — nagły wzrost błędów 5xx oznacza, że serwer nie wyrabia,
- działanie poczty, jeśli była przenoszona,
- zadania cron, które często nie przenoszą się razem z plikami.
Stary hosting zostaw włączony przez 2–4 tygodnie. To najtańsza polisa w całym procesie.
Poczta przy zmianie hostingu — trzy scenariusze
| Scenariusz | Co robisz | Na co uważać |
| Poczta zostaje u starego dostawcy | Zmieniasz tylko rekordy A/CNAME, MX bez zmian | Nowy serwer może próbować dostarczać maile lokalnie zamiast wysyłać je na MX — formularze kontaktowe przestają działać. Rozwiązanie: wyłączenie lokalnego dostarczania albo wysyłka przez SMTP |
| Poczta przenosi się razem ze stroną | Pełna migracja skrzynek plus zmiana MX | Kalendarze i kontakty nie przeniosą się przez IMAP; konieczna konfiguracja kont na wszystkich komputerach i telefonach |
| Poczta idzie do Microsoft 365 lub Google Workspace | Osobny projekt, niezależny od hostingu WWW | Warto rozdzielić oba przełączenia w czasie — nie zmieniaj serwera strony i dostawcy poczty tego samego dnia |
Przy drugim i trzecim wariancie proces jest znacznie szerszy niż samo przeniesienie plików — opisaliśmy go osobno w przewodniku o przenoszeniu poczty na nowy serwer. W ramach migracji poczty IMAP najczęściej prowadzimy oba przełączenia w odstępie tygodnia, żeby w razie problemu wiadomo było, co je wywołało.
Zmiana hostingu a SEO — co naprawdę ma znaczenie
Krąży przekonanie, że zmiana adresu IP szkodzi pozycjom. Sam adres IP nie jest czynnikiem rankingowym i jego zmiana nie powoduje spadków. Ryzyko leży gdzie indziej:
- Przestój w czasie, gdy robot odwiedza stronę. Kilka godzin błędów 5xx potrafi wypaść z indeksu części podstron. Krótki przestój jest odwracalny, wielodniowy — już nie.
- Wolniejszy serwer. Czas odpowiedzi wpływa na ocenę doświadczenia użytkownika i na to, ile podstron robot zdąży odwiedzić.
- Odległość serwerowni od użytkowników. Serwer w innej części świata to realnie dłuższy czas odpowiedzi dla polskiego ruchu.
- Zgubione przekierowania. Reguły z .htaccess bardzo często nie przenoszą się razem z plikami. Wyeksportuj je i porównaj po migracji.
- Zmieniony robots.txt lub zostawiony noindex ze środowiska testowego. To jedyny scenariusz, w którym zmiana hostingu potrafi naprawdę zniszczyć widoczność.
- Mieszana zawartość po zmianie SSL — część zasobów ładowana po HTTP blokuje kłódkę i psuje odbiór strony.
Wniosek praktyczny: nie zmieniaj hostingu w szczycie sezonu sprzedażowego ani w trakcie kampanii. Poza tym, przy poprawnie przeprowadzonym procesie, pozycje nie powinny drgnąć. Jeśli równolegle prowadzisz działania pozycjonujące, uprzedź o migracji osobę odpowiedzialną — inaczej wahania z tygodnia migracji zostaną przypisane do czegoś innego.
Lista kontrolna po migracji
- strona główna i najważniejsze podstrony otwierają się poprawnie
- formularze kontaktowe wysyłają wiadomości i docierają one na skrzynkę
- certyfikat SSL działa, brak ostrzeżeń o mieszanej zawartości
- przekierowania z .htaccess odtworzone
- robots.txt i mapa strony dostępne, brak noindex
- panel administracyjny i logowanie działają
- wyszukiwarka wewnętrzna, koszyk, płatności i integracje przetestowane
- zadania cron uruchomione na nowym serwerze
- kopie zapasowe skonfigurowane u nowego dostawcy
- poczta odbiera i wysyła
- stary hosting nadal aktywny
- Search Console sprawdzony po 3 i po 7 dniach
FAQ
Ile trwa zmiana hostingu? Techniczne przeniesienie typowej strony firmowej to 2–3 godziny. Do tego dochodzi propagacja DNS, zwykle od kilkunastu minut do kilku godzin przy wcześniej obniżonym TTL. Przy sklepie z integracjami i dużą bazą trzeba założyć jeden dzień roboczy.
Czy strona będzie niedostępna podczas zmiany hostingu? Nie musi. Jeśli postawisz działającą kopię na nowym serwerze przed zmianą DNS, użytkownicy przez cały czas trafiają na sprawną stronę — najpierw na starym serwerze, potem na nowym.
Czy zmiana hostingu wpłynie na pozycje w Google? Poprawnie przeprowadzona nie powinna. Szkodzi dopiero dłuższy przestój, wolniejszy serwer, zgubione przekierowania albo pozostawiony znacznik noindex ze środowiska testowego.
Co z pocztą przy zmianie hostingu strony? Jeśli skrzynki zostają u dotychczasowego dostawcy, nie zmieniasz rekordów MX i poczta działa bez przerwy. Jeśli przenosisz również pocztę, to osobny proces obejmujący migrację wiadomości i konfigurację kont na wszystkich urządzeniach.
Kiedy można wyłączyć stary hosting? Po 2–4 tygodniach stabilnej pracy nowego serwera. Wcześniej warto pobrać końcową kopię plików, bazy i poczty do archiwum.
Czy trzeba przenosić domenę razem z hostingiem? Nie. Domena i hosting to dwie niezależne usługi. Wystarczy w panelu rejestratora zmienić rekordy DNS lub serwery nazw. Transfer domeny to osobna operacja, którą lepiej przeprowadzić w innym terminie niż migrację strony.
Kiedy najlepiej przeprowadzić migrację? W okresie najmniejszego ruchu — dla większości stron firmowych to piątek wieczorem lub weekend. Unikaj szczytów sprzedażowych i trwających kampanii reklamowych.