Lista kontrolna SEO przy migracji strony

Migracja strony to kontrolowana zmiana platformy, domeny, protokołu, architektury informacji, struktury adresów URL lub systemu renderowania witryny. Jest zakończona tylko wtedy, gdy użytkownicy, roboty wyszukiwarek i analityka mogą dotrzeć do zamierzonych treści poprzez stabilne trasy, a zespół może udowodnić, że wartościowa widoczność została zachowana.

Lista kontrolna: SEO przy migracji strony. Ramy czasowe: rozpocznij 6–12 tygodni przed uruchomieniem dla średniej wielkości witryny; zarezerwuj ostatnie 5 dni roboczych na zamrożenie zmian, dzień uruchomienia na obsadzoną walidację i co najmniej 4 tygodnie na aktywne monitorowanie. Właściciel: jeden lider migracji odpowiedzialny za całe wdrożenie, wspierany przez wyznaczonych właścicieli z obszarów inżynierii, SEO, analityki, treści i infrastruktury.

Dlaczego ta lista kontrolna istnieje i dlaczego jest tutaj

Ta warstwa kontroli wdrożenia w procesie SEO wykorzystuje dowody z przeszukiwania i indeksowania z audytu bazy technicznej , decyzje o zachowaniu/scaleniu/usunięciu z inwentaryzacji i audytu treści oraz hierarchię docelową z mapy tematycznej i architektury informacji . Te wyniki muszą istnieć, zanim można ocenić przekierowania lub środowisko staging.

Wykonaj ją po zatwierdzeniu docelowej struktury, ale przed zamrożeniem produkcyjnych tras. Jeśli zostanie wykonana wcześniej, zespół mapuje przekierowania do miejsc docelowych, które mogą się jeszcze zmienić. Jeśli zostanie wykonana później, routing, szablony, analityka lub komunikacja uruchomieniowa mogą być już zbyt kosztowne, aby bezpiecznie je poprawić.

Mapa przekierowań jest artefaktem o najwyższym ryzyku, ponieważ łączy stare trasy z nowymi. Każdy wartościowy stary adres URL powinien być kierowany jeden-do-jednego do najbliższego miejsca docelowego, które zachowuje jego cel. Nigdy nie używaj strony głównej jako uniwersalnego kosza: frustruje to odwiedzających i maskuje brakujące miejsca docelowe.

Wejścia i wyjścia

Wyniki są kontraktem z operacjami uruchomieniowymi. Arkusz kalkulacyjny bez właścicieli, dowodów i warunków akceptacji nie jest przekazaniem.

Lista kontrolna

Każda pozycja określa co, dlaczego, jak, narzędzie i obserwowalny warunek ukończenia. Zastąp próg tylko ostrzejszą regułą lub udokumentowaną regułą opartą na bazie.

Faza 1: inwentaryzacja przed migracją

1. Zbuduj scalony spis adresów URL. Co: połącz wszystkie możliwe do odkrycia stare adresy URL z przeszukiwań, map XML, analityki, Search Console, eksportów linków zwrotnych, rekordów CMS, płatnych kampanii i logów serwera. Dlaczego: żadne pojedyncze źródło nie zawiera każdego wartościowego lub żądanego adresu URL; strona nieobecna w nawigacji może nadal mieć linki, ruch lub znaczenie umowne. Jak: znormalizuj protokół, host, wielkość liter, końcowy ukośnik, parametry i zakodowane znaki, zachowując surową wartość źródłową. Deduplikuj dopiero po zarejestrowaniu, gdzie znaleziono każdy adres URL. Narzędzie: crawler, eksport CMS, analityka, Search Console, dane o linkach zwrotnych i logi. Warunek ukończenia: każde źródło ma datę, każdy wiersz ma znormalizowany adres URL i źródło odkrycia, duplikaty są rozwiązane, a sumy źródeł zgadzają się z końcowym spisem.

