PrestaShop na WooCommerce — co dokładnie chcesz zrobić?

Pod hasłem „prestashop na woocommerce” kryją się dwie różne decyzje. Pierwsza: masz działający sklep na PrestaShop i chcesz przenieść katalog, klientów i zamówienia do WooCommerce. Druga: sklepu jeszcze nie ma, a Ty porównujesz platformy przed startem. Ten tekst dotyczy wyłącznie pierwszej sytuacji. Mapa danych z dalszej części przyda się też przy porównaniu, ale widełki godzinowe i uwagi o RODO już nie.

Trzy sygnały, że to faktycznie migracja, a nie porównanie:

• Sklep stoi na PrestaShop 1.6 lub wczesnym 1.7 i od lat nie był aktualizowany. Te wersje nie obsługują PHP 8.x — po podbiciu PHP na serwerze dostajesz biały ekran albo błędy w koszyku. Aktualizacja z 1.6 do 1.7/8/9 to osobny projekt, często droższy niż sama migracja.
• Nie masz dewelopera PHP w okolicy. Lokalne agencje robią WordPressa i WooCommerce, na PrestaShop nikt nie chce brać serwisu. Efekt: każda poprawka w module płatności czeka tygodniami.
• Zespół i tak pracuje w WordPressie. Blog firmowy, landing page pod kampanie i treści idą przez WP, marketing dodaje wpisy bez programisty, a sklep żyje osobnym życiem.

Jedno zdanie prawdy, które trzeba powiedzieć wprost: PrestaShop nie jest porzucony. Wersje 9.2 i 10 są nadal rozwijane — jeśli Twój sklep jest na aktualnej gałęzi, migracja jest decyzją biznesową o koszcie utrzymania, dostępności ludzi i ekosystemie, a nie ratunkiem przed dead-endem. Zanim cokolwiek przeniesiesz, sprawdź, czy problemem jest platforma, czy zaniedbany serwer i nieaktualne moduły. Pomocne bywa porównanie z naszym omówieniem co sprawdzić przed aktualizacją do PrestaShop 9.2.

Dalej omawiamy pięć rzeczy, które decydują o powodzeniu projektu: mapowanie danych, hasła i dane osobowe (RODO), przekierowania 301, wydajność przy Twojej liczbie SKU oraz realny koszt godzinowy — tak, żebyś umiał zestawić ze sobą dwie oferty wykonawców i wiedzieć, czego w nich szukać.

PrestaShop czy WooCommerce — kiedy migracja ma sens, a kiedy lepiej zostać

Nie sprzedam Ci migracji, jeśli nie jest Ci potrzebna. Poniżej pięć kryteriów, które naprawdę różnicują obie platformy w polskich warunkach — bez ogólników o „nowoczesności”.

Kryterium	PrestaShop	WooCommerce
Koszt utrzymania	Więcej modułów płatnych rocznie, każda aktualizacja core wymaga dewelopera PHP	Core darmowy, płatne bywają wtyczki; aktualizacje robisz sam, ryzyko konfliktu wtyczek
Dostępność deweloperów	Wąska grupa specjalistów, wyższa stawka godzinowa, dłuższy czas reakcji	Szeroki rynek — WP robi większość agencji i freelancerów w Polsce
Ekosystem wtyczek	Mniejszy katalog modułów, wyższa średnia jakość, ale i wyższa cena	Dziesiątki tysięcy wtyczek, jakość bardzo nierówna — trzeba czytać changelogi
Wydajność przy liczbie SKU	Dobrze trzyma 20–50 tys. SKU przy włączonym cache i sensownych indeksach	Do ok. 2000 SKU działa swobodnie na przeciętnym hostingu
Hosting i cache	Wymaga PHP zgodnego z wersją sklepu, mniej gotowych szablonów hostingowych	Szeroka oferta, Redis i object cache dostępne w standardzie na VPS

Progi skali. Do ok. 2000 SKU WooCommerce jedzie bez problemu na hostingu za 50–150 zł miesięcznie, z cache stron i PHP 8.2. Przy 20–50 tys. SKU musisz założyć cache obiektowy (Redis), HPOS (High-Performance Order Storage) i plan wydajnościowy — bez tego lista produktów i koszyk klękną przy pierwszej kampanii.

