Jak przenieść stronę WordPress na nowy hosting bez przestoju i utraty SEO

Aktualizacja: październik 2026

Informacja: ten materiał może zawierać linki afiliacyjne. Jeżeli skorzystasz z takiego linku i dokonasz zakupu, PICKNIVO może otrzymać prowizję. Nie zwiększa to ceny po Twojej stronie.

Wyobraź sobie, że przeprowadzasz się do nowego mieszkania: zgłaszasz przekierowanie poczty, ale jeszcze przez jakiś czas zaglądasz do starej skrzynki, bo nie wszyscy nadawcy zdążyli zapisać nowy adres. Migracja strony działa na tej samej zasadzie. Zdecydowałeś się na zmianę hostingu — może po lekturze rankingu najlepszych hostingów albo porównania Hostinger vs Kinsta — i teraz potrzebujesz konkretnej odpowiedzi na jedno pytanie: jak to zrobić, żeby strona nie zniknęła na kilka godzin i nie straciła pozycji w Google?

Ten poradnik nie testuje żadnego konkretnego hostingu z pierwszej ręki — opisuje sprawdzoną, powtarzalną procedurę migracji WordPressa opartą na oficjalnej dokumentacji WordPress.org, WP-CLI i Google Search Central, uzupełnioną o aktualne zasady migracji największych dostawców hostingu.

Co naprawdę znaczy "bez przestoju" — zasada, nie magia

Migracja "bez przestoju" nie polega na jakimś specjalnym triku. To konsekwentne trzymanie się kolejności: najpierw zbuduj i przetestuj stronę na nowym hostingu, dopiero na końcu przełącz ruch (DNS), a stary serwer trzymaj włączony jeszcze przez jakiś czas po przełączeniu.

Powód jest techniczny: gdy zmieniasz DNS, informacja o nowym adresie serwera rozchodzi się po internecie stopniowo — część odwiedzających i robotów wciąż trafia na stary adres, dopóki ich dostawca internetu nie odświeży swojego cache DNS. Dlatego przez ten czas oba serwery — stary i nowy — muszą serwować tę samą, aktualną treść.

Skrócenie tego okna zaczyna się wcześniej, od obniżenia wartości TTL (Time To Live) rekordów DNS przed samą migracją. Tu źródła nieco się różnią: Google w swojej oficjalnej dokumentacji sugeruje obniżenie TTL z około tygodniowym wyprzedzeniem, natomiast niezależne źródła techniczne najczęściej wskazują krótszy, bardziej praktyczny margines — 24–48 godzin przed przełączeniem, z docelową wartością rzędu 300 (czasem 60) sekund, przywracaną do normalnej po potwierdzeniu stabilności nowej strony. Bezpieczna zasada: im wcześniej obniżysz TTL, tym lepiej — 24 godziny to praktyczne minimum, tydzień to komfortowy wariant, jeśli możesz zaplanować migrację z wyprzedzeniem.

Przygotowanie przed migracją — checklista

Zanim cokolwiek przeniesiesz, zrób trzy rzeczy:

1. Pełny, zweryfikowany backup plików i bazy danych. To niepodważalny warunek wstępny w praktycznie każdym niezależnym poradniku migracji — backup, który sam nie da się przywrócić, nie chroni przed niczym. Zrób próbne przywrócenie backupu, jeśli masz taką możliwość, zanim zaczniesz właściwą migrację.
2. Sprawdź zgodność środowiska. Jeśli Twoja strona korzysta z niestandardowych wtyczek lub buildera, upewnij się, że nowy hosting je obsłuży — niektóre usługi migracyjne wprost wykluczają zamknięte platformy (np. Wix, Squarespace, Shopify) lub przenoszenie między dwoma kontami tego samego dostawcy.
3. Zanotuj, jakie wtyczki bezpieczeństwa i cache masz aktywne. Wtyczki takie jak Wordfence, Sucuri czy W3 Total Cache bywają wskazywane w niezależnych poradnikach jako częste źródło problemów podczas migracji — blokują transfer plików, generują fałszywe blokady dostępu albo serwują nieaktualną, zbuforowaną wersję strony. To spostrzeżenie ma niższą wiarygodność źródłową (pojedynczy branżowy wpis), więc traktuj je jako praktyczną ostrożność, a nie regułę: warto je tymczasowo wyłączyć na czas migracji i włączyć z powrotem po jej zakończeniu.
4. Spisz integracje zewnętrzne. Bramki płatności, CRM, CDN i webhooki, które mogą odwoływać się do konkretnego adresu IP lub subdomeny — jeśli którakolwiek z nich ma "na twardo" zapisany stary adres, samo przełączenie DNS jej nie naprawi i trzeba to zaktualizować ręcznie po stronie integracji.
5. Zapisz dane dostępowe w jednym miejscu. FTP/SSH do obu serwerów, panel DNS, dostęp administracyjny do poczty firmowej — żeby w trakcie migracji nie tracić czasu na odzyskiwanie haseł.

