SEO migracji hostingu

TL;DR — Migracja hostingu przenosi zaplecze techniczne witryny, podczas gdy użytkownicy nadal korzystają z tych samych adresów URL. Najpierw zbuduj i przetestuj nowy hosting, przed uruchomieniem obniż czas TTL DNS, podczas przełączenia pozostaw stary hosting działający i porównaj odpowiedzi obu systemów. Obserwuj DNS, certyfikaty, kody statusu, treść, szybkość i dostęp crawlerów. Wyłącz stary hosting dopiero wtedy, gdy jego logi pokażą, że ruch spadł do zera.

Czym jest migracja hostingu?

Migracja hostingu zmienia miejsce lub sposób serwowania witryny bez zmiany adresów URL widocznych dla użytkowników. Przeniesienie do innej firmy hostingowej to jeden z przykładów. Dodanie lub wymiana sieci dostarczania treści (CDN), zmiana serwera źródłowego albo przełączenie dostawcy DNS może być częścią tego samego projektu.

To, że adres URL pozostaje taki sam, jest warunkiem definiującym. https://example.com/page/ musi pozostać https://example.com/page/ przed przeniesieniem i po nim.

Google traktuje to jako przeniesienie witryny bez zmian adresów URL. Jeśli zmienia się domena, protokół, nazwa hosta lub ścieżka, użyj pełnego procesu migracji witryny. Możliwe, że przeprowadzasz jednocześnie dwie migracje.

Dlaczego przeniesienie przy tych samych adresach URL może wpłynąć na SEO?

Migracja hostingu może zmienić wszystko, co znajduje się za stabilnym adresem. Wyszukiwarki mogą napotkać inny kod odpowiedzi, wolniejszy serwer, wygasły certyfikat, wyzwanie zapory, nieaktualną stronę z pamięci podręcznej, uszkodzony obraz, brakujący nagłówek albo inaczej wyrenderowaną stronę.

Najbezpieczniejsze przeniesienie zachowuje obserwowalną odpowiedź, a jednocześnie wymienia infrastrukturę. Użytkownicy i crawlery powinni otrzymać z nowego systemu tę samą prawidłową stronę, którą otrzymywali ze starego.

Jakie są podstawowe kroki?

1. Skopiuj witrynę do nowej infrastruktury lub podłącz ją do niej.
2. Przetestuj nowy origin i CDN bez zmiany publicznego DNS.
3. Z wyprzedzeniem obniż TTL DNS, aby późniejsza zmiana szybciej się rozpropagowała.
4. Potwierdź certyfikaty, cache, zasady bezpieczeństwa i dostęp crawlerów.
5. Zmień DNS tak, aby kierował ruch do nowej infrastruktury.
6. Utrzymuj oba środowiska online, aż wygasną cache DNS.
7. Monitoruj logi, błędy, szybkość, crawlowanie i widoczność w wyszukiwarce.
8. Wyłącz stary hosting dopiero wtedy, gdy jego logi pokażą brak pozostałego ruchu.

Google zaleca tę samą sekwencję przygotowania, przełączenia, monitorowania i wyłączenia w swojej dokumentacji zmiany hostingu.

Jak działa TTL DNS?

TTL DNS określa, jak długo resolver może przechowywać odpowiedź DNS w cache. Niższy TTL przed przeniesieniem pozwala szybciej usunąć zmienione rekordy z cache. Nie sprawia jednak, że każdy resolver przełączy się natychmiast, a obniżenie TTL dopiero w chwili uruchomienia jest zbyt późne dla cache przechowujących starą wartość.

Google sugeruje obniżenie TTL do ostrożnie niskiej wartości, na przykład kilku godzin, co najmniej tydzień przed przeniesieniem. Potraktuj to jako przykład, a nie uniwersalną liczbę; dokładną wartość określają dostawca DNS i wymagania operacyjne.

Czy potrzebujesz przekierowań?

Prawdziwa migracja hostingu nie wymaga przekierowań SEO, ponieważ publiczne adresy URL się nie zmieniają. Dodanie zbiorczych przekierowań podczas przenoszenia wyłącznie hostingu tworzy nowe tryby awarii, nie rozwiązując problemu infrastruktury.

Istniejące przekierowania nadal muszą działać dokładnie tak jak wcześniej. Przetestuj je na nowym stosie, w tym stare reguły, które mogą znajdować się na obecnym serwerze WWW, w CMS-ie, load balancerze lub CDN-ie.

