Migracja sklepu na nowy silnik bez utraty widoczności

Zmiana silnika sklepu (z autorskiego CMS na Shopify, z PrestaShop na WooCommerce, z Magento na platformę SaaS) to dla działu SEO najbardziej ryzykowny projekt w roku. Serwis firmowy ma kilkadziesiąt adresów, które da się przepisać ręcznie w arkuszu. Sklep ma ich tysiące, a do tego filtry, warianty, paginację, feed produktowy i integracje, które po cichu przestają działać dzień po wdrożeniu. Migracja sklepu internetowego pod kątem SEO to w praktyce projekt inwentaryzacyjny: wygrywa ten, kto przed przełączeniem wie, jakie adresy ma i które z nich zarabiają.

Ten tekst jest częścią serii o tym, jak mierzyć widoczność e-commerce w Google i w AI. Poniżej opisujemy kolejność prac i miejsca, w których ruch ginie najczęściej. Liczby i progi, które podajemy bez źródła, są redakcyjną regułą kciuka, nie wynikiem badania.

Co odróżnia migrację sklepu od migracji zwykłego serwisu

Przy serwisie treściowym każdy adres to zwykle jeden artykuł, a jego odpowiednik po migracji łatwo wskazać. W sklepie ten sam produkt może żyć pod kilkoma adresami: w ścieżce kategorii, pod krótkim URL-em, w wersji z parametrem wariantu. Nowa platforma prawie zawsze narzuca własny schemat adresów. Shopify wymusza prefiksy /products/ i /collections/, WooCommerce domyślnie korzysta z /produkt/ i /kategoria-produktu/, a wiele platform SaaS nie pozwala w ogóle zachować starej struktury.

Druga różnica to dane, które nie są stroną. Feed do Merchant Center, mapa witryny, dane strukturalne produktu, identyfikatory w systemie analitycznym i w porównywarkach cen zależą od tego samego katalogu. Migracja, która przenosi strony, ale zmienia identyfikatory produktów, potrafi zachować pozycje organiczne i jednocześnie wyzerować historię kampanii produktowych. Trzecia różnica to skala błędów: jeden zły wzorzec przekierowania w sklepie nie psuje jednej strony, tylko kilka tysięcy naraz.

Inwentaryzacja adresów: produkty, kategorie, filtry, warianty

Zanim ktokolwiek napisze regułę przekierowania, potrzebna jest pełna lista starych adresów. Żadne pojedyncze źródło jej nie da, dlatego warto połączyć kilka:

• eksport katalogu z obecnej platformy (produkty aktywne, wyłączone i archiwalne, z identyfikatorem i SKU),
• crawl całego serwisu z zapisem kodów odpowiedzi i adresów kanonicznych,
• aktualne mapy witryny,
• eksport stron z Google Search Console i z analityki za ostatnie 12–16 miesięcy,
• logi serwera, jeśli są dostępne, bo pokazują adresy odwiedzane przez Googlebota, których crawler nie znalazł.

Każdy adres dostaje w arkuszu typ (produkt, kategoria, filtr, wariant, strona CMS, wpis blogowy) i wagę: kliknięcia, przychód, liczbę linków zewnętrznych. Dzięki temu wiadomo, które kilkaset adresów trzeba sprawdzić ręcznie, a które wystarczy objąć regułą.

Najwięcej kłopotu robią filtry i warianty. Jeżeli stary sklep indeksował wybrane kombinacje filtrów (na przykład „buty damskie czarne”), a nowy nie ma odpowiednika takiej strony, ruch z tych fraz zniknie bez względu na jakość przekierowań. Decyzję, które kombinacje filtrów mają zostać osobnymi stronami docelowymi, trzeba podjąć przed migracją, razem z projektem struktury URL i linkowania wewnętrznego. Podobnie z wariantami: jeśli dotąd każdy kolor miał własny adres, a nowa platforma łączy je w jedną kartę, stare adresy wariantów powinny prowadzić do tej karty, najlepiej z parametrem, który od razu zaznacza właściwy kolor.

Mapa przekierowań dla wycofanych produktów

Zasada podstawowa jest prosta: przekierowanie 301 jeden do jednego, ze starego adresu na najbliższy odpowiednik, bez łańcuchów. Dokumentacja Google o przenoszeniu witryny ze zmianą adresów URL mówi wprost, że Googlebot przejdzie do 10 przekierowań w łańcuchu, ale zaleca kierowanie od razu do adresu docelowego, a jeśli się nie da, utrzymanie łańcucha poniżej 3–5 skoków. Ten sam dokument zaleca utrzymanie przekierowań możliwie długo, zwykle co najmniej rok.

Trudniejsze są produkty, których w nowym sklepie nie będzie. Do wyboru są trzy ścieżki:

Najczęstszy błąd to masowe przekierowanie wszystkiego, czego nie udało się dopasować, na stronę główną. Taki adres nie odpowiada intencji starej strony, więc Google i tak potraktuje go jak stronę, która przestała istnieć, a przy okazji rozmyje sygnały strony głównej. Lepiej mieć uczciwe 404 na kilkuset martwych produktach niż kilkaset przekierowań donikąd.

W praktyce mapa ma dwie warstwy: reguły wzorcowe (np. cała stara ścieżka kategorii zamieniona na nowy prefiks) i wyjątki wpisane ręcznie dla adresów z największą wagą. Reguły testuje się na pełnej liście starych adresów, a nie na kilku przykładach: skrypt, który odpytuje każdy stary URL na środowisku testowym i sprawdza, czy po jednym skoku dostaje kod 200 pod oczekiwanym adresem, wyłapuje błędy, których ręczne klikanie nie znajdzie.