Realistyczny harmonogram — ile czasu na to zarezerwować

Migracja "bez przestoju" nie oznacza migracji w jeden wieczór. Składając w całość zalecane ramy czasowe: obniżenie TTL z wyprzedzeniem minimum 24–48 godzin (przy stronach ważnych dla SEO nawet tygodnia), transfer plików i bazy równolegle ze starym serwerem bez sztywnego terminu, propagacja rekordów MX do 48 godzin po ich zmianie oraz utrzymanie starego serwera aktywnego jeszcze 48–72 godziny po przełączeniu. Sumarycznie cały proces rozciąga się realnie na 4–10 dni, a nie na jedno popołudnie — nawet jeśli sama widoczna zmiana dla użytkowników trwa kilka minut.

Wybór metody: hosting zrobi to za Ciebie czy robisz to sam

To najważniejsza decyzja w całym procesie. Dla większości czytelników PICKNIVO odpowiedzią jest darmowa migracja realizowana przez nowego dostawcę — to opcja z najmniejszym ryzykiem błędu, bo robi ją ktoś, kto robi to na co dzień.

Migracja wykonywana przez hosting

• Hostinger oferuje darmową, nielimitowaną migrację przy każdym planie; strony WordPress są zwykle przenoszone w mniej niż 2 godziny, inne CMS-y oparte na cPanelu mogą zająć ponad 20 godzin. Usługa nie obejmuje zamkniętych builderów (Wix, Squarespace, Shopify) ani przenoszenia między dwoma kontami Hostingera — to wymaga procesu ręcznego lub osobnego narzędzia.
• Kinsta przenosi WordPressa za darmo i bez limitu, z własnym zespołem migracyjnym oraz wyraźną obietnicą "zero downtime"; standardowe zgłoszenie realizowane jest zwykle w ciągu jednego dnia roboczego, ekspresowe nawet w 8 godzin. Mimo to samo przełączenie DNS na koniec musisz zrobić sam, a strony z ciągłą aktywnością (sklepy WooCommerce, strefy członkowskie) powinny na czas transferu przejść w tryb konserwacji, żeby nie stracić danych wpisanych w międzyczasie.
• SiteGround udostępnia darmową wtyczkę SiteGround Migrator, działającą na bazie tokena; według własnej deklaracji dostawcy nie powoduje przestoju strony źródłowej, choć przy dłuższych transferach zaleca tryb konserwacji. Wtyczka nie przenosi treści spoza WordPressa, nie działa z instalacji czysto lokalnych ani z WordPress.com, nie obsługuje pełnej sieci Multisite (choć pojedyncze podstrony da się przenieść), a sam SiteGround przyznaje, że bywa zawodna na niektórych restrykcyjnych hostingach firm trzecich.

Głosy użytkowników (dane anegdotyczne, nie fakt zweryfikowany). Część recenzentów opisuje migracje przez hosting jako gładkie i bezproblemowe, inni zgłaszają tarcia proceduralne — najczęściej wokół kolejności zmiany serwerów nazw (nameserverów) i rekordów DNS. Powtarzający się, konkretny wątek dotyczy Hostingera: część użytkowników zgłasza konieczność przełączenia domeny na nameservery Hostingera, zanim da się dodać niektóre rekordy DNS, co przy braku wcześniejszego planowania tworzy realne okno przestoju. To pojedyncze relacje z platformy z recenzjami, a nie zweryfikowany fakt — nie traktuj ich jako podstawy do wyboru albo odrzucenia konkretnego dostawcy.