Kiedy przeniesienie jest zakończone?

Przeniesienie hostingu jest zakończone, gdy nowa infrastruktura konsekwentnie serwuje zamierzone odpowiedzi, a stara infrastruktura nie otrzymuje już rzeczywistego ruchu użytkowników ani crawlerów. Google wyraźnie zaleca sprawdzenie logów starego dostawcy i wyłączenie go dopiero po osiągnięciu zera ruchu.

TL;DR — Traktuj migrację hostingu, CDN-u lub DNS-u przy tych samych adresach URL jako projekt zachowania zgodności odpowiedzi i routingu ruchu. Zainwentaryzuj każdą nazwę hosta i zależność, przed uruchomieniem obniż TTL DNS, skonfiguruj nowy origin i edge, zweryfikuj certyfikaty oraz zabezpieczenia, przetestuj obciążenie odpowiadające rzeczywistemu zapotrzebowaniu crawlerów i użytkowników, a także porównaj odpowiedzi surowe i wyrenderowane. Uruchom stary i nowy system równolegle podczas propagacji DNS. Monitoruj oba strumienie logów, odpowiedzi DNS, błędy, opóźnienia, zachowanie cache, aktywność crawlowania i Search Console. Przywróć poprzedni routing w ramach wycofania tylko wtedy, gdy wystąpi uzgodniona awaria infrastruktury.

Ustal, czy to naprawdę migracja przy tych samych adresach URL

Migracja hostingu przy tych samych adresach URL zmienia infrastrukturę bez zmiany dokładnego publicznego ciągu adresu URL. Schemat, nazwa hosta, port, ścieżka, obsługa parametrów zapytania i zachowanie końcowego ukośnika pozostają stabilne.

Sklasyfikuj projekt przed jego zaplanowaniem:

Nie pozwól, aby project manager nazwał zmianę URL „tylko hostingiem”. Plan wdrożenia musi uwzględniać każdy typ migracji, który faktycznie zostanie uruchomiony.

Zbuduj inwentarz infrastruktury

Inwentarz infrastruktury zapobiega temu, by ciche zależności stały się niespodziankami w dniu uruchomienia. Zapisz:

• wszystkie publiczne nazwy hostów, w tym hosty zasobów, obrazów, API, hosty międzynarodowe i starsze aliasy;
• rekordy A, AAAA, CNAME, NS, SOA, CAA, MX, TXT oraz odpowiednie rekordy SRV;
• wystawców certyfikatów, metody walidacji, nazwy Subject Alternative Names i terminy wygaśnięcia;
• adresy originów, porty, testy zdrowia, load balancery i zachowanie failover;
• klucze cache CDN, reguły cache, przekierowania, transformacje, workery i metody purge;
• reguły WAF, botów, limitów, geolokalizacji, uwierzytelniania oraz zezwalania/blokowania adresów IP;
• nagłówki odpowiedzi, kompresję, zachowanie cookies i nagłówki bezpieczeństwa;
• miejsca docelowe logów, retencję, próbkowanie, pola i strefy czasowe;
• metody weryfikacji Search Console i analityki;
• wywołania zwrotne stron trzecich, webhooki, płatności, feedy i dozwolone adresy IP.

Przegląd DNS musi obejmować rekordy inne niż webowe. Uszkodzenie rekordów MX, SPF, DKIM, DMARC lub rekordów usług może bezpośrednio nie zmienić pozycji, ale może przerwać działanie firmy, którą próbujesz chronić.

Ustal punkt odniesienia zgodności odpowiedzi

Zgodność odpowiedzi oznacza porównanie starego i nowego systemu dla tego samego żądanego URL-a, a nie tylko sprawdzenie, czy oba zwracają 200.

Zbierz reprezentatywny zestaw obejmujący szablony i zachowania:

• status i łańcuch przekierowań;
• końcowy URL i negocjację protokołu;
• tytuł, canonical, dyrektywy robots, hreflang i dane strukturalne;
• surowy HTML oraz główną treść wyrenderowaną w przeglądarce;
• Content-Type, Cache-Control, Vary, kompresję i nagłówki bezpieczeństwa;
• obrazy, fonty, JavaScript, CSS, pliki PDF i zasoby multimedialne;
• cookies oraz warianty zalogowane i spersonalizowane;
• zachowanie na urządzeniach mobilnych i desktopowych;
• opóźnienie, czas do pierwszego bajtu i współczynnik błędów.