2. Sklasyfikuj przeznaczenie każdego adresu URL. Co: oznacz każdy adres URL jako zachowaj, przenieś, scal, usuń lub zbadaj. Dlaczego: przekierowania nie mogą być poprawnie mapowane, dopóki decyzja dotycząca treści nie jest jawna. Jak: połącz ruch, konwersje, linki zwrotne, stan indeksowania, jakość treści, potrzebę biznesową i intencję; zapisz dowód i zatwierdzającego właściciela. Narzędzie: arkusz spisu i audyt treści. Warunek ukończenia: 100% adresów URL w zakresie ma jedno przeznaczenie, właściciela, miejsce docelowe lub powód usunięcia, a żaden nierozwiązany wiersz „do zbadania” nie pozostaje w momencie zamrożenia.

3. Przechwyć podpisaną bazę. Co: zachowaj przeduruchomieniowe organiczne sesje, kliknięcia, wyświetlenia, konwersje, przychody, zaindeksowane adresy URL, błędy przeszukiwania, kody odpowiedzi, czas działania i wydajność dla priorytetowych szablonów i katalogów. Dlaczego: bez datowanego punktu porównawczego normalne wahania i szkody migracyjne wyglądają tak samo. Jak: wyeksportuj co najmniej 28 porównywalnych dni, opisz kampanie i sezonowość oraz zidentyfikuj priorytetowe adresy URL wymagające codziennego przeglądu. Narzędzie: analityka, Search Console, crawler, dane o pozycjach i monitorowanie. Warunek ukończenia: baza jest tylko do odczytu, powtarzalna, segmentowana, oznaczona znacznikiem czasu i zatwierdzona przez właścicieli SEO i analityki.

Faza 2: mapowanie przekierowań

4. Mapuj źródła jeden-do-jednego, gdzie to możliwe. Co: przypisz każdy przeniesiony lub scalony stary adres URL do najbliższego nowego adresu URL o tej samej podstawowej intencji. Dlaczego: precyzyjne miejsce docelowe zachowuje ciągłość dla odwiedzającego i daje robotom wyszukiwarek spójny sygnał zastępczy. Jak: porównaj temat, produkt, lokalizację geograficzną, język i zadanie; mapuj scalenia do zachowanej strony i udokumentuj celowe usunięcia. Nigdy nie mapuj niepasujących adresów URL do strony głównej. Narzędzie: arkusz mapy przekierowań, spis i przeszukanie miejsc docelowych. Warunek ukończenia: każde zmieniające się źródło ma dokładnie jeden zatwierdzony wynik, każde miejsce docelowe jest odpowiednie i w zakresie, a mapowania typu „strona główna jako kosz” są zerowe.

5. Zweryfikuj mechanikę przekierowań przed uruchomieniem. Co: przetestuj kody statusu, miejsca docelowe, zachowanie parametrów, warianty wielkości liter, protokół, subdomeny, końcowe ukośniki, pliki i adresy URL kampanii. Dlaczego: poprawnie wyglądający arkusz kalkulacyjny może nadal generować pętle, łańcuchy, symbole wieloznaczne połykające prawidłowe strony lub miejsca docelowe zwracające błędy. Jak: wygeneruj reguły stagingu lub proxy, zażądaj każdego źródła, podążaj za skokami i porównaj końcowy adres URL z zatwierdzoną mapą. Narzędzie: zautomatyzowany test HTTP, crawler i przegląd konfiguracji serwera. Warunek ukończenia: 100% zamapowanych źródeł dociera do zatwierdzonego miejsca docelowego z kodem 200 w jednym trwałym skoku przekierowania; pętle, łańcuchy, tymczasowe przekierowania i miejsca docelowe z błędami są zerowe.

6. Uzgodnij kanonikale, linki i mapy witryn z przekierowaniami. Co: spraw, aby kanoniczny adres URL , linki wewnętrzne, odniesienia hreflang, dane strukturalne, kanały i mapy XML wskazywały bezpośrednio na końcowe adresy URL. Dlaczego: przekierowywanie starych adresów URL przy jednoczesnym dalszym ich publikowaniu tworzy sprzeczne sygnały migracyjne i marnuje żądania robotów. Jak: przejrzyj każde źródło odniesienia i porównaj znormalizowane cele z mapą przekierowań. Narzędzie: crawler, renderowany HTML, parser map witryn i porównanie konfiguracji. Warunek ukończenia: końcowe strony samokanoniczują się, chyba że zatwierdzony wyjątek stanowi inaczej, wewnętrzne odniesienia do przekierowanych adresów URL są zerowe, a nowe mapy witryn zawierają tylko kanoniczne adresy URL z kodem 200.

