Migracja sklepu na nową platformę wygląda na projekt czysto techniczny, a rozlicza się z niej dział marketingu. Powód jest prosty: w dniu przełączenia zmienia się jednocześnie struktura adresów, szablon strony, sposób generowania danych produktowych i konfiguracja serwera. Jeśli którykolwiek z tych elementów wypadnie spod kontroli, spadek widoczności widać w Search Console w ciągu kilku dni, a odbudowa zajmuje cały kwartał.
Poniższa checklista migracji sklepu porządkuje trzydzieści punktów kontrolnych w kolejności, w jakiej realnie się je wykonuje: od inwentaryzacji, przez dzień przełączenia, po monitoring długoterminowy. Zasada nadrzędna brzmi: czego nie zmierzyłeś przed migracją, tego nie obronisz po niej. Jeżeli przenosisz sam WordPress bez zmiany silnika sklepu, szybsza będzie węższa procedura opisana w tekście o migracji WordPressa na nowy hosting.
Inwentaryzacja przed migracją
Ten etap zaczyna się na cztery do sześciu tygodni przed przełączeniem. Jego celem jest jedno: mieć zamrożony obraz stanu sprzed migracji, do którego można wrócić w sporze o przyczynę spadku.
- Pełny crawl starego sklepu zapisany do pliku: adres, kod odpowiedzi, tytuł, opis, kanoniczny, status indeksowania. To jest punkt odniesienia dla wszystkich późniejszych porównań.
- Eksport wszystkich adresów z sitemapy oraz osobno z logów serwera za ostatnie 90 dni. Logi wyłapią adresy, których nie ma w sitemapie, a które Googlebot regularnie odwiedza.
- Eksport danych z Search Console w podziale na stronę, zapytanie i kraj, za pełne 16 miesięcy. Po migracji ten zakres już nie będzie dostępny w tej samej formie.
- Lista 200 adresów o największej liczbie kliknięć i osobno lista adresów z linkami zewnętrznymi. To one dostają priorytet w mapowaniu przekierowań i w testach po wdrożeniu.
- Inwentaryzacja treści niekatalogowych: wpisy blogowe, poradniki zakupowe, strony informacyjne, landingi kampanijne. Ta grupa ginie w migracjach najczęściej, bo nie ma jej w eksporcie produktów. Pomocny będzie szablon audytu treści w Arkuszach Google, w którym od razu oznaczysz, co przenosisz, co scalasz, a co usuwasz świadomie.
- Zrzut konfiguracji: robots.txt, reguły hreflang, tagi analityczne, kody weryfikacyjne, ustawienia paginacji i filtrów. Na nowej platformie żadna z tych rzeczy nie przenosi się sama.
Mapowanie adresów i przekierowania
Mapowanie to najdroższy i najbardziej pracochłonny element migracji. Jest też jedynym, którego nie da się naprawić szybko po fakcie, bo utracone sygnały wracają miesiącami.
- Arkusz mapowania 1 do 1: stary adres, nowy adres, typ strony, właściciel decyzji. Bez kolumny z typem strony nie zauważysz, że cała kategoria trafiła w jedno miejsce.
- Zero przekierowań zbiorczych na stronę główną. Produkt bez odpowiednika kierujemy do kategorii nadrzędnej albo do produktu zastępczego, nigdy do home.
- Przekierowania 301, nie 302 i nie meta refresh. Google traktuje przekierowanie stałe jako silny sygnał kanoniczny, co opisuje dokumentacja Google Search Central.
- Brak łańcuchów przekierowań. Jeśli stary sklep miał już własne reguły, nowa mapa musi kierować od adresu źródłowego wprost do docelowego, bez przeskoków pośrednich.
- Spójność ze slashem końcowym i z wielkością liter. Jedna kanoniczna forma adresu, reszta przekierowana. Ten punkt generuje potem najwięcej zduplikowanych wyników w indeksie.
- Test mapy na środowisku testowym przed przełączeniem: automatyczny przebieg po całej liście i raport pokazujący każdy kod odpowiedzi inny niż 301 z docelowym 200.
Dane produktowe i warianty
Nowe platformy inaczej modelują warianty, atrybuty i dostępność. Właśnie tutaj powstają ciche straty: strona działa, ale traci połowę treści, która ją rankowała.
- Porównanie długości opisów przed migracją i po niej, produkt po produkcie. Ucięte opisy to typowy skutek limitu znaków w nowym systemie.
- Weryfikacja obsługi wariantów. Ustal, czy warianty mają własne adresy, czy są parametrem. Każdy scenariusz wymaga innej konfiguracji kanonicznych.
- Przeniesienie treści dodatkowych: tabele rozmiarów, specyfikacje, pytania klientów, opinie wraz z datami i ocenami. Opinie są elementem wyniku rozszerzonego, więc ich utrata widać od razu w SERP.
- Kontrola obrazów: nazwy plików, atrybuty alt, rozdzielczość źródłowa. Masowa zmiana nazw plików kasuje pozycje w wyszukiwarce grafiki.
Dane strukturalne i feed zakupowy
Dane strukturalne po migracji są zwykle generowane przez nowy motyw lub nową wtyczkę, więc ich kształt zmienia się nawet wtedy, gdy treść pozostaje identyczna.
- Walidacja schematu Product na losowej próbce 30 produktów: cena, waluta, dostępność, oceny, identyfikator. Zakres pól, które faktycznie czytają dziś zarówno wyszukiwarki, jak i modele językowe, rozpisuje tekst o Product schema pod AI.
- Spójność encji marki. Schemat Organization, pole sameAs i dane kontaktowe muszą wskazywać na te same profile co przed migracją, co szerzej tłumaczy materiał o budowaniu encji marki przez sameAs.
- Feed produktowy pod nowe adresy. Identyfikatory ofert muszą zostać te same, bo ich zmiana resetuje historię w Merchant Center. Wymagania pól opisuje specyfikacja danych produktowych Google.
- Zgodność ceny na stronie i w feedzie po przełączeniu podatków i zaokrągleń. Rozjazd na poziomie groszy kończy się odrzuceniem ofert.
Wydajność na nowej platformie
Nowa platforma bywa wolniejsza od starej, mimo nowocześniejszego stosu technologicznego, bo szablon ładuje więcej zasobów. Wydajność mierzymy przed przełączeniem, nie po reklamacji klienta.
- Pomiar odniesienia: czas do pierwszego bajtu, największy element treści i stabilność układu na trzech typach stron (główna, kategoria, produkt), w wersji mobilnej.
- Kontrola zasobów blokujących renderowanie w nowym szablonie: arkusze stylów w nagłówku, skrypty zewnętrzne, czcionki bez wstępnego ładowania.
- Konfiguracja cache i CDN przed przełączeniem DNS, razem z regułami pomijania cache dla koszyka i konta klienta.
Dzień przełączenia: kolejność działań
W dniu przełączenia liczy się sekwencja, a nie liczba osób na dyżurze. Odwrócenie kolejności dwóch kroków potrafi wpuścić do indeksu wersję testową.
- Zdjęcie blokady indeksowania ze środowiska produkcyjnego jako jedna z ostatnich czynności, po potwierdzeniu, że szablon renderuje się poprawnie. Równolegle sprawdź, czy testowa domena nadal jest zablokowana.
- Publikacja nowej sitemapy i zgłoszenie jej w Search Console, przy zachowaniu starej sitemapy przez pierwsze dni. Stara lista pomaga robotowi szybciej odwiedzić adresy, które mają zostać przekierowane.
- Weryfikacja tagów pomiarowych w realnym ruchu: transakcja testowa od wejścia do potwierdzenia zamówienia, z kontrolą zgody na pomiar.
Weryfikacja w pierwszym tygodniu
Pierwsze siedem dni służy wyłapaniu błędów krytycznych. W tym oknie nie wyciągamy jeszcze wniosków o pozycjach, bo dane są niepełne z definicji.
- Codzienny crawl całej listy starych adresów z raportem zmian względem dnia poprzedniego. Każdy nowy kod 404 albo 500 jest zgłoszeniem o priorytecie krytycznym.
- Kontrola raportu indeksowania w Search Console: nagły wzrost kategorii „wykluczone przez tag noindex” oznacza, że blokada została zdjęta tylko częściowo.
- Porównanie liczby sesji i transakcji rok do roku oraz tydzień do tygodnia, w podziale na kanały. Spadek wyłącznie w ruchu organicznym wskazuje na problem indeksacyjny, spadek we wszystkich kanałach na problem z pomiarem albo z samym sklepem.
Monitoring przez kwartał
Ostatni punkt jest procesem, nie zadaniem. Sygnały z przekierowań konsolidują się stopniowo, a pełny obraz skutków migracji widać dopiero po dwóch, trzech pełnych cyklach przeliczania.
- Stały raport miesięczny porównujący widoczność i sprzedaż z zamrożonym obrazem sprzed migracji, z komentarzem o przyczynach odchyleń. Gotową strukturę takiego dokumentu znajdziesz w szablonie raportu miesięcznego.
Przez pierwsze 90 dni po przełączeniu warto utrzymać dwie dyscypliny. Pierwsza: nie wprowadzać innych dużych zmian, takich jak przebudowa kategorii czy zmiana szablonu, bo rozmyją one przyczynowość. Druga: zachować reguły przekierowań co najmniej rok, a dla adresów z linkami zewnętrznymi bezterminowo.
| Etap | Punkty | Kiedy | Sygnał alarmowy |
|---|---|---|---|
| Inwentaryzacja | 1–6 | 4–6 tygodni przed | Brak zamrożonego crawla |
| Mapowanie adresów | 7–12 | 2–4 tygodnie przed | Przekierowania na stronę główną |
| Dane produktowe | 13–16 | 2 tygodnie przed | Skrócone opisy produktów |
| Schema i feed | 17–20 | Tydzień przed | Zmienione identyfikatory ofert |
| Wydajność | 21–23 | Tydzień przed | Wolniejszy czas do pierwszego bajtu |
| Przełączenie | 24–26 | Dzień zero | Aktywny noindex na produkcji |
| Weryfikacja | 27–29 | Dni 1–7 | Nowe kody 404 i 500 |
| Monitoring | 30 | Dni 8–90 | Brak powrotu ruchu po 6 tygodniach |
FAQ
Ile trwa odbudowa ruchu po migracji sklepu?
Przy poprawnie wykonanym mapowaniu adresów typowy okres wahań to od czterech do ośmiu tygodni, a pełna stabilizacja następuje w okolicach trzeciego miesiąca. Jeśli po sześciu tygodniach ruch organiczny nie wraca do poziomu sprzed przełączenia, przyczyną jest zwykle błąd strukturalny, a nie naturalne wahanie: najczęściej niekompletna mapa przekierowań albo utracona treść na kartach produktów.
Czy można zmienić strukturę adresów przy okazji migracji?
Technicznie tak, praktycznie odradzamy. Zmiana platformy i zmiana struktury adresów to dwie niezależne przyczyny spadku, a połączone w jednym wdrożeniu uniemożliwiają diagnozę. Jeśli nowa struktura jest konieczna, wykonaj ją w osobnym wdrożeniu, co najmniej sześć tygodni po migracji i po potwierdzeniu, że ruch wrócił do normy.
Jak długo trzymać stare przekierowania?
Minimum dwanaście miesięcy dla wszystkich adresów. Dla podstron, które mają linki z domen zewnętrznych, przekierowania utrzymuje się bezterminowo, bo to one przenoszą realną wartość linkową. Reguły warto trzymać w pliku konfiguracyjnym pod kontrolą wersji, a nie w panelu wtyczki, żeby przetrwały kolejne wdrożenia.
Czy migracja wymaga nowej usługi w Search Console?
Nie, jeżeli domena pozostaje ta sama. Nową usługę zakłada się tylko przy zmianie domeny albo protokołu i wtedy dodatkowo uruchamia narzędzie zmiany adresu. Przy migracji samej platformy wystarczy ponownie zweryfikować własność, jeśli metoda weryfikacji opierała się na znaczniku w szablonie starego sklepu.
Co zrobić z produktami, które nie mają odpowiednika na nowej platformie?
Produkty wycofane trwale przekierowujemy do najbliższej kategorii albo do produktu zastępczego i zostawiamy w indeksie tylko wtedy, gdy generują ruch informacyjny. Produkty czasowo niedostępne zostawiamy pod ich adresem z poprawnym oznaczeniem dostępności w danych strukturalnych, bo usunięcie strony kasuje historię, którą trzeba będzie odbudować od zera.