Użyj narzędzia Staging vs. Production SEO Diff do porównywania par stron. Pełny crawler i zestaw skryptowanych żądań powinny objąć większy inwentarz.

Przygotuj nowy origin

Przygotowanie originu zaczyna się od zgodności treści i konfiguracji. Skopiuj bieżącą treść, szablony, multimedia, reguły robots, przekierowania, obsługę błędów i pliki weryfikacyjne. Zamroź zapisy albo je synchronizuj, aby nowa baza danych nie została uruchomiona z nieaktualnymi danymi.

Przetestuj origin bezpośrednio przez kontrolowaną nazwę hosta, lokalne nadpisanie pliku hosts albo mechanizm podglądu dostawcy. Test musi zachować produkcyjny nagłówek Host, ponieważ wirtualne hosty, routing aplikacji, certyfikaty, canonicale i bezwzględne linki często od niego zależą.

Nowy origin musi także obsłużyć obciążenie po przełączeniu. Rozgrzej aplikację i bazę danych, potwierdź pule połączeń i autoskalowanie oraz przetestuj niecacheowany ruch. Braki w cache CDN mogą natychmiast po uruchomieniu skoncentrować ruch na originie.

Skonfiguruj CDN jako osobny system

Migracja CDN zmienia więcej niż położenie geograficzne. Wyraźnie porównaj zachowanie starego i nowego edge:

• skład zestawu klucza cache, w tym ciągi zapytań, cookies, nagłówki i warianty urządzeń;
• kody statusu i typy plików, które można cache’ować;
• TTL przeglądarki, TTL edge, serwowanie nieaktualnych danych, rewalidację i osłonę originu;
• przekierowania, przepisywanie, transformacje nagłówków i funkcje edge;
• reguły omijania cache dla kont, koszyków, wyszukiwania i stron spersonalizowanych;
• kompresję i optymalizację obrazów;
• zakres purge i propagację;
• WAF, zarządzanie botami, limity ruchu i ochronę originu.

Aktualna dokumentacja Cloudflare zauważa na przykład, że domyślne cache’owanie może respektować nagłówki Cache-Control z originu, ale reguły edge mogą je nadpisać. Cloudflare udostępnia także purge celowane lub pełne, aby wymusić świeże pobranie z originu. Dokładne zachowanie zależy od dostawcy, dlatego eksportuj i porównuj konfigurację, zamiast zakładać, że równoważne etykiety oznaczają równoważne wyniki. Zobacz dokumentację cache Cloudflare.

Traktuj zgodność cache jak zgodność treści

Konfiguracja cache może szybko i poprawnie technicznie serwować niewłaściwą stronę. Testuj warianty anonimowe, uwierzytelnione, zlokalizowane, mobilne i z ciągiem zapytania. Klucz cache pomijający znaczące cookie lub nagłówek może ujawnić spersonalizowaną treść. Klucz uwzględniający każdy parametr śledzący może rozdrobnąć cache i przeciążyć origin.

Purge’uj lub wstępnie rozgrzewaj kluczowe zasoby i strony zgodnie z planem uruchomienia. Nie purge’uj bez namysłu wszystkiego w czasie szczytowego ruchu, chyba że origin przetestowano pod kątem wynikającej z tego fali braków w cache.

Zweryfikuj TLS od użytkownika do edge i od edge do originu

Walidacja TLS ma dwa odcinki, gdy CDN kończy HTTPS: od przeglądarki do CDN-u oraz od CDN-u do originu. Potwierdź obsługę nazw hostów, kompletne łańcuchy certyfikatów, nowoczesne protokoły, odnowienie i ścisłą walidację originu.

Certyfikaty wyłącznie dla originu mogą nie być publicznie zaufane. Cloudflare ostrzega, że certyfikaty Origin CA mogą powodować błędy zaufania przeglądarki, gdy proxy jest wyłączone lub wstrzymane. Ma to znaczenie przy wycofaniu: awaryjne przejście DNS-only do originu korzystającego z modelu zaufania wyłącznie dla edge może nie działać użytkownikom. Zobacz wytyczne Cloudflare dotyczące Origin CA.

Przetestuj każdą publiczną nazwę hosta, w tym założenia dotyczące wildcardów oraz rzadko używane hosty zasobów i regionalne. Prawidłowy certyfikat apexu nie dowodzi, że objęta jest każda subdomena.

Obniż TTL DNS przed przeniesieniem

