Planowanie migracji domeny
Plan przeniesienia domeny na inny serwer zaczyna się od pytania, czy adresy URL zostaną takie same, bo od tego zależy wpływ na SEO. Google opisuje dwa scenariusze: sam nowy hosting przy niezmienionych linkach daje zwykle tylko chwilowy spadek szybkości indeksowania. Migracja z nową strukturą URL oznacza tymczasowe wahania pozycji i kilka tygodni lub więcej, zanim w wynikach średniej wielkości strony nowe odnośniki zastąpią dotychczasowe.
Na start przygotuj pełny backup plików i baz danych, dane dostawcy i listę testów do wykonania na końcu. Termin wybierz na okres najmniejszego ruchu, np. noc z niedzieli na poniedziałek albo miesiąc poza sezonem. Spisz usługi powiązane z domeną (certyfikaty SSL, skrzynki pocztowe, subdomeny, konfiguracja CDN) i kontakty techniczne po obu stronach, czyli u obecnej firmy i u nowej.
Wybór odpowiedniego hostingu
Dobry hosting dla strony firmowej to taki, który szybko odpowiada na żądania, ma w umowie gwarancję dostępności (SLA) i pomoc techniczną osiągalną w dniu przeprowadzki. Sprawdź, czy w pakiecie są narzędzia do zarządzania domeną i certyfikaty SSL. Gdy klienci są głównie w Polsce, wybierz centrum danych w Europie Środkowej. Porównaj parametry: wersję PHP, bazy MySQL lub PostgreSQL, limity pamięci operacyjnej i transferu.
Przed decyzją zmierz TTFB (czas do pierwszego bajtu) na kopii testowej. Po przełączeniu domeny porównaj go z wartością "Średni czas odpowiedzi" w Search Console, w raporcie "Statystyki indeksowania" (Ustawienia, dostępne dla usług najwyższego poziomu). Google pisze, że to zestawienie przyda się głównie stronom mającym ponad 1000 podstron.
Przygotowanie do migracji
Przygotowanie do migracji to 2 zadania: pełny backup i test nowego środowiska, zanim zmienisz DNS. Google zaleca, żeby duplikat strony najpierw umieścić u docelowego dostawcy i szczegółowo sprawdzić, a dopiero potem kierować tam użytkowników.
Tworzenie kopii zapasowej
Kopia zapasowa obejmuje wszystkie pliki, bazy danych i konfigurację, wykonane narzędziami obecnego hostingu albo osobnym programem. Zapisz archiwum w co najmniej 2 miejscach, np. na dysku lokalnym i w chmurze (Google Drive, Dropbox). Dla stron na WordPressie sprawdzają się wtyczki UpdraftPlus albo All-in-One WP Migration. Integralność potwierdzisz, rozpakowując paczkę i otwierając kilka losowych elementów. Dane dostępowe do paneli, FTP i baz trzymaj w menedżerze haseł.
Testowanie nowego środowiska
Działanie strony na nowej infrastrukturze sprawdzasz przed przeniesieniem, na tymczasowym adresie albo subdomenie, np. beta.example.com. Dokumentacja Google radzi, żeby taka wersja testowa miała regułę noindex w kodzie HTML lub nagłówkach HTTP, a dostęp ograniczony do wybranych numerów IP. Możesz też ustawić plik hosts na swoim komputerze i obejrzeć stronę na docelowej maszynie bez zmiany DNS.
Zweryfikuj wersję PHP i rozszerzenia wymagane przez CMS, przetestuj formularze kontaktowe, płatności i logowanie. Narzędziem do sprawdzania adresów URL w Search Console potwierdź, że Googlebot może pobrać treść z serwera, a zapora i ochrona przed atakami DoS go nie blokują. Na koniec zmierz szybkość ładowania w Google PageSpeed Insights i GTmetrix i porównaj wyniki z obecnym hostingiem.
Wykonanie przeniesienia
Samo przeniesienie składa się z 2 kroków: przesłania danych na nowy serwer i aktualizacji DNS, która kieruje ruch pod nowy numer IP. Wcześniej usuń z nowej kopii blokady indeksowania (robots.txt, noindex), o czym Google przypomina wprost.
Przesyłanie plików i baz danych
Pliki przesyłasz przez FTP, SFTP albo narzędzia migracyjne nowego dostawcy, z zachowaniem struktury katalogów. Przy dużych stronach lepiej sprawdza się rsync, który przenosi tylko zmienione elementy. Bazę importujesz w phpMyAdmin albo z linii poleceń MySQL. Jeśli w tabelach są ścieżki bezwzględne ze starą lokalizacją, wykonaj operację search-and-replace. Uprawnienia (chmod) ustaw zgodnie z wymaganiami bezpieczeństwa nowej maszyny.
Aktualizacja rekordów DNS
Zmiana DNS polega na wpisaniu w rekordach A i AAAA (dla IPv6) numerów IP nowego hostingu. Google zaleca, by wartość TTL obniżyć do bezpiecznego niskiego poziomu, np. kilku godzin, co najmniej na tydzień przed przeniesieniem, żeby dostawcy internetu szybciej odświeżyli zapisane ustawienia. Wpisy MX modyfikujesz tylko wtedy, gdy przenosisz również pocztę. Sprawdź konfigurację subdomen i CNAME. Postęp propagacji w różnych krajach pokażą publiczne narzędzia, np. DNS Checker albo WhatsMyDNS.
Weryfikacja po migracji
Po przeniesieniu sprawdzasz, czy strona na nowym serwerze działa tak samo jak na poprzednim: każdą funkcję, link, formularz i element interaktywny. Przejrzyj logi błędów i wyszukaj odpowiedzi 500 albo problemy z uprawnieniami. Otwórz stronę w kilku przeglądarkach i na telefonie. Sprawdź certyfikat SSL: wszystkie zasoby mają ładować się przez HTTPS, bez ostrzeżeń o zawartości mieszanej.
Upewnij się, że plik weryfikacyjny HTML, tag meta albo kod Google Analytics, którymi potwierdzasz własność w Search Console, są na nowej wersji. Jeśli przy okazji zmieniły się URL-e, Google zaleca przekierowania stałe 301 albo 308 ze starych adresów na nowe, utrzymane zwykle przez co najmniej rok.
Monitorowanie parametrów widoczności
Widoczność po przeniesieniu śledzisz w Google Search Console i Google Analytics 4, porównując ruch, pozycje i obecność podstron w Google z okresem sprzed zmiany. W pierwszych dniach obserwuj logi obu maszyn: na poprzedniej liczba wizyt ma spadać, a na nowej rosnąć. W Search Console otwórz raport "Indeksowanie stron" (dawny "Stan w indeksie") i znajdź podstrony wykluczone albo zwracające błędy.
Zestawienie "Statystyki indeksowania" pokaże, czy Googlebot wrócił do zwykłego tempa. Według Google chwilowy spadek szybkości pobierania po zmianie hostingu jest normalny, a po nim przychodzi kilkudniowy wzrost, nawet powyżej poziomu sprzed przeniesienia. Podstawowe wskaźniki internetowe (LCP, INP, CLS) porównaj z progami 2,5 sekundy, 200 milisekund i 0,1. Pozycje fraz kontroluj w Senuto albo Semstorm przez co najmniej 2-3 tygodnie, a w Search Console sprawdź, czy podstrony z linkami zwrotnymi nie zwracają błędu 404.
Komunikacja z odbiorcami
Użytkowników uprzedzasz o przeniesieniu wtedy, gdy migracja może ich dotknąć, czyli przy przerwie w działaniu, ponownym logowaniu albo nowych hasłach. Wystarczy e-mail, komunikat na stronie i wpis w mediach społecznościowych z datą i godziną prac. Przygotuj krótkie FAQ: czy trzeba zmienić hasło, czy konto i historia zamówień zostają. W sklepie internetowym poinformuj klientów z wyprzedzeniem, np. 3 dni wcześniej, o możliwej krótkiej przerwie. Przez kilka dni po migracji sprawdzaj skrzynkę e-mail i komentarze, żeby szybko odpowiadać na zgłoszenia.
Przegląd techniczny i dalsza optymalizacja
Przegląd techniczny po migracji potwierdza, że nowy serwer jest skonfigurowany tak dobrze jak stary albo lepiej: certyfikaty SSL, przekierowania 301 i indeksowanie podstron. Ustaw reguły pamięci podręcznej w pliku .htaccess albo w konfiguracji nginx, bo nagłówki cache-control skracają ponowne wczytanie strony. Włącz kompresję gzip lub Brotli dla HTML, CSS i JavaScript. Jeśli nowy hosting nie ma CDN, darmowy plan Cloudflare przyspieszy dostarczanie plików statycznych.
Przeprowadź audyt sekcji head: meta tagi, schema.org i dane strukturalne muszą zostać bez zmian. Poprzednią infrastrukturę wyłącz dopiero wtedy, gdy logi pokażą, że nikt, łącznie z Googlebotem, już z niej nie korzysta. Do alertów o awariach zainstaluj monitoring dostępności, np. UptimeRobot.
