Migracja strony bez utraty SEO: mapa przekierowań 301, testy i monitoring

Migracja strony nie jest jednym przekierowaniem domeny. To przeniesienie relacji między treścią, adresami, linkami, canonicalami, mapami XML, danymi analitycznymi i sygnałami wyszukiwarki. Jeżeli zespół potraktuje ją jak zmianę szablonu zakończoną w dniu publikacji, problemy pojawią się dopiero po wejściu robotów i klientów.

Nie da się uczciwie obiecać migracji bez żadnych wahań widoczności. Google uprzedza, że przy istotnej zmianie adresów wyniki mogą przejściowo się zmieniać, gdy system ponownie odwiedza i indeksuje strony. Można natomiast ograniczyć błędy, zachować drogę użytkownika i stworzyć warunki do sprawnego przeniesienia sygnałów. Służy temu jedna zasada: każdy ważny stary URL musi otrzymać świadomą decyzję i testowalny wynik.

Najpierw nazwij rodzaj migracji

Zakres kontroli zależy od tego, co się zmienia. Inne ryzyko ma wymiana hostingu bez zmiany adresów, a inne połączenie dwóch domen z nową architekturą informacji.

Najczęstsze warianty to:

• zmiana domeny lub subdomeny;
• przejście z HTTP na HTTPS albo między www i wersją bez www;
• zmiana CMS, frameworka lub sposobu renderowania;
• nowa struktura kategorii i ścieżek URL;
• połączenie kilku serwisów;
• usunięcie, scalenie lub podział treści;
• zmiana języków, regionów i oznaczeń hreflang.

Zapisz wszystkie jednoczesne zmiany. Im więcej warstw zmieniasz podczas jednego wdrożenia, tym trudniej wskazać przyczynę spadku, błędu konwersji albo wzrostu odpowiedzi 404. Jeżeli możesz bezpiecznie oddzielić zmianę platformy od przebudowy treści, zyskujesz czytelniejszy test.

Zbuduj inwentarz, zanim zaprojektujesz nowe adresy

Mapa przekierowań jest tak dobra jak lista wejściowa. Zbierz stare adresy z kilku źródeł: aktualnego crawla, map XML, danych analitycznych, Search Console, eksportu CMS oraz listy stron z linkami zewnętrznymi. Żadne pojedyncze źródło nie musi być kompletne.

Inspektor mapy strony może pomóc wyeksportować adresy zgłoszone w XML. Następnie połącz rekordy i usuń techniczne duplikaty bez tracenia informacji o źródle. Dla każdego URL warto zachować:

• status i canonical przed migracją;
• typ strony oraz język;
• ruch, konwersje i znaczenie biznesowe;
• liczbę istotnych linków wewnętrznych i zewnętrznych, jeśli dane są dostępne;
• planowany nowy adres albo decyzję o usunięciu;
• właściciela treści i status akceptacji.

Inwentarz pełni również rolę listy testowej po wdrożeniu. Bez niego zespół widzi tylko błędy, które ktoś przypadkiem zgłosił.

Mapa 301 wymaga dopasowania intencji

Najlepszym celem starego adresu jest nowa strona odpowiadająca temu samemu zadaniu użytkownika. Nie kieruj setek usuniętych produktów i artykułów na stronę główną. Google ostrzega, że masowe przekierowanie do nieistotnego celu może być potraktowane jak soft 404; użytkownik również nie znajdzie tam obiecanej informacji.

Każdy wiersz mapy powinien należeć do jednej z kategorii:

Google zaleca trwałe przekierowania serwerowe, takie jak 301 i 308, gdy zmiana jest stała. Unikaj łańcuchów: stary URL powinien prowadzić prosto do ostatecznego celu, a nie przez historię poprzednich migracji.

Pojedynczą ścieżkę możesz sprawdzić przez tester przekierowań. Przy dużej mapie potrzebny jest test automatyczny całego pliku, raportujący status każdego kroku, cel końcowy, pętle i przekroczenia czasu.

Nowa strona musi być gotowa na przyjęcie sygnałów

Przekierowanie nie naprawi nowego adresu z noindex, blokadą w robots.txt, błędnym canonicalem albo pustą treścią. Przed uruchomieniem sprawdź środowisko produkcyjne lub możliwie wierną wersję przedprodukcyjną.

Każdy nowy URL powinien:

• zwracać oczekiwany status i mieć samowskazujący canonical;
• być osiągalny z nowych linków wewnętrznych, bez przejścia przez 301;
• zawierać właściwą treść, tytuł, nagłówek i dane strukturalne;
• używać nowych adresów w hreflangach, obrazach i metadanych społecznościowych;
• znaleźć się w nowej mapie XML, jeśli jest kanoniczny i przeznaczony do indeksowania;
• zachowywać pomiar kluczowych zdarzeń i zgód.

Nie kopiuj blokady środowiska stagingowego na produkcję. Jednocześnie nie zdejmuj jej zbyt wcześnie. Lista kontrolna wydania powinna wskazywać dokładny moment zmiany noindex, reguł dostępu, DNS, przekierowań i map.

Test przed wdrożeniem powinien mieć kryteria akceptacji

„Kliknęliśmy kilka stron” nie wystarcza. Ustal mierzalne warunki:

• 100% zatwierdzonych starych adresów ma przewidziany wynik;
• każdy redirect dociera do celu w jednym skoku;
• cele przekierowań zwracają 200 i są indeksowalne zgodnie z planem;
• nie ma pętli, łańcuchów ani celów prowadzących do soft 404;
• canonicale, hreflangi i mapy używają nowego schematu adresów;
• nawigacja i treść nie zawierają starych linków wewnętrznych;
• najważniejsze formularze, koszyk, wyszukiwanie i logowanie działają;
• analityka rozpoznaje nowe hosty i nie tworzy niepożądanych odesłań własnych.

Przygotuj również plan wycofania zmian technicznych, ale nie myl go z chaotycznym cofnięciem domeny po pierwszym wahaniu raportu. Decyzja o rollbacku powinna wynikać z ustalonych błędów krytycznych, np. braku dostępu, masowych odpowiedzi 5xx albo niedziałającej płatności.

Dzień wdrożenia to początek obserwacji

Po publikacji uruchom pełny test mapy i crawl nowego serwisu. Porównaj liczbę adresów, statusy, canonicale, dyrektywy robots i linki wewnętrzne z planem. Tester niedziałających linków pomoże sprawdzić konkretną stronę, ale duży serwis wymaga kontroli całego zbioru.

Dla zmiany domeny lub subdomeny zweryfikuj stare i nowe właściwości w Search Console oraz użyj narzędzia zmiany adresu tam, gdzie Google je przewiduje. Nie służy ono do każdej zmiany ścieżki, przejścia HTTP–HTTPS ani zmiany między www i bez www. Zgłoś nową mapę XML i obserwuj indeksowanie obu zestawów adresów.

Google rekomenduje utrzymywanie przekierowań możliwie długo, ogólnie co najmniej rok. Z perspektywy użytkowników sensowne może być pozostawienie ich bezterminowo, zwłaszcza gdy stare linki nadal krążą. Jednocześnie zaktualizuj własne linki, kampanie i profile, aby nie wysyłać ruchu przez zbędny skok.

Monitoruj system, a nie jedną linię ruchu

Porównuj stare i nowe dane w warstwach:

1. dostępność: błędy 4xx/5xx, DNS, czas odpowiedzi i logi serwera;
2. crawl: wizyty robotów, odkrywanie nowych URL-i i użycie starych;
3. indeksowanie: adresy przesłane, zaindeksowane i wykluczone;
4. widoczność: zapytania, strony, kraje i urządzenia w Search Console;
5. zachowanie: landing pages, błędy aplikacji i ukończenie zadań;
6. biznes: leady, rezerwacje, transakcje i jakość danych.

Oznacz datę migracji w narzędziach i zachowaj poprzednie eksporty. Różnica rok do roku może być bardziej użyteczna niż tydzień do tygodnia, jeżeli biznes jest sezonowy. Nie przypisuj każdej zmiany migracji bez sprawdzenia kampanii, dostępności produktów i zmian popytu.

Jeżeli plan obejmuje domenę, CMS, architekturę i analitykę jednocześnie, pomocny będzie jeden właściciel mapy oraz wspólne kryteria dla SEO, developmentu i biznesu. Zakres takiego wdrożenia znajdziesz w usługach projektowych i developerskich. Możesz też opisać skalę migracji i termin, aby zacząć od inwentarza i ryzyk zamiast od samego pliku przekierowań.

Źródła

• Google Search Central: przenoszenie witryny ze zmianą adresów URL
• Google Search Central: przekierowania a wyszukiwarka
• Google Search Central: tworzenie i przesyłanie mapy witryny
• Google Search Console: narzędzie zmiany adresu