Zostań na PrestaShop, jeśli: masz silną bazę wariantów z indywidualnymi cenami i regułami rabatowymi, moduły ERP są już wdrukowane w procesy magazynowe, a sklep działa wielojęzycznie na jednym backendzie (w WooCommerce to WPML/Polylang i w praktyce druga kopia produktów). WooCommerce realnie wygrywa, gdy: potrzebujesz content marketingu spiętego z katalogiem w jednej instalacji, zespół zna WP, a Twoje integracje (CRM, mailing, program lojalnościowy) nie mają modułów do PrestaShop. Sprawdź też, jak wygląda wysyłka w PrestaShop i WooCommerce — integracje kurierskie to najczęstsze zaskoczenie po migracji.

Mapa danych: co przenosi się z PrestaShop do WooCommerce, a co nie

Zanim podpiszesz umowę, poproś wykonawcę o mapowanie tabel — nie o „wycenę migracji”. Poniżej punkt wyjścia do takiej rozmowy. Nazwy tabel PrestaShop mają prefiks ps_, w WordPressie produkty i zamówienia siedzą w innych strukturach, niż podpowiada intuicja.

Co nie ma odpowiednika 1:1: ceny i zdjęcia per kombinacja (w PrestaShop każda kombinacja może mieć własną cenę i własne zdjęcia — w WooCommerce wariant ma jedno zdjęcie i nadpisanie ceny); reguły specific_price (rabaty per klient, grupa, ilość — w WooCommerce trzeba je odtworzyć jako coupons lub wtyczkę dynamic pricing); przedziały przewoźników (carrier ranges — cennik zależny od wagi i kwoty nie przenosi się, konfigurujesz strefy i progi od zera).

Trzy warianty zakresu. Sam katalog to najczęściej 20–60 godzin pracy. Katalog plus klienci: +8–16 godzin. Pełna historia zamówień: +20–60 godzin, zależnie od liczby rekordów i bałaganu w statusach. W wielu projektach historia zamówień zostaje na starym sklepie jako archiwum — na subdomenie, w trybie tylko do odczytu, z wyłączonym koszykiem. To najtańsza i najbezpieczniejsza opcja.

RODO i hasła. Przenoszenie danych klientów wymaga podstawy prawnej i umowy powierzenia przetwarzania (art. 28 RODO) z wykonawcą, a także zasady minimalizacji — nie migruj kont z 2015 roku, które nigdy nie złożyły zamówienia. Hasła: PrestaShop 1.7 przechowuje je jako bcrypt, WordPress domyślnie w formacie phpass. Hashe nie są kompatybilne, więc realne opcje to wymuszenie resetu hasła przy pierwszym logowaniu albo wtyczka obsługująca stary format. Struktury tabel sprawdzisz w dokumentacji deweloperskiej PrestaShop oraz w dokumentacji WooCommerce — zanim uwierzysz na słowo, że „wszystko się przeniesie”.

Migracja krok po kroku — 7 etapów z realnym czasem

Migrację warto rozbić na etapy, dla których da się policzyć godziny. Wtedy oferta wykonawcy przestaje być jedną kwotą, a staje się listą pozycji do porównania z innymi ofertami.

• Audyt i eksport — 4–8 h. Zrzut bazy, lista produktów z kombinacjami, kategorie, klienci, zamówienia, strony CMS, zdjęcia w oryginalnych rozmiarach.
• Mapowanie danych — 8–24 h. Ustalenie, co w WooCommerce zostanie produktem, a co wariantem; jak traktować cechy, rabaty, grupy klientów i stany magazynowe. Wynik w arkuszu, nie w głowie wykonawcy.
• Import — 8–16 h. WP All Import albo skrypt na WP-CLI, partiami po 500–1000 rekordów, z logiem błędów i możliwością powtórzenia paczki.
• Szablony i moduły — 16–40 h. Theme, karta produktu, koszyk i checkout blokowy oraz zamiana funkcji z modułów PrestaShop na wtyczki WooCommerce — to zwykle najszerszy widełkowy etap.
• Płatności i wysyłka — 8–16 h. Bramki, metody dostawy, waga i gabaryty, próg darmowej dostawy. Konfigurację wysyłki po obu stronach opisujemy szerzej w materiale wysyłka w PrestaShop i WooCommerce.
• SEO i 301 — 8–16 h. Osobny etap, opisany niżej.
• Testy — 8–16 h. Scenariusze akceptacyjne, nie „klikanie po sklepie”.