Jeśli chcesz porównać konkretne oferty przed decyzją, zobacz jak ocenić ofertę hostingu przed zakupem oraz jak wybrać hosting dla początkujących bez przepłacania.

Migracja samodzielna, krok po kroku

Jeśli wolisz zrobić to sam — bo lubisz mieć pełną kontrolę albo Twój przypadek nie mieści się w standardowej usłudze hostingu — trzymaj się tej kolejności.

1. Skopiuj pliki i bazę danych. Jeśli adres URL strony i baza danych pozostają takie same, przeniesienie sprowadza się w praktyce do skopiowania plików witryny i bazy danych na nowy serwer; dane logowania w wp-config.php trzeba zaktualizować tylko wtedy, gdy faktycznie się zmieniły (inny host, inna nazwa bazy, inne hasło).

2. Zaktualizuj wp-config.php i posprzątaj po sobie. Jeśli podczas migracji korzystałeś ze stałej RELOCATE do automatycznego wykrycia nowego adresu URL, koniecznie usuń ją zaraz po zakończeniu — pozostawienie jej w środowisku produkcyjnym jest udokumentowanym zagrożeniem bezpieczeństwa, bo pozwala w pewnych warunkach przekierować adres strony.

3. Podmień adresy URL w bazie — ostrożnie z GUID-em. Do zamiany starego adresu na nowy w treści bazy danych najwygodniej użyć komendy wp search-replace z WP-CLI. Domyślny, oparty na SQL tryb tej komendy bezpiecznie obsługuje dane zserializowane przez PHP; flaga --precise włącza wolniejszy, dokładniejszy tryb oparty na PHP, przydatny tylko przy problematycznych przypadkach.

Kluczowa pułapka: kolumna guid w bazie WordPressa nie powinna być zmieniana podczas migracji, bo czytniki RSS identyfikują po niej wpisy — jej modyfikacja może sprawić, że już opublikowane treści pojawią się w kanałach RSS jako nowe. Wbrew temu, co sugerują niektóre poradniki, WP-CLI nie pomija kolumny guid automatycznie — trzeba jawnie dodać flagę --skip-columns=guid. Zanim uruchomisz właściwą operację, zawsze przetestuj ją flagą --dry-run — pokaże liczbę planowanych podmian w każdej tabeli, nie zapisując żadnych zmian. (Jeśli prowadzisz sieć Multisite, pamiętaj też o fladze --network — bez niej operacja obejmie tylko bieżącą witrynę w sieci, nie całą sieć.)

4. Albo skorzystaj z wtyczki, jeśli wolisz interfejs graficzny. Dwie najpopularniejsze opcje mają wyraźne limity na darmowym poziomie:

• All-in-One WP Migration (ponad 5 mln aktywnych instalacji) pozwala eksportować kopię strony bez limitu rozmiaru, ale import na darmowej wersji jest ograniczony — sam producent nie podaje jednej konkretnej liczby, a niezależne źródła podają różne wartości zależnie od ustawień PHP hostingu, więc nie warto opierać się na jednej sztywnej liczbie megabajtów. Płatne rozszerzenie "Unlimited Extension" znosi te limity narzucone przez hosting.
• Duplicator w wersji darmowej nie obsługuje sieci Multisite, a paczkę migracyjną buduje na serwerze źródłowym — na hostingu współdzielonym z ciasnym limitem miejsca lub czasu wykonania PHP proces może się zatrzymać niezależnie od tego, czy używasz wersji darmowej czy płatnej. Wersja płatna odblokowuje m.in. obsługę Multisite i integrację z chmurą — dokładną, aktualną cenę sprawdź bezpośrednio na stronie producenta, bo promocje zmieniają się często.

Testowanie nowego hostingu przed przełączeniem DNS

Zanim przełączysz ruch, przetestuj nową stronę pod docelowym adresem, nie zmieniając jeszcze publicznego DNS. Najprostszy sposób to edycja pliku hosts w Twoim systemie operacyjnym — wpis kierujący domenę na adres IP nowego serwera działa tylko na Twoim komputerze i trzeba go usunąć po zakończeniu testów. Google w swojej dokumentacji sugeruje podobne podejście: testowanie na środowisku z ograniczonym dostępem po adresie IP albo na tymczasowej, nieindeksowanej domenie, a następnie zweryfikowanie w Search Console (narzędziem inspekcji adresu URL), że Googlebot faktycznie widzi nowe środowisko poprawnie.

