Migracja strony internetowej — hosting, domena i przekierowania 301

Migracja strony internetowej nie kończy się w dniu, w którym działa już na nowym serwerze albo pod nowym adresem. Kończy się wtedy, kiedy Google to zauważy — a to może potrwać tygodnie. Wiemy to z własnej strony, bo ten artykuł sam przeszedł migrację.

Do 14 września stał pod adresem w dziale poradników, który zlikwidowaliśmy. Tego dnia dostał przekierowanie stałe na obecny adres. Pięć dni później Search Console pokazywała taki stan:

Czytelnik, który kliknie stary link, trafia na nowy adres od pierwszej sekundy. Ale Google dowie się o przekierowaniu dopiero przy następnej wizycie na starym adresie — a ten odwiedził ostatnio w lipcu. Do tego czasu w indeksie stoi adres, który już nie istnieje, a nowy czeka w kolejce. Dokumentacja Google mówi o tym wprost: przy małej i średniej stronie przeniesienie większości adresów zajmuje „a few weeks", a wahania widoczności w tym czasie są „normal".

To nie jest argument przeciw migracji. Jest argumentem za tym, żeby ją zaplanować tak, jakby Google miał się o niej dowiedzieć późno — bo tak właśnie będzie.

Trzy migracje pod jednym słowem

„Migracja strony" to słowo, którym opisuje się trzy różne operacje. Różnią się tym, co się zmienia z punktu widzenia wyszukiwarki — a od tego zależy, co może pójść źle.

Zmiana hostingu — ta sama strona, te same adresy, inny serwer. Dla Google nic się nie dzieje poza tym, że pod znanym adresem odpowiada inna maszyna. To najbezpieczniejsza z trzech, pod warunkiem że przeniosło się wszystko.

Zmiana domeny — każdy adres w serwisie staje się nowy. Dla Google to przeprowadzka całej witryny, którą trzeba zgłosić i przeprowadzić przekierowaniami adres po adresie.

Zmiana struktury lub platformy — nowy system zarządzania treścią, nowy sklep, uporządkowanie działów. Domena zostaje, ale część adresów się zmienia. To najczęstsze źródło strat, bo wygląda na zmianę „tylko techniczną", a dla wyszukiwarki każdy zmieniony adres bez przekierowania jest nową, pustą stroną.

W praktyce te operacje często idą razem — nowa platforma na nowym hostingu, czasem pod nową domeną. Wtedy warto je rozdzielić w czasie, jeśli się da. Google dopuszcza przenoszenie dużych serwisów sekcjami, a przy mniejszych zaleca przenieść wszystkie adresy naraz; w obu przypadkach łatwiej znaleźć przyczynę spadku, gdy w danym tygodniu zmieniła się jedna rzecz, a nie trzy.

Przeniesienie strony na inny hosting

Przeniesienie strony na inny hosting bez zmiany adresów Google opisuje w osobnym dokumencie, i są w nim trzy zalecenia, które warto wziąć dosłownie.

Obniżcie TTL co najmniej tydzień wcześniej. Google proponuje wartość „a few hours" ustawioną „at least a week in advance". Dlaczego tak wcześnie — wyjaśnia następna sekcja; w skrócie: obniżenie działa dopiero wtedy, gdy wygaśnie stara, dłuższa wartość zapamiętana na serwerach po drodze.

Nie wyłączajcie starego hostingu w dniu przeniesienia. Google radzi obserwować logi starego serwera i wyłączyć go dopiero wtedy, gdy ruch na nim spadnie do zera. Przez kilka dni część odwiedzających — i część robotów — nadal będzie trafiać na stary adres IP. Jeśli stary serwer już nie odpowiada, to są stracone wizyty. Przy okazji: to argument, żeby nie wypowiadać umowy na stary hosting tak, żeby kończyła się w dniu migracji.

Spadek aktywności Googlebota po przeniesieniu jest normalny. Według dokumentacji tuż po starcie na nowym serwerze Google zwykle chwilowo zwalnia pobieranie stron, a w ciągu kilku kolejnych dni stopniowo przyspiesza. Nie trzeba na to reagować.

