Migracja sklepu internetowego: 50 problemów i jak ich uniknąć (2026)

Migracja sklepu internetowego to zwykle decyzja o rozwoju: stara platforma przestała wystarczać, abonament rośnie, brakuje integracji albo swobody w dopasowaniu sklepu. Sama zmiana platformy rzadko jest jednak problemem. Kłopoty pojawiają się w szczegółach: warianty produktów, które nie przeszły, klienci bez dostępu do kont, stare adresy bez przekierowań, płatności bez powiadomień i integracje, które po starcie zaczynają dublować zamówienia. Zebraliśmy 50 problemów, które najczęściej widzimy przy przenoszeniu sklepów z Shopera, PrestaShop, IdoSell, Shopify i innych platform, głównie na WooCommerce.

Lista jest ułożona w kolejności migracji: od decyzji i przygotowania, przez dane i SEO, po integracje i pierwsze tygodnie po starcie. Jeśli migracja już się odbyła i coś nie działa, przejdź od razu do właściwej grupy albo użyj wyszukiwania w przeglądarce (Ctrl+F). Jeśli dopiero ją planujesz, przeczytaj całość, bo najtańsze są problemy, którym zapobiegniesz przed przełączeniem domeny.

Decyzja i przygotowanie

Najdroższe błędy migracji zapadają przed pierwszym eksportem: zły moment, niejasny zakres i brak kopii testowej.

1. Kiedy warto zmienić platformę sklepu internetowego?

Platformę warto zmienić, gdy blokuje sprzedaż albo rozwój: brakuje potrzebnych integracji, koszty abonamentu i dodatków rosną szybciej niż sklep, a zmian nie da się zrobić bez obejść. Sam wolny sklep czy słaba konwersja to częściej sprawa motywu, hostingu i konfiguracji niż platformy. Migracja kosztuje czas i niesie ryzyko dla ruchu z Google, więc powinna rozwiązywać konkretny problem.

Rozwiązanie: spisz, czego obecny sklep nie umie i ile to kosztuje (ręczna praca, utracone zamówienia, opłaty). Jeśli większość punktów da się naprawić na obecnej platformie, zacznij od naprawy, a migrację zaplanuj dopiero wtedy, gdy lista ograniczeń się nie skraca.

2. Jak wybrać nową platformę, żeby za dwa lata nie migrować znowu?

Platformę wybiera się pod procesy sklepu, a nie pod modę: liczbę produktów i wariantów, sprzedaż B2B, marketplace, magazyn i integracje. Sklep abonamentowy daje mniej obowiązków technicznych, a WooCommerce czy sklep dedykowany więcej swobody i własność danych. Kolejna migracja najczęściej wynika z tego, że wybór oparto na cenie startowej, a nie na planach na kilka lat.

Rozwiązanie: wypisz wymagania na teraz i na najbliższe lata, sprawdź gotowe integracje i warunki eksportu danych z nowej platformy. Pomocne będzie nasze porównanie WooCommerce, Shopify i PrestaShop.

3. Nie wiadomo, co dokładnie trzeba przenieść

Bez spisanego zakresu migracja kończy się niespodziankami po starcie: brakuje stron informacyjnych, wpisów na blogu, opinii, kuponów albo przekierowań. Każdy sklep po latach ma treści i ustawienia, o których nikt już nie pamięta. Zakres decyduje też o koszcie i terminie, więc jego brak to najczęstsza przyczyna sporów z wykonawcą.

Rozwiązanie: przygotuj listę: produkty z wariantami, kategorie, strony, blog, klienci, zamówienia, zgody, opinie, kupony, przekierowania, integracje i maile. Przy każdej pozycji zapisz, czy przenosisz ją automatycznie, ręcznie, czy wcale.

4. Czy da się przenieść sklep z Shopera, IdoSell albo PrestaShop na WooCommerce?

Tak, produkty, kategorie, klientów i zwykle także zamówienia da się przenieść, korzystając z eksportu CSV lub XML, API platformy albo narzędzi do migracji. Nie przenosi się wygląd, aplikacje i płatności zintegrowane ze starą platformą ani hasła klientów. Zakres eksportu zależy od platformy i pakietu, dlatego trzeba go sprawdzić przed decyzją.

Rozwiązanie: zrób próbny eksport wszystkich danych i sprawdź, czy zawiera warianty, zdjęcia i adresy URL. Dla platform abonamentowych potwierdź w panelu lub u dostawcy, jakie dane możesz pobrać i do kiedy. Szczegóły i naprawa krok po kroku.

5. Migracja zaplanowana tuż przed sezonem

