Migracja e-commerce i SEO: checklista w 24 krokach

1. Zakres migracji i dane wyjściowe

Google zaleca, żeby w miarę możliwości zmieniać jedną rzecz naraz. Gdy jednocześnie zmienia się domena, CMS, struktura adresów, treści i design, trudno potem ustalić przyczynę spadku. Jeśli biznes wymaga szerszego zakresu, opisz każdą zmianę osobno i przypisz do niej test oraz plan powrotu.

Dane wyjściowe (baseline) trzeba zebrać przed przełączeniem. Powinny obejmować okres reprezentatywny dla sezonowości, a nie przypadkowy tydzień. Zachowaj eksporty, bo zmiany w interfejsach narzędzi i okres przechowywania danych mogą później utrudnić porównanie.

• 1. Przygotuj kartę migracji: co się zmienia, co zostaje bez zmian, kto za co odpowiada, data, rynki, domeny i systemy.
• 2. Zbierz dane wyjściowe: kliknięcia, wyświetlenia, pozycje, indeksacja, crawl, strony docelowe, konwersja, przychód, błędy 404/5xx i Core Web Vitals.

2. Inwentaryzacja: adresów jest więcej niż w sitemapie

Google wymienia sitemapę, analitykę, logi, linki i CMS jako źródła starych adresów URL. Żadne z nich osobno nie jest kompletne. Inwentaryzacja powinna objąć strony HTML, obrazy, dokumenty, zasoby, na które wchodzi ruch, dawne kampanie i adresy, których nie ma dziś w sitemapie, ale roboty wciąż je odwiedzają.

Każdy adres przypisz do typu strony i osoby odpowiedzialnej. Dzięki takiemu podziałowi łatwiej zauważyć błąd systemowy, na przykład brak wszystkich stron marek, zamiast przeglądać tysiące rekordów bez kontekstu.

• 3. Połącz adresy z sitemapy, CMS/PIM, crawla, logów, Search Console, analityki, linków zewnętrznych i kampanii.
• 4. Dla każdego adresu podejmij decyzję: zachować, scalić, przekierować, usunąć z kodem 404/410 albo wyłączyć z indeksacji.

3. Mapa adresów i przekierowania

Mapowanie adresów to decyzja o treści. Stary produkt powinien prowadzić do swojego nowego odpowiednika, następcy albo pasującej kategorii, ale tylko wtedy, gdy odpowiada to intencji użytkownika. Masowe przekierowanie wszystkiego na stronę główną jest złym doświadczeniem dla użytkownika i może zostać uznane za soft 404.

Google zaleca stałe przekierowania po stronie serwera, np. 301 lub 308, prowadzące od razu do docelowego adresu. Łańcuchy przekierowań wydłużają czas odpowiedzi i zwiększają ryzyko błędu. Reguły oparte na wzorcach są przydatne, ale najważniejsze adresy wymagają jawnego zmapowania i sprawdzenia.

• 5. Przygotuj mapę stary adres → nowy adres w relacji 1:1, z uzasadnieniem decyzji i oznaczeniem najważniejszych adresów.
• 6. Wdróż serwerowe przekierowania 301/308 prosto do adresu docelowego. Usuń pętle, łańcuchy, przekierowania przez HTTP i reguły przekierowujące wszystko na stronę główną.

4. Zgodność treści, metadanych i linkowania

Migracja platformy nie powinna przy okazji usuwać opisów kategorii, wariantów, stron marek, informacji o dostawie, opinii ani innych elementów, które pomagają klientowi w decyzji. Zgodność nie oznacza kopiowania każdego znaku. Chodzi o to, żeby strona zachowała swój cel, ważne informacje i to, że da się do niej dotrzeć.

Porównanie powinno być automatyczne dla całej inwentaryzacji i ręczne dla reprezentatywnej próbki. Sam title i nagłówek H1 to za mało. Sprawdź treść główną, linki, obrazy, teksty alternatywne, breadcrumb, warianty, dane o ofercie, canonical, robots i hreflang.

• 7. Porównaj stary i nowy szablon pod kątem title, description, H1, treści, obrazów, tekstów alternatywnych, breadcrumbów i linków wewnętrznych.
• 8. Zachowaj albo świadomie zastąp treści, warianty, pliki i media, które mają ruch, linki albo wartość dla użytkownika.

5. Renderowanie, statusy HTTP i dostępność dla robotów

Google przetwarza JavaScript w trzech etapach (crawl, renderowanie i indeksowanie) i wskazuje renderowanie po stronie serwera lub prerendering jako dobre rozwiązanie zarówno dla użytkowników, jak i dla robotów. Najważniejsza treść, linki, canonical i dane produktu powinny być widoczne w wyrenderowanej stronie, a na stronach przeznaczonych do indeksowania najlepiej już w początkowym HTML.