Czego dokumentacja Google nie mówi, bo to nie jej sprawa: co trzeba przenieść. Pliki strony to tylko część. Do tego baza danych, pliki wgrane przez użytkowników, zadania uruchamiane cyklicznie, konfiguracja serwera, certyfikat, poczta — jeśli była na tym samym hostingu, jej przeniesienie jest osobną operacją, łatwą do przeoczenia, bo „strona działa". I wersja PHP: jeśli nowy serwer ma nowszą niż stary, starsza wtyczka może przestać działać w dniu przeprowadzki. Zanim cokolwiek się przestawi, potrzebna jest kopia, która daje się odtworzyć — najlepiej właśnie na nowym serwerze, bo wtedy test kopii i próba migracji to jedna czynność.

Propagacja DNS to TTL, a nie 48 godzin

O zmianie DNS krąży zdanie, że „propagacja trwa do 48 godzin". Brzmi to tak, jakby informacja o nowym adresie rozchodziła się po internecie jak fala. Tak nie jest. Nic się nie rozchodzi — wygasają kopie, które serwery po drodze zapamiętały, a czas ich przechowywania ustala właściciel rekordu. To jest TTL, czas życia rekordu podany w sekundach.

Jeśli rekord wskazujący adres serwera ma TTL 86 400 sekund, czyli dobę, to serwer, który zapytał o niego tuż przed zmianą, przez następną dobę będzie odsyłał odwiedzających na stary adres. Jeśli ma 300 sekund — przez pięć minut. Dlatego TTL obniża się z wyprzedzeniem: najpierw musi wygasnąć stara, długa wartość, a dopiero potem zmiana adresu rozejdzie się w czasie nowej, krótkiej.

Sprawdziliśmy obie wartości na własnej domenie. Rekordy wskazujące adres naszego serwera mają TTL 300 sekund. Ale rejestr domeny .pl podaje informację o tym, jakie serwery nazw obsługują domenę, z TTL 86 400 sekund. Z tego wynika praktyczna różnica między dwiema operacjami, które w panelach nazywają się podobnie:

• Zmiana rekordów (adres serwera, poczta) — zmiana DNS u dotychczasowego dostawcy. Działa w czasie TTL, który sami ustawiliście.
• Zmiana serwerów nazw (przeniesienie obsługi DNS do innej firmy) — tu dochodzi doba, której nie skrócicie, bo ustala ją rejestr. Stąd biorą się obiegowe „24–48 godzin".

To samo dotyczy przeniesienia poczty, nawet jeśli poczta nigdzie się nie przenosi. Przy zmianie serwerów nazw nowa firma obsługująca DNS nie zna Waszych dotychczasowych rekordów — trzeba je przepisać, w tym rekordy poczty (MX) i te, które potwierdzają, że wolno Wam wysyłać pocztę z domeny (SPF, DKIM). Jeśli zostaną pominięte, strona zacznie działać na nowym serwerze w tej samej chwili, w której poczta przestanie dochodzić. Przed zmianą serwerów nazw warto więc wyeksportować całą strefę, a nie tylko zapisać adres serwera.

Wniosek na dzień migracji: przy zmianie hostingu lepiej zmienić rekordy u obecnego dostawcy DNS niż w tym samym dniu przenosić obsługę DNS gdzie indziej. Dwie zmiany jednocześnie to dwa różne zegary.

Przeniesienie domeny .pl — kod AuthInfo

Przeniesienie domeny, nazywane też transferem, to zmiana firmy, która obsługuje Waszą domenę — rejestratora. Nie zmienia właściciela, nie zmienia adresu strony i sama z siebie nie wpływa na jej działanie. Ale to przy niej zdarza się najwięcej zablokowanych migracji, i prawie nigdy z powodów technicznych.

Dla domen .pl procedurę opisuje NASK, który prowadzi rejestr. Ma trzy etapy:

1. Kod AuthInfo. Obecny rejestrator wydaje abonentowi kod autoryzacyjny według własnej procedury. Jeśli odmawia, choć spełniliście jego warunki, można złożyć reklamację do NASK.
2. Zainicjowanie transferu. Nowy rejestrator, mając kod, zgłasza przejęcie obsługi. Najwcześniej 5 dni od rejestracji domeny albo od jej ostatniego transferu.
3. Potwierdzenie. NASK wysyła wiadomość z linkiem na adres e-mail abonenta zapisany w rejestrze. Kliknięcie kończy transfer.