Przełączenie sklepu przed Black Friday, świętami czy szczytem sezonu branżowego zostawia zero czasu na poprawki. Każdy błąd w płatnościach, wysyłce albo przekierowaniach kosztuje wtedy najwięcej, a zespół jest zajęty obsługą zamówień. Do tego wahania ruchu z Google po migracji nakładają się na najważniejsze tygodnie roku.

Rozwiązanie: zaplanuj start w okresie najniższej sprzedaży i z zapasem kilku tygodni przed sezonem. Dzień przełączenia wybierz w środku tygodnia, w godzinach, gdy zespół może reagować na błędy.

6. Nowy sklep powstaje na żywej domenie, bez kopii testowej

Budowa i import na działającej domenie oznaczają, że klienci widzą niedokończony sklep, a Google indeksuje półprodukt. Bez środowiska testowego (stagingu) nie da się bezpiecznie powtórzyć importu ani przetestować płatności. Każdą poprawkę robi się wtedy na sklepie, który przyjmuje zamówienia.

Rozwiązanie: zbuduj nowy sklep na kopii testowej pod osobnym adresem, zabezpieczonej hasłem i zablokowanej przed indeksowaniem. Zrób na niej co najmniej jedną pełną migrację próbną, a domenę przełącz dopiero po testach.

7. Abonament starego sklepu wygasł razem z danymi

W sklepie abonamentowym dane są dostępne tylko w czasie trwania usługi. Jeśli abonament wygaśnie przed pełnym eksportem, możesz stracić historię zamówień, klientów, opinie i listę adresów URL potrzebną do przekierowań. To samo dotyczy starego hostingu przy migracji z PrestaShop czy innej platformy instalowanej na serwerze.

Rozwiązanie: przedłuż abonament lub hosting o okres po starcie nowego sklepu. Zrób pełny eksport wszystkich danych do plików, które przechowasz u siebie, i zachowaj listę wszystkich adresów URL starego sklepu.

8. Domena i konta są zapisane na dostawcę albo dawną agencję

Przy migracji często okazuje się, że domena została kupiona przez dostawcę platformy, a Google Analytics, Search Console czy Merchant Center są na koncie dawnego wykonawcy. Bez dostępu nie zmienisz DNS, nie zweryfikujesz domeny i nie przeniesiesz historii danych. Odzyskiwanie dostępów potrafi trwać dłużej niż sama migracja.

Rozwiązanie: jeszcze przed startem projektu sprawdź, kto jest abonentem domeny, i przejmij ją na firmę (kodem transferu). Upewnij się, że masz uprawnienia właściciela we wszystkich kontach Google, Meta i systemach płatności.

9. Zmiana platformy, wyglądu i adresów naraz

Gdy jednocześnie zmieniasz platformę, szablon, strukturę kategorii, adresy URL i treści, po starcie nie wiadomo, która zmiana zaszkodziła sprzedaży lub widoczności. Google musi też ponownie ocenić prawie całą witrynę. Każda dodatkowa zmiana zwiększa ryzyko i utrudnia diagnozę.

Rozwiązanie: jeśli to możliwe, przenieś sklep z możliwie podobną strukturą i treściami, a przebudowę kategorii lub treści zrób w kolejnym etapie. Jeśli robisz wszystko naraz, dokładnie zapisuj każdą zmianę i jej datę.

10. Nowy sklep nie robi czegoś, co robił stary

Funkcje używane na co dzień często nie trafiają do specyfikacji, bo są oczywiste: cenniki dla firm, rabaty ilościowe, darmowa dostawa od progu, produkty w zestawach, powiadomienia o dostępności. Po starcie wychodzi, że nowy sklep ich nie ma. Obsługa klienta dowiaduje się o tym od klientów.

Rozwiązanie: przejdź stary sklep jako klient i jako obsługa zamówień, spisz każdą funkcję i ustawienie, a potem przypisz im odpowiednik w nowym sklepie (ustawienie, wtyczka albo moduł na zamówienie).

Dane: produkty, warianty, zdjęcia, klienci, zamówienia

Dane to serce migracji: ich eksport jest prosty, ale dopasowanie do struktury nowej platformy wymaga sprawdzenia każdego typu danych.

11. Po imporcie produkty nie mają wariantów

Najczęstsza przyczyna to inna budowa wariantów na starej i nowej platformie: jedna platforma zapisuje je jako osobne wiersze, druga jako kombinacje atrybutów produktu nadrzędnego. Bez przekształcenia pliku import tworzy osobne produkty albo produkty bez wyboru rozmiaru i koloru. Rozpoznasz to po zdublowanych produktach lub brakujących listach wyboru.

