Migracja sklepu internetowego — plan krok po kroku, przekierowania 301 i eksport danych z platformy

Migracja sklepu internetowego to przeniesienie produktów, klientów, zamówień, treści i adresów URL ze starej platformy na nową — tak, żeby klient wchodzący ze starej zakładki i robot Google odwiedzający stary adres trafili we właściwe miejsce. Instalacja nowego sklepu to najmniejsza część tej pracy. Najwięcej ryzyka niesie to, co trzeba przenieść bez zmian: adresy, dane i opisy, na które od lat pracuje Twoja widoczność.

Nie znajdziesz tu obietnicy „zero spadków” — Google sam pisze, że wahania pozycji w czasie przenosin są normalne. Dostajesz plan w siedmiu krokach oparty na wytycznych Google dla przenosin ze zmianą adresów URL, dokumentacji eksportu danych od producentów platform (odczyt 30 września 2026 roku) i wymaganiach Core Web Vitals z web.dev, a do tego listę rzeczy do sprawdzenia, zanim przełączysz domenę.

Kiedy zmiana platformy sklepu ma sens, a kiedy nie

Migracja ma sens, gdy obecna platforma kosztuje więcej niż zmiana — w pieniądzach albo w utraconych możliwościach. Sama zmiana też kosztuje: pracę wykonawcy, czas zespołu, ryzyko przejściowego spadku ruchu i zamieszanie w obsłudze zamówień. Najczęstsze powody:

• Koszt. Abonament, opłaty od zamówień lub transakcji i płatne aplikacje rosną razem ze sprzedażą. Platformy SaaS liczą to bardzo różnie: jedne pobierają opłatę od zamówienia, inne dopłatę za bramkę płatności spoza własnej oferty, inne tylko abonament. Zanim uznasz, że inna platforma będzie tańsza, policz koszt całkowity dla swojej liczby zamówień w kalkulatorze TCO e-commerce i sprawdź zestawienie w tekście ile kosztuje sklep internetowy.
• Ograniczenia platformy. Brakuje integracji z ERP lub magazynem, nie da się obsłużyć cenników B2B, wielu walut albo rynków, a obejścia kosztują więcej niż nowy system.
• Koniec wsparcia albo produktu. Silnik open source przestaje dostawać aktualizacje bezpieczeństwa w Twojej wersji, a platforma SaaS zmienia właściciela lub znika. Przykład z polskiego rynku: w sierpniu 2021 roku Shoper przejął Shoplo i — jak podał w komunikacie prasowym — przejął klientów, umowy oraz prawa do marki i domen, ale „did not take over the technology and employees” (tłumaczenie własne: „nie przejął technologii ani pracowników”). Komunikat mówi o około 4 700 sklepach. Ich właściciele musieli zdecydować o dalszej platformie niezależnie od własnych planów.

Migracja zwykle nie ma sensu, gdy problemem jest wygląd, wolny szablon albo słaba konwersja na platformie, która poza tym spełnia Twoje potrzeby. Nowy motyw, optymalizacja obrazów czy prostszy koszyk to zmiany w obrębie tej samej platformy — tańsze i bez ryzyka utraty adresów. Jeśli nie wiesz, czy Twoja platforma jeszcze wystarcza, porównaj modele w tekście porównanie platform e-commerce albo rozwiąż quiz: jaka platforma e-commerce.

Migracja sklepu a SEO: co mówi Google o przenosinach z nowymi adresami URL

Zmiana platformy niemal zawsze zmienia adresy, a Google opisuje ten scenariusz w dokumencie [„Site moves with URL changes”](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) w Search Central. Inna struktura kategorii, inne końcówki adresów produktów, inne parametry filtrów — z dokumentu wynikają dla nich cztery zasady.

Przekierowania stałe po stronie serwera. Google zaleca „HTTP permanent redirects if possible, such as 301 and 308” (tłumaczenie własne: „stałe przekierowania HTTP, jeśli to możliwe, takie jak 301 i 308”). Każdy stary adres ma odsyłać bezpośrednio na swój nowy odpowiednik — nie na stronę główną i nie przez łańcuch kilku przekierowań.

Przekierowania na długo. Dosłownie: „Keep the redirects for as long as possible, generally at least 1 year.” (tłumaczenie własne: „Utrzymuj przekierowania tak długo, jak to możliwe, zasadniczo co najmniej rok”). Rok to minimum, a nie termin usunięcia: linki do Twoich produktów w starych artykułach, na forach i w zakładkach klientów nie znikną po dwunastu miesiącach.