Planowanie TTL zaczyna się przed przełączeniem. Google zaleca obniżenie odpowiedniego TTL do ostrożnie niskiej wartości, na przykład kilku godzin, co najmniej tydzień przed przeniesieniem. Dostawca DNS może narzucać inne minima; rekordy proxied mogą także mieć stałe wartości.

Dokumentacja TTL Cloudflare wyjaśnia podstawowy kompromis: dłuższe wartości zwiększają ponowne wykorzystanie cache, a krótsze pozwalają szybciej zastosować zmiany rekordów. Zapisz pierwotny TTL i zaplanuj jego przywrócenie dopiero po ustabilizowaniu nowej infrastruktury.

Zmiany DNS mogą nie być atomowe w systemach rozproszonych. Podczas przełączenia zmieniaj jak najmniej, weryfikuj odpowiedzi z kilku publicznych resolverów i utrzymuj stare miejsce docelowe, dopóki ważne są zcache’owane odpowiedzi.

Zweryfikuj dostęp crawlerów i zabezpieczenia

Zgodność bezpieczeństwa nie polega na zgodności liczby reguł. WAF skopiowany od innego dostawcy może rzucać wyzwania crawlerom lub je blokować, usuwać parametry zapytania, przepisywać odpowiedzi albo inaczej ograniczać crawlowanie o dużym natężeniu.

Przewodnik Google dotyczący hostingu mówi, aby upewnić się, że zapory i ochrona przed atakami typu denial-of-service nie blokują Googlebota przed DNS-em ani serwerami hostingu. Weryfikuj Googlebota za pomocą udokumentowanych metod Google, a nie wyłącznie na podstawie ciągu user-agent.

Przetestuj zarówno zwykłe zachowanie crawlera, jak i uzasadnione skoki ruchu. Unikaj szerokiego allowlistingu, który wyłącza ochronę dla podszywających się user-agentów. Zachowaj logi bezpieczeństwa, aby zablokowane żądania można było odróżnić od awarii originu.

Zaplanuj działanie równoległe

Działanie równoległe oznacza, że stara i nowa infrastruktura mogą podczas propagacji serwować prawidłowe odpowiedzi produkcyjne. Stare środowisko musi nadal otrzymywać zmiany treści lub danych wpływające na witrynę. W przeciwnym razie użytkownicy skierowani przez zcache’owane odpowiedzi DNS mogą zobaczyć nieaktualne stany magazynowe, uszkodzone sesje albo nieaktualne strony.

Wybierz strategię synchronizacji:

• jedna baza danych współdzielona przez oba stosy, z prawem odczytu i zapisu;
• replikowane dane ze zrozumiałym opóźnieniem i zasadami rozwiązywania konfliktów;
• kontrolowane zamrożenie treści podczas przełączenia;
• jednokierunkowa replikacja zdarzeń dla zamówień, formularzy lub zapisów użytkowników.

Stan sesji, przesyłane pliki, unieważnienia cache i zadania w tle wymagają tej samej decyzji. „Oba serwery działają” nie jest planem równoległego uruchomienia, jeśli ich stan się rozbiega.

Wykonaj przełączenie

Przełączenie hostingu powinno być celowo nudne:

1. Zatrzymaj niezwiązane wdrożenia i potwierdź okno zmian.
2. Wykonaj końcowe kontrole zgodności, certyfikatów, przepustowości i kopii zapasowych.
3. Usuń tymczasowe blokady crawlowania lub dostępu z nowej ścieżki produkcyjnej.
4. Zmień wyłącznie zaplanowane rekordy routingu DNS lub CDN.
5. Potwierdź oczekiwane odpowiedzi z wielu resolverów.
6. Zażądaj chronionych stron przez publiczną ścieżkę jako użytkownik i crawler.
7. Potwierdź napływ logów z edge, nowego originu i starego originu.
8. Obserwuj błędy, opóźnienia, braki w cache, obciążenie originu i konwersje.

Nie używaj narzędzia Google do zmiany adresu podczas przenoszenia wyłącznie hostingu. Nie zmienił się żaden publiczny adres URL, więc nie ma zmiany adresu do zgłoszenia.

Monitoruj dowody potwierdzające przeniesienie

Monitoring infrastruktury powinien rozdzielać stary i nowy ruch. Użyj znacznika wdrożenia i porównuj tę samą bazę z danego dnia tygodnia, gdy znaczenie ma sezonowość.

Obserwuj:

• odpowiedzi DNS i propagację resolverów;
• żądania do starego i nowego hosta od użytkowników oraz zweryfikowanych crawlerów;
• rozkład kodów statusu edge i originu;
• błędy TLS, połączeń, limitów czasu i aplikacji;
• percentyle opóźnień oraz czas odpowiedzi niecache’owanego originu;
• współczynnik trafień cache i liczbę żądań do originu;
• żądania Googlebota, Crawl Stats, Page Indexing i reprezentatywną inspekcję URL-a;
• testy syntetyczne z różnych regionów i sieci;
• analitykę, konwersje i kluczowe transakcje biznesowe.

Google mówi, że tymczasowy spadek tempa crawlowania przez Googlebota bezpośrednio po zmianie hostingu może być normalny, a w kolejnych dniach może nastąpić wzrost. Każdą decyzję opieraj na dowodach dostępności i błędów, a nie wyłącznie na tym oczekiwanym wzorcu.

Zdefiniuj wycofanie przed uruchomieniem

Wycofanie przywraca routing do znanego, sprawnego stanu infrastruktury. Nie jest niejasną obietnicą „przełączenia DNS z powrotem”. Udokumentuj:

• dokładne rekordy, trasy i konfiguracje do przywrócenia;
• osoby, które mogą zatwierdzić i wykonać odwrócenie;
• sposób uzgodnienia zmienionej treści, sesji, formularzy, zamówień i przesłanych plików;
• to, czy stare certyfikaty i zależności pozostaną ważne;
• kroki purge na obu trasach;
• progi awarii uruchamiające wycofanie;
• maksymalny bezpieczny czas podjęcia decyzji.

Wyzwalacze wycofania powinny być obserwowalne: utrzymujące się awarie dostępności, istotne problemy z konwersją, powszechnie błędna treść, awarie certyfikatów, blokady crawlerów albo załamanie przepustowości, którego nie można naprawić w dostępnym oknie. Sam tymczasowy spadek tempa crawlowania nie jest wyzwalaczem wycofania.

Wycofuj starą infrastrukturę na podstawie logów, nie kalendarza

Wycofanie starego hosta następuje po tym, jak logi pokażą, że użytkownicy i crawlery już do niego nie docierają, a wszystkie zależne usługi zostały przeniesione. Google zaleca wyłączenie starego hosta po osiągnięciu przez jego ruch zera.

Zachowaj eksporty konfiguracji, logi i artefakty wycofania zgodnie z wymaganiami biznesowymi. Przywróć TTL DNS do docelowej wartości ustalonej dla stabilnego działania dopiero po potwierdzeniu stabilności. Usuń tymczasowe wyjątki zapory i zduplikowane zadania cykliczne, aby migracja nie pozostawiła trwałego bałaganu utrzymaniowego.

Podsumowanie AI

• Migracja hostingu zmienia serwery, CDN, origin lub DNS, zachowując identyczne publiczne adresy URL.
• Zmiany adresów URL wymagają szerszego procesu przeniesienia witryny. Prawdziwe przeniesienie wyłącznie hostingu nie potrzebuje nowej mapy przekierowań ani zgłoszenia w narzędziu do zmiany adresu.
• Przed uruchomieniem zainwentaryzuj DNS, TLS, origin, CDN, WAF, cache, logi, weryfikację, zasoby i zależności biznesowe.
• Obniż TTL DNS przed przełączeniem, zachowaj pierwotną wartość i przywróć ją po ustabilizowaniu nowej ścieżki.
• Porównaj stare i nowe odpowiedzi surowe, strony wyrenderowane, nagłówki, zasoby, przekierowania, kody statusu, opóźnienia i zachowanie biznesowe.
• Zweryfikuj TLS między przeglądarką i edge oraz między edge i originem, a także certyfikaty na każdej ścieżce wycofania.
• Uruchamiaj środowiska równolegle i synchronizuj zapisy, dopóki zcache’owane odpowiedzi DNS nie przestaną kierować ruchu do starego stosu.
• Monitoruj oba strumienie logów, odpowiedzi DNS, błędy, obciążenie originu, zachowanie cache, dostęp zweryfikowanych crawlerów, Search Console i konwersje.
• Wycofaj stary hosting dopiero wtedy, gdy jego logi pokażą, że ruch osiągnął zero.

Oficjalna dokumentacja

Google