Rozwiązanie: przed importem przekształć plik do formatu nowej platformy (w WooCommerce: produkt zmienny z atrybutami i wariantami), zachowując SKU, ceny i stany każdego wariantu. Sprawdź import na kilkunastu najbardziej złożonych produktach.

12. Filtry w nowym sklepie nie działają albo pokazują duplikaty

Atrybuty w starym sklepie bywają wpisane niespójnie: „czarny”, „Czarny” i „czarna” to dla filtrów trzy różne wartości. Migracja przenosi ten bałagan albo go powiększa, jeśli atrybuty trafiają do opisu zamiast do pól. Skutek to filtry z powtórzonymi pozycjami i produktami, których nie da się znaleźć.

Rozwiązanie: przed importem ujednolić nazwy atrybutów i wartości w arkuszu, zdecyduj, które atrybuty mają być filtrami, i importuj je jako atrybuty globalne. Po imporcie sprawdź każdy filtr na kategorii z największą liczbą produktów.

13. Zdjęcia produktów nie przeszły, są w złej kolejności albo bez opisów

Import zdjęć zwykle polega na pobraniu plików z adresów starego sklepu. Jeśli stary sklep blokuje pobieranie, adresy wygasły albo plików jest dużo, część zdjęć przepada lub przychodzi w złej kolejności. Gubią się też teksty alternatywne, ważne dla dostępności i wyszukiwarki grafik.

Rozwiązanie: pobierz wszystkie zdjęcia na dysk przed wyłączeniem starego sklepu, importuj je partiami i zachowaj kolejność oraz teksty alternatywne w pliku importu. Po imporcie porównaj liczbę zdjęć w obu sklepach dla losowych produktów.

14. Opisy produktów mają rozjechane formatowanie i linki do starego sklepu

Opisy zawierają kod HTML, style i obrazki osadzone z adresów starej platformy. Po migracji formatowanie się rozjeżdża, a obrazki i linki przestają działać, gdy stary sklep zostanie wyłączony. Problem często wychodzi dopiero po kilku tygodniach.

Rozwiązanie: po imporcie wyszukaj w opisach adresy starej domeny i starych ścieżek obrazków, przenieś obrazki do nowego sklepu i zamień adresy. Usuń z opisów zbędne style, tak aby wygląd ustalał motyw nowego sklepu.

15. Po migracji zmieniły się ID produktów i przestały działać integracje

Nowa platforma nadaje produktom własne numery ID. Integracje, które łączyły produkty po ID (hurtownie, BaseLinker, feedy do porównywarek i Merchant Center), tracą powiązania. Skutek to zdublowane oferty, złe stany magazynowe albo produkty odrzucone w reklamach.

Rozwiązanie: jako wspólny klucz stosuj SKU (kod produktu) i upewnij się, że każdy produkt i wariant ma unikalny SKU przed migracją. Stare ID zapisz w dodatkowym polu, aby w razie potrzeby odtworzyć powiązania i identyfikatory w feedach.

16. Klienci nie mogą zalogować się do nowego sklepu, bo haseł nie da się przenieść

Hasła są zapisane jako skróty (hashe), których nie da się odszyfrować, a platformy abonamentowe zwykle w ogóle ich nie udostępniają. Nawet gdy skróty są dostępne, nowy sklep nie rozpozna ich bez dodatkowego mechanizmu. Dlatego po migracji klienci muszą ustawić nowe hasło.

Rozwiązanie: przenieś konta bez haseł, a po starcie wyślij klientom wiadomość z linkiem do ustawienia nowego hasła i informacją, co się zmieniło. Upewnij się, że formularz resetu hasła działa i maile nie trafiają do spamu. Szczegóły i naprawa krok po kroku.

17. Klienci nie widzą historii swoich zamówień

Zamówienia są najtrudniejszą częścią migracji, bo łączą klientów, produkty, ceny, płatności i statusy. Często przenosi się je tylko jako plik do archiwum, przez co klient w swoim koncie widzi pustą historię, a obsługa nie znajduje zamówienia przy reklamacji. Zmieniają się też numery zamówień.

Rozwiązanie: przenieś zamówienia z powiązaniem do kont klientów i zachowaj stare numery (np. w dodatkowym polu albo przez numerację z prefiksem). Jeśli zamówień nie przenosisz, zachowaj dostęp do pełnego archiwum na czas, w którym klienci mogą składać reklamacje.

18. Zgody marketingowe przeniesione bez daty i źródła

Lista adresów do newslettera bez informacji, kiedy i jak klient wyraził zgodę, nie pozwala wykazać jej zgodnie z RODO. Migracja często przenosi samo pole „zgoda: tak” albo w ogóle pomija zgody. Wysyłka do osób bez udokumentowanej zgody to ryzyko skarg.