Nowy frontend musi zwracać statusy, które coś znaczą. Nieistniejący produkt nie może odpowiadać kodem 200 z komunikatem wyświetlanym przez aplikację. Przekierowanie powinno być prawdziwym przekierowaniem HTTP, a błędu serwera nie wolno maskować pustym szkieletem strony.

• 9. Sprawdź źródłowy i wyrenderowany HTML produktów, kategorii, marek, treści, wariantów i stron błędów.
• 10. Przetestuj kody 200, 301/308, 404/410 i 5xx. Usuń soft 404, puste szkielety aplikacji i treści, które pojawiają się dopiero po interakcji użytkownika.

6. Filtry, sortowanie, infinite scroll i paginacja

Parametry filtrów mogą wygenerować praktycznie nieskończoną liczbę adresów. Google zaleca taką strukturę adresów, dzięki której robot rozumie zależności między stronami i nie traci zasobów na bezwartościowe kombinacje. Potrzebna jest jawna lista stron filtrów przeznaczonych do indeksowania i zasady postępowania z pozostałymi.

Googlebot zwykle nie klika przycisków i nie przewija strony tak jak użytkownik. Przy infinite scroll albo przycisku „pokaż więcej” każda porcja produktów powinna mieć własny adres, do którego prowadzą zwykłe linki. Kolejne strony paginacji mają własne adresy i canonical wskazujący na siebie. Nie ustawia się na nich canonicala do pierwszej strony.

• 11. Ustal zasady dla filtrów i parametrów: które kombinacje są indeksowane, jak ustawiony jest canonical i noindex, co mogą crawlować roboty i jak wygląda linkowanie wewnętrzne.
• 12. Zadbaj o paginację dostępną dla robotów, z unikalnymi adresami i linkami href. Infinite scroll może zostać jako udogodnienie dla użytkownika, ale nie jako jedyna droga nawigacji.

7. Canonical, hreflang, sitemapa i linki wewnętrzne

Nowy adres powinien mieć canonical wskazujący na siebie, chyba że istnieje uzasadniona duplikacja. Po zmianie adresów canonical, hreflang, sitemapa i linki wewnętrzne muszą wskazywać nowe, docelowe adresy. Przekierowanie nie zastępuje poprawienia linku.

Google zaleca przygotowanie sitemapy z nowymi adresami i obserwowanie jej w Search Console. W serwisach wielojęzycznych hreflang musi być wzajemny i wskazywać nowe adresy. W sitemapie nie powinno być przekierowań, stron 404, stron z noindex ani niekanonicznych wariantów.

• 13. Zaktualizuj canonical, hreflang, linki wewnętrzne, breadcrumby, znaczniki alternate i wszystkie inne odwołania, tak żeby prowadziły do docelowych adresów.
• 14. Wygeneruj czyste sitemapy zawierające tylko nowe adresy kanoniczne ze statusem 200, podzielone na segmenty potrzebne do monitoringu.

8. Dane strukturalne, feed produktowy i spójność oferty

Dane strukturalne muszą opisywać to, co faktycznie widać na stronie. Google dokumentuje wymagania dla danych Product i Merchant listings. Poprawny składniowo JSON-LD nie wystarczy, jeśli cena, dostępność albo wariant różnią się od tego, co pokazuje interfejs.

Podczas migracji często rozjeżdżają się identyfikatory produktów na stronie, w feedzie i w systemie reklamowym. Zachowaj stałe identyfikatory, kody GTIN/MPN tam, gdzie są używane, oraz spójność wariantu, ceny, waluty, stanu magazynowego i adresu. Sprawdź zarówno poprawność techniczną, jak i zgodność z rzeczywistym produktem.

• 15. Porównaj dane strukturalne Product, Offer, Breadcrumb i Organization ze starym serwisem i z aktualną dokumentacją Google.
• 16. Uzgodnij stronę, feed produktowy i backend pod kątem identyfikatorów, wariantów, ceny, waluty, dostępności, dostawy i zasad zwrotów.

9. Bramka testowa przed uruchomieniem

Bramka testowa to lista warunków, które muszą być spełnione, zanim nastąpi przełączenie. Każdy warunek jest albo spełniony, albo nie. Stwierdzenie „SEO sprawdzone” nie jest takim warunkiem. Każdy test ma właściciela, wynik, dopuszczalną tolerancję i listę wyjątków zaakceptowanych przez osobę odpowiedzialną za ryzyko.

Żeby przecrawlować środowisko przedprodukcyjne, narzędzie musi mieć do niego dostęp, ale samo środowisko nadal powinno być chronione przed indeksacją. Przed startem przygotuj osobną, produkcyjną konfigurację robots i usuń tymczasowe noindex. Google wymienia to jako częsty problem przy migracjach.

