Zmiana hostingu przy zachowaniu tej samej domeny i tych samych adresów URL jest dla Google praktycznie neutralna. Przeniesienie strony na inny serwer zmienia adres IP, a sam adres IP nie jest czynnikiem rankingowym. Nie trzeba wtedy ustawiać przekierowań 301 ani zgłaszać niczego w Google Search Console. Pozycje spadają nie przez zmianę serwera, tylko przez rzeczy robione przy okazji: zmianę adresów URL, robots.txt z regułą Disallow: / skopiowany ze środowiska testowego, utratę certyfikatu SSL, kilkugodzinną przerwę w działaniu albo przesiadkę na serwer wolniejszy niż poprzedni.
To rozróżnienie jest sednem tematu, a większość poradników je zamazuje. Poniżej: co Google obchodzi, co realnie psuje widoczność i w jakiej kolejności to sprawdzać, jeśli ruch spadnie. Jeśli szukasz samej procedury, mamy osobny tekst: jak przenieść stronę na inny hosting krok po kroku. Ten artykuł odpowiada na pytanie, czego przy tym nie zepsuć.
Zmiana serwera to nie to samo co migracja strony
Słowo "migracja" opisuje dwie różne operacje o zupełnie różnych konsekwencjach dla SEO. Rozdziel je, zanim zaczniesz cokolwiek klikać.
Zmiana hostingu (serwera, adresu IP)
Te same pliki i ta sama baza lądują na innym serwerze. Domena, struktura adresów i treść zostają bez zmian. Dla użytkownika i dla robota Google adres twojafirma.pl/oferta nadal zwraca kod 200 i tę samą treść. Zmienia się wyłącznie to, gdzie fizycznie stoi maszyna generująca tę odpowiedź. Google nie ma tu czego indeksować od nowa. Nie ma przekierowań do ustawienia, bo nie ma starych adresów. Nie ma zgłoszenia do wysłania, bo nie ma zmiany, którą trzeba by zgłaszać.
Zmiana domeny lub zmiana adresów URL
To jest prawdziwa migracja. Adresy, które Google ma w indeksie, przestają istnieć albo zaczynają zwracać co innego. Przenosisz się z starafirma.pl na nowafirma.pl, albo zostajesz na tej samej domenie, ale przy przesiadce na nowy CMS zmienia się struktura: /produkty/?id=42 staje się /produkty/kabel-hdmi. Bez przekierowań 301 z każdego starego adresu na jego odpowiednik tracisz zgromadzone sygnały i lądujesz z podstronami, które Google widzi jako 404. Ten scenariusz odpowiada za większość historii "zmieniłem hosting i wszystko poleciało".
Cała procedura zmiany samego adresu jest opisana osobno, w artykule o przeniesieniu strony na nową domenę. Problem w tym, że obie operacje często robi się jednocześnie. Ktoś przy okazji przeprowadzki odświeża stronę, zmienia motyw, porządkuje adresy i wycina "niepotrzebne" podstrony. Potem spadek przypisuje hostingowi, choć hosting był tu jedyną rzeczą bez winy. Rozdziel te zmiany w czasie: najpierw przeprowadzka jeden do jednego, dwa tygodnie obserwacji, dopiero potem przebudowa.
Co zmieniasz, a co z tego obchodzi Google
| Co zmieniasz | Czy Google to obchodzi | Co musisz zrobić |
|---|---|---|
| Zmiana serwera i adresu IP (ta sama domena, te same URL) | Nie. IP nie jest czynnikiem rankingowym | Nic w Search Console. Pilnujesz dostępności, SSL, robots.txt i czasu odpowiedzi |
| Zmiana domeny (starafirma.pl na nowafirma.pl) | Tak, bardzo | Przekierowania 301 jeden do jednego, narzędzie "Zmiana adresu" w Search Console, nowa usługa dla nowej domeny, aktualizacja linków wewnętrznych |
| Zmiana struktury adresów URL (ta sama domena) | Tak | Przekierowania 301 ze starego adresu na nowy, aktualizacja mapy witryny i linków wewnętrznych. Narzędzie "Zmiana adresu" tu NIE działa |
| Przejście z HTTP na HTTPS | Tak, to zmiana adresów | Przekierowanie 301 z http na https, poprawny certyfikat, wymuszenie HTTPS w konfiguracji, aktualizacja adresów w bazie |
| Zmiana CMS przy tych samych adresach | Nie, o ile adresy i treść zostają | Zmapować adresy jeden do jednego przed startem i sprawdzić, czy nowy CMS nie dokłada slasha ani nie generuje duplikatów |
| Wolniejszy serwer po przeprowadzce | Trochę. Page experience to realny, ale umiarkowany sygnał | Zmierzyć TTFB przed i po, porównać Core Web Vitals, poprawić lub wrócić do hostingu z reklamacją |
Jeden wiersz zasługuje na podkreślenie, bo błąd powtarza się nagminnie. Narzędzie "Zmiana adresu" w Google Search Console służy wyłącznie do zmiany domeny. Nie do zmiany serwera. Jeśli zostajesz na tej samej domenie, nie masz go nawet jak sensownie użyć, a poradniki każące uruchomić je po przeprowadzce nie rozumieją, do czego ono jest.
Lista kontrolna: przed, w trakcie i po
Przed przełączeniem
- Obniż TTL rekordów A i AAAA do 300 do 600 sekund, co najmniej 24 do 48 godzin wcześniej. Domyślne TTL to często 86400 s (24 h), a stara wartość musi najpierw wygasnąć z pamięci serwerów DNS. Tego kroku nie nadrobisz w dniu przeprowadzki.
- Zrób pełną kopię plików i bazy i sprawdź, czy da się ją odtworzyć. Kopia, której nikt nie próbował przywrócić, to nie kopia.
- Zapisz .htaccess albo konfigurację nginx. To tam żyją stare przekierowania 301, budowane latami, i to je najłatwiej zgubić przy kopiowaniu "samych plików strony".
- Zrób listę zaindeksowanych adresów (mapa witryny plus raport indeksowania), żeby mieć z czym porównać stan po migracji.
- Zmierz TTFB i Core Web Vitals na starym serwerze. Bez punktu odniesienia nie ocenisz nowego.
- Sprawdź, czy SSL będzie gotowy na nowym serwerze przed przełączeniem DNS, a nie po.
W trakcie
- Przetestuj kopię na nowym serwerze, zanim ruszysz DNS. Lokalny plik hosts pozwala otworzyć docelową domenę z nowego serwera, kiedy świat wciąż widzi stary.
- Sprawdź robots.txt na kopii testowej. To numer jeden na liście przyczyn spadków. Środowiska testowe rutynowo mają Disallow: / albo globalny noindex, a ta reguła jedzie razem z plikami na produkcję.
- W WordPressie sprawdź ustawienie widoczności dla wyszukiwarek. Zaznaczone na kopii testowej potrafi przenieść się na żywą stronę.
- Trzymaj stary serwer włączony jeszcze kilka dni. Dopóki TTL nie wygaśnie u wszystkich, część ruchu nadal tam leci, a wyłączenie go w dniu przełączenia to samodzielnie zafundowana przerwa w działaniu.
- Wstrzymaj publikowanie na czas przełączenia, żeby nie zapisać czegoś na serwerze, który za chwilę przestanie obsługiwać ruch.
Po przełączeniu
- Otwórz twojadomena.pl/robots.txt i przeczytaj, co tam jest. Naprawdę.
- Sprawdź, czy mapa witryny nadal się otwiera i zwraca 200.
- Obserwuj raport indeksowania w Search Console przez 2 do 3 tygodnie: czy nie rośnie liczba błędów 5xx i czy nie znikają zaindeksowane adresy.
- Przetestuj kilka przekierowań 301, które działały wcześniej. Nadal się odpalają?
- Sprawdź HTTPS na kilku podstronach, nie samej stronie głównej, oraz wersję z www i bez www.
- Porównaj TTFB z pomiarem sprzed migracji i przywróć TTL do około 3600 s, gdy wszystko działa.
- Sprawdź pocztę i formularze. Nie wpływają na SEO, ale wpływają na przychód.
Czy zmiana hostingu wpływa na pozycje w Google?
Nie, o ile domena i adresy URL zostają bez zmian. Google nie traktuje adresu IP ani lokalizacji serwera jako czynnika rankingowego samego w sobie. Spadki po przeprowadzce prawie zawsze wynikają z czegoś innego: zablokowanego robots.txt, błędu SSL, dłuższej niedostępności strony albo równoległej zmiany adresów.
Czy po zmianie hostingu trzeba ustawiać przekierowania 301?
Nie. Przekierowania 301 są potrzebne wtedy, gdy zmienia się adres URL. Przy zmianie samego serwera adresy zostają identyczne, więc nie ma z czego ani na co przekierowywać. Musisz natomiast przenieść przekierowania, które już wcześniej istniały w .htaccess lub w konfiguracji nginx, bo ich utrata to realna strata.
Ile trwa zmiana hostingu?
Samo przeniesienie plików i bazy to zwykle kilka godzin. Najwięcej zależy od propagacji DNS: przy TTL obniżonym wcześniej do 300 s ruch przenosi się w około 5 do 15 minut. Przy domyślnym TTL 86400 s to nawet do 48 godzin, dlatego TTL obniża się dobę lub dwie przed przełączeniem, nie w jego trakcie.
Czy trzeba zgłaszać zmianę hostingu w Google Search Console?
Nie. Narzędzie "Zmiana adresu" obsługuje zmianę domeny, a nie zmianę serwera. Przy tej samej domenie nie ma czego zgłaszać, usługa w Search Console działa dalej bez żadnej akcji. Search Console przydaje się po migracji do czegoś innego: do obserwowania raportu indeksowania i błędów serwera.
Czy szybszy serwer poprawi pozycje w Google?
Może pomóc, ale bez cudów. Szybkość ładowania i Core Web Vitals to realny sygnał, tyle że umiarkowany, i nie przebije treści dopasowanej do zapytania. Największą korzyść ze skrócenia TTFB zobaczysz zwykle w konwersji i w tempie indeksowania, a nie w skoku o dziesięć pozycji.
Co zrobić, jeśli po zmianie hostingu ruch spadł?
Sprawdź w tej kolejności: robots.txt, meta noindex, kod odpowiedzi HTTP, certyfikat SSL, przekierowania i dopiero na końcu wydajność. Zwykle winowajcą jest jedna konkretna rzecz zablokowana technicznie, a nie "Google karze za migrację". Naprawa i prośba o ponowne zindeksowanie zwykle przywracają stan sprzed migracji.
Ruch spadł po migracji: co sprawdzać po kolei
Idziesz od rzeczy wyłączających stronę z indeksu do tych, które ją tylko osłabiają.
- robots.txt. Otwórz twojadomena.pl/robots.txt. Jeśli widzisz Disallow: / , masz sprawcę i koniec śledztwa. Popraw plik i poproś o ponowne zindeksowanie.
- Meta noindex. Podejrzyj źródło strony i poszukaj <meta name="robots" content="noindex">. W WordPressie sprawdź Ustawienia, Czytanie, widoczność dla wyszukiwarek. To pozostałość po środowisku testowym.
- Kod odpowiedzi. Strona zwraca 200 czy 500 albo 503? Sprawdź logi błędów na nowym serwerze. Nagły wzrost 5xx w Search Console jest jednoznaczny.
- SSL. Certyfikat ważny, obejmuje www i bez www, bez mieszanej treści? Błąd certyfikatu wygląda dla robota jak strona niedostępna.
- Przekierowania. Odpal ręcznie kilka reguł 301 działających przed przeprowadzką. Jeśli .htaccess nie przyjechał, one nie działają.
- Wersje domeny. Czy z www i bez www prowadzą do tej samej wersji przez 301, czy nagle istnieją równolegle jako duplikaty?
- Treść. Czy wszystkie podstrony przyjechały? Porównaj liczbę adresów w mapie witryny przed i po. Brakująca kategoria to brakujący ruch.
- Wydajność. Dopiero teraz porównaj TTFB i Core Web Vitals ze stanem sprzed migracji.
Jeśli przeszedłeś tę listę, wszystko jest w porządku, a ruch nadal jest niższy, sprawdź daty. Aktualizacja algorytmu Google, która wypadła w tym samym tygodniu co przeprowadzka, to zbieg okoliczności częstszy, niż się wydaje, i bywa mylony ze skutkiem migracji.
Kiedy przeprowadzka faktycznie pomaga
Zmiana hostingu nie podniesie pozycji sama z siebie, ale potrafi usunąć rzeczy, które ciągną je w dół. Serwer regularnie zwracający 503 pod obciążeniem spowalnia indeksowanie. Serwer z TTFB skaczącym do dwóch sekund obniża Core Web Vitals. Hosting bez sensownych kopii oznacza, że jedna awaria kosztuje tygodnie odbudowy. Przeprowadzka to rozwiązuje, tylko nie nazywajmy tego działaniem SEO.
Kiedy serwer jest już stabilny, wraca temat bieżącej pracy nad widocznością w wyszukiwarce, czyli treści, linków i tego, czy strona odpowiada na pytania klientów. Hosting jest fundamentem, ale fundament sam nie sprowadza zapytań.
Jak to robimy u nas
Migrację przeprowadza nasz zespół, za darmo i bez przerwy w działaniu: stawiamy kopię na naszym serwerze, testujemy ją pod Twoją domeną przed przełączeniem DNS, sprawdzamy robots.txt, SSL i istniejące przekierowania, i dopiero wtedy przełączamy ruch. Szczegóły opisaliśmy na stronie bezpłatnej migracji strony www, a dla WordPressa mamy osobny, zarządzany wariant przy hostingu WordPress.
Serwery stoją fizycznie w Polsce, wsparcie odpowiada po polsku, wystawiamy fakturę VAT i podpisujemy umowę powierzenia zgodną z art. 28 RODO. Jedna rzecz odróżnia nas od większości rynku: cena odnowienia jest taka sama jak cena startowa, bez pierwszego roku za złotówkę i rachunku szoku w trzynastym miesiącu. Startowy 29 zł netto miesięcznie, Biznes 69 zł netto (zarządzany WordPress, kopie z 30 dni, 40 GB, 5 stron), Zarządzany Pro 149 zł netto, całość w cenniku hostingu dla firm. Masz 14 dni za darmo bez karty i 30 dni na zwrot, więc test nowego serwera nic nie kosztuje.
Domen nie rejestrujemy i nie sprzedajemy. Twoja domena zostaje tam, gdzie jest, a Ty kierujesz jej DNS na nasze serwery. Skoro nie zmienia właściciela ani adresu, Google nie ma powodu cokolwiek przeliczać od nowa.
Ostatnia aktualizacja: lipiec 2026.