Nowa mapa witryny. Google zaleca: „Submit the new sitemap in Search Console” (tłumaczenie własne: „Prześlij nową mapę witryny w Search Console”). Narzędzie do zmiany adresu w Search Console dotyczy tylko sytuacji „when moving from one domain or subdomain to another”, czyli zmiany domeny lub subdomeny. Jeśli sklep zostaje pod tą samą domeną, a zmieniają się tylko ścieżki, to narzędzie nie jest potrzebne.

Wahania pozycji są normalne. Google pisze wprost: „you may experience ranking fluctuations while Google recrawls and reindexes your site” (tłumaczenie własne: „możesz zaobserwować wahania pozycji, gdy Google ponownie skanuje i indeksuje Twoją witrynę”). Dla witryn średniej wielkości „it can take a few weeks or more” — „może to potrwać kilka tygodni lub dłużej”.

Z tego zdania wynika rzecz niewygodna dla każdego, kto sprzedaje migracje: nikt uczciwy nie zagwarantuje Ci, że pozycje nie spadną. Dobrze przygotowana migracja skraca okres wahań i zmniejsza ich skalę, bo Google szybko odnajduje każdą starą stronę pod nowym adresem, ale ponownego indeksowania nie wyłączy. Jeśli ktoś obiecuje „migrację bez spadku pozycji”, zapytaj, na jakiej podstawie — i ułóż budżet oraz kampanie tak, żeby kilka słabszych tygodni nie zachwiało sprzedażą.

Plan migracji sklepu internetowego w siedmiu krokach

Najpierw ustalasz, co trzeba przenieść, potem przenosisz i sprawdzasz, a dopiero na końcu przełączasz. Całość prowadzi jedna osoba, która zatwierdza przejście do kolejnego kroku. Nie musi to być programista, tylko ktoś, kto łączy platformę, marketing, obsługę klienta i SEO. Wszystkie punkty w formie listy do odhaczania znajdziesz w naszej checkliście migracji sklepu.

1. Inwentaryzacja adresów URL

Zbierz pełną listę adresów starego sklepu: produkty (także niedostępne i wycofane, jeśli mają ruch albo linki), kategorie, strony informacyjne, wpisy na blogu, strony producentów, ważne adresy z filtrami. Masz trzy źródła: crawler, który przejdzie po sklepie jak robot wyszukiwarki, mapę witryny obecnej platformy oraz Search Console i analitykę, które pokażą adresy z ruchem i wyświetleniami — także te, do których nie prowadzi już żaden link w menu. Oznacz adresy, które przynoszą ruch, sprzedaż lub linki z zewnątrz: one wymagają największej staranności.

Porządki przy okazji są w porządku, ale z umiarem. Usunięcie pustej kategorii czy produktu, którego nie ma od lat, nie szkodzi — pod warunkiem że jego adres i tak dostanie przekierowanie na najbliższą sensowną stronę.

2. Mapa przekierowań

Mapa przekierowań to arkusz z dwiema kolumnami — stary adres i nowy adres — i najważniejszy dokument całej migracji. Zasady:

• każdy stary adres wskazuje jeden konkretny nowy adres — produkt na produkt, kategorię na kategorię;
• produkt wycofany bez następcy przekieruj na kategorię, w której był, a nie na stronę główną;
• przekierowania mają być stałe (301 lub 308) i działać po stronie serwera, a nie przez skrypt w przeglądarce;
• żadnych łańcuchów: jeśli stary sklep ma już przekierowania z wcześniejszych zmian, zaktualizuj je tak, żeby prowadziły prosto pod nowy adres.

Z punktu widzenia SEO najwięcej problemów przy migracji sklepu robią adresy generowane automatycznie: warianty produktów, paginacja, wyniki filtrów. Ustal zawczasu, jak nowa platforma buduje takie adresy i czy pozwala zachować stare ścieżki. Jeśli pozwala, zachowanie tej samej struktury URL jest najprostszą ochroną przed wahaniami.

3. Eksport danych: produkty, klienci, zamówienia

Na platformach SaaS eksport to główna — często jedyna — droga wyjścia z danymi, a jego zakres różni się między platformami. Według stron pomocy odczytanych 30 września 2026 roku:

• Shoper: „Eksport plików CSV jest możliwy z zakładek: zamówienia, klienci, produkty, kupony rabatowe” (pomoc Shoper).
• Shopify: eksport klientów, zamówień i produktów do plików CSV opisany w centrum pomocy (klienci, zamówienia, produkty).
• IdoSell: eksport bazy klientów do CSV potwierdzony w pomocy IdoSell; eksportu produktów i zamówień nie potwierdziliśmy na stronie producenta — zapytaj dostawcę.
• Sky-Shop i Selly: eksport produktów opisany w pomocy (Sky-Shop, Selly); eksport zamówień i klientów potwierdziliśmy tylko pośrednio.
• Wix: produkty do CSV do 5 000 wierszy (bez produktów cyfrowych), zamówienia, kontakty do 50 000 (pomoc Wix).
• Squarespace: produkty do 10 000, zamówienia „available on all plans”, kontakty (pomoc Squarespace).
• BigCommerce: zamówienia i klienci w CSV lub XML, produkty w CSV; dane sklepu testowego są przechowywane 90 dni po zakończeniu okresu próbnego, potem usuwane (pomoc BigCommerce).

Wynikają z tego dwie rzeczy. Po pierwsze, plik CSV to dane, a nie sklep: szablon, konfigurację płatności i dostaw, reguły rabatów, aplikacje i przekierowania odtwarzasz ręcznie. Po drugie, eksport to połowa zadania — druga połowa to import w nowej platformie. Kolumny rzadko się pokrywają, więc przed właściwą migracją zrób próbny eksport i import na kilkudziesięciu rekordach, łącznie z wariantami produktów i zdjęciami.

Warunki wyjścia z platformy SaaS najlepiej sprawdzić przed wejściem. Dlaczego to część oceny każdej usługi w chmurze, piszemy w tekście o bezpieczeństwie danych w chmurze, a o modelu abonamentowym ogólniej — w przewodniku po SaaS.

Migracja z Shoper do PrestaShop. Shoper eksportuje zamówienia, klientów, produkty i kupony do CSV, więc dane wyjdą w formacie tabelarycznym. PrestaShop jest oprogramowaniem open source: sklep działa na Twoim serwerze albo w wersji PrestaShop Hosted, która według cennika producenta kosztuje 29 EUR miesięcznie bez VAT przy płatności miesięcznej lub 24 EUR przy rocznej (odczyt 30.09.2026; ceny się zmieniają). O wersji Hosted producent pisze: „you're free to recover all your ecommerce data if you want to stop your subscription” (tłumaczenie własne: „możesz odzyskać wszystkie dane sklepu, jeśli zrezygnujesz z subskrypcji”). Najwięcej pracy wymaga dopasowanie kolumn z plików Shopera do formatu importu PrestaShop i odtworzenie struktury kategorii tak, żeby mapa przekierowań miała na co wskazywać.

Migracja do Shopify. Shopify pozwala przetestować import przed zakupem: według polskiego cennika (odczyt 30.09.2026) okres próbny to 3 dni, potem 4 zł miesięcznie przez 3 miesiące. Plan Basic kosztuje 79 zł miesięcznie przy płatności rocznej lub 109 zł przy miesięcznej; cennik nie określa, czy to kwoty netto, czy brutto. Przed decyzją sprawdź koszty płatności: jeśli zostajesz przy własnej umowie z zewnętrzną bramką, Shopify dolicza opłatę za transakcje zewnętrzne — 2% w Basic, 1% w Grow, 0,6% w Advanced i 0,2% w Plus — ponad opłatę samej bramki. Nie dotyczy to metod ręcznych, takich jak płatność przy odbiorze. Alternatywą jest Shopify Payments, dostępne w Polsce.

4. Treści i metadane

Opisy, tytuły i metadane sprawiają, że strona pod nowym adresem jest „tą samą stroną”, a nie nową, którą Google musi ocenić od zera. Chodzi o opisy produktów i kategorii, tytuły stron, meta opisy, nagłówki, teksty alternatywne obrazów, dane strukturalne produktów i wpisy na blogu. Porównaj eksport treści ze starego i nowego sklepu pole po polu na próbce produktów z największym ruchem. Częsty problem: nowy szablon generuje tytuły i opisy według własnego wzoru i nadpisuje te, które ktoś latami dopracowywał.

