Zmiana hostingu może wpłynąć na widoczność strony, jeśli po przenosinach Google otrzyma inną treść, błędne odpowiedzi albo utraci dostęp do części adresów. Samo przeniesienie plików na nowy serwer nie wymaga jednak zmiany domeny ani rozpoczynania pozycjonowania od początku. Celem jest zachowanie działających adresów i ustawień oraz sprawdzenie, czy nowa infrastruktura poprawnie obsługuje odwiedzających i roboty.
Ten poradnik dotyczy zmiany hostingu z zachowaniem domeny, HTTPS, wariantu z www lub bez www i ścieżek podstron. Możesz wykonać opisane kontrole w przeglądarce i Search Console, a błędy konfiguracji przekazać osobie prowadzącej migrację. Kolejność prac zebrano w planerze migracji strony i poczty. Tutaj najważniejsze będzie to, co powinno pozostać bez zmian i jak rozpoznać problem po przełączeniu.
Czy zmiana hostingu może obniżyć pozycje w Google?
Google rozdziela zmianę infrastruktury bez zmiany adresów od przeprowadzki witryny pod nowe URL-e. Przy samym hostingu robot ma nadal odwiedzać te same podstrony. Zmienia się serwer, który odpowiada na żądanie, nie adres wskazany przez link z innej witryny.
Po przełączeniu może przejściowo zmniejszyć się częstotliwość wizyt Googlebota, zanim dostosuje ją do nowej infrastruktury. To zachowanie opisane przez Google; nie jest równoznaczne ze spadkiem pozycji. Inaczej wygląda sytuacja, gdy serwer regularnie zwraca błędy albo odpowiada znacznie wolniej. Wtedy trzeba usunąć przyczynę, a nie czekać na samo „przyzwyczajenie się Google”.
Gdy przy okazji zmieniasz domenę, przechodzisz z HTTP na HTTPS lub przebudowujesz ścieżki, potrzebujesz również planu migracji ze zmianą URL-i. Obejmuje on przypisanie starych adresów do nowych i odpowiednie przekierowania. Rozdzielenie zmiany serwera od dużej redakcji treści ułatwia też później ustalenie, skąd wzięła się różnica w wynikach.
Przy samej zmianie hostingu nie używasz narzędzia „Zmiana adresu” w Search Console. Google wprost wyłącza ten scenariusz z jego zastosowań. Nie dodajesz również przekierowania z adresu na ten sam adres tylko dlatego, że zmieniło się IP.
Przed migracją: zachowaj punkt odniesienia
Wybierz adresy reprezentujące różne szablony oraz strony najważniejsze dla działalności: stronę główną, ważne usługi lub kategorie, kilka artykułów z ruchem, starszą podstronę i plik do pobrania. W sklepie dołącz kategorię i produkt.
W Search Console otwórz raport skuteczności w wynikach wyszukiwania i kartę Strony. Zapisz zestawienie kliknięć i wyświetleń oraz użyty zakres dat. Możesz przyjąć ostatnie 28 pełnych dni jako własny punkt odniesienia; przy sezonowej działalności zachowaj również porównywalny okres poprzedniego roku. Raport pozwala zmieniać okres, typ wyszukiwania i grupowanie danych. Później stosuj te same filtry.
Dla każdego wybranego adresu zachowaj jeden wiersz zestawienia: sprawdzany URL; kod odpowiedzi HTTP; kod i cel każdego przekierowania; końcowy URL; tytuł i główny nagłówek; canonical w HTML i ewentualnym nagłówku HTTP Link; reguły meta robots, meta googlebot oraz X-Robots-Tag. Jeśli znacznika lub nagłówka nie ma, zapisz „brak”, zamiast zostawiać puste pole, które może oznaczać pominiętą kontrolę. Dla pliku bez HTML pola tytułu strony, H1 i znaczników HTML oznacz jako „nie dotyczy”; nagłówki HTTP nadal sprawdzasz. Sposób odczytu tych ustawień jest opisany w części o sprawdzaniu kopii — ten sam odczyt wykonaj najpierw na obecnym hostingu.
Zachowaj również dotychczasowy plik robots.txt oraz adres mapy witryny. Taki zapis pomoże odróżnić nowy błąd od ustawienia, które istniało wcześniej. Nie trzeba naprawiać wszystkich dawnych problemów w godzinie przeprowadzki.
Jeszcze przed migracją wykonaj pomiary w PageSpeed Insights dla wybranych ważnych adresów. Zapisz raporty, datę i tryb: mobilny albo komputerowy. Przy ocenie pojawiania się głównej treści zanotuj LCP (Largest Contentful Paint) — czas wyświetlenia największego elementu treści w widocznym obszarze strony. Pomiar laboratoryjny powtórz kilka razy i zachowaj wszystkie wyniki, aby mieć z czym porównać nową wersję.
Sprawdź, czy po migracji pozostanie dostęp do tej samej usługi Search Console. Weryfikacja własności może opierać się na rekordzie DNS, pliku HTML, znaczniku lub innym obsługiwanym sposobie. Plik trzeba przenieść, znacznik zachować, a przy zmianie dostawcy DNS odtworzyć potrzebny rekord. Zanotuj też identyfikator używanej analityki i jej zasady zgód, aby po przeprowadzce odróżnić utratę pomiaru od utraty odwiedzin.
Ustal zakres przenosin i odpowiedzialność za kontrolę
Kopiowanie plików, sprawdzenie strony głównej i kontrola SEO całej witryny to różne zakresy pracy. Przed umówieniem terminu przekaż wykonawcy listę ważnych adresów i ustal, kto sprawdzi przekierowania, dostęp robotów oraz wyniki w Search Console. Właściciel może porównać treść i raporty, a administrator poprawić reguły serwera.
Przenoszę stronę bez zmiany adresów. Proszę zachować treść, przekierowania, ustawienia indeksowania, canonicale i mapę witryny oraz przygotować HTTPS przed przełączeniem. Dołączam listę adresów do sprawdzenia. Proszę potwierdzić, czy migracja wymaga przerwy. Jeśli tak, proszę wskazać jej termin i przewidywany czas. Proszę również wskazać osobę sprawdzającą wynik i sposób powrotu w razie awarii. Potrzebuję też potwierdzenia, które stare usługi muszą pozostać aktywne.
Zachowaj niezależną kopię danych i konfiguracji. Przy stronie przyjmującej zamówienia, komentarze lub zgłoszenia uzgodnij także końcową synchronizację oraz postępowanie z danymi powstałymi już po przełączeniu. Przywrócenie poprzedniego serwera nie przeniesie ich automatycznie. Etapy samego kopiowania i zatrzymania zapisów opisuje instrukcja migracji WordPressa.
Gdy szukasz hostingu z usługą przeniesienia, przykładem jest Hostido: operator opisuje migrację jednego konta źródłowego na jedno docelowe, po ocenie zgodności aplikacji; kolejne migracje na to samo konto są płatne. Warunki migracji porównaj ze swoim zakresem, a kontrolę SEO uzgodnij osobno. Zobacz ofertę hostingu w Hostido — link partnerski.
Sprawdź nową kopię, zanim skierujesz do niej ruch
Przygotowany serwer sprawdź pod właściwą domeną przez lokalny podgląd. Procedura podglądu przed zmianą DNS pozwala potwierdzić, skąd pochodzi odpowiedź. Kopia powinna korzystać z odrębnej bazy i mieć ograniczony dostęp. Do poniższej kontroli wystarczą odczyt stron, nagłówków i kodu; składanie zamówień czy wysyłanie formularzy nie jest jej częścią.
W Chrome otwórz F12, wybierz Network / Sieć, zaznacz Preserve log i Disable cache, a następnie odśwież podgląd. Kliknij żądanie dokumentu. W Headers / Nagłówki odczytasz status i nagłówki odpowiedzi, a w Response / Odpowiedź — zwrócony HTML. Panel sieciowy pokazuje też przekierowania i pobrane zasoby. Wyłączenie cache działa przy otwartych narzędziach; nie czyści pamięci na serwerze ani w CDN.
Dostęp do treści i ustawienia indeksowania
robots.txt reguluje skanowanie, a noindex wyklucza stronę z indeksowania, gdy robot może odczytać tę regułę. Może ona znajdować się w znaczniku meta lub nagłówku HTTP X-Robots-Tag. Zablokowanie skanowania nie zastępuje noindex i może uniemożliwić jego zauważenie.
Dla stron przeznaczonych do wyszukiwania przygotuj usunięcie testowych blokad na moment publikacji nowej kopii. Zachowaj świadome wyłączenia, np. dla koszyka lub panelu klienta. Ochrony podglądu nie zdejmuj wcześniej tylko po to, aby sprawdzić ustawienia SEO. W lokalnym podglądzie widzisz konfigurację, którą później ponownie skontrolujesz publicznie.
W kodzie odpowiedzi odszukaj znaczniki meta name="robots" i meta name="googlebot"; w nagłówkach odpowiedzi — X-Robots-Tag. Sprawdź wartości we właściwych znacznikach, nie samo występowanie słowa „noindex” w tekście strony. Dodanie index w jednym miejscu nie neutralizuje zakazu w innym. Gdy kod generuje wtyczka lub serwer, poprawka musi dotyczyć tego źródła ustawienia.
Adresy, przekierowania i canonicale
Porównaj dotychczasowe URL-e z odpowiedzią nowej instalacji. Główna wersja strony ma nadal otwierać tę samą treść, a warianty HTTP lub www — zachowywać uzgodnione przekierowania. Przekierowanie powinno prowadzić do właściwego adresu docelowego. Nie zastępuj brakujących podstron jednym zbiorczym odesłaniem na stronę główną.
Canonical wskazuje preferowany adres danej treści. W HTML odszukaj link rel="canonical" i odczytaj adres z href. Dla samodzielnej podstrony https://example.com/uslugi/ sprawdź, czy po migracji nie wskazuje przypadkiem domeny podglądu albo strony głównej. Przy świadomie utrzymywanych duplikatach zachowaj odpowiednie wskazanie do wybranej wersji. Jeżeli serwer przekazuje canonical w nagłówku HTTP Link z rel="canonical", porównaj także ten zapis — dotyczy to również plików bez HTML, np. PDF. Gdy obie metody są już używane, sprawdź, czy nie wskazują różnych adresów. Canonical jest sygnałem dla Google, nie poleceniem gwarantującym wybór adresu; linkowanie i mapa witryny powinny być z nim zgodne.
Treść, zasoby i mapa witryny
Otwórz strony z przygotowanej listy. Porównaj tekst, tytuły, nagłówki, linki wewnętrzne, zdjęcia i pobierane pliki. Przy wielu językach zachowaj powiązania wersji językowych. Jeśli strona korzysta z danych strukturalnych, sprawdź także ich obecność i zgodność z widoczną treścią. Przeniesienie bazy nie potwierdza, że nowy serwer odtworzył wszystkie elementy szablonu.
Otwórz używaną mapę XML, a przy indeksie map również pliki, do których prowadzi. Mają zawierać właściwe publiczne adresy, bez domeny testowej. Wartość lastmod opisuje istotną aktualizację strony. Nie ustawiaj daty migracji przy wszystkich wpisach wyłącznie z powodu zmiany serwera, jeśli treść i inne istotne elementy tych stron się nie zmieniły.
Jak przeprowadzić krótką przerwę techniczną?
Nowe środowisko, HTTPS, kopię i sposób przywrócenia działania przygotuj przed przerwą. Jeżeli wybrana metoda wymaga czasowego wyłączenia publicznej strony, na ten okres użyj odpowiedzi HTTP 503 zalecanej przy krótkotrwałej niedostępności. To inny stan niż brak strony 404, odmowa dostępu 403 lub usuwanie jej z indeksu przez noindex.
Ustal z administratorem, jak włączy i zdejmie tę odpowiedź. Sprawdź rzeczywisty status, nie tylko napis na planszy. Dotychczasowy robots.txt powinien pozostać dostępny i nie otrzymać zbiorczej blokady skanowania. Po zakończeniu prac istniejące podstrony wracają do swoich prawidłowych odpowiedzi.
Kod 503 jest rozwiązaniem na krótki przestój, a nie gwarancją zachowania widoczności przy wielodniowej niedostępności. Gdy przygotowanie przeciąga się jeszcze przed przełączeniem, odłóż migrację i pozostaw starą stronę dostępną. Sposób ograniczenia zapisów w sklepie musi uwzględniać zamówienia i płatności; nie wybiera się go wyłącznie pod kątem kodu HTTP.
Co sprawdzić od razu po zmianie DNS?
Najpierw sprawdź publiczną stronę, dopiero potem czekaj na raporty Google. Usuń wpisy podglądu z pliku hosts, zamknij wcześniejsze połączenia przeglądarki i otwórz witrynę ponownie. Wykonaj również próbę z innego połączenia, np. telefonu przez sieć komórkową. Gdy działa Cloudflare lub inny pośrednik, kontrola powinna obejmować publiczną trasę przez niego, nie tylko bezpośredni adres nowego serwera.
Przy pierwszej publicznej próbie potwierdź także, czy odpowiedź pochodzi już z nowego hostingu. Zapisz URL i godzinę; w razie wątpliwości poproś administratora o odszukanie żądania w logach starego i nowego środowiska. Trafienie na starą kopię podczas odświeżania DNS nie oznacza samo w sobie awarii, ale poprawna odpowiedź tej kopii nie sprawdza jeszcze nowego serwera.
Przy CDN odpowiedź może pochodzić z pamięci pośrednika, bez nowego żądania do serwera źródłowego. Wtedy sam adres IP CDN ani brak wpisu w logu hostingu nie rozstrzyga, skąd zostałaby pobrana świeża treść. Administrator powinien potwierdzić publiczną trasę do nowego środowiska na podstawie konfiguracji pośrednika i kontrolowanej próby pobrania odpowiedzi z nowego serwera źródłowego.
Powtórz kontrolę w panelu Network, tym razem dla publicznej strony, bez lokalnego wskazania serwera. Dla każdego adresu oceń łącznie pochodzenie odpowiedzi, status HTTP i wyświetloną treść:
| Próba | Oczekiwany wynik |
|---|---|
| Główna wersja ważnej podstrony | Właściwa treść, poprawne HTTPS i końcowy status 200, bez planszy podglądu lub przerwy |
| Używane warianty HTTP i www | Przekierowanie do zachowanej wersji docelowej, bez pętli i domeny tymczasowej |
| Stary adres, który wcześniej miał przekierowanie | Nadal trafia do właściwego odpowiednika, a nie ogólnie na stronę główną |
| Nieistniejący adres o własnej losowej nazwie | Strona błędu z kodem 404, nie komunikat „nie znaleziono” zwrócony jako 200 |
| Strony przeznaczone do indeksowania | Brak testowego noindex i ochrony dostępu; właściwe canonicale oraz treść |
| robots.txt, mapa XML, zdjęcia i pliki | Właściwa zawartość i dostępność; brak przypadkowej strony logowania w odpowiedzi |
Kod 200 oznacza poprawną odpowiedź HTTP, ale nie gwarantuje indeksowania. Jeśli pod tym statusem serwer pokazuje pustą stronę lub komunikat błędu, Google może potraktować ją jako soft 404. Dlatego w tabeli treść i status są sprawdzane łącznie. Pojawienie się 404 pod losowym, nieistniejącym adresem jest natomiast prawidłowe.
Search Console po migracji: odróżnij dane z indeksu od testu bieżącej strony
Komunikat o obecności adresu w Google może dotyczyć skanowania sprzed migracji. Narzędzie do sprawdzania URL-i rozdziela dane zapisane w indeksie od testu wersji opublikowanej. Po zmianie serwera sprawdź oba widoki, zaczynając od kilku ważnych podstron.
- Wpisz pełny adres w pasku sprawdzania URL-i w Search Console.
- Odczytaj stan indeksowania, datę ostatniego skanowania i adres kanoniczny wybrany przez Google. Data sprzed przełączenia oznacza, że te informacje nie potwierdzają jeszcze nowego hostingu.
- Uruchom Test wersji opublikowanej. Sprawdź pobranie strony oraz informacje o dopuszczeniu skanowania i indeksowania.
- Otwórz podgląd przetestowanej strony i dostępny HTML. Powinna być widoczna właściwa treść, nie formularz logowania, plansza ochrony lub błąd.
Test bieżącej strony nie przewiduje adresu kanonicznego, który wybierze Google, ani nie potwierdza jej późniejszej pozycji. Lokalny podgląd przez hosts nie wpływa na żądanie narzędzia Google. Podczas przejścia może ono jeszcze trafić do starej infrastruktury; przy niejednoznacznym wyniku poproś administratora o sprawdzenie w logach, gdzie obsłużono próbę.
Po naprawieniu konkretnej blokady możesz poprosić o ponowne zindeksowanie ważnego adresu. Przy większej liczbie stron wykorzystaj poprawną mapę. Wielokrotne zgłaszanie tego samego URL-a nie przyspiesza skanowania. Nie zgłaszaj całej witryny wielokrotnie tylko dlatego, że dostała nowy serwer; najpierw usuń błąd i sprawdź poprawkę.
Jak obserwować stronę w kolejnych dniach?
Jako roboczy harmonogram przyjmij kontrolę bezpośrednio po przełączeniu, ponowną kontrolę następnego dnia i regularne sprawdzanie w pierwszym tygodniu. To sposób organizacji pracy, nie termin gwarantowanego powrotu pozycji. Gdy pojawia się błąd dostępności albo znikają ważne treści, reagujesz od razu.
W raporcie indeksowania stron szukaj nowych problemów dotyczących przeniesionych adresów. Porównuj z zachowanym stanem wcześniejszym. Nie każda pozycja „niezindeksowana” oznacza usterkę: prawidłowe przekierowania i świadomie wyłączone strony mogą pozostawać poza indeksem. Ważne, czy po migracji zmienił się status stron, które mają pozyskiwać ruch.
W Ustawienia → Statystyki indeksowania znajdziesz historię żądań Google, odpowiedzi i problemów z dostępnością hosta. Ten raport przydaje się szczególnie przy większej witrynie lub podejrzeniu błędu technicznego. Sprawdź, czy nie przybyło problemów z DNS, połączeniem lub pobraniem robots.txt, zamiast oceniać samą liczbę wizyt robota.
Przy błędach przekaż administratorowi przykładowy URL i godzinę próby. Niech porówna logi serwera i ochrony ruchu. Żądanie opisane nazwą Googlebot wymaga sprawdzenia jego pochodzenia; sama nazwa klienta może zostać podrobiona. Przejście testu inspekcji również nie zastępuje kontroli zwykłego skanowania — różne narzędzia mogą trafiać na odmienne reguły zapory.
W raporcie Mapy witryn skontroluj wynik ostatniego odczytu mapy. Przyjęcie mapy oznacza jej odczytanie i przetworzenie, nie zaindeksowanie każdego wymienionego adresu. Jeśli URL-e się nie zmieniły, nie potrzebujesz nowej nazwy pliku mapy wyłącznie z powodu przeprowadzki.
Czy nowy hosting przyspieszył stronę i pomoże w SEO?
Do porównania wykorzystaj raporty zachowane przed migracją. Po zmianie sprawdź te same publiczne strony z docelową konfiguracją cache i CDN. Wynik dla zalogowanego administratora może dotyczyć innej ścieżki obsługi niż widok zwykłego odwiedzającego.
PageSpeed Insights rozdziela pojedynczy test laboratoryjny od danych rzeczywistych użytkowników. Te drugie obejmują ostatnie 28 dni, więc bezpośrednio po migracji mogą nadal opisywać głównie stary hosting. Gdy dla podstrony brakuje danych, raport może pokazać wynik zbiorczy dla tego samego źródła, np. https://example.com — stron pod danym protokołem i nazwą hosta. Sprawdź wskazany zakres. Przy zbyt małej liczbie pomiarów dane użytkowników nie pojawią się; nie jest to wynik zerowy.
Przykładowo chcesz sprawdzić, czy główna treść pojawia się szybciej. Dla tego samego URL-a wybierz w PageSpeed Insights ten sam tryb — mobilny albo komputerowy — i odczytaj Largest Contentful Paint (LCP) w części laboratoryjnej. Powtórz test kilka razy, tak jak przed migracją, i porównaj serie wyników, nie tylko najlepszy odczyt. Wyniki Lighthouse zmieniają się wraz z warunkami pomiaru. Porównuj sekundy LCP z sekundami LCP, nie z ogólną oceną wydajności ani z 28-dniowym wynikiem użytkowników.
Core Web Vitals obejmują ładowanie, interaktywność i stabilność układu, nie tylko pracę serwera. Szybsza odpowiedź nie naprawi automatycznie ciężkich skryptów czy przesuwających się elementów. Dobre wyniki wydajności nie gwarantują najwyższych pozycji; porównanie techniczne i ocena ruchu to dwa osobne zadania.
Ruch spadł — jak ustalić, czy przyczyną jest migracja?
Zacznij od zakresu zmiany. Czy spadły kliknięcia w Search Console, sesje w analityce, czy oba pomiary? Gdy zmieniła się tylko analityka, najpierw sprawdź obecność kodu i działanie zgód. Dane Search Console i analityki mogą się różnić, m.in. przez sposób zbierania i przetwarzania. Porównuj ich przebieg, nie oczekuj identycznych sum kliknięć i sesji.
W Search Console porównaj pełne okresy o podobnym układzie dni, z tym samym typem wyszukiwania i filtrami. Zajrzyj do stron i zapytań, nie tylko do średniej pozycji całej witryny. Spadki mogą wynikać m.in. z problemów technicznych, zmian systemów rankingowych, sezonowości i zmiany zainteresowania opisanych w diagnostyce ruchu z wyszukiwarki. Zbieżność daty z migracją jest wskazówką do sprawdzenia, nie dowodem przyczyny.
| Co zaobserwowałeś | Od czego zacząć |
|---|---|
| Strona główna działa, lecz ważne podstrony zwracają 404 | Sprawdź reguły adresów i kompletność przeniesionej treści; porównaj z listą sprzed migracji |
| Przeglądarka otwiera stronę, lecz test Google otrzymuje blokadę | Przekaż administratorowi URL, godzinę i odpowiedź; sprawdź zaporę, ochronę botów i reguły dostępu |
| Po przenosinach pojawiło się noindex na publicznych podstronach | Ustal, czy pochodzi z CMS, nagłówka serwera czy pośrednika, i usuń przypadkowy zakaz u źródła |
| Canonical prowadzi do domeny testowej | Popraw generowanie adresów w szablonie lub wtyczce i sprawdź kolejne strony tego samego typu |
| Spadek dotyczy tylko jednego katalogu lub szablonu | Porównaj kilka jego stron: treść, linki, statusy i ustawienia indeksowania |
| Technicznie strony działają, lecz maleją wyświetlenia i kliknięcia | Rozszerz analizę o zapytania, sezonowość i zmiany wyników wyszukiwania. Nie zmieniaj ponownie hostingu bez ustalenia przyczyny spadku |
Po znalezieniu błędu wykonaj poprawkę i ponów tę samą kontrolę. Zapisz datę naprawy. Nie cofaj hostingu na podstawie jednego dnia danych, gdy nie potwierdzono usterki. Przy niedostępności serwisu lub utracie ważnej funkcji uruchom uzgodniony plan awaryjny, zabezpieczając także nowe dane powstałe po przełączeniu.
Kiedy można wyłączyć stary hosting i zakończyć kontrolę?
Administrator powinien potwierdzić, że publiczny ruch jest poprawnie obsługiwany przez nowe środowisko, a stary serwer nie jest już potrzebny do dostarczania strony. Sprawdzenie obejmuje logi, DNS i używane warianty adresów. Pozostaw dostęp do kopii oraz możliwość analizy problemów z okresu przejściowego. Jeśli stare konto nadal utrzymuje pocztę lub DNS, zachowaj te usługi.
Techniczną kontrolę migracji można zamknąć, gdy ważne adresy działają zgodnie z wcześniejszym przeznaczeniem, publiczna treść i ustawienia SEO są poprawne, a potwierdzone problemy z dostępem zostały usunięte. Obserwacja indeksowania i ruchu trwa dalej, według zachowanego punktu odniesienia. O zakończeniu technicznego przeniesienia decyduje wynik tych kontroli, nie oczekiwanie na wzrost pozycji.