Faza 3: walidacja stagingu

7. Przetestuj staging bez udostępniania go do indeksowania. Co: przejrzyj całe wdrożenie stagingowe, zapobiegając jednocześnie indeksowaniu środowiska przez wyszukiwarki. Dlaczego: zespół potrzebuje dowodów na poziomie crawlera bez dopuszczania duplikatu witryny do wyników wyszukiwania. Jak: użyj kontroli dostępu dla zewnętrznych robotów, a następnie uruchom uwierzytelnione wewnętrzne przeszukiwanie z renderowaniem JavaScript, jeśli witryna produkcyjna jest od niego zależna. Traktuj blokadę stagingu jako tymczasową konfigurację wdrożenia, a nie coś do ślepego kopiowania na produkcję. Narzędzie: uwierzytelniony crawler, przeglądarka i inspekcja nagłówków odpowiedzi. Warunek ukończenia: oczekiwany spis stagingu jest przeszukiwalny przez zespół testujący, nieautoryzowane publiczne indeksowanie jest zablokowane, a lista kontrolna uruchomienia produkcyjnego wyraźnie usuwa ograniczenia stagingowe.

8. Zweryfikuj szablony i priorytetowe ścieżki. Co: przetestuj reprezentatywne strony z każdego szablonu plus nawigację, wyszukiwanie, formularze, rejestrację, realizację zamówienia, lokalizację, paginację, filtry i strony błędów. Dlaczego: zaliczenie strony głównej nie ujawni błędu kanonikala na stronach produktów ani zepsutego stanu zgód, który tłumi analitykę. Jak: stwórz macierz urządzeń i szablonów, przetestuj czyste i powracające sesje oraz zapisz zrzuty ekranu lub dowody odpowiedzi dla każdego wyniku. Narzędzie: przeglądarka, narzędzie do sprawdzania dostępności, walidator danych strukturalnych, debuger analityki i testy transakcji. Warunek ukończenia: każdy szablon w zakresie i każda podstawowa ścieżka przechodzą na uzgodnionych przeglądarkach i urządzeniach, z zerową liczbą krytycznych defektów.

9. Porównaj staging z zatwierdzonymi kontraktami. Co: porównaj tytuły, opisy, nagłówki, kanonikale, dyrektywy robotów, dane strukturalne, linki wewnętrzne, kody odpowiedzi, treści i tagi analityczne ze starą witryną i specyfikacją docelową. Dlaczego: migracje platform często tracą metadane lub zmieniają renderowanie, nawet gdy widoczna kopia wydaje się nienaruszona. Jak: przejrzyj starą produkcję i staging z dopasowanymi ustawieniami, segmentuj różnice według szablonu i zatwierdzaj tylko zamierzone zmiany. Narzędzie: raport porównania przeszukań i inspekcja źródła. Warunek ukończenia: każda istotna różnica jest albo poprawiona, albo wymieniona jako zatwierdzona zmiana z właścicielem i powodem; przypadkowe zmiany noindex, kanonikali, treści i śledzenia są zerowe.

10. Zamroź kandydata do wdrożenia. Co: zamroź spis adresów URL, mapę przekierowań, definicje tras, reguły kanonikali i robotów, generowanie map witryn, konfigurację analityki i zgód, plan DNS/CDN oraz niezwiązane wdrożenia produkcyjne. Dlaczego: wynik testu dotyczy tylko testowanej wersji. Jak: oznacz artefakty wdrożenia, ogranicz zmiany do ścieżki incydentów i wymagaj ponownego testowania wszystkiego, czego dotknęła edycja awaryjna. Narzędzie: system wdrożeń, dziennik zmian i rejestr zatwierdzeń. Warunek ukończenia: jeden niezmienny kandydat jest nazwany, dostęp jest ograniczony, wszystkie wyjątki mają właściciela, a każda zmiana po zamrożeniu niesie ze sobą wynik testu.

