Checklista migracji witryny: od T-4 tygodni do dnia 45
Zmiana domeny, zmiana platformy, przeniesienie hostingu lub nowy schemat URL – linki do Twojej witryny nie mają znaczenia, która z tych opcji zostanie wybrana. Ta lista mówi, co należy zebrać przed uruchomieniem, a co należy ponownie sprawdzić po nim.
Zespół badawczy ArchiLinks ·
Nasza pozycja
Większość strat migracyjnych wynika z brakujących przekierowań, a nie z typu przekierowania
Zespoły godzinami dyskutują nad wyborem między 301 a 302, a następnie wdrażają 3000 adresów URL z linkami zewnętrznymi zwracających błąd 404. Znajdź wszystkie backlinki do witryny przed podjęciem jakiejkolwiek innej decyzji, ponieważ lista pokaże, gdzie tkwi ryzyko.
- Pobierz strony z linkami 4 tygodnie wcześniej, a nie w nocy przed uruchomieniem.
- Każdy URL z linkiem zewnętrznym musi mieć jedno-hopowe przekierowanie 301 do odpowiedniej strony.
- Zostaw przekierowania aktywne przez co najmniej rok, ponieważ stare linki często przetrwają strony, na które kiedyś wskazywały.
Harmonogram
T-4 tygodnie: inwentaryzacja
Przeanalizuj starą witrynę, wyeksportuj raport wydajności z Search Console oraz uruchom toppages oraz refdomains dla starego hosta. Przechowuj trzy pliki razem z datą.
T-3 tygodnie: mapowanie
Zbuduj mapę przekierowań najpierw na podstawie stron z linkami, następnie na podstawie ruchu, a na końcu na podstawie analizy crawlowania. Przepis na mapę przekierowań pokazuje skrypt rangujący.
T-2 tygodnie: testy na środowisku staging
Przetestuj każdy stary URL na środowisku staging i upewnij się, że jest to jedno-hopowe przekierowanie, status 301 i wynik 200 na końcu. Odrzuć wdrożenie przy wystąpieniu łańcucha lub pętli.
T-0: uruchomienie
Wdróż przekierowania, nową mapę witryny, zaktualizowane tagi canonical oraz linki wewnętrzne w jednym wydaniu. Prześlij nową mapę witryny w Search Console. W przypadku zmiany domeny użyj narzędzia Zmiana adresu.
T+1 tydzień: logi i pokrycie
Sprawdź logi serwera pod kątem odwiedzin Googlebot na starych URLach, a następnie raport Strony pod kątem wzrostu liczby błędów 404 lub soft 404. Popraw mapę; nie czekaj.
T+30 do 45 dni: porównanie linków
Po miesięcznej aktualizacji pobierz refdomains dla nowego hosta i porównaj je ze starym plikiem. Różnice większe niż kilka procent wymagają uwagi.
Co zmienia się w zależności od typu przeniesienia
| Przeniesienie | Przekierowania | Dodatkowe sprawdzenia | Skupienie na danych linków |
|---|---|---|---|
| Nowa domena | Przekierowanie 301 na poziomie hosta, na poziomie ścieżki tam, gdzie ścieżki się zmieniają | Narzędzie Zmiana adresu, stara domena zachowana przez co najmniej 12 miesięcy | Domeny odsyłające przenoszące się na nowy host z upływem czasu |
| HTTP do HTTPS lub zmiana www | Przekierowanie 301 na poziomie hosta | Canonical, HSTS, mieszana zawartość | Małe różnice; potwierdź, że oba hosty rozwiązują się do jednego |
| Zmiana platformy, ta sama domena | Mapa na poziomie ścieżki | Paginacja, parametry, ukośniki końcowe | Najczęściej linkowane strony, które zmieniły ścieżkę |
| Poddomena do folderu (lub odwrotnie) | Mapa na poziomie ścieżki, reguły na poziomie hosta | Ciasteczka, robots.txt na poziomie hosta, analityka | Czy linki wskazują na stary host, czy na nowy |
| Scalanie dwóch witryn | Mapa wiele-do-jednego | Duplikacja treści, wybór canonical | Nakładanie się domen odsyłających poprzez intersect |
Checklista dnia uruchomienia
- Stare URLe zwracają 301 w jednym hopie, przetestowane przez skrypt, a nie ręcznie.
- Nowy host zwraca 200 z self-referencing canonical na każdym szablonie.
- robots.txt na nowym hostie nie zawiera reguł środowiska staging. Pozostałe Disallow: / to klasyczny błąd w dniu uruchomienia.
- XML sitemap zawiera tylko URLe z kodem 200, indeksowalne i z canonical.
- Linki wewnętrzne, nawigacja i dane strukturalne wskazują na nowe URLe, a nie na przekierowane.
- Właściwości Analityki i Search Console istnieją dla nowego hosta przed przełączeniem.
- Pliki bazowe JSON są zatwierdzone, z datą w nazwie każdego pliku.
Nasz wykres linków jest odbudowywany około raz w miesiącu. Link utworzony w tygodniu Twojego uruchomienia może nie pojawić się przy pobieraniu w dniu 30. Użyj raportu Linki w Search Console dla ostatniego etapu i oceń różnicę od drugiego odświeżenia. Te same dane zasilają recenzję równowaga wewnętrzna vs zewnętrzna po uruchomieniu, a domeny regionalne hreflang pokrywają przypadek wielokrajowy.
Przekierowanie 301 kończące się 404 nie zachowuje niczego
Niektóre zespoły wysyłają każdy stary URL do nowej lokalizacji i pozwalają stronom docelowym wygasnąć później. Samo przekierowanie działa. Dlatego ta praktyka jest ryzykowna, ponieważ każdy hop wygląda czysto w logach, podczas gdy strona na końcu odpowiada błędem 404.
Załóżmy, że przenosisz sklep na nową domenę i zachowujesz tylko produkty, które nadal się sprzedają. Strony kategorii, które zawierały większość zewnętrznych linków, teraz prowadzą do niczego użytecznego. Policz URLe z linkami zewnętrznymi przed wycofaniem czegokolwiek. Zrób to jako pierwszy krok. Strona z domenami odsyłającymi wymaga żywego celu na ten sam temat, a nie bezradności.
Zachowaj krótką regułę: jeden hop, a następnie końcowe 200. Wszystko inne to wyciek, który wybrałeś.
Co chroni jedno-hopowe przekierowanie 301 do aktywnej strony
Wartość linku spoczywa na URLu, na który wskazuje. Przekierowanie przenosi tę wartość tylko wtedy, gdy adres, na który prowadzi, odpowiada i nadal pasuje do tematu. Produkt przeniesiony do tego samego produktu w nowym katalogu przechodzi ten test, podczas gdy produkt wysłany na stronę główną zwykle nie, nawet jeśli była to strona, do której wszyscy linkowali.
Ponownie sprawdź status końcowy po każdej zmianie szablonu. Przekierowanie, które działało przy uruchomieniu, może kończyć się błędem 404 po późniejszym wydaniu, gdy ktoś usunie kategorię podczas porządkowania menu.
Kiedy 410 jest uczciwą odpowiedzią
Niektóre stare URLe nie miały linków, odwiedzin ani prawdziwej alternatywy. Dla nich jasne 404 lub 410 jest bardziej uczciwe niż przekierowanie do strony, która nie odpowiada na pytanie, na które odpowiadała stara. Przekierowanie do niepowiązanej strony jest często traktowane jako soft 404, więc nic nie ratuje.
Zapisz decyzję dla każdej grupy URLi z uzasadnieniem obok. Folder wycofanych poradników otrzyma inną odpowiedź niż folder stron z osiemdziesięcioma domenami odsyłającymi, a za sześć miesięcy będziesz chciał wyjaśnić tę różnicę koledze.
Sprawdzanie ostatniego hopu, a nie tylko pierwszego
Większość testów przekierowań zatrzymuje się przy pierwszej odpowiedzi, co jest niewłaściwym miejscem do zatrzymania. Śledź łańcuch do końca, a następnie zapisz liczbę hopów i końcowy status obok starego URLa. Łańcuch dwóch hopów nie jest uszkodzony, ale dodaje opóźnienie i jedno dodatkowe miejsce, w którym reguła może zawieść.
Jeśli skrypt jest poza zasięgiem, arkusz kalkulacyjny i kilka wywołań curl wykona swoją pracę. Strona skryptów API ma wersję, którą można zaplanować.
Mapy witryny i żądania ręczne po uruchomieniu
Zostaw starą mapę witryny dostępną przez kilka tygodni po przeniesieniu. Przeglądarki, które ponownie odwiedzą stary host, nadal mogą znaleźć te adresy na jednej liście, co przyspieszy ich pierwsze przejście przez przekierowania.
Żądania ręczne to inne narzędzie. Używaj ich dla kilku najważniejszych stron, a nie dla setek URLi wysyłanych pojedynczo. Żądana strona bez linków wewnętrznych i cienką treścią ma tendencję do ponownego usunięcia z indeksu, więc żądanie jest tak dobre, jak strona za nim.
Czekanie to poprawny plan. Daj czas na crawlowanie, a następnie oceń go na podstawie danych.
Zachowanie starej mapy witryny przez pewien czas
Zostaw starą mapę witryny w Search Console, dopóki stare URLe przestaną pojawiać się w statystykach crawlowania. Następnie usuń ją celowo i odnotuj datę w dzienniku migracji.
Nie usuwaj jej w dniu uruchomienia tylko po to, aby właściwość wyglądała na uporządkowaną. Wczesne usunięcie ukrywa jedną listę, która wymienia każdy stary URL, który nadal musisz śledzić.
Żądanie indeksowania dla stron zawierających linki
Wybierz dwadzieścia nowych URLi z największą liczbą linków zewnętrznych, używając tego samego joinu, który zbudowałeś dla mapy przekierowań, i żądaj ich ręcznie. Nakład pracy odpowiada wtedy ryzyku, a nie wielkości witryny.
Jeśli żądana strona nadal nie istnieje po kilku tygodniach, sprawdź stronę przed ponownym żądaniem. Sprawdź jej linki wewnętrzne, canonical i treść. Piąte żądanie nic nie zmieni.
Jak długo przed przeniesieniem można ocenić
Oceń przeniesienie od drugiego pobrania linków, a nie pierwszego. Nasz indeks odświeża się około raz w miesiącu, więc pobranie w dniu trzecim pokazuje głównie obraz z ubiegłego miesiąca. Uruchom drugie pobranie po odświeżeniu i użyj go do znalezienia wszystkich backlinków do witryny na nowym hoście.
Raport Stron i dane linków odpowiadają na różne pytania. Czytaj je obok siebie, a nie jako konkurujące werdykty dotyczące tego samego przeniesienia.
Pięć sprawdzeń przed uruchomieniem witryny staging
Zostaw staging poza indeksem
Umieść hasło lub listę dozwolonych adresów przed stagingiem. Reguła robots.txt sama w sobie nie powstrzyma wyszukiwarek przed indeksowaniem URLi, które już znają z linków.
Sprawdź ustawienia noindex i canonical
Otwórz szablon i ustawienia CMS i poszukaj flagi noindex lub canonical, który wskazuje inny URL. W WordPressie ustawienie widoczności wyszukiwarek to to, o czym ludzie zapominają po skopiowaniu witryny ze stagingu.
Zamień plik robots stagingu
Pobierz live robots.txt po dokonaniu przełączenia i porównaj go z plikiem, który miałeś wdrożyć. Reguły stagingu, które trafią do produkcji, mogą wykluczyć przeglądarki z całego hosta.
Uruchom test hopów na live hoście
Staging potwierdza, że mapa działa na kopii. Uruchom ponownie test jednego hopu na prawdziwej domenie po zmianach DNS, ponieważ bufor CDN lub reguła hosta mogą zachowywać się tam inaczej.
Zachowaj odpowiedź starego hosta
Zostaw starą domenę obsługującą przekierowania tak długo, jak długo jej URLe nadal otrzymują linki lub odwiedziny. Wpisz datę odnowienia w kalendarz, zanim ktokolwiek zapomni o istnieniu domeny.
Obserwacja witryny po uruchomieniu, a nie tylko przed nim
Audyt przed uruchomieniem odnotowuje, co było prawdą w dniu jego przeprowadzenia. Większość szkód po uruchomieniu ujawnia się później, po aktualizacji wtyczki, zmianie reguły CDN lub szablonie, który dotyka ustawienie, którego nikt nie sprawdził.
Traktuj nadzór po uruchomieniu jako zestaw małych różnic względem zapisanej bazy. Nie jest potrzebny dashboard. Wystarczy harmonogram i folder z plikami z datami.
Co powinna porównywać cotygodniowa obserwacja
Wybierz sprawdzenia, które najbardziej zaszkodzą, gdyby się zmieniły, i uruchamiaj je tego samego dnia każdego tygodnia.
- Kod statusu i końcowy URL dla 50 najczęściej linkowanych starych URLi
- robots.txt i tag meta robots na głównych szablonach
- Liczba aktywnych URLi 200 w porównaniu z liczbą w nowej mapie witryny
- Tagi canonical na stronie głównej, jednej kategorii i jednym artykule
Daczego jednorazowy audyt pomija powolny dryf
Ustawienia dryfują po uruchomieniu. Pozostawiona flaga testowa, wtyczka przepisująca permalinki lub przekierowanie dodane w celu naprawy jednej strony mogą cofnąć część planu. Audyt przeprowadzony w dniu uruchomienia nie może tego zobaczyć.
Zaplanowana różnica może. Przechowuj pliki bazowe w kontrolce wersji i porównuj wyniki każdego tygodnia z nimi, aby nieoczekiwana zmiana była widoczna w dniu jej wystąpienia.
Poddomeny, usunięcia i całkowite zmiany domeny witryny
Niektóre zespoły przenoszą sekcję na poddomenę i indeksują tylko jej popularne strony. Może to zadziałać. Kosztem jest to, że linki skierowane do cichszych stron teraz trafiają na host z mniejszą historią, więc policz je przed odcięciem czegokolwiek.
Żądania usunięcia są węższe, niż się wydaje. Search Console stosuje usunięcie do właściwości, w której je zgłaszasz, więc żądanie złożone na poddomenie nie działa na głównej domenie. Sprawdź właściwość najpierw. Następnie zgłoś i utrzymaj obie zweryfikowane.
Indeksowanie tylko popularnych stron na poddomenie
Zacznij od linków na URL w tej sekcji. Strony, które zawierają linki zewnętrzne, ale mało ruchu, są pierwszymi, które zasada tylko popularnych stron mogłaby ukryć. Zostaw je dostępnych do crawlowania lub przekieruj każdą z nich do najbliższej popularnej strony i zapisz przyczynę obok reguły.
Gdzie główna witryna linkuje do poddomeny, decyduje o tym, jak łatwo znaleźć jej strony. Wymień te linki przed wyborem, które strony mają pozostać ukryte, ponieważ strona, do której główna witryna nigdy nie linkuje, jest trudna do osiągnięcia w każdym przypadku.
Całkowita zmiana domeny witryny, strona po stronie
Reguła na poziomie hosta obsługuje root, ale zmiana domeny wymaga również mapy na poziomie ścieżki. Gdy pierwsza część URL się zmienia, a slug pozostaje ten sam, zamiana hosta pokrywa większość stron, a wyjątki potrzebują własnych linii.
Zbuduj listę najpierw ze stron z linkami, a następnie dopasuj każdą starą ścieżkę do nowej. Przepis na mapę przekierowań pokazuje, jak rangować tę listę według linków.