Suma: 60–136 h. Jeśli oferta opiewa na 20 h, ktoś albo czegoś nie policzył, albo pominie mapowanie i testy. Zakres naszych wdrożeń i migracji PrestaShop zawsze zaczyna się od audytu, bo bez niego widełki są zgadywaniem.

Staging odseparowany od produkcji. Kopia bazy na subdomenie, noindex przez nagłówek X-Robots-Tag oraz wtyczkę blokującą indeksację, dodatkowo login na HTTP auth (.htpasswd). Wyłączone crony (WP Crontrol), zablokowana wysyłka maili transakcyjnych i odpięte webhooki bramek płatniczych — inaczej testowe zamówienie pojedzie do prawdziwego operatora płatności.

Kolejność krytyczna: mapa URL-i gotowa PRZED importem. Strukturę produktów (slug, kategoria nadrzędna) buduje się pod docelowe adresy; poprawianie tego po fakcie to podwójna robota i ryzyko 404.

Okno zamrożenia: 2–6 h. Finalne dosynchronizowanie zamówień i klientów oraz przełączenie DNS. TTL domeny obniżony do 300 s na 24–48 h wcześniej, żeby propagacja nie trwała pół dnia.

Testy akceptacyjne: po 3 zamówienia w każdej metodzie płatności, po jednym z InPost, DPD i DHL, sprawdzenie maila transakcyjnego, faktury, statusu płatności w panelu i cofnięcia zamówienia.

Hasła klientów — pułapka, która psuje migrację najczęściej

Najczęstszy objaw „zepsutej migracji” nie ma nic wspólnego z szablonem: klienci nie mogą się zalogować i masowo proszą o reset hasła. Powód jest techniczny i znany z góry.

PrestaShop 1.7 i nowsze trzyma hasła w bcrypt (funkcja password_hash), a 1.6 w MD5 z solą opartą na COOKIE_KEY. WordPress i WooCommerce korzystają z phpass. Hashe nie są kompatybilne — skopiowanie kolumny password do wp_users.user_pass sprawi, że wp_check_password odrzuci każdą próbę logowania. Szczegóły formatu opisuje dokumentacja deweloperska PrestaShop.

Rozwiązanie: rehash-on-login. Podpinamy się pod filtr authenticate (lub wp_authenticate_user) i działamy tak:

• pobieramy stary hash z tabeli tymczasowej zaimportowanej z PrestaShop, dopasowanej po e-mailu;
• weryfikujemy: password_verify($plain, $hash) dla bcrypt albo md5($cookieKey.$plain) dla 1.6;
• jeśli hasło pasuje, wywołujemy wp_set_password() — klient dostaje normalny hash phpass i od tej chwili loguje się standardowo;
• rekord tymczasowy usuwamy, żeby baza nie trzymała dwóch prawd o haśle.

To jeden plik, około 60 linii, wrzucony jako mini-wtyczka (mu-plugin). Nie potrzeba do tego płatnego rozszerzenia.

Koszt alternatywy. Masowy reset hasła to spadek logowań i powtórnych zakupów. Z naszych obserwacji wynika, że realnie kilkanaście do kilkudziesięciu procent klientów po takim zabiegu nie wraca w najbliższych miesiącach — a to ruch, który już raz zapłacił za pozyskanie.

Test przed startem. Minimum 20 kont z różnymi znakami specjalnymi w haśle: polskie znaki, cudzysłowy, ampersand, spacja, znak mniejszości. Sprawdź też logowanie przez API (legacy webservice lub REST), jeśli sklep z niego korzysta, oraz aplikację mobilną — tam bywa osobna ścieżka uwierzytelniania i łatwo ją pominąć. Cały etap warto wpisać w checklistę audytu i przygotowania sklepu do migracji.

SEO przy przejściu na WooCommerce: URL-e, 301 i to, co najczęściej ginie

