Jak przenieść stronę na hosting bez utraty SEO [2026]

Przeniesienie strony na inny hosting bez zmiany domeny to operacja o minimalnym ryzyku dla SEO – Google śledzi adres URL, nie serwer, na którym strona jest hostowana. Ryzyko rośnie tylko wtedy, gdy popełnisz błędy podczas migracji: zerwiesz dostępność strony, pomylisz przekierowania lub źle skonfigurujesz DNS.

Zmiana hostingu a SEO – czy naprawdę możesz stracić pozycje w Google?

Sama zmiana serwera nie usuwa Cię z Google. Twoje pozycje są powiązane z domeną i strukturą URL, nie z adresem IP hostingu. Jeśli strona działa pod tym samym adresem przed i po migracji, Google nie ma powodu, żeby obniżyć jej pozycje.

Straty pozycji zdarzają się z konkretnych powodów:

• Strona była niedostępna przez wiele godzin podczas migracji (Googlebot trafił na błąd 503 lub 404).
• Przekierowania 301 zostały skonfigurowane błędnie – np. wszystkie podstrony kierują na stronę główną zamiast na odpowiadające im nowe adresy.
• Stary hosting wygasł przed zakończeniem propagacji DNS.
• Środowisko testowe na nowym hostingu było dostępne publicznie bez blokady noindex, co wygenerowało duplikaty treści.

Dobra migracja na szybszy serwer może nawet poprawić pozycje, bo Core Web Vitals (LCP, CLS, INP) są czynnikiem rankingowym. Jeśli nowy hosting ładuje stronę o 1-2 sekundy szybciej, masz realną szansę na lepsze wyniki.

Zmiana hostingu vs. zmiana domeny – dlaczego to kluczowa różnica

To najważniejsze rozróżnienie, które większość poradników myli lub pomija.

Jeśli zmieniasz tylko hosting i zachowujesz domenę np. twojafirma.pl, nie potrzebujesz ani przekierowań 301, ani powiadamiania Google o zmianie adresu. Skupiasz się wyłącznie na tym, żeby strona była dostępna bez przerwy.

Zanim zaczniesz – co zrobić na 48-72 godziny przed migracją

1. Zmniejsz TTL rekordu DNS do 300 sekund (5 minut). Wejdź w panel zarządzania domeną (np. w home.pl: Domeny → Zarządzaj → Strefa DNS, w Cyber_Folks: Domeny → DNS → Edytuj rekord A). Znajdź rekord A swojej domeny i zmień wartość TTL z domyślnych 86400 (24h) na 300. Dzięki temu po zmianie adresu IP propagacja DNS zajmie 5-15 minut zamiast nawet 24 godzin. Musisz to zrobić przed migracją, żeby serwery DNS na świecie zdążyły pobrać nowe TTL.
2. Zrób pełny backup strony. W panelu WordPressa zainstaluj wtyczkę UpdraftPlus (Wtyczki → Dodaj nową → szukaj „UpdraftPlus”). Wejdź w Ustawienia → UpdraftPlus, kliknij Utwórz kopię zapasową teraz i zaznacz opcję kopii plików i bazy danych. Pobierz wszystkie pliki backupu na swój komputer.
3. Zablokuj środowisko testowe na nowym hostingu. Jeśli nowy hosting daje Ci subdomenę testową (np. preview.twojafirma.pl), koniecznie dodaj do pliku robots.txt na tej subdomenie:

   User-agent: *
   Disallow: /

   Zapobiega to indeksowaniu duplikatów Twojej strony przez Google.

4. Zapisz listę wszystkich rekordów DNS. Zrób zrzut ekranu lub skopiuj do notatnika wszystkie rekordy z panelu DNS: A, CNAME, MX, TXT (SPF, DKIM, DMARC). Będziesz ich potrzebować przy konfiguracji nowego hostingu.
5. Sprawdź aktualny stan strony w Google Search Console. Zaloguj się na search.google.com/search-console, wejdź w Skuteczność i zapisz aktualne pozycje dla kluczowych fraz. To Twój punkt odniesienia po migracji.

Krok po kroku: bezpieczna migracja strony na nowy hosting