Rozwiązanie: eksportuj zgody razem z datą, źródłem i treścią zgody, przechowaj kopię eksportu i importuj je do osobnych pól w nowym sklepie lub systemie mailingowym. Osoby bez udokumentowanej zgody nie dostają newslettera.

19. Kupony, karty podarunkowe i punkty lojalnościowe przepadły

Aktywne kody rabatowe, salda kart podarunkowych i punkty klientów są przechowywane przez moduły starej platformy i rzadko trafiają do standardowego eksportu. Po migracji klient, który ma ważny kod albo punkty, nie może ich użyć. To szybka droga do reklamacji i złych opinii.

Rozwiązanie: wyeksportuj listę aktywnych kuponów, kart i sald przed przełączeniem, odtwórz je w nowym sklepie (ręcznie albo importem) i sprawdź kilka z nich na zamówieniu testowym. Klientom z saldem wyślij potwierdzenie, że środki są dostępne.

20. Po migracji zniknęły opinie i historia cen

Opinie o produktach i historia cen są zapisane w osobnych tabelach lub modułach, więc zwykły eksport produktów ich nie obejmuje. Brak opinii obniża konwersję, a brak historii cen utrudnia pokazanie najniższej ceny z 30 dni przy promocjach, czego wymaga dyrektywa Omnibus.

Rozwiązanie: wyeksportuj opinie z datą, oceną i produktem (po SKU) i zaimportuj je do nowego sklepu. Zachowaj historię cen z ostatnich 30 dni i przez pierwszy miesiąc uważaj z promocjami. Więcej o tym w artykule o najniższej cenie z 30 dni.

Adresy URL i SEO

To w tej grupie migracja najczęściej traci ruch z Google, bo każdy adres starego sklepu musi mieć jasny odpowiednik w nowym.

21. Stare adresy produktów prowadzą do błędu 404

Każda platforma buduje adresy inaczej, więc po migracji prawie wszystkie adresy produktów i kategorii się zmieniają. Bez przekierowań 301 linki z Google, porównywarek, maili i innych stron prowadzą do błędu 404, a nowe adresy zaczynają od zera. To najczęstsza przyczyna spadku ruchu po migracji sklepu.

Rozwiązanie: przygotuj mapę przekierowań: listę wszystkich starych adresów (z mapy witryny, Search Console, analityki i crawla) z dopasowanym nowym adresem dla każdego. Wdróż przekierowania 301 w dniu przełączenia i sprawdź je narzędziem do masowego testowania.

22. Wszystkie stare adresy przekierowują na stronę główną

Przekierowanie wszystkiego na stronę główną to skrót, który Google traktuje zwykle jak błąd 404 (tzw. soft 404). Wartość linków do konkretnych produktów i kategorii przepada, a klient z wyników wyszukiwania ląduje na stronie, której nie szukał. Rozpoznasz to w Search Console w raporcie stron.

Rozwiązanie: przekierowuj każdy stary adres na najbliższy odpowiednik: produkt na produkt, kategorię na kategorię. Produkt, którego już nie ma, przekieruj na jego kategorię lub następcę, a stronę bez odpowiednika zostaw z kodem 404 lub 410.

23. Przekierowania tworzą łańcuchy i pętle

Jeśli sklep był już wcześniej migrowany albo zmieniał adresy, nowe przekierowania dokładają się do starych: adres A prowadzi do B, B do C, a C do nowego sklepu. Łańcuchy spowalniają odwiedzających i Googlebota, a pętle całkowicie blokują stronę. Dochodzą do tego warianty z http, https, www i bez www.

Rozwiązanie: w mapie przekierowań każdy stary adres (także z dawnych migracji) kieruj bezpośrednio na adres docelowy. Po wdrożeniu przetestuj losowe adresy we wszystkich wariantach protokołu i www.

24. Stare adresy z parametrami i filtrami nie mają przekierowań

Oprócz czystych adresów stary sklep ma adresy z parametrami: identyfikatorami produktów, sortowaniem, filtrami czy wersjami językowymi. Część z nich ma linki i ruch, a zwykłe reguły przekierowań je pomijają. Po migracji kończą jako 404 albo pokazują przypadkową stronę. Najczęściej dotyczy to sklepów, które przez lata zmieniały silnik albo moduły.

Rozwiązanie: wyciągnij z Search Console i analityki adresy z parametrami, które mają wejścia lub linki, i dodaj dla nich reguły przekierowań. Adresy filtrów bez wartości możesz przekierować na kategorię.

25. Kopia testowa sklepu trafiła do Google

