Co psuje się w tygodniu po migracji na PrestaShop
Dzień uruchomienia niemal zawsze przebiega dobrze. To fałszywy sygnał
Migracja, która „działa” w najbardziej dosłownym sensie, czyli nowy sklep działa i przyjmuje zamówienia, jest stosunkowo łatwa do przeprowadzenia: produkty, ceny, stany magazynowe i historia zamówień to dane ustrukturyzowane, narzędzia importu przenoszą je dość dobrze, a pierwszego dnia wszystko wydaje się w porządku. Prawdziwe problemy nie pojawiają się w dniu uruchomienia, tylko siedem do dziesięciu dni później, gdy odwiedzający przychodzą ze starym adresem URL zapisanym w zakładkach, gdy Google wznawia indeksowanie z mapą adresów, które znał, i gdy ktoś zauważa, że zniknęła funkcja, która „kiedyś była”: nie dlatego, że ktoś ją celowo usunął, lecz dlatego, że żadne narzędzie importu nigdy jej nie uwzględniało. Ten artykuł nie opowiada o tym, jak migrować (istnieją do tego wyspecjalizowane usługi, to nie nasza dziedzina): opowiada o tym, co należy sprawdzić w kolejnym tygodniu, gdy sklep już działa, a lista problemów zaczyna sama wychodzić na jaw.
Martwe adresy URL: nie dziesiątki, lecz setki
Najbardziej niedoceniany problem to skala. Osoby migrujące spodziewają się poprawienia „kilku adresów URL”, a nie całej struktury adresów. W praktyce prawie żadna platforma nie ma takiego samego schematu adresów URL jak inna: katalog, który działał pod adresem /product/nazwa-produktu/ w WooCommerce, pod /nazwa-kategorii/nazwa-produktu.html w Magento albo pod /products/nazwa-produktu w Shopify, trafia do PrestaShop z jeszcze innym schematem, który często zawiera w adresie numeryczny identyfikator produktu. Każdy adres URL zaindeksowany przez wyszukiwarkę, każdy link zapisany przez inną witrynę lub klienta wskazuje teraz na ścieżkę, która po prostu nie istnieje w nowym sklepie. Przy katalogu liczącym kilka tysięcy produktów, wraz z kategoriami, zaindeksowanymi stronami filtrów i treściami redakcyjnymi, liczba adresów do przekierowania z łatwością sięga kilkuset, nawet w średniej wielkości sklepie: to nie jest przypadek graniczny zarezerwowany dla dużych katalogów.
Dobra praktyka, której prawie nigdy nie stosuje się na czas, polega na wyeksportowaniu przed przełączeniem pełnej listy adresów URL, które stara platforma miała w indeksie (z Google Search Console, a nie z mapy witryny starego sklepu, często już niekompletnej), i zaplanowaniu przekierowań jako części projektu migracji, a nie jako poprawki po pierwszych raportach o utraconym ruchu.
Baner cookies, który przestał rozróżniać kraje
Wielojęzyczna migracja wykonana w pośpiechu prawie zawsze przejmuje teksty i ustawienia przygotowane dla języka głównego, a konfiguracja zgody na pliki cookies to jedno z pierwszych miejsc, w których to widać: baner, który poprawnie rozróżniał odbiorców według języka lub kraju, po migracji czasem wraca do jednej domyślnej wartości albo, co gorsza, wyświetla nieprzetłumaczony tekst w językach pomocniczych (znaleźliśmy i poprawiliśmy dokładnie taki błąd we wrześniu 2026 r. w naszym własnym module zgody na cookies, nie z powodu migracji, lecz z tej samej głębszej przyczyny: teksty obejmowały tylko dwa języki z pięciu). Warto ponownie sprawdzić konfigurację zgody w każdym aktywnym języku zaraz po przełączeniu, a nie tylko w języku głównym, w którym faktycznie przeprowadzono testy.
Dane dotyczące zgodności, których narzędzie importu nawet nie umiało szukać
Narzędzia importu dobrze przenoszą wszystko, co istniało już jako pojęcie na platformie źródłowej: ceny, opisy, zdjęcia, kategorie. Pole takie jak „producent GPSR”, „ostrzeżenie dotyczące bezpieczeństwa dla tego konkretnego produktu” czy „przedstawiciel w UE” często w ogóle nie istniało jako dane ustrukturyzowane na dawnej platformie, więc żadne narzędzie importu nie mogło go przenieść, po prostu dlatego, że nie było pola źródłowego do skopiowania. Prawdziwe ryzyko to sklep po migracji, który zakłada, że „skoro wcześniej było dobrze, to jest dobrze i teraz”, podczas gdy luka w zgodności, jeśli istniała, była już wcześniej, a migracja tylko czyni ją bardziej widoczną, zmuszając do przemyślenia danych produktowych od początku.
Wyszukiwarka wewnętrzna, która zaczyna od zera
Jeśli poprzedni sklep miał wyszukiwarkę dostrajaną z czasem, z synonimami dodawanymi ręcznie po tym, jak klienci szukali jakiegoś terminu i nic nie znajdowali, ze słowami pomijanymi dopasowanymi do języka katalogu, z kolejnością trafności poprawianą po miesiącach obserwowania, w co klienci naprawdę klikali, to nic z tego dostrojenia nie przechodzi razem z importem produktów. To praca wykonana nad zachowaniem wyszukiwarki, a nie nad danymi katalogu, i żadne narzędzie migracji nie może jej przenieść, bo nie jest to nawet „dana” w zwykłym znaczeniu: to nagromadzona konfiguracja. Typowym objawem jest spadek konwersji z wyszukiwarki wewnętrznej w pierwszych tygodniach, nie dlatego, że nowa wyszukiwarka jest sama w sobie gorsza, lecz dlatego, że zaczyna od ogólnych ustawień zamiast od miesięcy poprawek.
Pliki produktowe, które nadal wskazują stary schemat
Plik produktowy Google Shopping lub marketplace jest zbudowany na adresach URL i identyfikatorach platformy źródłowej. Po migracji, jeśli plik nie zostanie w całości odbudowany na nowym schemacie adresów, każda reklama nadal wskazuje adres URL, który zwraca przekierowanie albo, co gorsza, błąd 404: po przekroczeniu pewnego odsetka uszkodzonych linków Google Merchant Center zaczyna oznaczać plik i może zawiesić wyświetlanie reklam, co jest bezpośrednią i natychmiastową szkodą handlową, a nie tylko problemem pozycjonowania organicznego.
Lista kontrolna na pierwszy tydzień
- Należy porównać listę adresów URL zaindeksowanych przed migracją (z Search Console) z tym, co dziś zwraca kod 200: każdy brakujący adres wymaga albo przekierowania stałego do odpowiadającej mu treści, albo świadomego zamknięcia, jeśli treści naprawdę już nie ma.
- Należy sprawdzić baner cookies w każdym aktywnym języku i kraju, nie tylko w języku głównym.
- Należy ponownie sprawdzić dane produktów dotyczące zgodności (w tym GPSR), przyjmując, że import ich nie przeniósł, bo prawie na pewno tak jest.
- Należy osobno śledzić konwersje z wyszukiwarki wewnętrznej przez pierwsze dwa tygodnie: to najszybszy sygnał, czy konfigurację wyszukiwarki trzeba zrobić od nowa.
- Należy odbudować plik produktowy na nowym schemacie adresów URL przed wznowieniem kampanii, a nie po zauważeniu spadku.
W skrócie
Tydzień po migracji nie jest spokojnym okresem docierania: to moment, w którym ujawniają się problemy, których dzień uruchomienia nie mógł pokazać. Adresy URL, których nikt nie przekierował, ustawienia bez pola źródłowego do skopiowania, miesiące dostrajania (wyszukiwarka, zgoda, pliki produktowe), które nigdy nie istniały jako „dana” do przeniesienia. Menedżer przekierowań ze śledzeniem błędów 404, taki jak cll_seoredirect, pomaga wychwycić te luki w chwili, gdy się otwierają, a nie wtedy, gdy zauważyli je już odwiedzający, ale powyższa lista kontrolna pozostaje aktualna niezależnie od użytego narzędzia.