• Zmiana hostingu i SEO wyjaśnia proces przygotowania, przełączenia DNS, monitorowania i wyłączenia przy tych samych adresach URL.
• Przeniesienia witryny ze zmianą adresów URL dotyczą sytuacji, gdy zmienia się także schemat, nazwa hosta lub ścieżka.
• Weryfikacja Googlebota opisuje weryfikację przez odwrotne i zwykłe DNS oraz opublikowane adresy IP.
• Raport Crawl Stats pomaga monitorować żądania Googlebota i dostępność hosta.

Materiały dotyczące infrastruktury

• TTL DNS Cloudflare wyjaśnia kompromisy związane z TTL i propagacją.
• Cache Cloudflare opisuje cache na edge, reguły cache i purge.
• Cloudflare Origin CA opisuje certyfikaty między edge i originem oraz ograniczenie zaufania przeglądarki.

Cytaty ze źródła

• “This guide is only for migrations that don’t affect the user-visible URL.” Google Search Central. Przejdź do przewodnika dotyczącego hostingu
• Parafraza: Google zaleca z wyprzedzeniem ograniczyć TTL DNS, dopilnować, aby zapory nadal przepuszczały zweryfikowany ruch Googlebota, oczekiwać tymczasowego spadku tempa crawlowania i utrzymać stary hosting do czasu zakończenia jego ruchu. Wskazówki dotyczące TTL, wskazówki dotyczące zapory, wskazówki dotyczące tempa crawlowania oraz wskazówki dotyczące wyłączenia.

Lista kontrolna migracji hostingu

Zakres i punkt odniesienia

• Potwierdzono, że żaden publiczny URL się nie zmieni.
• Zainwentaryzowano każdą nazwę hosta webowego, zasobów, API i regionalną.
• Wyeksportowano konfiguracje DNS, CDN, WAF, cache, przekierowań, TLS i originu.
• Zapisano reprezentatywne punkty odniesienia surowych i wyrenderowanych odpowiedzi.
• Zapisano punkty odniesienia ruchu, błędów, opóźnień, crawlowania, indeksacji i konwersji.

Nowa infrastruktura

• Zsynchronizowano bieżącą treść, multimedia, przekierowania, reguły robots i pliki weryfikacyjne.
• Przetestowano routing na podstawie nagłówka Host i każdą publiczną nazwę hosta.
• Zweryfikowano certyfikaty między przeglądarką i edge oraz między edge i originem.
• Dopasowano klucze cache, obejścia, TTL, cookies, transformacje i zachowanie purge.
• Dopasowano zachowanie WAF, botów, limitów i dostępu do originu.
• Przetestowano obciążenie wynikające z braków w cache, zależności aplikacji i przepustowości bazy danych.
• Potwierdzono, że logi edge, originu, aplikacji i bezpieczeństwa są przechowywane i można je przeszukiwać.

DNS i uruchomienie

• Z wyprzedzeniem obniżono odpowiednie TTL i zapisano pierwotne wartości.
• Zachowano rekordy inne niż webowe, DNSSEC, weryfikację i zależności usług.
• Udokumentowano dokładną zmianę routingu i polecenia wycofania.
• Utrzymano starą i nową infrastrukturę przy działającym planie synchronizacji danych.
• Usunięto każdą tymczasową blokadę crawlowania lub dostępu na ścieżce produkcyjnej.
• Zweryfikowano odpowiedzi DNS przez kilka niezależnych resolverów.

Po uruchomieniu

• Porównano w produkcji status, treść, nagłówki, renderowanie, zasoby i przekierowania.
• Potwierdzono, że użytkownicy i zweryfikowane crawlery nie są kwestionowani ani blokowani.
• Obserwowano logi starego i nowego hosta, błędy, opóźnienia, braki w cache, obciążenie originu i konwersje.
• Sprawdzono Crawl Stats, Page Indexing i reprezentatywne wyniki inspekcji URL-i.
• Przywrócono ustalony TTL dopiero po potwierdzeniu stabilności.
• Wyłączono stary hosting dopiero po osiągnięciu przez jego ruch zera.

Pięciowarstwowa struktura zgodności

Model stanów migracji

Przygotowana oznacza, że nowy stos przechodzi testy zgodności i obciążenia. Przełączanie oznacza, że odpowiedzi DNS i żądania są rozdzielone. Stabilizacja oznacza, że nowy stos obsługuje prawie cały ruch, a stary pozostaje dostępny. Zakończona oznacza, że ruch do starego hosta osiągnął zero, a wszystkie zależności zostały wycofane lub przeniesione.