Podczas tego testu koniecznie sprawdź dwie rzeczy:

• Certyfikat SSL — powinien być aktywny na nowym hostingu jeszcze przed przełączeniem DNS, żeby żaden odwiedzający nie zobaczył ostrzeżenia o niezabezpieczonym połączeniu w momencie cutoveru.
• Treści mieszane (mixed content) — strona działająca na HTTPS, ale wciąż ładująca część zasobów po HTTP, to częsty efekt uboczny migracji, wynikający z nie w pełni zaktualizowanych adresów wewnętrznych; sprawdź to jako element testu przedmigracyjnego.

Przełączenie DNS bez przestoju

Gdy nowa strona przeszła test, czas na właściwe przełączenie:

1. Upewnij się, że TTL rekordów DNS został obniżony z odpowiednim wyprzedzeniem (patrz sekcja wyżej — 24 godziny to praktyczne minimum, tydzień daje większy margines bezpieczeństwa).
2. Zmień rekordy A/AAAA (i CNAME, jeśli dotyczy) tak, by wskazywały na nowy serwer.
3. Przez cały okres propagacji trzymaj oba serwery aktywne i serwujące identyczną treść — część ruchu wciąż trafi na stary adres, dopóki cache DNS u operatorów się nie odświeży.
4. Nie kasuj ani nie wyłączaj starego hostingu od razu po przełączeniu. Zostaw go jako punkt awaryjnego powrotu co najmniej do końca okna propagacji i potwierdzenia, że nowa strona działa stabilnie.

Poczta e-mail podczas migracji — krok, o którym łatwo zapomnieć

Migracja hostingu WWW i poczty e-mail to formalnie dwie osobne sprawy, ale łatwo je przypadkiem połączyć. Zasada jest prosta: zostaw rekordy MX oraz powiązane z nimi SPF, DKIM i DMARC skierowane na obecnego dostawcę poczty i zmieniaj wyłącznie rekordy A/CNAME odpowiadające za samą stronę WWW — to oddziela pocztę od migracji strony.

Realne ryzyko: niektórzy nowi dostawcy przy dodawaniu domeny podmieniają całą strefę DNS na domyślną, po cichu kasując istniejące rekordy MX/SPF/DKIM/DMARC — efektem jest przerwa w działaniu poczty (także w usługach typu Google Workspace), dopóki rekordy nie zostaną ręcznie przywrócone. Po każdej zmianie DNS sprawdź, czy poczta nadal działa poprawnie, zanim uznasz migrację za zakończoną.

Ochrona SEO podczas migracji

W scenariuszu tego poradnika — ta sama domena, te same adresy URL, zmienia się wyłącznie infrastruktura po stronie serwera — narzędzie Change of Address w Google Search Console nie jest potrzebne. Ono dotyczy zmiany domeny lub subdomeny, a nie przeniesienia tej samej witryny na inny serwer. (Jeśli przy okazji zmiany hostingu zmieniasz też domenę albo przechodzisz z HTTP na HTTPS, to już inny scenariusz — wymaga przekierowań 301/308, unikania łańcuchów dłuższych niż 3 przeskoki i utrzymania przekierowań przez około rok, z uwzględnieniem, że ponowne poukładanie się rankingów na większych stronach może potrwać kilka tygodni.)

Trzy rzeczy do sprawdzenia po przełączeniu:

• Nie zostawiaj aktywnych reguł noindex ani blokad w robots.txt, które służyły do ukrycia środowiska testowego/stagingowego — po przejściu na produkcję muszą zniknąć.
• Upewnij się, że weryfikacja Search Console (plik HTML, meta tag albo weryfikacja przez Analytics) nadal działa na nowym hostingu.
• Zablokowanie Googlebota przez firewall albo ochronę antyDDoS nowego serwera to kolejny częsty, przypadkowy błąd — warto to jawnie sprawdzić. Chwilowy spadek, a potem odbudowa częstotliwości crawlowania przez Googlebota bezpośrednio po migracji jest zjawiskiem normalnym.

Najczęstsze błędy i kiedy nie robić tego samodzielnie