Najważniejsza zasada tego etapu: nie zmieniaj wszystkiego naraz. Nowa platforma, nowa struktura kategorii, nowe opisy i nowy wygląd w jednym dniu to cztery zmiany, których skutków potem nie rozdzielisz. Najpierw przenieś sklep możliwie wiernie, a przebudowę treści i wyglądu zaplanuj na czas, gdy ruch się ustabilizuje.

5. Środowisko testowe

Nowy sklep powstaje na kopii danych, w środowisku testowym zablokowanym przed indeksowaniem — hasłem albo ograniczeniem dostępu. Kopia testowa widoczna dla Google to duplikat Twojego sklepu pod innym adresem. Z tego samego powodu nie zostawiaj po migracji publicznie dostępnej starej wersji „na wszelki wypadek” pod subdomeną: zachowaj pełną kopię danych i plików, a nie działający drugi sklep.

6. Testy przed przełączeniem

Na środowisku testowym sprawdź:

• przekierowania — całą mapę, automatycznie: czy każdy stary adres odpowiada kodem 301 lub 308, prowadzi prosto pod właściwy nowy adres i czy nie ma pętli ani błędów 404;
• ścieżkę zakupu — dla każdej metody płatności i każdego sposobu dostawy: zamówienie testowe, e-mail z potwierdzeniem, faktura, zwrot;
• analitykę — czy działają zdarzenia dodania do koszyka, rozpoczęcia zamówienia i zakupu oraz czy płatności wracające z bramki są prawidłowo rejestrowane;
• integracje — magazyn, ERP, marketplace, kurierzy;
• wydajność — Core Web Vitals na kluczowych szablonach: strona główna, kategoria, produkt, koszyk (szczegóły niżej).

7. Dzień przełączenia

Wybierz dzień z mniejszym ruchem i bez kampanii promocyjnych. Na chwilę wstrzymaj zmiany w katalogu, żeby ostatni eksport był kompletny, przenieś zamówienia złożone w ostatnich godzinach, włącz przekierowania, przełącz domenę i od razu sprawdź na żywo próbkę starych adresów oraz testowe zamówienie. Tego samego dnia prześlij nową mapę witryny w Search Console. Kampanie płatne przestaw na nowe adresy, zamiast polegać na przekierowaniach.

Dane i konta klientów po migracji

Konta klientów to najbardziej niedoceniana część migracji. Zanim wyznaczysz datę przełączenia, ustal z oboma dostawcami — starym i nowym — trzy sprawy.

Hasła. Dokumentacja eksportu cytowana wyżej mówi o danych klientów, ale nie obiecuje przeniesienia haseł. Zapytaj starego dostawcę, czy i w jakiej formie hasła można wyeksportować, a nowego — czy potrafi je przyjąć. Jeśli którakolwiek odpowiedź brzmi „nie”, przygotuj komunikację: e-mail do klientów z informacją o nowym sklepie i instrukcją ustawienia hasła, wysłany w dniu przełączenia, oraz jasny komunikat na stronie logowania.

Zgody i historia. Sprawdź, czy eksport zawiera zgody marketingowe (z datą i źródłem, jeśli stara platforma je zapisuje), historię zamówień potrzebną do obsługi reklamacji i zwrotów oraz adresy dostaw. Zgody na newsletter przenoś tylko wtedy, gdy masz ich zapis, a sposób przeniesienia danych osobowych skonsultuj z osobą odpowiedzialną w Twojej firmie za ochronę danych. Eksport klientów to plik z danymi osobowymi: przechowuj go i przesyłaj tak jak każdą inną bazę klientów, a kopie robocze usuń po zakończeniu migracji.

Zamówienia. To, że stara platforma eksportuje zamówienia do CSV, nie znaczy, że nowa zaimportuje je jako pełną historię. Czasem wystarczy archiwum poza sklepem, a czasem historia musi być widoczna na koncie klienta. Ustal to na początku, bo od tego zależy zakres prac.

Wydajność i Core Web Vitals po migracji

Zmierz Core Web Vitals przed migracją, na tych samych typach stron, które zmierzysz po niej — bez punktu odniesienia nie ocenisz, czy przenosiny pomogły. Nowa platforma i nowy szablon zmieniają szybkość sklepu, na lepsze albo na gorsze.