Nie nazywaj projektu zakończonym w chwili „zmiany DNS”. To początek przełączenia, a nie koniec migracji.

Który plan migracji ma zastosowanie?

Typowe awarie migracji hostingu

Niektóre regiony nadal docierają do starego hosta

Prawdopodobna przyczyna: zcache’owane odpowiedzi DNS, zachowanie resolvera albo rekordy, które nie zostały zmienione spójnie. Naprawa: porównaj odpowiedzi autorytatywne z kilkoma publicznymi resolverami, pozostaw stary hosting serwujący aktualną treść i sprawdź TTL, zamiast wymuszać kolejne zmiany.

Po uruchomieniu spada liczba żądań Googlebota

Prawdopodobna przyczyna: normalne krótkotrwałe dostosowanie tempa crawlowania, wyzwanie zapory, awaria DNS, opóźnienie lub błędy serwera. Naprawa: sprawdź Crawl Stats i logi dostępu zweryfikowanych botów. Udokumentowany przez Google krótkotrwały spadek nie jest powodem, aby ignorować rzeczywiste awarie dostępu.

Strony są szybkie, ale pokazują nieaktualną treść

Prawdopodobna przyczyna: TTL edge, klucz cache, nieudany purge albo rozbieżne źródło danych. Naprawa: sprawdź nagłówki Age, Cache-Control, Vary i statusu cache dostawcy; testuj znaczące warianty, wykonaj wąski purge, a następnie osobno zweryfikuj origin i edge.

Witryna działa przez CDN, ale zawodzi przy jego ominięciu

Prawdopodobna przyczyna: zaufanie do certyfikatu originu, routing nagłówka Host, allowlisty zapory albo brakująca zależność bezpośredniego originu. Naprawa: zweryfikuj zamierzoną ścieżkę edge–origin i udokumentowaną ścieżkę wycofania. Nie ujawniaj prywatnego originu tylko po to, aby zaplanowany test ominięcia CDN zakończył się powodzeniem.

Zasoby zawodzą, choć HTML działa

Prawdopodobna przyczyna: pominięte nazwy hostów zasobów, CORS, certyfikaty, bezwzględne URL-e, reguły cache, ochrona hotlinkowa albo uprawnienia originu. Naprawa: przeprowadź crawl i testy w przeglądarce dla inwentarza zasobów, w tym fontów, obrazów, CSS, JavaScriptu, PDF-ów i multimediów.

Obciążenie originu natychmiast rośnie

Prawdopodobna przyczyna: zimny cache, zmieniony klucz cache, ominięty cache, brak osłony albo ruch botów docierający bezpośrednio do originu. Naprawa: przywróć zamierzone reguły cache, ostrożnie rozgrzej wartościowe obiekty i dodaj przepustowość. Wycofaj zmianę, jeśli utrzymujące się awarie przekroczą uzgodniony próg.

Narzędzia do przeniesienia infrastruktury przy tych samych adresach URL

• DNS Checker porównuje typowe rekordy przez kilka publicznych resolverów. Użyj go podczas propagacji, ale porównaj wynik także ze strefą autorytatywną.
• HTTP Header Checker pokazuje nagłówki w całym łańcuchu przekierowań, w tym odciski CDN-u, kompresję, bezpieczeństwo i sterowanie cache.
• Staging vs. Production SEO Diff porównuje pary URL-i pod kątem statusu, canonicali, dyrektyw, wybranych nagłówków, schematu i treści.
• Bulk HTTP Status Code Checker sprawdza status, przekierowania, miejsce docelowe i opóźnienie dla reprezentatywnego zestawu URL-i.
• Google Index Checker sprawdza obserwowalne blokady crawlowania i indeksowania, a następnie odsyła do Search Console po widok Google.
• Logi serwera i edge dowodzą, dokąd trafił ruch, jaką otrzymał odpowiedź i kiedy stara infrastruktura naprawdę przestała być używana.
• Monitoring syntetyczny testuje publiczną dostępność i kluczowe transakcje z kilku sieci i regionów.

Udowodnij, że migracja hostingu się udała

Test propagacji DNS i odpływu ze starego hosta