1. Skopiuj pliki strony na nowy serwer. Najprościej przez Menedżer plików w panelu nowego hostingu (cPanel: File Manager, DirectAdmin: File Manager) lub przez FTP (program FileZilla). Skopiuj całą zawartość katalogu public_html ze starego hostingu do katalogu głównego nowego hostingu.
2. Wyeksportuj bazę danych MySQL ze starego hostingu. Wejdź w phpMyAdmin na starym hostingu (cPanel → Bazy danych → phpMyAdmin). Kliknij na bazę danych swojej strony, wybierz zakładkę Eksportuj, format SQL, kliknij Wykonaj. Pobierz plik .sql.
3. Utwórz nową bazę danych na nowym hostingu. W panelu nowego hostingu utwórz bazę danych i użytkownika bazy. Zapisz: nazwę bazy, nazwę użytkownika, hasło i host (zazwyczaj localhost).
4. Zaimportuj bazę danych. Wejdź w phpMyAdmin na nowym hostingu, wybierz nową pustą bazę, kliknij zakładkę Importuj i wgraj plik .sql.
5. Zaktualizuj plik wp-config.php. Przez Menedżer plików lub FTP otwórz plik wp-config.php w głównym katalogu strony na nowym hostingu i wpisz dane nowej bazy:

   define('DB_NAME', 'nazwa_twojej_bazy');
   define('DB_USER', 'uzytkownik_bazy');
   define('DB_PASSWORD', 'haslo_bazy');
   define('DB_HOST', 'localhost');

6. Przetestuj stronę na nowym hostingu przed zmianą DNS. Możesz to zrobić, edytując plik hosts na swoim komputerze (Windows: C:\Windows\System32\drivers\etc\hosts; Mac/Linux: /etc/hosts). Dodaj linię:

   NOWY_ADRES_IP twojafirma.pl www.twojafirma.pl

   Zamień NOWY_ADRES_IP na adres IP nowego serwera. Odwiedź stronę w przeglądarce – zobaczysz wersję ze nowego hostingu, ale reszta świata nadal widzi stary. Sprawdź, czy wszystkie podstrony działają, formularze wysyłają wiadomości, sklep (jeśli masz) się otwiera.

7. Zmień rekord A w DNS. Wróć do panelu zarządzania domeną, znajdź rekord A i zmień adres IP na adres nowego hostingu. Po zmniejszonym wcześniej TTL (300s) propagacja zajmie kilka-kilknaście minut.
8. Usuń zapis z pliku hosts na swoim komputerze po 15-30 minutach od zmiany DNS. Odwiedź stronę w trybie incognito, żeby zobaczyć ją tak, jak widzą ją inni.
9. Utrzymaj stary hosting aktywny przez minimum 7 dni. To bufor bezpieczeństwa na wypadek, gdyby niektóre serwery DNS propagowały wolniej.

TTL, DNS i propagacja – co to znaczy dla właściciela firmy

TTL (Time To Live) to liczba sekund, przez którą serwery DNS na całym świecie „pamiętają” adres IP Twojej domeny. Domyślna wartość to 86400 sekund, czyli 24 godziny. Oznacza to, że po zmianie adresu IP, część użytkowników przez całą dobę mogła być kierowana na stary serwer.

Dlatego na 48-72h przed migracją ustawiasz TTL na 300 sekund (5 minut). Serwery DNS zaczynają „zapominać” stary adres szybciej. Gdy zmienisz rekord A, propagacja nowego IP kończy się w ciągu 5-15 minut dla większości użytkowników.

Po zakończeniu migracji możesz z powrotem zwiększyć TTL do 3600 lub 86400 – to zmniejsza obciążenie serwerów DNS i przyspiesza otwieranie strony dla powracających użytkowników.

Propagacja DNS to czas potrzebny, żeby nowy adres IP dotarł do wszystkich serwerów DNS na świecie. Przy TTL 300s trwa 15-60 minut. Przy domyślnym TTL 86400s – nawet 48 godzin. Nie możesz tego przyspieszyć, ale możesz go skrócić właśnie przez TTL.

Poczta e-mail podczas migracji – rekordy MX, SPF i DKIM

To obszar, który właściciele firm pomijają, a potem nie mogą wysyłać ani odbierać e-maili przez kilka dni. Rekordy pocztowe są niezależne od rekordu A strony www.

Co musisz zrobić z pocztą:

• Rekord MX wskazuje, który serwer obsługuje pocztę. Jeśli poczta jest na starym hostingu, nie zmieniaj rekordu MX podczas migracji strony. Zmień go dopiero po osobnym przeniesieniu skrzynek pocztowych na nowy serwer.
• Rekord SPF (typ TXT) określa, które serwery mogą wysyłać e-mail w imieniu Twojej domeny. Przykład:

  v=spf1 include:_spf.nowy-hosting.pl ~all

  Zaktualizuj go do danych nowego hostingu dopiero po przeniesieniu poczty.