Trzeci punkt jest tym, na którym transfery stają. Jeśli domenę kilka lat temu rejestrowała agencja albo pracownik, który już nie pracuje w firmie, adres w rejestrze może należeć do nich — i link potwierdzający trafi do skrzynki, której nikt nie czyta albo do której nie macie dostępu. NASK zaznacza wprost, żeby przed transferem upewnić się, że obecny rejestrator przekazał do rejestru aktualny adres.

To ten sam problem, który opisujemy przy obsłudze strony: domena powinna być zarejestrowana na firmę, z adresem e-mail, który ktoś czyta. Przy transferze przestaje to być dobrą praktyką, a staje się warunkiem.

Zmiana domeny

Zmiana domeny — nowa nazwa firmy, przejście z .com.pl na .pl, połączenie dwóch serwisów — to jedyna z trzech migracji, przy której Google daje osobne narzędzie. W Search Console jest funkcja zmiany adresu; według dokumentacji stosuje się ją przy przeprowadzce z jednej domeny lub subdomeny na inną, a nie przy przejściu na HTTPS, przy zmianie www na wersję bez www ani przy przenoszeniu podstron w obrębie tej samej domeny.

Trzy zasady z dokumentacji Google, które przesądzają o wyniku:

• Każdy stary adres przekierowany na swój odpowiednik, nie na stronę główną nowej domeny. Przekierowanie wszystkiego na stronę główną to dla wyszukiwarki informacja, że podstron już nie ma.
• Przekierowania stałe po stronie serwera — 301 albo 308.
• Trzymajcie je „for as long as possible, generally at least 1 year". Stara domena musi więc być opłacana przez co najmniej rok po zmianie — i to jest koszt, który warto wpisać do budżetu przeprowadzki, zanim ktoś zdecyduje, że „starej już nie przedłużamy".

Przekierowanie 301 — mapa starych adresów

Przekierowanie 301 to odpowiedź serwera „ten adres przeniósł się na stałe tam". Jest sercem każdej migracji, przy której zmieniają się adresy, i najczęstszym miejscem, w którym migracja się psuje.

Google rozróżnia dwie grupy. Przekierowania stałe — 301 i 308 — Google traktuje jako sygnał, że adres docelowy ma być tym właściwym, kanonicznym. Przy tymczasowych — 302, 303, 307 — idzie za przekierowaniem, ale nie przenosi na cel tego sygnału. Przekierowanie 302 ustawione przez pomyłkę przy migracji to więc przekierowanie, które działa dla ludzi i nie działa dla wyszukiwarki. Natychmiastowy meta refresh w kodzie strony Google traktuje jak stały, opóźniony jak tymczasowy. Przekierowanie w JavaScripcie — tylko wtedy, gdy nic innego nie jest możliwe, bo Google może go nie wykonać.

Mapa przekierowań to arkusz z dwiema kolumnami: stary adres, nowy adres. Listę starych adresów najlepiej złożyć z trzech źródeł, bo każde pokazuje co innego: z obecnej mapy witryny, z raportu stron w Search Console i z listy adresów, na które prowadzą linki z zewnątrz. Każdy wiersz ma cel — nawet jeśli strona znika, przekierowanie idzie do najbliższej tematycznie, nie do strony głównej.

Gdzie ustawia się przekierowanie 301. Na serwerach Apache robi się to w pliku .htaccess w katalogu strony — jedna linia na adres, na przykład Redirect 301 /stary-adres/ https://www.example.pl/nowy-adres/. Przy dziesiątkach adresów o wspólnym wzorze stosuje się reguły z wyrażeniami regularnymi, ale każda taka reguła to ryzyko, że przekieruje więcej, niż miała — dlatego po jej dodaniu sprawdza się także adresy, które miały zostać nietknięte. Serwery nginx pliku .htaccess nie czytają wcale; tam przekierowania są w konfiguracji serwera, zwykle po stronie hostingu. W WordPressie służą do tego wtyczki. W systemach takich jak nasz reguły są częścią kodu i przechodzą ten sam przegląd co każda inna zmiana. Niezależnie od miejsca obowiązuje jedna zasada: przekierowanie ma odpowiadać serwer, zanim uruchomi się strona — nie skrypt na stronie.

Dwie rzeczy, które sprawdza się po wdrożeniu:

• Łańcuchy. Jeśli adres A przekierowuje na B, a B — z poprzedniej migracji — na C, to każda kolejna zmiana dokłada ogniwo. Stare reguły trzeba przepiąć tak, żeby prowadziły od razu do celu.
• Czy przekierowanie w ogóle działa na produkcji. To brzmi jak oczywistość, ale mamy świeży dowód, że nie jest. Nasza strona obsługuje 318 reguł przekierowań. 9 września jedna z nich została napisana, zatwierdzona i wdrożona — a stary adres dalej odpowiadał 200 ze starą treścią, bo reguła trafiła do kodu źródłowego, a nie do pliku, który serwer faktycznie czyta. Nic tego nie sygnalizowało. Jedynym testem, który to wykrył, było sprawdzenie odpowiedzi starego adresu po wdrożeniu.

Ten test to jedna komenda albo jedno narzędzie online: dla każdego starego adresu z mapy — czy odpowiada 301 lub 308 i czy po przekierowaniu kończy na stronie odpowiadającej 200. Przy kilkudziesięciu adresach to kwadrans. Przy migracji, po której „wszystko działa", ten kwadrans jest jedynym dowodem.

Migracja WordPress — adres siedzi w bazie

WordPress ma jedną właściwość, która zmienia sposób migracji przy zmianie domeny: adres strony jest zapisany w bazie danych, i to w wielu miejscach — w ustawieniach, w treściach, w konfiguracji motywu i widżetów. Przeniesienie plików i bazy na nowy serwer pod tą samą domeną tego nie dotyka. Zmiana domeny — dotyka wszystkiego.

Intuicyjne rozwiązanie to wyszukanie starego adresu w całej bazie i zamiana na nowy. Dokumentacja WordPressa ostrzega przed tym wprost: taka zamiana „can cause issues with data serialization", bo niektóre motywy i widżety zapisują wartości razem z ich długością. Nowy adres ma inną liczbę znaków niż stary, zapisana długość przestaje się zgadzać i ustawienia po cichu znikają. Do zmiany adresu w bazie WordPressa używa się narzędzi, które rozumieją ten format — nie zwykłego „znajdź i zamień".

Druga zasada z tej samej dokumentacji jest sformułowana jeszcze mocniej: kolumny GUID w tabeli wpisów „never, ever" się nie zmienia. To identyfikator wpisu, nie jego adres — po zmianie czytniki kanałów RSS pokażą wszystkie wpisy jeszcze raz jako nowe.

Pierwszy tydzień po migracji

Przez pierwszy tydzień po migracji sprawdza się nie to, czy strona działa, tylko czy działa to, czego nie widać na stronie głównej:

• Formularze — czy wiadomości dochodzą. Nowy serwer często wysyła pocztę inaczej niż stary.
• Poczta w domenie — wysyłanie i odbieranie, jeśli była przenoszona.
• Płatności i konta klientów — jedna prawdziwa transakcja zamiast założenia.
• Search Console — raport stron i lista błędów 404. Każdy nowy 404 to adres, który wypadł z mapy przekierowań; jak go przeczytać i naprawić, opisujemy przy błędzie 404.
• Monitoring dostępności — ustawiony na nowy serwer, nie na stary; osobno o tym, co powinien sprawdzać.

Jeśli po migracji zmieniła się szybkość strony, porównujcie dane z tego samego źródła. Wynik z testu laboratoryjnego i dane od prawdziwych użytkowników mierzą co innego, a te drugie zbierają się przez 28 dni — rozkładamy to przy Core Web Vitals.

Czego w tym tekście świadomie nie ma

• Migracji sklepu — przeniesienie sklepu między platformami ma własne ryzyka (produkty, warianty, konta klientów, historia zamówień); opisujemy je w osobnym tekście o migracji sklepu bez utraty SEO, jest też lista kontrolna.
• Decyzji, czy przebudowywać stronę — to przebudowa czy optymalizacja.
• Wyboru nowego hostingu — jak wybrać hosting, a ile kosztuje razem z domeną — domena i hosting.
• Tego, kto ma dostęp do domeny i serwera — obsługa strony internetowej, z listą dostępów, które powinny być na firmę.

Najkrótsze podsumowanie: nazwijcie, którą z trzech migracji robicie, i rozdzielcie je w czasie, jeśli idą razem. Przy zmianie hostingu pilnujcie TTL i starego serwera. Przy zmianie adresów — mapy przekierowań i sprawdzenia, że działają. A potem dajcie Google tygodnie, nie dni: nasz własny przeniesiony adres był w indeksie pięć dni po przekierowaniu i to nie była awaria, tylko kalendarz robota.