• Test do wykonania: odpytaj autorytatywny DNS oraz kilka publicznych resolverów, a następnie przedstaw na wykresie wolumen żądań do starej i nowej infrastruktury.
• Oczekiwany wynik: publiczne odpowiedzi zbiegają się z zamierzoną trasą, a ruch do starego hosta spada do zera.
• Interpretacja niepowodzenia: niespójne rekordy, zcache’owane odpowiedzi lub niezarejestrowane nazwy hostów nadal kierują ruch gdzie indziej.
• Okno monitorowania: od przełączenia przez co najmniej najdłuższy wcześniejszy istotny TTL i do chwili, gdy logi starego hosta utrzymają zero.
• Wyzwalacz wycofania: istotne regiony nie mogą rozwiązać nazwy nowej usługi ani się z nią połączyć, a problemu nie można naprawić w oknie odzyskiwania.

Test zgodności odpowiedzi

• Test do wykonania: porównaj punkt odniesienia z produkcją za pomocą Staging vs. Production SEO Diff, crawlera i testów wyrenderowanych w przeglądarce.
• Oczekiwany wynik: zamierzone statusy, canonicale, reguły robots, treść, dane strukturalne, linki wewnętrzne, zasoby i nagłówki pozostają zachowane.
• Interpretacja niepowodzenia: konfiguracja nowego originu, edge albo aplikacji zmieniła widoczną dla wyszukiwarki odpowiedź mimo stabilnych URL-i.
• Okno monitorowania: bezpośrednio przed przełączeniem i po nim, a następnie po każdej poprawce uruchomieniowej.
• Wyzwalacz wycofania: ogólnowitrynowa awaria indeksowania, canonicali, treści lub zasobów wpływa na chronione szablony i nie może być bezpiecznie naprawiona na gorąco.

Test dostępu crawlerów i przepustowości

• Test do wykonania: sprawdź logi zweryfikowanych crawlerów, Crawl Stats w Search Console, opóźnienie originu, współczynniki błędów i testy obciążenia bez cache.
• Oczekiwany wynik: zweryfikowane crawlery otrzymują prawidłowe odpowiedzi bez wyzwań, a origin pozostaje w ustalonym przedziale przepustowości.
• Interpretacja niepowodzenia: WAF, DNS, TLS, ograniczanie ruchu lub przepustowość originu uniemożliwiają niezawodne crawlowanie.
• Okno monitorowania: stale podczas uruchomienia i przez pierwsze dni stabilizacji tempa crawlowania.
• Wyzwalacz wycofania: utrzymujące się awarie crawlerów i użytkowników przekraczają zatwierdzony próg błędów lub dostępności.

Test bezpieczeństwa cache

• Test do wykonania: wykonuj żądania dla wariantów anonimowych, uwierzytelnionych, zlokalizowanych, mobilnych i z parametrami zapytania, jednocześnie sprawdzając klucze cache i nagłówki odpowiedzi.
• Oczekiwany wynik: publiczna treść jest cache’owana zgodnie z projektem; odpowiedzi prywatne lub spersonalizowane nie są współdzielone; znaczące warianty pozostają rozdzielone.
• Interpretacja niepowodzenia: reguły klucza cache lub obejścia mogą serwować nieprawidłową treść albo przeciążać origin.
• Okno monitorowania: przed uruchomieniem, bezpośrednio po przełączeniu i po każdej zmianie reguły cache lub purge.
• Wyzwalacz wycofania: ujawniono spersonalizowane dane, serwowana jest powszechnie nieaktualna treść albo origin nie może obsłużyć współczynnika braków w cache.

Zasoby warte uwagi

Moje powiązane teksty

• Migracja witryny wymaga czegoś więcej niż checklisty, aby się udać omawia szerszy proces migracji, punkty odniesienia, staging i monitoring.
• Przekierowania dla SEO wyjaśniają zachowanie starszych przekierowań, które musi przetrwać przeniesienie infrastruktury.

Powiązane przewodniki w tej witrynie

• Migracje witryn obejmują klasyfikację migracji i uniwersalny proces.
• Lista kontrolna migracji witryny zawiera fazową checklistę projektu.
• Kody statusu HTTP wyjaśniają warstwę odpowiedzi, którą należy zachować i monitorować.

Z całej branży

• Google: Zmiana hostingu
• Google: Weryfikacja Googlebota
• Cloudflare: TTL DNS
• Cloudflare: Zarządzanie rekordami DNS
• Cloudflare: Dokumentacja cache
• Cloudflare: Origin CA
• Bing: IndexNow

Sprawdź się: SEO migracji hostingu

Pięć pytań o klasyfikowanie, uruchamianie i weryfikowanie przeniesienia infrastruktury przy tych samych adresach URL. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.

Dziennik zmian