Feed produktowy i integracje po zmianie silnika

Feed do Google Merchant Center to miejsce, w którym migracja psuje najwięcej po cichu. Pomoc Merchant Center w opisie atrybutu identyfikator [id] zaleca stabilny identyfikator, najlepiej SKU, i ostrzega, że jego zmiana nadpisuje produkt razem z historią skuteczności w Merchant Center i Google Ads. Nowa platforma często generuje własne identyfikatory (np. numer rekordu w bazie), więc jeśli wtyczka feedu pobierze je domyślnie, cały katalog wróci do Google jako nowe produkty.

Przed przełączeniem warto więc sprawdzić trzy rzeczy: czy wartość id w nowym feedzie jest taka sama jak w starym dla tego samego produktu, czy link wskazuje na nowy, docelowy adres (a nie na stary, który przekierowuje), oraz czy ceny i dostępność w feedzie zgadzają się z tym, co pokazuje karta produktu. Rozbieżność ceny lub dostępności między feedem a stroną to typowy powód odrzuceń produktów zaraz po migracji. Jak przygotować sam feed pod nowe formaty wyników, opisujemy w tekście o integracji oferty z Google Shopping i AI Overviews.

Ta sama lista dotyczy porównywarek cen, marketplace’ów zasilanych z feedu, systemu mailingowego (linki do produktów w automatycznych wiadomościach) i reklam z wpisanymi na sztywno adresami docelowymi. Każda z tych integracji powinna mieć w planie wdrożenia osobną pozycję i właściciela.

Dane strukturalne produktu na nowej platformie

Szablon produktu na nowej platformie prawie zawsze ma inne dane strukturalne niż stary. Czasem lepsze, czasem uboższe: bez GTIN, bez marki, bez informacji o dostawie i zwrotach, z ceną zapisaną w złym formacie. Google opisuje dwa typy oznaczeń dla produktów (fragmenty produktu i informacje o sprzedawcy) i dodaje, że połączenie danych na stronie z feedem Merchant Center daje najszersze możliwości wyświetlania oferty.

Dlatego przed wdrożeniem warto porównać dane strukturalne kilkunastu reprezentatywnych kart (produkt prosty, produkt z wariantami, produkt niedostępny, produkt w promocji) na starej i nowej wersji. Jeżeli stary sklep miał oceny, GTIN i szczegóły dostawy, a nowy ich nie ma, to regresja, która po migracji objawi się utratą rozszerzonych wyników. Te same pola karmią systemy AI, które budują odpowiedzi o produktach, o czym piszemy w przewodniku o feedzie, opisach i schema produktu w sklepach pod AI. Spójność marki, kategorii i atrybutów między stroną, feedem i danymi strukturalnymi to także fundament semantic SEO opartego na encjach.

Kolejność wdrożenia i okno przejściowe

Kolejność, która w sklepach sprawdza się najlepiej, wygląda tak:

1. Zamrożenie zmian w katalogu na kilka dni przed migracją, żeby lista adresów nie zmieniała się w trakcie testów.
2. Środowisko testowe zablokowane przed indeksacją (hasło lub ograniczenie po IP, a nie samo noindex, które łatwo przenieść na produkcję).
3. Test mapy przekierowań na pełnej liście starych adresów i porównanie danych strukturalnych, tagów kanonicznych oraz meta robots.
4. Przełączenie w okresie niskiej sprzedaży, poza szczytem sezonu i poza kampaniami promocyjnymi.
5. Wdrożenie przekierowań w tej samej chwili, w której zmienia się DNS lub konfiguracja serwera, a nie „w ciągu kilku dni”.
6. Nowa mapa witryny w Search Console i pozostawienie starej na kilka tygodni, żeby obserwować, jak spada liczba zaindeksowanych starych adresów.

Google ostrzega, że po dużej zmianie wahania pozycji są normalne, a przy średnich serwisach przejście na nowe adresy trwa kilka tygodni lub dłużej, przy dużych jeszcze dłużej. Sklep z kilkudziesięcioma tysiącami adresów powinien więc planować okno przejściowe liczone w miesiącach, a nie dniach, i nie oceniać migracji po pierwszym tygodniu. Dokumentacja dopuszcza też przenoszenie serwisu częściami, co przy dużych katalogach bywa bezpieczniejsze niż jedno przełączenie wszystkiego naraz.

Kontrola po migracji: co sprawdzić w pierwszym tygodniu

Pierwszy tydzień to czas na wyłapanie błędów systemowych, a nie na ocenę wyników. Lista kontrolna, którą warto przejść codziennie:

• ponowny crawl pełnej listy starych adresów: każdy powinien dawać jeden skok i kod 200 albo świadome 404/410,
• raport stron w Search Console: przyrost błędów 404, soft 404 i stron „wykluczonych przez tag noindex”,
• plik robots.txt i meta robots na produkcji (pozostawiona blokada z testów to klasyczny powód nagłego spadku),
• diagnostyka Merchant Center: liczba odrzuconych produktów i rozbieżności cen,
• analityka: czy zdarzenia zakupowe działają i czy przychód z ruchu organicznego jest w ogóle mierzony,
• top 50 adresów według przychodu sprzed migracji, sprawdzone ręcznie w przeglądarce i w narzędziu do sprawdzania adresów URL.

Po pierwszym tygodniu porównanie robi się na poziomie typów stron: osobno kategorie, osobno karty produktów, osobno treści blogowe. Spadek skupiony w jednym typie wskazuje zwykle na konkretny wzorzec przekierowań albo szablon. Szerzej o tym, jak ułożyć techniczne, treściowe i linkowe priorytety sklepu po zmianie platformy, piszemy w tekście SEO dla sklepów 2026.

FAQ