Zmiana platformy, scalenie podkatalogu lub zmiana domeny zmieniają to, które adresy URL zbierają linki. Zrób zrzut kotwic przed przeniesieniem, a następnie porównaj je po tym, jak indeks się zaktualizuje.
Zespół badawczy Anchor Social ·
Kolejność ma znaczenie
Zrób zrzut przed dniem uruchomienia. Gdy stare adresy URL zaczną przekierowywać, odtworzenie tego, co do czego linkowało, stanie się trudniejsze. Nasz indeks odświeża się około raz w miesiącu, więc obraz po przeniesieniu pojawi się za jeden do dwóch cykli. Przewodnik krok po kroku zawiera metodę pobierania i grupowania, a potrzebujesz obu końców przeniesienia w plikach.
Przed przeniesieniem
Pobierz anchors i toppages dla starej domeny i zapisz oba pliki z datą
Wypisz 50 stron, które przyciągają najwięcej linków; te wymagają przekierowań jeden-do-jeden
Oznacz kosze kotwic raz, używając tych samych zasad, których będziesz używać później
Wyeksportuj raport linków z Search Console za ten sam dzień jako drugą opinię
Określ host canonical i zachowaj spójność w mapach strony i hreflang
Znotuj każdy wzorzec adresu URL, który usuwasz, np. podkatalog /us
Zapisz kalendarz aktualizacji Google na dany miesiąc, np. aktualizacje główne i spamowe z marca 2024 roku, aby późniejsza zmiana pozycji nie była winiona tylko migracji
Stwórz mapę przekierowań przed uruchomieniem
Mapa przekierowań to część przeniesienia, która jest niedoceniana. Kierunki mają największe znaczenie. Przed analizą danych linków po przeniesieniu stare adresy URL muszą mieć jasny kierunek, ponieważ to na te adresy wskazują już Twoje linki.
Przekierowanie jeden-do-jeden wygrywa z wysypem na stronę główną
Wysłanie setek niepowiązanych starych adresów URL na stronę głównę mówi wyszukiwarkom i odwiedzającym bardzo mało. Istotność to test. Przypisz każdy stary adres URL o wysokiej wartości do najbliższej nowej strony, a pozostałe wyślij do sekcji, która nadal pasuje do ich tematyki.
Najpierw wyeksportuj stare adresy URL z ich kodami statusu. Zachowaj ten plik bezpiecznie. Ten plik to checklista i pokazuje, które strony zdobyły linki.
Gdzie strona nie ma bliskiego odpowiednika, zaznacz to w mapie i wyślij ją do najbliższej sekcji z notatką. Puste komórki ukrywają decyzje. Pusta komórka w tabeli to decyzja, której nikt nie podjął.
Spłaszcz łańcuchy przed uruchomieniem
Przekierowanie, które przechodzi przez dwa wcześniejsze reguły przed dotarciiem do nowej strony, dodaje opóźnienie i ryzyko. Łańcuchy łatwo tworzyć, gdy druga migracja nakłada się na pierwszą, więc sprawdź mapę przed każdą zmianą, zamiast zakładać, że jest nadal czysta. Każda dodatkowa przystanek kosztuje. Poproś o każdy stary adres URL raz po zmianie i potwierdź, że odpowiada jednym przystankiem.
Napraw to wcześnie. Napraw łańcuchy w samej mapie, nie jeden po drugim po uruchomieniu, aby lista pozostała krótka.
Zachowaj ścieżki, które nadal działają
Zmiana struktury adresów URL podczas redesignu to najłatwiejsza do uniknięcia strata. Każda zmiana ścieżki to również zmiana każdego linku, który do niej prowadzi, a te linki są poza Twoją kontrolą. Zachowaj to, co działa. Jeśli ścieżka nadal działa, zachowaj ją i zmieniaj tylko to, co wymusza przeniesienie.
Mniej przekierowań, mniej błędów. Każda ścieżka, którą zachowasz, to link, który nigdy nie potrzebował przekierowania.
Zachowana ścieżka oznacza, że stare wiersze kotwic nadal wskazują na coś użytecznego, co jest jedną rzeczą mniej do odbudowania w arkuszu. Mniej odbudowy później.
Czego się spodziewać po przeniesieniu
One wykonują ciężką pracę, a przekierowanie 301 ze starego na nowy adres URL pozwala starym linkom działać dalej. Zachowanie jednego przekierowania na stary adres URL, bez łańcucha między nimi, to najprostszy sposób na zachowanie wartości każdego linku. Przekierowania. Łańcuchy trzech lub czterech przystanków spowalniają crawlerów i najlepiej je spłaszczać.
Tekst kotwicy nie zmienia się, gdy adres URL się przenosi, ponieważ tekst znajduje się na stronie linkującej. Zmienia się liczba kierunków: Twoja tabela top-pages pokaże, jak stary host zanika, a nowy rośnie przez kilka miesięcznych odświeżeń. Kierunki przesuwają się powoli.
Pospolitym zaskoczeniem jest zbyt wczesne usunięcie starej platformy. Nie rób tego. Squarespace, Wix i podobne hosty często przechowują reguły przekierowań, więc anulowanie planu może je usunąć, a linki wtedy wskazują na martwy koniec, dopóki nie odbudujesz reguł gdzie indziej.
Hreflang i canonicaly również wymagają uwagi. Niedopasowania są powszechne. Po migracji z CRA do Next.js strony często kończą się z tagami canonical, które nie zgadzają się z ich zestawami hreflang, a linki dzielą się na dwie wersje strony.
Jeśli liczby nie zgadzają się po przeniesieniu, sprawdź tabelę rozwiązywania problemów przed założeniem, że linki zostały utracone. Samo miesięczne odświeżenie wyjaśnia wiele luk. Luki są często kwestią czasu.
Spodziewaj się pierwszej czystej porównania około dwa miesięczne odświeżenia po uruchomieniu i zapisz datę każdego odświeżenia w swoim arkuszu, aby pusty miesiąc nie był mylony z utknętym. Daj mu czas. Ahrefs lub Semrush mogą wypełnić lukę świeższymi crawlowaniami, jeśli potrzebujesz pośredniego odczytu.
Obserwuj, co się dzieje bez wcześniejszej zapowiedzi
Dzień premiery ma swoją listę kontrolną, ale kilka problemów pojawia się później, cicho i stopniowo. Dają o sobie znać w raportach indeksowania i w indeksie Google, długo po tym, jak zespół przeszedł do innych zadań. Łatwo je przeoczyć.
Noindex przenoszony wraz z wersją stagingową
Kopia na stagingu, która była wyłączona z indeksowania, może przenieść swoje ustawienia na stronę produkcyjną. Sprawdź tagi meta robots oraz nagłówki noindex przy pierwszym crawlowaniu i zrób próbki stron z każdej sekcji, a nie tylko ze strony głównej. Sprawdź każdą sekcję.
Szablony łamią się jako pierwsze. Jeśli cała sekcja wypadnie z indeksu po premierze, sprawdź najpierw jej szablon, zanim przeanalizujesz treść.
Przydadzą się też zrzuty ekranu. Zachowaj kopię ustawień robots z wersji stagingowej. Gdy coś wypadnie z indeksu, porównanie obu zestawów ustawień zajmie minuty, a nie popołudnie.
Linki fragmentowe indeksowane przez wyszukiwarki
Linki kotwiczne (np. do spisu treści) mogą pojawiać się w wynikach wyszukiwania jako osobne adresy URL. Wyszukiwarki zazwyczaj łączą je ze stroną główną, ale gdy tak się nie dzieje, ta sama treść może pojawiać się pod wieloma adresami. Rozdzielają one sygnały od strony głównej i mogą wyglądać na duplikaty w raporcie pokrycia. Adresy z hashem mnożą się cicho.
Jedna wersja, jeden adres. Tag canonical wskazujący na jeden adres, podczas gdy mapa strony wymienia inny, wysyła mieszane sygnały, a raport pokaże rozbieżność. Ustal jedną wersję canonical dla każdej strony i upewnij się, że mapa strony wskazuje tę samą wersję.
Sprawdź raport pokrycia po premierze pod kątem adresów URL zawierających hash, ponieważ to one mnożą się cicho. Hashe są winne.
Poddomena, która staje się domeną główną
Przeniesienie strony z poddomeny stagingowej na domenę główną generuje własne duplikaty, ponieważ obie wersje mogą przez jakiś czas pozostać dostępne. Zdecyduj, który host jest canonical przed premierą. Wybierz hosta wcześnie.
Jeden host, wszędzie. Gdy host zmienia się w jednym miejscu, a w innym nie, starsza wersja może nadal zbierać linki przez miesiące bez zauważenia tego przez nikogo. Następnie upewnij się, że mapa strony, tagi canonical oraz zestawy hreflang wskazują na ten jeden host.
Linki do-follow, które zdają się znikać
Po redesignzie wiersze z linkami do-follow w narzędziach mogą gwałtownie spaść, a pierwszą myślą jest, że linki zniknęły. Porównaj stare najlepsze strony z nowymi, zanim przyjdziesz do wniosku, że linki zniknęły, a następnie sprawdź, czy każdy stary adres przekierowuje poprawnie. Sprawdź przed paniką.
Napraw to jako pierwsze. Link, który nadal istnieje na stronie odsyłającej, ale wskazuje na martwy adres, to przypadek do naprawy jako pierwszy.
Ustal datę wcześnie. Przydziel zespołowi stałą datę do porównania, aby nikt nie uruchamiał pobierania danych codziennie i nie interpretował szumu jako nowych informacji.
Potwierdź utratę linku w czterech krokach
Wykonaj je w kolejności i zachowaj plik z pierwszego kroku do ostatniego.
1
Zapisz stare najlepsze strony
Pobierz listę toppages dla starej domeny przed premierą i zachowaj plik z datą.
2
Przetestuj stare adresy
Zażądaj każdej wysokiej wartościowo starego URL i potwierdź, że odpowiada jednym przekierowaniem do nowej strony.
3
Porównaj po jednym odświeżeniu
Pobierz kotwice i toppages dla nowej domeny po kolejnym miesięcznym odświeżeniu i porównaj według domen odsyłających.
4
Zapytaj tylko największych nadawców linków
Dla linków, które nadal wskazują na stary adres, skontaktuj się z największymi witrynami odsyłającymi i poproś o aktualizację adresu URL.
Praca z programistą podczas przenoszenia
Większość pracy nad przekierowaniami spoczywa na programiście, a monitorowanie na osobie przeglądającej arkusz. Zapisanie podziału w postaci krótkiej tabeli z jednym imieniem w każdej komórce często wystarczy, aby zapobiec sytuacji, w której dwie osoby uważają, że to ich zadanie. Podziel te role na papierze przed premierą, aby nikt nie zakładał, że drugi człowiek pilnuje spraw. Role wymagają przypisanych osób.
Daj programiście mapę, nie listę zadań
Lista zadań mówi programiście, co zrobić, podczas gdy mapa pokazuje, który stary adres prowadzi gdzie. Wyślij tabelę jedno-z-jednym z kodami statusu i przyczyną dla każdego wiersza, aby przypadki brzegowe wymagały decyzji, a nie zgadywania. Decyzje są lepsze niż zgadywanie.
Plan testów jako pierwszy. Poproś o krótki plan testów, który zaczyna się od starych adresów z pliku toppages.
Ustal, kto czyta miesięczny plik
Pierwsze czyste porównanie następuje około dwa odświeżenia po premierze, a plik będzie wymagał czytelnika. Pierwsze odczytanie po premierze jest zwykle obarczone szumem, a czytelnik, który o tym wie, uniknie reakcji na pojedynczy nietypowy miesiąc. Wyznacz tę osobę, dzień, w który go otwiera, oraz arkusz, w którym trafią wyniki. Ktoś musi to pilnować.
Daty rozstrzygają kwestię. Zapisanie daty odświeżenia obok każdego pliku zamartwiając się o zablokowany indeks w zwykły fakt kalendarzowy. Płyty miesiąc jest łatwo odczytać jako zablokowany, chyba że ktoś zapisze daty odświeżeń.
Poproś tę osobę o wpisanie jednej linijki na każde odświeżenie, nawet gdy nic się nie zmieniło, aby plik prowadził ciągły zapis. Jedna linijka za każdym razem.
Zaplanuj cofnięcie zmian przed premierą
Jeśli nowy host zepsuje krytyczną ścieżkę, zespół potrzebuje sprawdzonej z góry możliwości powrotu. Zapisz kroki, w tym kto może przełączyć przełącznik i jak zachowują się przekierowania podczas jego cofania. Odrób to przed premierą.
Zapisz plan cofnięcia. Cofnięcie, które istnieje tylko w głowie jednej osoby, nie jest planem.