Staging bez hasła i blokady indeksowania potrafi trafić do wyników wyszukiwania i konkurować z właściwym sklepem jako duplikat. Bywa też odwrotnie: znaczniki canonical lub ustawienia skopiowane ze stagingu wskazują na adres testowy. Google widzi wtedy dwie wersje tego samego sklepu.

Rozwiązanie: zabezpiecz kopię testową hasłem i usuń ją z indeksu narzędziem usuwania adresów w Search Console, jeśli już się pojawiła. Po starcie sprawdź w kodzie stron, czy canonical wskazuje na właściwą domenę.

26. Search Console nie wie o nowym sklepie

Po migracji Google sam znajdzie zmiany, ale wolniej, jeśli nie dostanie sygnałów. Stara mapa witryny prowadzi do nieistniejących adresów, a przy zmianie domeny bez użycia narzędzia zmiany adresu przeniesienie sygnałów trwa dłużej. Brak danych w Search Console utrudnia też wykrycie błędów.

Rozwiązanie: zweryfikuj nową domenę w Search Console, zgłoś nową mapę witryny i usuń starą. Przy zmianie domeny użyj narzędzia zmiany adresu. Przez pierwsze tygodnie codziennie sprawdzaj raporty stron i indeksowania.

27. Linki w opisach, menu i blogu prowadzą do starych adresów

Przekierowania ratują ruch z zewnątrz, ale linki wewnętrzne powinny prowadzić bezpośrednio do nowych adresów. Po migracji opisy produktów, wpisy na blogu, menu i stopka często zawierają stare adresy, przez co każde kliknięcie przechodzi przez przekierowanie. Googlebot marnuje na to czas, a część linków kończy się błędem.

Rozwiązanie: po imporcie przeskanuj sklep crawlerem i zamień stare adresy na nowe w treściach, menu i widżetach. Narzędzie do wyszukiwania i zamiany w bazie zrobi to hurtowo, ale wcześniej zrób kopię zapasową.

28. Zniknęły tytuły SEO, opisy meta i teksty kategorii

Tytuły i opisy meta są zapisane w polach specyficznych dla każdej platformy, więc standardowy import produktów ich nie przenosi. Podobnie z tekstami kategorii i nagłówkami, które budowały pozycje na frazy ogólne. Po migracji strony mają automatyczne tytuły, a kategorie są puste.

Rozwiązanie: wyeksportuj tytuły, opisy meta i teksty kategorii osobno i zaimportuj je do pól wtyczki SEO w nowym sklepie. Porównaj kilkadziesiąt najważniejszych stron (według ruchu) przed i po migracji.

29. Po migracji zniknęły gwiazdki i ceny w wynikach Google

Wyniki rozszerzone produktów wymagają danych strukturalnych (schema Product) z ceną, dostępnością i opiniami. Stary sklep mógł je generować automatycznie, a nowy motyw lub wtyczka SEO nie, albo generuje je z błędami. Skutek to mniej widoczne wyniki i mniej kliknięć.

Rozwiązanie: sprawdź kilka produktów w Teście wyników z elementami rozszerzonymi i w raporcie produktów w Search Console. Uzupełnij brakujące pola (cena, dostępność, marka, GTIN, opinie) wtyczką SEO lub w kodzie motywu.

30. Produkty w Merchant Center zostały odrzucone po migracji

Feed produktowy po migracji ma nowe adresy, często nowe ID i inne formaty cen lub dostępności. Merchant Center odrzuca produkty, gdy dane w feedzie nie zgadzają się z danymi na stronie, a zmiana ID sprawia, że produkty są traktowane jak nowe. Kampanie produktowe tracą wtedy wyświetlenia.

Rozwiązanie: jeśli możesz, zachowaj w feedzie te same identyfikatory produktów co przed migracją (np. SKU). Podłącz nowy feed przed przełączeniem domeny, a po starcie sprawdź diagnostykę w Merchant Center i zgodność cen.

Płatności, dostawa, integracje

Integracje działają w tle, więc ich błędy zwykle wychodzą dopiero przy pierwszych prawdziwych zamówieniach.

31. Klient zapłacił, a zamówienie w nowym sklepie czeka na płatność

Najczęściej bramka płatności nadal wysyła powiadomienia o płatności na adres starego sklepu albo klucze w nowym sklepie pochodzą z trybu testowego. Płatności zintegrowane z platformą abonamentową trzeba zastąpić nową umową z operatorem lub nowym modułem. Pieniądze wpływają, a zamówienia stoją.

Rozwiązanie: skonfiguruj bramkę w nowym sklepie z kluczami produkcyjnymi, ustaw adres powiadomień na nową domenę i wykonaj prawdziwą płatność przed startem. Więcej w artykule zamówienie oczekuje na płatność.

32. Nie da się zwrócić pieniędzy za zamówienie ze starego sklepu

