Ustal najpierw, co dokładnie migrujesz

„Migracja” to worek, do którego wrzuca się cztery bardzo różne operacje, a ryzyko każdej z nich jest inne.

• Zmiana domeny przy zachowaniu struktury adresów — najprostszy przypadek, bo mapowanie jest mechaniczne i można zgłosić zmianę adresu w Search Console.

• Zmiana platformy sklepowej bez zmiany domeny — trudniejsza, bo razem z platformą zmieniają się wzorce adresów kategorii, paginacji, filtrów i kart produktów, a często też szablony.

• Przebudowa struktury — nowe drzewo kategorii, inna nawigacja. Tu nie ma mapowania jeden do jednego i to jest źródło największych strat.

• Zmiana protokołu, subdomeny lub sposobu renderowania — adresy zostają, ale zmienia się to, co widzi robot.

Zanim ruszę cokolwiek, chcę mieć na piśmie, które z tych rzeczy dzieją się jednocześnie. Jeżeli więcej niż dwie, proponuję rozbicie na etapy — przy kilku zmianach naraz nie da się później ustalić, która odpowiada za spadek.

Przypadek, na którym najwięcej się nauczyłem

Najbardziej pouczająca migracja, w jakiej brałem udział, dotyczyła sklepu z kilkudziesięcioma tysiącami kart produktów, przenoszonego na nową platformę razem z przebudową kategorii. Nie podam nazw ani danych z konta — opiszę mechanikę, bo ona powtarza się niezależnie od branży.

Mapa przekierowań powstała dla kategorii i dla produktów aktywnych w dniu wdrożenia. Dla katalogu była kompletna. Problem polegał na tym, że ruch z wyszukiwarki przychodził też na adresy, których w katalogu już nie było: produkty wycofane, ale mające linki i historię, warianty wpięte w indeks jako osobne strony, adresy z parametrami filtrów oraz starą paginację kategorii.

Wszystko to po wdrożeniu odpowiadało błędem 404, a objawiło się nie od razu, tylko przez kolejne dwa, trzy tygodnie — Google potrzebował czasu, żeby te adresy odwiedzić i przeliczyć.

Druga rzecz była jeszcze bardziej banalna: plik produktowy przez kilka dni wskazywał stare adresy, więc kampanie produktowe prowadziły do przekierowań, a część ofert została odrzucona przy weryfikacji strony docelowej. Nikt tego nie zauważył, bo zespół pilnował SEO, a nie Merchant Center.

Wniosek jest nudny i sprawdza się do dziś: inwentaryzacja adresów nie może pochodzić z bazy sklepu. Baza wie, co jest w sprzedaży, wyszukiwarka wie, co jest zaindeksowane. To dwa różne zbiory, a migrację przeżywa ten drugi.

Inwentaryzacja przed migracją

Zbieram adresy z pięciu źródeł i traktuję je jako sumę, nie jako alternatywy.

Pierwsze to raport skuteczności w Search Console, wyeksportowany przed migracją, bo później tych danych już nie odtworzysz. Drugie to raport indeksowania, a w nim zwłaszcza adresy zaindeksowane, których nie ma w sitemapie. Trzecie to logi serwera z co najmniej trzydziestu dni — jedyne źródło pokazujące, po czym faktycznie chodzi robot. Czwarte to crawl własnym narzędziem, dla struktury linkowania. Piąte to plik produktowy i adresy docelowe z kampanii.

Do tego jedna lista, o której łatwo zapomnieć: adresy z linkami z zewnątrz. Nawet jeśli strona dawno nie istnieje w katalogu, link do niej wciąż przekazuje wartość.

Z tego wszystkiego robię jeden arkusz z kolumną priorytetu. Adresy z ruchem i linkami mapuję ręcznie, reszta idzie regułą — przy dziesiątkach tysięcy adresów nie ma innego wyjścia.

Mapa przekierowań przy dużej skali

Przy dużej witrynie mapa przekierowań to nie tabela, a zestaw reguł plus tabela wyjątków. Reguły obsługują powtarzalne wzorce adresów, tabela — wszystko, co nie mieści się w schemacie.

Zasady, których nie odpuszczam: przekierowania stałe, jeden do jednego, do najbliższego sensownego odpowiednika i nigdy hurtem na stronę główną. Jeżeli kategoria zniknęła, celem jest kategoria nadrzędna, a nie wyniki wyszukiwania w sklepie. Żaden łańcuch nie może mieć więcej niż jednego skoku — przy sklepie z historią wcześniejszych zmian adresów to najczęstszy problem, bo nowa reguła nakłada się na starą.

Osobno pilnuję wydajności. Kilkadziesiąt tysięcy reguł w pliku konfiguracyjnym serwera potrafi położyć czas odpowiedzi, a to widać i w statystykach indeksowania, i w Core Web Vitals. Reguły trzymam więc w bazie lub w mapie z indeksem, nie w liniowej liście warunków.