W starych notatkach z audytów jedna rzecz się zdezaktualizowała: wskaźnik FID (First Input Delay) nie jest już częścią Core Web Vitals. Zespół web.dev ogłosił: „INP will officially become a Core Web Vital and replace FID on March 12 of this year” (tłumaczenie własne: „INP oficjalnie stanie się jednym z Core Web Vitals i zastąpi FID 12 marca tego roku”) — chodzi o 12 marca 2024 roku (web.dev). INP (Interaction to Next Paint) opisuje, jak szybko strona reaguje na działania użytkownika: kliknięcia, dotknięcia, naciśnięcia klawiszy.

Progi według web.dev: „An INP below or at 200 milliseconds means a page has good responsiveness” (tłumaczenie własne: „INP na poziomie 200 milisekund lub niżej oznacza dobrą responsywność”); od 200 do 500 ms wynik wymaga poprawy, powyżej 500 ms jest słaby. Przy migracji zwróć szczególną uwagę na skrypty zewnętrzne — widżety czatu, recenzji, rekomendacji, piksele reklamowe — i na filtry w kategoriach. Każda przeniesiona aplikacja to kolejny kod wykonywany w przeglądarce klienta, więc sprawdź, które są jeszcze potrzebne.

Przed migracją i po niej mierz LCP, INP i CLS dla strony głównej, kategorii, karty produktu i koszyka, osobno na telefonie i komputerze, w Search Console oraz w PageSpeed Insights. Dane z rzeczywistych wizyt zbierają się z opóźnieniem, więc pełny obraz po migracji zobaczysz po kilku tygodniach. Szerzej o technicznym SEO sklepu piszemy w przeglądzie SEO w e-commerce, a elementy koszyka i zamówienia do sprawdzenia przy okazji zebraliśmy w checkliście UX sklepu.

Pierwsze 90 dni po migracji: co monitorować

Przez pierwsze trzy miesiące po przełączeniu sprawdzasz, czy Google i klienci odnaleźli się pod nowymi adresami.

Pierwszy tydzień. Codziennie przeglądaj błędy 404 — w Search Console i w logach serwera lub panelu platformy. Każdy stary adres, który zwraca 404, a ma ruch albo linki, dopisz do mapy przekierowań. Pilnuj zamówień: czy spływają, czy płatności się księgują, czy e-maile dochodzą. Porównuj konwersję z tym samym okresem przed migracją.

Pierwszy miesiąc. W Search Console śledź indeksowanie nowych adresów i znikanie starych z wyników. Porównuj ruch organiczny i wyświetlenia z okresem sprzed przenosin, pamiętając, że według Google wahania przez kilka tygodni lub dłużej są normalne. Poproś właścicieli najważniejszych linków zewnętrznych — partnerów, katalogi branżowe, porównywarki — o aktualizację adresów. Przekierowanie działa, ale bezpośredni link jest pewniejszy.

Drugi i trzeci miesiąc. Gdy ruch się ustabilizuje, wprowadź zmiany odłożone na później: poprawki treści, wyglądu, struktury. Każdą osobno, żeby widzieć jej skutek. Porównaj Core Web Vitals z pomiarem sprzed migracji.

Przez cały rok i dłużej. Nie usuwaj przekierowań. Google zaleca utrzymać je „generally at least 1 year”, a w praktyce najlepiej tak długo, jak działa sklep. Przy kolejnej zmianie serwera lub platformy mapa przekierowań z tej migracji przechodzi razem ze sklepem.

Jeśli nowy sklep działa w modelu SaaS, dostępność i czas reakcji na awarie wyznacza umowa z dostawcą. Co w niej sprawdzić, opisujemy w tekście o SLA.

Migracja na headless

Przejście na headless podlega tym samym zasadom, ale adresy, metadane i dane strukturalne musisz zaprojektować sam. W tej architekturze frontem sklepu jest osobna aplikacja, a silnik (SaaS albo open source) dostarcza produkty, koszyk i zamówienia przez API. Mapa przekierowań, eksport i test importu, środowisko testowe i monitoring obowiązują bez zmian. Różnica polega na tym, że adresy URL, metadane i dane strukturalne generuje Twój własny front, a nie szablon platformy. Kiedy taki krok się opłaca, a kiedy wystarczy klasyczny sklep, opisujemy w tekście headless czy klasyczny sklep. Sami budujemy sklepy w tym modelu — szczegóły na stronie oferty sklepu headless.

Wszystkie teksty o wyborze i zmianie platformy znajdziesz w przeglądzie platform e-commerce.