Zwrot płatności robi się zwykle w tym samym systemie, w którym przyjęto płatność. Jeśli nowy sklep korzysta z innej bramki albo innego konta, zamówienia sprzed migracji nie mają powiązania z płatnością. Przy odstąpieniu od umowy obsługa nie wie, skąd zrobić zwrot, a klient czeka na pieniądze dłużej, niż pozwalają przepisy i jego cierpliwość.

Rozwiązanie: utrzymaj aktywne konto starej bramki płatności przez okres zwrotów i reklamacji. Opisz w procedurze obsługi, jak zwracać pieniądze za zamówienia sprzed migracji.

33. Po migracji nie działają metody dostawy i paczkomaty

Strefy wysyłki, progi darmowej dostawy, wagi produktów i integracje z przewoźnikami trzeba w nowym sklepie skonfigurować od nowa. Najczęściej brakuje wag lub wymiarów produktów, przez co metody dostawy znikają z koszyka, albo klucze integracji z InPost nie zostały przeniesione. Klient dochodzi do koszyka i nie ma jak wybrać dostawy.

Rozwiązanie: przenieś wagi i wymiary produktów w imporcie, odtwórz strefy i zasady kosztów dostawy i podłącz integracje przewoźników z kluczami produkcyjnymi. Zobacz też brak paczkomatów InPost przy zamówieniu.

34. BaseLinker dubluje zamówienia albo zeruje stany magazynowe

Po migracji BaseLinker łączy się z nowym sklepem, ale ma zapisane powiązania produktów ze starego. Bez ponownego powiązania (po SKU) synchronizacja stanów trafia do złych produktów, a zamówienia mogą pobierać się z obu sklepów. Problem widać od razu w magazynie.

Rozwiązanie: przed przełączeniem wyłącz pobieranie zamówień ze starego sklepu, dodaj nowy sklep jako osobną integrację i powiąż produkty po SKU. Synchronizację stanów włącz dopiero po sprawdzeniu powiązań na kilku produktach.

35. Dokumenty sprzedaży i KSeF nie działają w nowym sklepie

Integracja sklepu z programem księgowym lub systemem wystawiania faktur jest zwykle przypisana do platformy, więc po migracji trzeba ją skonfigurować od nowa. Ryzykowne są numeracja dokumentów, dane nabywcy z formularza zamówienia i przesyłanie e-faktur do KSeF. Błędy wychodzą przy pierwszym zamknięciu miesiąca.

Rozwiązanie: podłącz integrację z programem księgowym w nowym sklepie, sprawdź pola danych firmy w formularzu zamówienia i ciągłość numeracji. Wystaw testowy dokument i potwierdź z księgowością, że wszystko jest poprawne.

36. Allegro, porównywarki i marketplace nie widzą nowego sklepu

Feedy XML do porównywarek, integracje z Allegro i innymi marketplace są skonfigurowane pod adresy i ID starego sklepu. Po migracji feed przestaje się aktualizować, oferty prowadzą do 404 albo ceny i stany się rozjeżdżają. Sprzedaż z tych kanałów spada bez widocznego błędu w sklepie.

Rozwiązanie: spisz wszystkie kanały sprzedaży i feedy, przygotuj nowe w nowym sklepie i podmień adresy feedów w panelach porównywarek i integracji w dniu przełączenia. Po starcie sprawdź ceny i stany w każdym kanale.

37. Klienci nie dostają maili z nowego sklepu

Nowy sklep często wysyła maile funkcją serwera, bez uwierzytelnienia, a domena nie ma rekordów SPF i DKIM dla nowego źródła wysyłki. Potwierdzenia zamówień i linki do resetu hasła trafiają wtedy do spamu. Przy migracji to szczególnie groźne, bo klienci muszą ustawić nowe hasła.

Rozwiązanie: skonfiguruj wysyłkę przez SMTP lub usługę maili transakcyjnych, dodaj rekordy SPF, DKIM i DMARC i przetestuj każdy typ wiadomości. Zobacz też WordPress nie wysyła maili.

38. Po migracji Google Analytics i Google Ads nie widzą sprzedaży

Kody pomiarowe trzeba w nowym sklepie wdrożyć od nowa: GA4, tag Google Ads, piksel Meta i zdarzenia e-commerce. Najczęściej brakuje zdarzenia zakupu albo jest ono zliczane podwójnie, gdy tag jest wpięty i wtyczką, i ręcznie. Kampanie optymalizują się wtedy na błędnych danych.

Rozwiązanie: wdróż pomiar przez jedno narzędzie (np. Google Tag Manager), sprawdź zdarzenia w trybie podglądu i złóż zamówienie testowe. Szczegóły w artykule Google Ads nie zlicza konwersji.