Konflikt wzorców adresów. PrestaShop domyślnie generuje /123-nazwa-produktu.html — z ID i rozszerzeniem. WooCommerce daje /produkt/nazwa-produktu/. Zachowanie starych permalinków jest technicznie możliwe (własne reguły rewrite i parser), ale kosztuje zwykle 8–16 h więcej i komplikuje aktualizacje. Drugie wyjście: pełna mapa 301 ze starego adresu na nowy. Wybierz świadomie, nie „jak wyjdzie”.

Kombinacje produktów. W PrestaShop część konfiguracji generuje osobne URL-e dla wariantów. W WooCommerce warianty siedzą pod jednym adresem produktu nadrzędnego. Dla starych adresów wariantów ustawiasz 301 na produkt nadrzędny — nigdy 404. To najczęstsze miejsce, w którym po migracji wyparowuje ruch long tail.

Skąd wziąć listę starych adresów: Search Console → Wydajność → Strony za 12 miesięcy, eksport z Analytics za ten sam okres, sitemap.xml z GSC oraz logi serwera jako uzupełnienie. Do tego pomiar etapów sprzedaży w GA4 — bez niego nie ocenisz, czy spadek dotyczy ruchu, czy konwersji.

Elementy mapy: produkty 1:1, kategorie 1:1, strony CMS na odpowiedniki w WordPressie, paginacja i filtry — z jawną decyzją: zostawiamy z 301 czy zamykamy noindex. Brak decyzji to najczęściej tysiące miękkich 404 w GSC.

Higiena wdrożenia: 301, nie 302; bez łańcuchów przekierowań (A→B→C skracaj do A→C); nowy sitemap zgłoszony w GSC; uporządkowany robots.txt; monitoring przez 90 dni na raporcie 404 i spadku CTR w GSC. Po starcie sprawdź też Core Web Vitals — nowy szablon zmienia LCP i CLS, a te liczby wpływają na to, jak Google traktuje stronę.

Najczęstsze błędy: brak przekierowania starych kategorii (spadek widoczności list produktów), polskie znaki w slugach — stare adresy z %C5%82, %C4%99 po podwójnym zakodowaniu dają 404, oraz pominięcie stron CMS, które przez lata zbierały linki.

Wydajność i wtyczki: gdzie WooCommerce zaczyna odstawać od PrestaShop

WooCommerce nie jest wolniejsze „z natury”. Jest cięższe przy tej samej liczbie funkcji: każdy request dociąga WordPressa, rdzeń WooCommerce i wszystkie aktywne wtyczki. W PrestaShop odpowiednikiem są moduły, więc pytanie nie brzmi „który CMS jest szybszy”, tylko „ile kodu ładuje się przy każdym wejściu na kartę produktu i czy da się to odciąć cache’em”. Zanim przepiszesz funkcje sklepu na wtyczki WooCommerce, porównaj je z tym, co masz po stronie modułów i integracji PrestaShop — część z nich nie ma sensownego odpowiednika 1:1.

Praktyczny limit to 20–25 aktywnych wtyczek. Powyżej tego progu zaczyna się praca, której nikt nie wycenił: konflikty w hookach, podwójne ładowanie bibliotek JS, dwie wtyczki przechwytujące ten sam filtr woocommerce_product_get_price. Każda kolejna wtyczka to nie tylko kilka zapytań SQL, ale też wyższy TTFB i dłuższy czas do pierwszej interakcji. Diagnostyka takiego konfliktu to zwykle 2–6 godzin wyłączania wtyczek po kolei.

Minimum wydajnościowe przy katalogu powyżej 1000 SKU: page cache (WP Rocket, LiteSpeed Cache albo cache serwerowy), cache obiektowy w Redisie z wyłączeniem koszyka i checkoutu, OPcache w PHP oraz CDN na statyce. Bez tego filtry wariantów i sortowanie dokładają 300–800 ms do odpowiedzi serwera — warianty w WooCommerce siedzą w postmeta i taxonomy, więc filtrowanie po dwóch atrybutach generuje kilka JOIN-ów. TTFB i LCP to elementy Core Web Vitals, więc nie da się tego zrzucić na „kosmetykę”.