Faza 4: dzień uruchomienia

11. Wykonaj jeden zarządzany runbook. Co: wdróż routing, aplikację, DNS/CDN, analitykę, mapy witryn i monitory w zatwierdzonej kolejności. Dlaczego: równoległe, niesekwencyjne zmiany utrudniają izolowanie awarii i sprawiają, że wycofanie jest niebezpieczne. Jak: jeden lider migracji wydaje każde polecenie, wyznaczony operator rejestruje wykonanie, a osoby walidujące testują dowody przed kolejnym zależnym krokiem. Narzędzie: runbook, logi wdrożenia, kontrole DNS i współdzielony kanał incydentów. Warunek ukończenia: każda linia ma rzeczywisty czas, operatora, wynik i link do dowodu, a żadna zależność nie jest oznaczona jako wykonana wyłącznie na podstawie ustnego zapewnienia.

12. Przeprowadź test dymny uruchomienia. Co: przetestuj stronę główną, plik robots, mapy witryn, co najmniej jeden adres URL na szablon, każdą priorytetową ścieżkę, odbiór analityki oraz stratyfikowaną próbkę źródeł przekierowań. Dlaczego: najszybsza bezpieczna odpowiedź pochodzi z wykrycia szerokiej awarii, zanim pamięci podręczne i roboty ją rozprzestrzenią. Jak: testuj spoza sieci produkcyjnej, używaj wersji desktopowej i mobilnej, zweryfikuj zarówno HTML dostarczony przez serwer, jak i renderowane wyjście oraz porównaj z zamrożonymi oczekiwaniami. Narzędzie: crawler, przeglądarka, klient HTTP, widok analityki w czasie rzeczywistym i monitor transakcji. Warunek ukończenia: krytyczne strony zwracają zamierzony status i treść, priorytetowe przekierowania docierają do dokładnych miejsc docelowych, zdarzenia analityki docierają z poprawnymi adresami URL, a wszystkie blokujące uruchomienie kontrole przechodzą.

13. Prześlij i zweryfikuj sygnały odnajdywania. Co: opublikuj ostateczne mapy witryn, potwierdź zachowanie robotów i kanonikali oraz zażądaj inspekcji dla małego zestawu priorytetowych adresów URL. Dlaczego: czyste sygnały odnajdywania pomagają robotom wyszukiwarek trafić na zestaw docelowy, bez traktowania przesłania jako gwarancji indeksowania. Jak: prześlij każdą mapę produkcyjną raz, sprawdź reprezentatywne nowe adresy URL i zapisz zgłoszony przez Google kanonikal i stan indeksowania. Narzędzie: Mapy witryn i indeksowanie oraz Inspekcja adresu URL . Warunek ukończenia: mapy witryn są osiągalne i zawierają zamrożony kanoniczny spis, reprezentatywne inspekcje nie wykazują blokady produkcyjnej ani błędnego kanonikala, a każde ostrzeżenie ma właściciela.

Faza 5: monitorowanie po uruchomieniu

14. Obserwuj pierwsze 72 godziny jako okno incydentów. Co: monitoruj czas pracy, błędy 5xx, 4xx, awarie przekierowań, opóźnienia, wolumen przeszukiwania, odbiór analityki, konwersje, przetwarzanie map witryn i priorytetowe ścieżki w sposób ciągły lub w najkrótszym praktycznym interwale. Dlaczego: defekty infrastruktury i routingu ujawniają się szybko, podczas gdy wydajność wyszukiwania wymaga więcej czasu i nie powinna być jedynym alarmem uruchomieniowym. Jak: porównaj z podpisaną bazą, segmentuj według szablonu i katalogu oraz kieruj alerty do dyżurnego właściciela. Narzzędzie: logi, analityka, crawler, Monitory czasu pracy i panel incydentów. Warunek ukończenia: panel nie ma niewyjaśnionego krytycznego alertu uruchomieniowego, każdy incydent ma właściciela i znacznik czasu, a przeglądy po 24, 48 i 72 godzinach są podpisane.