39. Nowy sklep uruchamia skrypty przed zgodą na cookies

Baner cookies ze starej platformy nie przechodzi do nowego sklepu, a nowy często jest dodawany na końcu, już po wdrożeniu kodów. Skrypty analityczne i reklamowe ładują się wtedy przed zgodą, a Consent Mode nie przekazuje Google informacji o wyborze użytkownika. To problem prawny i pomiarowy jednocześnie.

Rozwiązanie: wdróż baner z obsługą Consent Mode v2 przed włączeniem kodów pomiarowych i sprawdź w narzędziach przeglądarki, że przed zgodą nie ładują się skrypty reklamowe. Więcej w artykule o skryptach przed zgodą.

40. Regulamin i polityka prywatności opisują stary sklep

Po migracji zmieniają się dostawcy usług (hosting, płatności, mailing, analityka), a często też metody dostawy i płatności. Stare dokumenty wymieniają podmioty, które już nie przetwarzają danych, i pomijają nowe. To niezgodność z RODO i ryzyko sporu z klientem, bo regulamin opisuje zasady zakupów, których sklep już nie stosuje.

Rozwiązanie: zaktualizuj regulamin i politykę prywatności przed startem, podpisz umowy powierzenia danych z nowymi dostawcami i opublikuj nowe wersje z datą. Zobacz politykę prywatności na stronie internetowej.

Start i pierwsze tygodnie

Dzień przełączenia i kolejne tygodnie decydują o tym, czy migracja zostanie zapamiętana jako krótka przerwa, czy jako kryzys.

41. Co sprawdzić przed uruchomieniem nowego sklepu?

Przed startem potrzebna jest lista kontrolna, bo w dniu przełączenia łatwo pominąć oczywiste rzeczy: przekierowania, wyłączenie blokady indeksowania, klucze produkcyjne płatności, maile i pomiar. Bez listy każdy zakłada, że ktoś inny to sprawdził. Najczęściej pomijane są ustawienia, które na stagingu celowo były wyłączone.

Rozwiązanie: przygotuj listę z osobą odpowiedzialną przy każdym punkcie: dane, przekierowania, indeksowanie, płatności, dostawa, maile, dokumenty, pomiar, cookies, kopia zapasowa. Odhaczaj ją w dniu przełączenia, a nie z pamięci.

42. Po zmianie DNS część klientów trafia do starego sklepu

Zmiana rekordów DNS nie działa wszędzie natychmiast, bo serwery i przeglądarki pamiętają stare wpisy przez czas określony w ustawieniu TTL. Przez ten okres część klientów składa zamówienia w starym sklepie. Do tego dochodzą błędy certyfikatu SSL, jeśli nowy serwer nie wystawił go na czas.

Rozwiązanie: kilka dni przed migracją skróć TTL rekordów DNS, przygotuj certyfikat SSL na nowym serwerze i po przełączeniu monitoruj, czy stary sklep nie przyjmuje zamówień. Pamiętaj o zachowaniu rekordów poczty (MX) przy zmianie DNS.

43. Zamówienia z dnia przełączenia zginęły między sklepami

Między ostatnim eksportem a przełączeniem domeny stary sklep nadal przyjmuje zamówienia i rejestracje. Bez planu te dane nie trafiają do nowego sklepu, a klienci nie widzą zamówień w koncie. Im dłuższa przerwa między eksportem a startem, tym więcej takich zamówień i tym trudniej je potem odnaleźć.

Rozwiązanie: na czas przełączenia wstrzymaj przyjmowanie zamówień w starym sklepie (krótka przerwa techniczna z komunikatem) albo zaplanuj import różnicowy: ostatnie zamówienia i klientów przenieś tuż po przełączeniu.

44. Pierwsze prawdziwe zamówienia ujawniają błędy

Zamówienia testowe na stagingu nie sprawdzają wszystkiego, bo używają trybów testowych płatności i przewoźników. Dopiero prawdziwe zamówienia pokazują brakujące maile, złe koszty dostawy, błędy dokumentów sprzedaży czy integracji magazynowych. Lepiej, żeby trafił na nie zespół niż klient.

Rozwiązanie: zaraz po starcie złóż kilka prawdziwych zamówień: różne płatności, dostawy, kupon, konto i zakup bez rejestracji, firma i osoba prywatna. Przejdź każde do końca, łącznie z wysyłką, dokumentem i zwrotem.

45. Search Console pokazuje coraz więcej błędów 404

Nawet dobra mapa przekierowań nie obejmuje wszystkiego: zapomniane strony, stare kampanie, linki z forów i adresy obrazków. Rosnąca liczba 404 w pierwszych tygodniach to sygnał, że brakuje przekierowań dla adresów, które mają ruch lub linki. Każdy taki adres to klient, który trafia na stronę błędu zamiast na produkt.