Z relacji praktyków (źródła niższej wiarygodności, ale powtarzające się niezależnie od siebie) najczęstsze objawy nieudanej, samodzielnie prowadzonej migracji to: błędy 404 na całej witrynie, działająca tylko strona główna, zepsute lub niedopasowane linki permalink, albo strona "migająca" między starą a nową wersją w trakcie propagacji DNS. W większości przypadków źródłem problemu jest pominięcie testów przed przełączeniem albo zbyt wczesne skasowanie starego hostingu lub rekordów DNS.

Kiedy lepiej oddać to zadanie zespołowi migracyjnemu hostingu zamiast robić to samemu:

• strona ma duży ruch transakcyjny w czasie rzeczywistym (sklep WooCommerce, strefa członkowska) — takie strony wymagają trybu konserwacji na czas transferu, żeby nie zgubić danych wpisywanych w międzyczasie, a to łatwiej zapewnić zespołowi, który robi to rutynowo;
• nie czujesz się pewnie w linii poleceń ani w edycji plików konfiguracyjnych;
• witryna jest duża, złożona albo korzysta z niestandardowych integracji, gdzie błąd kosztuje więcej niż czas zaoszczędzony na samodzielnej migracji.

Prosta matryca decyzyjna, którą warto sobie zadać przed wyborem ścieżki:

Żadna z kolumn nie jest "lepsza" sama w sobie — to kwestia dopasowania do konkretnej sytuacji, a nie uniwersalnej rekomendacji.

Podsumowanie i dalsze kroki

1. Przygotuj zweryfikowany backup i sprawdź zgodność środowiska.
2. Zbuduj i przetestuj stronę na nowym hostingu (plik hosts, SSL, mixed content) — bez przełączania publicznego DNS.
3. Obniż TTL z wyprzedzeniem, potem przełącz DNS, trzymając oba serwery aktywne w trakcie propagacji.
4. Osobno zabezpiecz pocztę (MX/SPF/DKIM/DMARC) i sprawdź SEO (weryfikacja Search Console, brak blokad noindex/robots).
5. Nie kasuj starego hostingu, dopóki nowa strona nie jest w pełni stabilna.

Jeśli dopiero wybierasz, na co się przenieść, zobacz ranking najlepszego hostingu 2026, porównanie Hostinger vs Kinsta oraz jak ocenić ofertę hostingu przed zakupem i jak wybrać hosting dla początkujących bez przepłacania.

FAQ

Ile trwa przestój przy dobrze zaplanowanej migracji?
Przy odpowiednio wcześnie obniżonym TTL propagacja DNS trwa zwykle minuty, a nie godziny. Nie ma tu jednej gwarantowanej liczby — zależy to od tego, jak długo przed zmianą TTL został obniżony (24–48h to praktyczne minimum, tydzień to bezpieczniejszy margines rekomendowany przez Google), dlatego stary serwer zawsze powinien działać jeszcze kilkadziesiąt godzin dłużej jako zabezpieczenie.

Czy stracę pozycje w Google po zmianie hostingu?
Przy zachowaniu tych samych adresów URL i poprawnie przeprowadzonej migracji chwilowy spadek częstotliwości crawlowania jest zjawiskiem normalnym, a nie oznaką utraty pozycji — aktywność Googlebota zwykle odbudowuje się w miarę adaptacji do nowej infrastruktury.

Co jest większym ryzykiem: strona czy poczta?
Z opisanych tu źródeł wynika, że to poczta — reset nameserverów potrafi nadpisać rekordy MX bez ostrzeżenia, podczas gdy sama strona ma zwykle wyraźnie widoczne (i łatwiejsze do zdiagnozowania) objawy problemu.

Czy muszę korzystać z konkretnego narzędzia do sprawdzania propagacji DNS?
Nie — to tylko pomoc w monitorowaniu, nie element samej migracji. Wystarczy dowolne ogólnodostępne narzędzie tej kategorii (np. typu "DNS checker"), sprawdzające rekordy z wielu lokalizacji na świecie jednocześnie.

Powiązane materiały w PICKNIVO

• Najlepszy hosting 2026 – Hostinger vs SiteGround vs Kinsta
• Hostinger czy Kinsta – który hosting wybrać?
• Hostinger – jak ocenić ofertę przed zakupem hostingu
• Najlepszy hosting dla początkujących – jak wybrać bez przepłacania