15. Kontynuuj monitorowanie wyszukiwania i indeksowania po osiągnięciu stabilności. Co: śledź kliknięcia, wyświetlenia, stan indeksowania, wybrane kanonikale, błędy przeszukiwania, wydajność katalogów i wyniki konwersji na poziomie strony przez co najmniej cztery tygodnie. Dlaczego: przeszukiwanie, wybór kanonikala i zastąpienie w indeksie są opóźnione w stosunku do walidacji infrastruktury. Jak: porównuj podobne okna czasowe, oddziel przeniesione adresy URL od niezmienionych kontrolnych i badaj klastry, zamiast reagować na jeden dzienny wynik całkowity. Narzędzie: Strony Google Search , Widok katalogu , Inspekcja adresu URL, analityka i logi. Warunek ukończenia: priorytetowe miejsca docelowe są odkrywalne i indeksowalne, stare adresy URL konsekwentnie rozwiązują się do zatwierdzonych miejsc docelowych, niewyjaśnione straty mają zgłoszenia, a odpowiedzialność przechodzi do normalnego rytmu raportowania.

Narzędzia w AmICited

AmICited dostarcza dowody uruchomienia i powierzchnie monitorowania; zatwierdzona mapa przekierowań i logi wdrożenia pozostają operacyjnym źródłem prawdy.

Reguły decyzyjne

Są to zabezpieczenia wdrożenia, a nie uniwersalne progi wyszukiwarek. Uzgodnij je przed uruchomieniem i zaostrz tam, gdzie wymaga tego ryzyko.

Wycofanie przywraca znany dobry stan usługi; nie cofa zwykłych wahań wyszukiwarki. Osoba zatwierdzająca uruchomienie stosuje uzgodnione reguły i rejestruje dowody.

Produkt końcowy

Przekaż jeden wersjonowany pakiet kontroli migracji dostępny dla działów inżynierii i SEO. Użyj arkusza kalkulacyjnego lub bazy danych do rejestrów na poziomie wierszy, runbooka do działań uruchomieniowych i pulpitu do pomiarów na żywo.

Musi zawierać zamrożony spis i uzgodnienie źródeł; zatwierdzoną mapę przekierowań z właścicielami i testami; dopasowane przeszukania starej, stagingowej i nowej wersji; porównania metadanych, kanonikali, robotów, map witryn, hreflang, danych strukturalnych, linków i analityki; podpisaną bazę i kohorty priorytetowe; runbook uruchomieniowy i procedurę odzyskiwania; numeryczne reguły wycofania i osobę decyzyjną; oraz dowody z 24, 48 i 72 godzin z czterotygodniowym właścicielem monitorowania.

Lider migracji musi być w stanie zidentyfikować dokładne wdrożenie, udowodnić każdy krytyczny test, odtworzyć każdą decyzję routingu i przypisać każdy wyjątek. W przeciwnym razie pakiet jest niekompletny.

Co idzie źle

Mapa przekierowań wykorzystuje tylko bieżącą mapę witryny. Porzucone strony, adresy URL kampanii, linki zwrotne i wcześniej zaindeksowane trasy znikają, więc każdy wiersz arkusza przechodzi, podczas gdy rzeczywiste żądania zawodzą.

Strona główna staje się domyślnym miejscem docelowym. Użytkownicy trafiają w nieodpowiednie miejsce, sygnały dla robotów stają się niejednoznaczne, a brakująca treść jest maskowana jako postęp wdrożenia.

Przekierowania działają, ale odniesienia pozostają stare. Nawigacja, hreflang, kanonikale, dane strukturalne i mapy witryn nadal wysyłają roboty przez niepotrzebne skoki i sprzeczne miejsca docelowe.

Ochrona stagingu trafia na produkcję. Skopiowany noindex, reguła uwierzytelniania, blokada robotów lub polityka CDN niszczy indeksowalność . Wymagaj jawnego kroku usunięcia i testu zewnętrznego.