Warto też pamiętać, że narzędzie do obsługi parametrów URL Google wyłączył w kwietniu tego roku i w Search Console nie ma już panelu do deklarowania, które parametry ignorować. Zostaje adres kanoniczny, robots.txt i architektura linkowania, więc decyzję o filtrach i sortowaniu trzeba podjąć przed wdrożeniem.

Google Ads, Merchant Center i analityka

Migracja bywa prowadzona wyłącznie jako projekt SEO i to jest błąd, który kosztuje najszybciej — bo w kampaniach skutki widać w godzinach, nie w tygodniach.

• Plik produktowy aktualizowany w tym samym okienku serwisowym co przekierowania, z adresami prowadzącymi wprost do nowych stron.

• Docelowe adresy w kampaniach — reklamy, rozszerzenia, szablony śledzenia. Zmiana strony docelowej oznacza ponowną weryfikację, lepiej zrobić to świadomie, niż odkryć wstrzymane reklamy w poniedziałek rano.

• Tagi konwersji i kod analityczny sprawdzone na środowisku testowym — brak tagu na stronie podziękowania odcina strategie automatyczne od danych.

• Weryfikacja witryny i deklaracja adresu w Merchant Center przy zmianie domeny, bez tego oferty przestaną się wyświetlać niezależnie od stanu SEO.

Skoro wyłączenie Universal Analytics zapowiedziano na 1 lipca przyszłego roku, wiele sklepów zbiera już dane równolegle w GA4 — przy migracji trzeba przenieść oba wdrożenia i sprawdzić wykluczenia ruchu wewnętrznego. Warto też zapisać datę wdrożenia w notatce do danych.

Dzień wdrożenia i pierwsze siedemdziesiąt dwie godziny

Wdrożenie planuję na okres najniższego ruchu i nigdy w piątek. Nie chodzi o wygodę, a o to, żeby ktokolwiek kompetentny był dostępny, gdy trzeba wycofać zmianę.

Kolejność jest zawsze taka sama: nowa witryna z odblokowanym robots.txt, natychmiast po niej przekierowania, potem nowa sitemapa zgłoszona w Search Console, na końcu zgłoszenie zmiany adresu, jeśli zmienia się domena. Najczęstszy wypadek na tym etapie to blokada indeksowania przeniesiona ze środowiska testowego na produkcję — robots.txt i znaczniki noindex sprawdzam więc jako pierwszą rzecz po wdrożeniu.

Przez pierwsze trzy dni patrzę na kody odpowiedzi dla priorytetowych adresów, czas odpowiedzi serwera, statystyki indeksowania w Search Console i liczbę adresów zwracających 404 w logach. Pojedyncze strony sprawdzam narzędziem kontroli adresu URL — wyłapuje różnice między tym, co renderuje przeglądarka, a tym, co dostaje Google.

Warto mieć też zapisany warunek wycofania zmian, ustalony z klientem wcześniej — bez tego dyskusja o cofnięciu migracji toczy się pod presją i kończy zwykle decyzją, żeby jeszcze poczekać.

Monitoring przez kolejne tygodnie i checklist

Widoczność po migracji nie wraca liniowo. Normalne jest wahanie w pierwszych dwóch, trzech tygodniach — Google musi odwiedzić stare adresy, zobaczyć przekierowania i przeliczyć sygnały. Niepokojące jest to, co się nie odwraca po miesiącu, i to, co widać na poziomie pojedynczych adresów, a nie całej witryny.

Jest jednak okoliczność, która utrudnia ocenę właśnie teraz. We wrześniu zakończyło się wdrożenie September 2022 core update, a nachodziła na nie osobna aktualizacja dotycząca opinii o produktach; w sierpniu doszedł Helpful Content Update. Migracja wypadająca w takim okresie sprawia, że przypisanie zmian widoczności samej przeprowadzce jest zgadywaniem. Dlatego sprawdzam, czy termin wdrożenia nie trafia w potwierdzone okno aktualizacji algorytmu — a jeśli trafił, opisuję oba zdarzenia w raporcie osobno.

Na koniec lista, którą odhaczam przy każdej migracji:

• Eksport adresów z raportu skuteczności, raportu indeksowania, logów, crawla i pliku produktowego — przed wdrożeniem.

• Mapa przekierowań: reguły plus wyjątki, jeden skok, bez przekierowań na stronę główną.

• Adresy kanoniczne, hreflang i dane strukturalne produktów sprawdzone na środowisku testowym.

• Linki wewnętrzne, menu i sitemapa wskazujące nowe adresy, nie przekierowania.

• Tagi konwersji, adresy docelowe kampanii i plik produktowy zmienione w tym samym okienku.

• robots.txt i noindex sprawdzone bezpośrednio po wdrożeniu, sitemapa i zmiana adresu zgłoszone w Search Console.

• Monitoring kodów odpowiedzi, czasu odpowiedzi i logów przez trzy dni, potem tygodniowo przez kwartał.

• Stare przekierowania utrzymywane co najmniej rok — linki z zewnątrz nie aktualizują się same.