Rozwiązanie: przez pierwsze tygodnie codziennie sprawdzaj błędy 404 w Search Console, logach serwera lub wtyczce przekierowań i dodawaj brakujące przekierowania 301. Priorytet mają adresy z ruchem i linkami zewnętrznymi.

46. Nowy sklep jest zablokowany przed indeksowaniem

Staging celowo blokuje roboty, a ta blokada często zostaje po przeniesieniu: zaznaczone pole „Proś wyszukiwarki o nieindeksowanie”, noindex w nagłówkach albo blokada w robots.txt. Sklep działa dla klientów, ale znika z Google. Rozpoznasz to w raporcie stron w Search Console.

Rozwiązanie: w dniu startu sprawdź ustawienia czytania w WordPressie, plik robots.txt i kod kilku stron pod kątem noindex. Zbadaj adres w Search Console narzędziem sprawdzania adresu URL. Zobacz też strona zeskanowana, ale niezindeksowana.

47. Nowy sklep działa wolniej niż stary

Platformy abonamentowe mają zoptymalizowaną infrastrukturę, a nowy sklep na WooCommerce zależy od hostingu, motywu i wtyczek. Bez cache, optymalizacji zdjęć i odpowiedniego serwera nowy sklep może wypaść gorzej w Core Web Vitals niż stary. Spada konwersja, szczególnie na telefonach.

Rozwiązanie: przed startem porównaj wyniki PageSpeed Insights starego i nowego sklepu dla tych samych typów stron i popraw to, co wypada gorzej. Więcej w artykule o wolnym sklepie na telefonie.

48. Po migracji sklepu spadł ruch z Google. Co sprawdzić najpierw?

Najczęściej przyczyną są brakujące lub błędne przekierowania 301, blokada indeksowania przeniesiona ze stagingu albo utracone treści i tytuły kategorii. Krótkie wahania po migracji są normalne, ale głęboki lub narastający spadek wskazuje na konkretny błąd. Kluczowe jest ustalenie, których stron dotyczy spadek.

Rozwiązanie: porównaj w Search Console strony z ruchem przed i po migracji, sprawdź przekierowania tych adresów, indeksowanie i treści. Ogólny poradnik znajdziesz w artykule o nagłym spadku ruchu z Google. Szczegóły i naprawa krok po kroku.

49. Nie ma planu powrotu do starego sklepu

Jeśli w dniu startu wyjdzie krytyczny błąd, na przykład nie działają płatności, potrzebna jest decyzja: naprawiamy na żywo czy wracamy do starego sklepu. Bez przygotowanego planu powrotu zostaje naprawianie pod presją, gdy klienci nie mogą kupić.

Rozwiązanie: zostaw stary sklep w pełni działający do czasu stabilizacji nowego, zapisz, które zmiany DNS cofnąć, i ustal z góry, kto i przy jakich błędach podejmuje decyzję o powrocie. Zaplanuj też, jak przenieść zamówienia złożone w tym czasie.

50. Kiedy wyłączyć stary sklep i jak długo trzymać przekierowania?

Stary sklep wyłącza się dopiero wtedy, gdy wszystkie dane są przeniesione, zwroty i reklamacje mają gdzie trafić, a nowy sklep działa stabilnie. Przekierowania trzeba utrzymać dużo dłużej: Google zaleca co najmniej rok, a w praktyce najlepiej na stałe. Przy zmianie domeny utrzymaj także starą domenę.

Rozwiązanie: przed wyłączeniem zrób ostatni pełny eksport i archiwum danych. Nie usuwaj przekierowań ani starej domeny, a po wygaszeniu starej platformy upewnij się, że dostawca usunął dane klientów zgodnie z umową.

Od czego zacząć

Jeśli migrację dopiero planujesz, zacznij od problemów 3, 6, 7 i 21: zakresu, kopii testowej, pełnego eksportu danych i mapy przekierowań. Jeśli sklep jest już przeniesiony, sprawdź najpierw indeksowanie, przekierowania i płatności (problemy 46, 45 i 31), bo kosztują najwięcej każdego dnia. Stan nowego sklepu szybko pokaże bezpłatny skan sklepu: sprawdzi szybkość, dane strukturalne, podstawy SEO i wymagania prawne. Problemy, które pojawią się już po migracji na WooCommerce, opisujemy w liście 100 problemów z WooCommerce. Jeśli wolisz oddać migrację zespołowi, który na co dzień buduje i przenosi sklepy, zobacz naszą ofertę sklepów internetowych.