Zespół waliduje tylko stronę główną. Współdzielony szablon może nieprawidłowo skonfigurować tysiące stron, podczas gdy strona główna przechodzi. Sprawdź każdy szablon i przeszukaj reguły na dużą skalę.

Niezwiązane wdrożenia są publikowane razem. Gdy platforma, analityka, zgody, nawigacja, realizacja zamówienia i zmiany CDN dzielą to samo okno, awarie stają się trudne do izolowania lub cofania.

Wyniki wyszukiwania są oceniane zbyt wcześnie lub zbyt ogólnie. Sumy witryny ukrywają uszkodzone katalogi, a jeden zmienny dzień powoduje niepotrzebne poprawki. Porównuj przeniesione kohorty, niezmienione grupy kontrolne, katalogi i dopasowane okna czasowe.

Debata o wycofaniu toczy się podczas awarii. Dobry plan określa progi, osobę decyzyjną, czas odzyskiwania, polecenia, konsekwencje danych i sekwencję walidacji przed uruchomieniem.

Następna faza

Gdy pierwsze 72 godziny są stabilne, kolejnym krokiem jest ciągłe odświeżanie i iteracja . Wymaga ono podpisanej bazy, końcowego mapowania URL, adnotacji uruchomieniowych, kohort katalogów, znanych wyjątków, historii incydentów i nazwanych właścicieli z tej listy kontrolnej. Bez tych danych wejściowych późniejszy spadek ruchu nie może być wiarygodnie oddzielony na szkody migracyjne, normalną zmianę popytu, degradację treści lub awarię pomiaru.

Zachowaj mapę przekierowań i adnotacje migracyjne na stałe. Przenieś niekrytyczne ustalenia do normalnego rytmu raportowania z kategorią ważności, hipotezą, właścicielem, terminem i metodą weryfikacji.

Często zadawane pytania

Kiedy zespół SEO powinien dołączyć do migracji strony?

Zanim trasy, szablony i ograniczenia platformy zostaną ustalone. SEO potrzebuje wystarczająco dużo czasu, aby zinwentaryzować obecne adresy URL, zachować wartościowe miejsca docelowe, wpłynąć na nową architekturę informacji, zdefiniować zachowanie przekierowań oraz uzgodnić mierzalne zasady uruchomienia i wycofania.

Czy stare adresy URL powinny przekierowywać do strony głównej, gdy nie ma bezpośredniego zamiennika?

Nie. Przekieruj stary adres URL do najbliższej strony, która spełnia tę samą intencję użytkownika. Jeśli nie istnieje żadne odpowiednie miejsce docelowe, a treść nie powinna być zachowana, zwróć uczciwy kod 404 lub 410, zamiast wysyłać użytkowników i roboty wyszukiwarek do niepowiązanej strony głównej.

Jak długo przekierowania migracyjne powinny pozostać aktywne?

Utrzymuj trwałe przekierowania tak długo, jak stare adresy URL mogą nadal otrzymywać wizyty, linki, zakładki lub żądania robotów. Traktuj je jako trwałą infrastrukturę routingu, a nie rusztowanie uruchomieniowe do usunięcia po kilku tygodniach.

Co należy zamrozić przed uruchomieniem migracji?

Zamroź zatwierdzony spis adresów URL, mapę przekierowań, reguły kanonikali i robotów, generowanie mapy witryny, konfigurację analityki i zgód, zmiany DNS i CDN oraz niezwiązane publikacje produkcyjne. Naprawy awaryjne podlegają nazwanej ścieżce kontroli zmian.

Kiedy należy wycofać migrację?

Użyj kryteriów uzgodnionych przed uruchomieniem. Wycofaj w przypadku awarii, takich jak długotrwała niedostępność, powszechne odpowiedzi 5xx, przerwane główne ścieżki użytkownika, brak analityki lub defekty routingu wpływające na istotną część priorytetowych adresów URL, których nie można bezpiecznie naprawić w uzgodnionym oknie naprawczym.