Kiedy własna wtyczka zamiast trzech płatnych: policz 3 × licencja roczna i porównaj z godzinami wdrożenia. Trzy wtyczki po 400 zł/rok to 1200 zł rocznie, własny moduł to 16–24 h pracy, czyli przy stawce 150 zł/h 2400–3600 zł. Zwrot po 2–3 latach — ale mniej kodu to mniej niespodzianek przy aktualizacjach WordPressa.

Hosting: PHP 8.2 lub nowsze, MySQL 8.0 / MariaDB 10.6+, InnoDB, minimum 512 MB na proces PHP. Przy bazie z historią zamówień rozdziel aplikację i bazę na osobne instancje — import zamówień i przejście na tabele HPOS potrafią położyć panel.

Ile kosztuje migracja z PrestaShop na WooCommerce — widełki, nie cennik z sufitu

Wycena to godziny × stawka, nie ryczałt z sufitu. Poniżej widełki dla sklepu, który przenosi katalog, klientów i zamówienia — nie dla „przerobienia szablonu”. Zakres prac po stronie docelowej opisuje dokumentacja WooCommerce i na jej podstawie warto rozpisać mapowanie kategorii, atrybutów i wariantów jeszcze przed podpisaniem umowy.

• Co podnosi koszt: niestandardowe moduły PrestaShop (każdy trzeba przepisać albo zastąpić wtyczką), indywidualne ceny per kombinacja, wielojęzyczność i multi-store (WooCommerce nie ma tego w rdzeniu — potrzebny WPML lub Polylang z licencjami), integracja z ERP po stronie WooCommerce.
• Co obniża: czysty katalog bez historii zamówień, brak modułów pisanych na zamówienie, decyzja o zachowaniu obecnych bramek płatności i przewoźników. Jeśli zostajesz przy tym samym operatorze, nie płacisz za nową integrację — sprawdź tylko, czy integracje wysyłkowe w PrestaShop i WooCommerce obsługują te same metody nadania.

Koszty po migracji to osobna pozycja w budżecie: licencje wtyczek (koszyk, filtry, wielojęzyczność, SEO) zwykle 1500–4000 zł rocznie, koszt utrzymania i administracji, plus czas na aktualizacje WordPressa i testy po każdej z nich. Sklep na PrestaShop też kosztuje — różnica polega na tym, że w WooCommerce więcej rzeczy dokupujesz jako wtyczki.

O co zapytać wykonawcę, żeby porównać oferty: czy w cenie jest import historii zamówień, czy tylko katalogu; kto robi mapowanie kombinacji na warianty; jak wygląda przeniesienie URL-i i przekierowania 301 ze struktury PrestaShop na permalinki WooCommerce; czy jest etap testów na kopii stagingowej i kto go wykonuje; czy wycena obejmuje konfigurację cache, CDN i PHP; co dzieje się z meta opisami, canonicalami i sitemapą. Oferta bez odpowiedzi na te punkty jest o 30–40% tańsza tylko dlatego, że czegoś w niej nie ma. Audyt starego sklepu przed migracją to osobne 8–16 h — przygotowanie sklepu PrestaShop do migracji bez tego etapu kończy się dopłacaniem w trakcie.

Plan B: jak zabezpieczyć migrację i kiedy się wycofać

Backup to nie „mamy kopię na hostingu”. Przed przełączeniem zrób zrzut bazy (mysqldump --single-transaction --quick) i archiwum plików (tar z katalogiem sklepu), a potem wynieś oba poza serwer — S3, Backblaze B2 albo zwykły dysk. Kopia, której nie odtworzyłeś na stagingu, nie istnieje. Sprawdź, czy zawiera zdjęcia produktów, PDF-y faktur i załączniki z katalogu /img — najczęściej pomijanego przy „szybkich” backupach.

TTL DNS obniż na 300 s na 24 h przed przełączeniem. Najpierw sprawdź aktualną wartość: jeśli masz 86400, stary rekord będzie cache’owany przez resztę doby także po zmianie. Zmieniaj rekord A/CNAME, nie nameservery. Efekt: rollback skraca się z godzin do minut, a klienci nie trafiają na stary IP przez pół dnia.