• 17. Uruchom automatyczny crawl i porównaj wyniki z inwentaryzacją: statusy, przekierowania, canonical, robots, hreflang, dane strukturalne, linki, treści i media.
• 18. Żeby przejść bramkę, trzeba też zaliczyć testy wydajności i obciążenia, analityki, transakcji, feedów i Search Console oraz ręcznie sprawdzić próbkę stron na różnych urządzeniach.

10. Przełączenie i plan powrotu

Google radzi planować migrację na okres mniejszego ruchu i zapewnić serwerom zapas mocy na wzmożony crawl. Przełączenie (cutover) ma runbook rozpisany co do minuty: zamrożenie zmian w danych, ostatnia synchronizacja, zmiana routingu, włączenie przekierowań, szybki test najważniejszych funkcji, monitoring i decyzja, czy kontynuować, czy się wycofać.

Powrót do starego systemu musi być technicznie możliwy i zrozumiały dla biznesu. Określ moment, po którym powrót wymaga uzgodnienia nowych zamówień albo przestaje być bezpieczny. Kopia bazy danych bez procedury jej odtworzenia nie jest planem powrotu.

• 19. Przeprowadź przełączenie zgodnie z runbookiem: z osobą podejmującą decyzje, kanałem komunikacji, zamrożeniem zmian, ostatnią synchronizacją i szybkim testem krytycznych adresów oraz checkoutu.
• 20. Ustal progi, po których przekroczeniu następuje powrót, maksymalny czas na decyzję, sposób przywrócenia DNS lub routingu, synchronizację zamówień i komunikację wewnątrz firmy.

11. Monitoring po 1, 7, 30 i 90 dniach

Google zaleca obserwowanie ruchu zarówno na starych, jak i na nowych adresach. Wyszukiwarka przenosi sygnały adres po adresie, więc jedna ogólna metryka może ukryć spadek w całym segmencie. Dashboard powinien pokazywać osobno produkty, kategorie, marki, treści, wersje językowe i urządzenia.

Nie każde wahanie oznacza awarię. Porównuj wyniki z danymi wyjściowymi, sezonowością, zmianami popytu i innymi kanałami. Na błędy techniczne reaguj od razu, ale widoczność oceniaj na grupach adresów i zapytań, a nie na podstawie pojedynczej pozycji.

• 21. Dzień 1: statusy, przekierowania, robots i noindex, sitemapa, dane strukturalne, transakcje, logi Googlebota, błędy 404/5xx, feedy i alerty.
• 22. Dzień 7: crawl i indeksacja poszczególnych segmentów, porównanie starych i nowych adresów, zapytania i strony docelowe, Core Web Vitals, soft 404, pętle i nieoczekiwane parametry.
• 23. Dzień 30: trend kliknięć i przychodu w porównaniu z danymi wyjściowymi, indeksacja, canonicale wybrane przez Google, najważniejsze linki zewnętrzne i lista zaległych poprawek.
• 24. Dzień 90: zamknięcie wyjątków, utrzymanie przekierowań, przegląd TCO, podsumowanie projektu, archiwizacja starego systemu i formalny odbiór migracji.

12. Kryteria formalnego odbioru migracji

Migracja nie kończy się w momencie zmiany DNS ani po pierwszym tygodniu bez incydentów. Do odbioru trzeba zamknąć ryzyka techniczne, uzgodnić dane transakcyjne i upewnić się, że monitoring obejmuje pełny cykl. Właściciel biznesowy powinien wiedzieć, jakie wyjątki pozostały otwarte po 90 dniach.

• Inwentaryzacja starych adresów jest zachowana, a każdy rekord ma ostateczną decyzję.
• Krytyczne przekierowania działają bez pętli, łańcuchów i błędnych adresów docelowych.
• Stare adresy nadal przekierowują i nie zostały wyłączone przedwcześnie.
• Nowe strony mają właściwe statusy, canonical wskazujący na siebie, hreflang i robots.
• Zgodność treści, linków, mediów i danych strukturalnych została zatwierdzona.
• Filtry i paginacja mają spisane zasady crawlowania i indeksacji.
• Sitemapy zawierają wyłącznie docelowe, indeksowalne adresy ze statusem 200.
• Strona, dane strukturalne, feed i backend pokazują tę samą ofertę.
• Logi, Search Console, analityka i RUM są dostępne dla osób odpowiedzialnych.
• Zamówienia, płatności, leady i zdarzenia analityczne zostały uzgodnione.
• Zaległe błędy 404, 5xx, soft 404 i błędne canonicale mają właścicieli i terminy.
• Dane z 1, 7, 30 i 90 dni porównano z danymi wyjściowymi w podziale na segmenty.
• Możliwość powrotu zamknięto dopiero po zaakceptowaniu momentu, od którego nie ma odwrotu.
• Stary system ma plan przechowywania danych, archiwizacji, zabezpieczenia i wyłączenia.