• Rekord DKIM (typ TXT) to podpis cyfrowy e-maili. Nowy hosting powinien dostarczyć Ci jego wartość po skonfigurowaniu skrzynek. Dodaj go jako nowy rekord TXT w panelu DNS domeny.

Bezpieczna kolejność: Najpierw przenieś stronę www (zmień rekord A). Działająca strona – dopiero potem przenoś skrzynki pocztowe i aktualizuj MX, SPF, DKIM. Nigdy jednocześnie.

Błąd miękki 404 – najgroźniejsza pułapka przy zmianie hostingu

Miękki 404 (ang. soft 404) to sytuacja, gdy strona zwraca kod HTTP 200 (wszystko OK), ale treść strony wskazuje, że strona nie istnieje – np. wyświetla stronę główną zamiast konkretnej podstrony. Google interpretuje to jako usunięcie podstrony i usuwa ją z indeksu.

Przy migracji hostingu najczęściej pojawia się w takim scenariuszu: podczas konfigurowania WordPressa na nowym serwerze zapomniałeś o pliku .htaccess lub nie włączyłeś mod_rewrite w Apache. Efekt: WordPress działa, strona główna się otwiera, ale każda podstrona (np. /oferta, /kontakt) przekierowuje na stronę główną.

Jak sprawdzić i naprawić:

1. Wejdź na kilka podstron swojej witryny ręcznie – czy otwierają się poprawnie czy lądują na stronie głównej?
2. Sprawdź, czy plik .htaccess jest w katalogu głównym na nowym serwerze (często jest ukryty – w Menedżerze plików cPanel zaznacz opcję „Pokaż ukryte pliki”).
3. Jeśli plik istnieje, sprawdź, czy zawiera standardowe reguły WordPressa:

   # BEGIN WordPress
   RewriteEngine On
   RewriteBase /
   RewriteRule ^index\.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   # END WordPress

4. Jeśli .htaccess jest poprawny, a problem nadal istnieje: w panelu WordPressa wejdź w Ustawienia → Bezpośrednie odnośniki (Permalinki) i kliknij Zapisz zmiany bez żadnych zmian. WordPress odtworzy reguły w .htaccess.

Checklista post-migracyjna: co sprawdzić po 24h, 7 i 30 dniach

Po 24 godzinach

• Otwórz stronę główną i 5-10 podstron w trybie incognito – czy działają poprawnie?
• Sprawdź formularz kontaktowy – wyślij testową wiadomość i sprawdź, czy doszła.
• Wejdź w Google Search Console → Sprawdzanie URL i wpisz kilka adresów podstron. Kliknij Przetestuj na żywo – czy Google widzi stronę poprawnie?
• Sprawdź certyfikat SSL – czy kłódka jest aktywna przy adresie strony? Jeśli nie, skonfiguruj bezpłatny certyfikat Let’s Encrypt w panelu nowego hostingu.
• Wejdź w GSC → Indeksowanie → Strony i sprawdź, czy nie pojawiły się nowe błędy.

Po 7 dniach

• Porównaj pozycje w Google Search Console (Skuteczność) z zapisanymi wartościami sprzed migracji.
• Sprawdź Google PageSpeed Insights (pagespeed.web.dev) – wyniki Core Web Vitals na nowym hostingu vs. poprzednie.
• Wejdź w GSC → Indeksowanie → Mapy witryny i sprawdź, czy sitemap.xml jest poprawnie zaindeksowany.
• Sprawdź logi serwera w panelu hostingu lub użyj wtyczki Redirection w WordPressie – czy nie ma nieoczekiwanych błędów 404?

Po 30 dniach

• Pełne porównanie ruchu organicznego w Google Analytics lub GSC – miesiąc po migracji vs. miesiąc przed.
• Jeśli ruch jest stabilny lub wyższy: możesz zamknąć konto na starym hostingu.
• Zmień TTL rekordu DNS z powrotem na 3600 lub 86400 sekund.
• Upewnij się, że backup automatyczny jest aktywny na nowym hostingu.

Kiedy warto zlecić migrację specjalistom zamiast robić to samemu?

Samodzielna migracja jest realna dla prostej strony firmowej opartej na WordPressie z kilkudziesięcioma podstronami. Warto jednak zlecić ją specjalistom, gdy:

• Masz sklep internetowy WooCommerce z aktywnym ruchem i zamówieniami – każda godzina niedostępności to realna strata.
• Strona generuje powyżej 1000 sesji dziennie i pozycje w Google są kluczowe dla Twojego biznesu.
• Jednocześnie zmieniasz domenę – to wymaga skonfigurowania przekierowań 301 dla każdego URL i zgłoszenia zmiany adresu w Google Search Console przez narzędzie Change of Address.
• Na stronie działają zewnętrzne integracje: systemy płatności, CRM, zewnętrzne API – błąd konfiguracji może je zerwać.
• Nie masz pewności, czy poradzisz sobie z krokami technicznymi: phpMyAdmin, FTP, edycja pliku hosts, konfiguracja DNS.

Jeśli planujesz nie tylko zmienić hosting, ale też odświeżyć lub całkowicie przeprojektować stronę, możesz sprawdzić ofertę tworzenia stron internetowych dla firm – migracja jest wtedy częścią kompleksowego procesu, a nie osobnym zadaniem.

Najczęstsze problemy

Problem 1: Strona wygląda poprawnie, ale zdjęcia się nie ładują

Najprawdopodobniej nie skopiowałeś katalogu wp-content/uploads w całości. Katalog ten przechowuje wszystkie media i ma często kilka GB. Skopiuj go ponownie przez FTP (program FileZilla: połącz się ze starym hostingiem, zaznacz cały folder uploads, przenieś na nowy serwer). Upewnij się też, że uprawnienia folderu to 755, a plików 644 – zmienisz to w Menedżerze plików, klikając prawym przyciskiem na folder → Zmień uprawnienia.

Problem 2: Po zmianie DNS strona nadal otwiera starą wersję

Twoja przeglądarka lub dostawca internetu buforuje stary adres IP. Wyczyść cache DNS na komputerze: w Windows otwórz Wiersz poleceń i wpisz ipconfig /flushdns. Na Macu: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Sprawdź stronę w trybie incognito lub na sieci mobilnej (LTE), gdzie cache jest czysty.

Problem 3: E-maile przestały działać po migracji

Zmieniając rekord A (adres strony), przypadkowo usunąłeś lub nadpisałeś rekordy MX. Wróć do panelu DNS domeny i sprawdź, czy rekordy MX nadal wskazują na właściwy serwer pocztowy. Jeśli masz pocztę na starym hostingu, a planujesz ją tam zostawić, rekordy MX muszą dalej wskazywać na stary serwer (lub Twoją usługę pocztową: Gmail Workspace, Office 365). Nie dotykaj rekordów MX, SPF i DKIM, jeśli nie przenosisz jednocześnie poczty.

FAQ

Czy zmiana hostingu powoduje utratę pozycji w Google?

Sama zmiana hostingu bez zmiany domeny nie powoduje utraty pozycji. Google indeksuje adresy URL, a nie adresy IP serwerów. Pozycje możesz stracić przez błędy podczas migracji: długą niedostępność strony, błędne przekierowania lub problemy z plikiem .htaccess. Poprawnie przeprowadzona migracja jest dla Google niewidoczna.

Jak długo trwa propagacja DNS po zmianie hostingu?

To zależy od wartości TTL Twojego rekordu DNS. Przy domyślnym TTL 86400 sekund (24h) propagacja może trwać nawet 48 godzin. Jeśli obniżysz TTL do 300 sekund minimum 48h przed migracją, nowy adres IP trafi do większości serwerów DNS w ciągu 5-30 minut po zmianie. Dlatego zmiana TTL to pierwszy krok w przygotowaniach.

Czy muszę powiadamiać Google o zmianie hostingu?

Nie. Narzędzie „Change of Address” w Google Search Console jest wymagane tylko przy zmianie domeny (np. z stara-firma.pl na nowa-firma.pl). Jeśli zmieniasz tylko hosting i zachowujesz tę samą domenę, Google sam wykryje stronę pod nowym adresem IP – nie musisz nic zgłaszać.

Jak sprawdzić, czy strona działa na nowym hostingu zanim zmienię DNS?

Edytuj plik hosts na swoim komputerze (Windows: C:\Windows\System32\drivers\etc\hosts; Mac: /etc/hosts) i dodaj linię: ADRES_IP_NOWEGO_SERWERA twojadomena.pl www.twojadomena.pl. Po zapisaniu pliku Twoja przeglądarka otworzy stronę z nowego serwera, podczas gdy reszta świata nadal widzi stary. Usuń tę linię po zakończeniu testów.