Stary sklep zostaw w trybie tylko do odczytu na 2–4 tygodnie. W PrestaShop wyłącz składanie zamówień (tryb katalogu w parametrach produktów) i dezaktywuj moduły płatności, ale zostaw logowanie i historię zamówień — klient, który szuka faktury, musi ją znaleźć. Wystaw to jako archiwum.domena.pl z noindex i bez linkowania. Publiczne URL-e produktów rób 301 na nowe adresy, inaczej zrobisz sobie duplikację treści i stracisz pozycje. W Search Console dodaj nową sitemapę i pilnuj raportu błędów 404 przez pierwszy miesiąc.

Kryteria rollbacku — ustal je na piśmie przed startem:

• brak możliwości złożenia zamówienia w którejkolwiek metodzie płatności,
• masowe błędy 5xx na koszyku lub checkoutcie,
• spadek ruchu organicznego powyżej 30% w 14 dni bez wyjaśnienia (np. awarii hostingu).

Dodaj do tego jedną osobę z prawem powiedzenia „wracamy” i okno decyzyjne, np. 48 h. Bez tego rollback zamienia się w tygodnie dyskusji, a sklep traci zamówienia w obu wersjach jednocześnie.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Spis SKU, kombinacji i wariantów — Zanim poprosisz o wycenę — policz produkty i kombinacje. Inny nakład to 800 SKU, inny 20 tys., a różnica siedzi właśnie w wariantach.
• Eksport katalogu do CSV — Zrób eksport produktów, kombinacji, kategorii, producentów i cech. Sprawdź, czy plik otwiera się poprawnie i czy liczba wierszy zgadza się z backendem.
• Lista modułów i ich odpowiedników w WooCommerce — Wypisz każdy aktywny moduł i zaznacz: przenosimy wtyczką, piszemy custom, zostaje w PrestaShop. Bez tego lista ukrytych kosztów pojawi się po fakturze.
• Mapa URL-i i reguły 301 — Gotowa przed importem — produkt, kategoria, producent, wpisy CMS. Sprawdź po wdrożeniu na próbce 20 adresów.
• Decyzja o historii zamówień — Trzy warianty: tylko katalog, katalog z klientami, pełna historia. Każdy kolejny wydłuża projekt — wybierz świadomie, nie „na wszelki wypadek”.
• Podstawa prawna i zakres danych osobowych — Ustal, które dane klientów przenosisz i na jakiej podstawie. Skonsultuj z osobą odpowiedzialną za RODO w firmie, nie z wykonawcą.
• Staging z noindex i HTTP auth — Sprawdź, czy kopia bazy nie jest indeksowana i czy dostęp ma tylko ekipa projektowa. Test na stagingu, nie na produkcji.
• Testy płatności — 3 zamówienia na metodę — Przelewy, BLIK, karta, płatność za pobraniem. Każda metoda: trzy zamówienia, w tym jedno z kodem rabatowym i jedno z darmową dostawą.
• Testy wysyłki — InPost, DPD, DHL — Sprawdź generowanie etykiet, przedziały wagowe i cenniki przewoźników. W PrestaShop carrier ranges nie mają odpowiednika 1:1, więc testuj każdy próg.
• Wydajność przy Twojej skali SKU — Do ok. 2000 SKU przeciętny hosting wystarcza. Przy 20–50 tys. SKU zaplanuj Redis i plan wydajnościowy — sprawdź to przed startem, nie po.
• Backup starego sklepu i bazy — Pełny zrzut plików i bazy z datą. Trzymaj go minimum 30 dni po przełączeniu — to Twoje jedyne archiwum, jeśli coś pójdzie nie tak.
• Obniżony TTL DNS — 24 h przed przełączeniem zejdź do 300 s. Skraca to czas propagacji i realnie skraca okno zamrożenia sklepu.
• Sitemap i Search Console po wdrożeniu — Zgłoś nową sitemapę, sprawdź indeksację po 7 i 30 dniach. Porównaj ruch z 301 z ruchem sprzed migracji.
• Testy akceptacyjne przed odbiorem — Zamówienie gość, zamówienie z konta, zwrot, zmiana statusu, mail potwierdzający. Podpisujesz odbiór dopiero, gdy wszystko przechodzi na stagingu i po przełączeniu.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• PrestaShop – dokumentacja dla deweloperów
• WooCommerce – dokumentacja