Wdrożenie PrestaShop w Zwierzynu – zakres, którego nie widać w cennikach

Instalacja PrestaShop to kilkanaście minut: wgrywasz pliki przez panel hostingu albo używasz instalatora, tworzysz bazę, przechodzisz kreator i masz sklep pod adresem testowym. Wdrożenie produkcyjne to inna praca – polega na przygotowaniu środowiska, które obsłuży ruch, płatności i faktury bez wywracania się przy pierwszej promocji.

Minimalny zakres, którego zwykle nie ma w cenniku „instalacja sklepu”:

• Hosting – dla kilkudziesięciu produktów wystarczy dobry hosting współdzielony, ale przy kilku tysiącach SKU i integracjach potrzebny jest VPS z min. 4 GB RAM i dyskiem NVMe. Sprawdź limity max_execution_time (min. 120 s) i memory_limit (min. 256 MB).
• PHP – PrestaShop 8 obsługuje PHP 8.1–8.2. Jeśli hosting trzyma Cię na 7.4, zmień hosting przed wdrożeniem, nie po.
• SSL i domena – certyfikat Let’s Encrypt kosztuje 0 zł, ale wymuszenie HTTPS, przekierowanie www i ustawienie domeny głównej w PrestaShop to osobne czynności.
• Szablon – zakup to 300–1500 zł, natomiast dopasowanie układu kategorii, kart produktu i mobile to zwykle 10–25 h pracy.
• Płatności – Przelewy24, tpay, PayPal. Każda wymaga konfiguracji w panelu operatora, adresu powrotu (webhook) i testu w trybie piaskownicy.
• Kurierzy – InPost, DPD, DHL: mapy paczkomatów, cenniki wg wagi i stref, darmowa dostawa od progu.
• Faktury i podatki – integracja z Fakturownia lub wFirma, reguły VAT, ceny brutto/netto, przy sprzedaży do UE kwestia OSS.

Do tego dochodzą elementy, o których zapomina się najczęściej: SMTP do e-maili transakcyjnych (bez tego potwierdzenia zamówień lądują w spamie), automatyczny backup bazy i plików, monitoring dostępności oraz feed do Google Merchant Center.

Sklep z Zwierzyńca, Zamościa czy Krasnegostawu nie różni się technicznie od sklepu z Warszawy. Praca zdalna działa dobrze, o ile na starcie ustalicie kanał zgłaszania uwag, dostępy do paneli i jedną osobę decyzyjną. Jak to poukładać, opisaliśmy w artykule o organizacji wdrożenia PrestaShop w Zamościu. Techniczne szczegóły wersji i modułów znajdziesz w dokumentacji dla deweloperów PrestaShop.

Migracja do PrestaShop w 7 etapach – harmonogram dla MŚP

Migracja z WooCommerce albo PrestaShop 1.6 to nie jedno zadanie, tylko sekwencja. Poniżej rozbicie na siedem etapów dla sklepu od kilkuset do kilku tysięcy produktów. Czasy dotyczą projektu prowadzonego równolegle, bez czekania tygodniami na materiały po Twojej stronie.

• 1. Audyt (2–3 dni). Zliczasz produkty, kombinacje, zamówienia, klientów i aktywne adresy URL. Spisujesz wtyczki lub moduły, które trzeba zastąpić. Ustalenie, że w Woo jest 3400 SKU i 18000 URL-i zmienia cały plan.
• 2. Backup (0,5–1 dnia). Pełna kopia plików i bazy, a potem test odtworzenia na subdomenie. Backup, którego nie odtworzyłeś, nie jest backupem.
• 3. Mapa URL (2–4 dni). Eksport adresów z sitemap i logów serwera, dopasowanie do nowej struktury, przekierowania 301 w .htaccess lub module. Zasada: jeden stary URL = jedno przekierowanie, bez łańcuchów. O tym, jak działa kod 301, pisze MDN w dokumentacji HTTP.
• 4. Import danych (3–10 dni). Produkty, kategorie, zdjęcia, cechy, kombinacje, klienci, opcjonalnie zamówienia. Import przez wbudowany CSV w PrestaShop dławi się przy dużych plikach – powyżej 5 tys. SKU lepiej użyć skryptu.
• 5. Konfiguracja (5–10 dni, może iść równolegle z importem). Strefy podatkowe, przewoźnicy, płatności, statusy zamówień, szablony e-mail, uprawnienia pracowników.
• 6. Testy (5–10 dni). Zamówienie testowe każdą metodą płatności i kurierem, faktura, mail potwierdzający, koszyk z rabatem, zwrot, zachowanie przy zerowym stanie magazynowym.
• 7. Cutover (1 dzień + 2–4 tygodnie monitoringu). 24–48 h wcześniej obniżasz TTL DNS do 300 s, potem przełączasz i sprawdzasz logi 404 oraz indeksację.

Go/no-go przed startem: wszystkie produkty mają cenę i stan, brak błędów 500 na kartach produktu, przetestowana min. jedna prawdziwa transakcja, wychodzą maile transakcyjne, mapa przekierowań gotowa i sprawdzona na kopii, backup odtworzony. Brak któregokolwiek punktu = przesunięcie startu.

Podział zadań między firmą a wykonawcą na mniejszym projekcie opiszemy na przykładzie organizacji wdrożenia PrestaShop w Szczebrzeszynie.

Ile trwa i ile kosztuje wdrożenie lub migracja PrestaShop w Zwierzyńcu?

Najuczciwiej liczyć w godzinach, nie w „pakietach”. Przy stawce 120–250 zł/h netto różnica między 60 a 160 godzinami to kilkanaście tysięcy złotych, więc warto wiedzieć, za co się płaci.

• Proste wdrożenie (nowy sklep, gotowy szablon, brak integracji z magazynem): 40–80 h, czyli około 6–12 tys. zł netto.
• Migracja z WooCommerce lub PrestaShop 1.6 z mapą URL i importem: 80–200 h, czyli 12–25 tys. zł netto. Górna granica dotyczy sklepów z tysiącami SKU i starymi danymi.
• Integracja z ERP, magazynem lub systemem księgowym: dodatkowe 40–120 h, czyli +8–20 tys. zł netto. Tu czas zależy od tego, czy system ma gotowe API.

Koszty zewnętrzne, których nie ma w ofercie wykonawcy: hosting lub VPS 30–150 zł/mies., szablon 300–1500 zł jednorazowo (albo 100–300 zł/rok przy licencji rocznej), moduły płatności i kurierów 0–1500 zł, certyfikat SSL 0 zł przy Let’s Encrypt, CDN 0–50 zł/mies., integracja z biurem rachunkowym 20–80 zł/mies. Zaplanuj to przed podpisaniem umowy – inaczej budżet rośnie po starcie.

Co realnie podnosi koszt:

• Niestandardowe moduły – konfigurator produktu, kalkulator dostawy, indywidualne ceny. Każda funkcja bez gotowego modułu to projekt od zera.
• Stare dane – eksporty z PrestaShop 1.4–1.6 bez zdjęć, z duplikatami i połamanymi opisami. Czyszczenie danych bywa droższe niż sam import.
• Wielojęzyczność – tłumaczenia, adresy URL per język, hreflang, czasem osobne konto płatności dla innego kraju.
• B2B – grupy klientów, ceny indywidualne, limity kredytowe, faktury z odroczonym terminem płatności, zatwierdzanie zamówień.

Jeśli migracja obejmuje kanał marketplace albo ERP, warto rozplanować ją osobno – pisaliśmy o tym w materiale o organizacji integracji z PrestaShop oraz o integracji Allegro z PrestaShop. Zanim przyjmiesz ofertę, poproś o rozbicie godzin na etapy z naszego harmonogramu – wtedy widać, gdzie wykonawca szacuje ryzyko.

Migracja z WooCommerce lub PrestaShop 1.6 do PrestaShop 8 – na co uważać

Dwa scenariusze migracji różnią się głównie liczbą miejsc, w których dane mogą się rozjechać.

WooCommerce → PrestaShop 8. WooCommerce trzyma katalog i zamówienia w tabelach WordPressa (wp_posts, wp_postmeta, wp_users). PrestaShop ma własny model: product, product_attribute, orders, order_detail, customer. Hasła: oba systemy używają innych mechanizmów, więc hasha nie przeniesiesz 1:1. Praktyka wygląda tak: importujesz konta, ustawiasz losowe hasła i wysyłasz mailing z linkiem do resetu — inaczej każdy klient pisze do Ciebie ręcznie. Zamówienia mapujesz po statusach (completed → Zrealizowane, processing → W realizacji) i przepisujesz pozycje do order_detail, bo bez tego historia nie pojawi się w panelu. Stany magazynowe: WooCommerce ma jedno pole stock i opcję backorders, PrestaShop pozwala włączyć zaawansowane zarządzanie zapasem i wiele magazynów — decyzję podejmujesz przed importem, nie po. Podatki: w WooCommerce cena bywa trzymana jako netto z doliczanym podatkiem, w PrestaShop ustalasz, czy ceny w katalogu są netto czy brutto i jaką grupę podatkową dostaje klient. Zaokrąglenia potrafią przesunąć cenę końcową o 1–2 grosze na pozycji.

PrestaShop 1.6 → 8. Wersja 1.6 nie jest już rozwijana ani wspierana — nie dostaje poprawek bezpieczeństwa. Moduły z 1.6 (system sprzed Symfony, stare hooki) na PrestaShop 8 nie wstaną, a override'y w katalogu /override trzeba przepisać. PHP 7.4 nie ma wsparcia producenta od listopada 2022, a 1.6 na PHP 8.x zwykle nie działa. Zakres obsługiwanych wersji sprawdź w dokumentacji dla deweloperów PrestaShop. Adresy zmieniają format (identyfikatory w strukturze), więc mapa 301 jest obowiązkowa. Warianty: wariacje w WooCommerce to w PrestaShop kombinacje z osobnym id_product_attribute — jeśli włączysz adresy z atrybutami, każda kombinacja dostanie własny URL i ruch rozproszy się na duplikaty.

Start na produkcji dopiero po migracji testowej na subdomenie (test.twojadomena.pl) i porównaniu koszyka na 20–30 produktach: cena, rabat, VAT, dostawa, zaokrąglenie pozycji. Kolejność prac i podział zadań po stronie firmy opisaliśmy w materiale o organizacji wdrożenia PrestaShop w Szczebrzeszynie.

Checklista przed startem – 12 punktów do odklikania

Checklista jest po to, żeby w dniu startu nikt nie zgadywał. Każdy punkt ma właściciela (Ty, agencja, księgowość, hosting) i termin — wpisz je do arkusza obok listy.

Backup i DNS. Kopia to nie „backup hostingu z zeszłego tygodnia”, tylko świeży zrzut bazy (mysqldump z opcją --single-transaction) i plików sklepu, pobrany na dysk poza serwerem. TTL rekordu A obniżasz z 3600 s do 300 s na 24–48 godzin przed zmianą: po przełączeniu DNS propagacja zajmuje minuty, a rollback przestaje być teorią.

Zaplecze sprzedaży. Jeśli sklep wymienia dane z ERP, magazynem, kurierem albo feedem Allegro, ustal przed startem, które połączenia są krytyczne dla sprzedaży — kolejność podłączania i testy opisaliśmy w materiale o integracjach z PrestaShop. Płatności sprawdzasz najpierw w piaskownicy, potem realną transakcją na 1 zł; dotyczy to też PayPal w PrestaShop, jeśli z niego korzystasz.

Okno serwisowe i rollback. Realistycznie 2–4 godziny w nocy albo w niedzielę rano, ze sklepem w trybie katalogu offline i komunikatem z godziną powrotu. Rollback: cofnięcie rekordu DNS na stary serwer i przywrócenie kopii bazy z godziny X. Warunek — stary sklep zostaje nietknięty, dopóki nowy nie działa 48 godzin bez błędów.

SEO i wydajność po migracji – jak nie stracić ruchu z Zwierzyńca i okolic

Po migracji ruch nie znika od razu — spada zwykle w ciągu 2–4 tygodni, jeśli stare adresy zwracają 404 albo nowe strony są wyraźnie wolniejsze. Kolejność działań jest stała.

Mapa 301. Zbierz stare adresy z trzech miejsc: crawl (Screaming Frog w wersji darmowej obsłuży 500 URL-i), eksport „All Pages” z Google Analytics za ostatnie 12 miesięcy i plik sitemap.xml starego sklepu. Mapuj 1:1 — produkty na produkty, kategorie na kategorie, a także paginację i tagi, jeśli generowały ruch. Reguły wpisujesz wzorcami w .htaccess albo w module przekierowań. Pilnuj, żeby nie tworzyć łańcuchów (301 → 301 → 200), bo wydłużają crawl. Linki wewnętrzne w treściach poprawiaj ręcznie na nowe adresy, zamiast liczyć na przekierowanie.

Canonical, sitemap, robots. Na karcie produktu ustawiasz adres kanoniczny na wersję bez identyfikatora kombinacji, jeśli warianty nie mają odrębnych opisów. Jeśli kombinacje mają różne ceny i treści, nie kieruj ich wszystkich na jeden URL. sitemap.xml generujesz z panelu i zgłaszasz w Google Search Console. Subdomena testowa musi mieć noindex — nagłówkiem X-Robots-Tag albo meta robots, plus ochronę hasłem. Nie blokuj jej w robots.txt: zablokowany adres nie zostanie pobrany, więc Google nie zobaczy noindex.

Wydajność. Cele Core Web Vitals dla 75. percentyla: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. W praktyce: OPcache i PHP 8.x na serwerze, cache Smarty oraz cache stron włączony w ustawieniach wydajności, CDN dla plików statycznych, obrazy w WebP z lazy loadingiem poza pierwszym ekranem.

Monitoring. Po starcie sprawdzasz dziennik 404 w Search Console i logi serwera, błędy 5xx z alertem oraz indeksację — pierwszy przegląd po 7 dniach, kolejny po 30. Skok liczby 404 w pierwszym tygodniu to najczęstszy sygnał brakującej reguły w mapie przekierowań.

Integracje z ERP, płatnościami i kurierami – kolejność wdrożenia

Kolejność integracji nie jest kwestią gustu. Moduły płatności, kurierów i ERP korzystają z tych samych hooków PrestaShop (m.in. actionValidateOrder, actionOrderStatusPostUpdate), więc wdrożone w złej kolejności potrafią nadpisywać swoje zachowanie. Sprawdzona sekwencja jest jedna: pieniądze → wysyłka → magazyn. Hooki i ich parametry opisuje dokumentacja dla deweloperów PrestaShop.

1. Płatności. Przelewy24, BLIK, karty i PayPal uruchamiaj najpierw na koncie sandbox operatora. Kluczowe ustawienia: poprawny adres powrotu (return URL), webhook/IPN odbierający zmianę statusu i mapowanie statusu operatora na status zamówienia w PrestaShop. Jeśli agregator zwraca „oczekuje na potwierdzenie”, zamówienie nie może iść do realizacji. Sposób uporządkowania tej części opisaliśmy w materiale o PayPal w PrestaShop: organizacja wdrożenia krok po kroku.

2. Kurierzy. InPost (paczkomaty przez API ShipX i geowidget na karcie produktu), DPD, DHL. Zakres prac: pobranie listy punktów, generowanie etykiety z panelu zamówienia, zapis numeru przesyłki i mapowanie statusów kuriera na statusy PrestaShop. Etykieta nie może startować wcześniej niż po statusie „opłacone” – inaczej drukujesz przesyłki do niezapłaconych koszyków.

3. ERP i BaseLinker. Subiekt, Comarch i BaseLinker wymieniają z PrestaShop cztery rzeczy: stany magazynowe, ceny, zamówienia i faktury. To najdłuższy etap, bo trzeba ustalić, kto jest źródłem prawdy dla stanu (magazyn, nie sklep) i co robić przy konflikcie danych. Kontekst i kolejność prac przy takich modułach opisuje Integracje z PrestaShop – organizacja pracy i wdrożenia.

• Nie wdrażaj trzech integracji równolegle – debugowanie staje się zgadywaniem.
• Każdą integrację zamknij testem end-to-end: zamówienie → płatność → etykieta → faktura → stan w ERP.

Kogo wybrać do wdrożenia PrestaShop w Zwierzyńcu? 5 kryteriów

W Zwierzyńcu i okolicy firm robiących PrestaShop zawodowo jest niewiele, więc wybór sprowadza się do pięciu konkretnych pytań. Zadaj je wszystkie, zanim podpiszesz cokolwiek.

1. Doświadczenie w PrestaShop i WooCommerce. Poproś o 2–3 wdrożenia z ostatnich 12 miesięcy z podaniem wersji (PrestaShop 8.x, PHP 8.1 lub 8.2) i zakresu. „Znamy PrestaShop” bez przykładów to za mało. Przy migracji z WooCommerce wykonawca musi znać oba systemy – inaczej nie zmapuje wariantów, atrybutów i kategorii.

2. Portfolio i referencje. Logotypy na stronie nic nie mówią. Poproś o kontakt do klienta, u którego robiono migrację z 1.6 lub WooCommerce co najmniej pół roku temu. Najlepsze pytanie brzmi: „co się zepsuło w pierwszym miesiącu po starcie?”.

3. Wycena godzinowa z widełkami, a nie cena z sufitu. Uczciwa oferta to stawka i liczba godzin na etap, nie jedna kwota. Realne widełki w Polsce: około 90–200 zł netto za godzinę (agencja zwykle 120–200 zł, doświadczony freelancer 90–150 zł). Wymagaj zapisu, co jest poza zakresem i ile kosztuje praca dodatkowa.

4. SLA i opieka po wdrożeniu. Ustal czas reakcji na awarię krytyczną (sklep nie przyjmuje zamówień): 2–4 godziny w godzinach pracy to norma. Zapytaj o miesięczny pakiet godzin i stawkę za nadwyżkę.

5. Agencja czy praca bezpośrednio z deweloperem. Bezpośrednia współpraca bywa tańsza o 20–30%, ale wiąże się z ryzykiem jednej osoby. Agencja daje zastępowalność i proces. Porównaj z opisem sklepu PrestaShop w Poznaniu: organizacja wdrożenia krok po kroku. Jeśli sprzedajesz na Allegro, przeczytaj też o integracji Allegro i PrestaShop: organizacja wdrożenia.

Najczęstsze pułapki przy migracji PrestaShop i jak je wykryć

Cztery pułapki odpowiadają za większość nieudanych migracji. Każdą wykryjesz tanio i przed startem, bez zgadywania.

1. Brak backupu i brak testowej kopii. Wykryjesz w pięć minut: jeśli nie istnieje subdomena typu test.twojadomena.pl z kopią bazy i plików, migracja idzie na żywym sklepie. Poproś o dump bazy i archiwum katalogu z datą oraz o adres stagingu. Brak któregokolwiek elementu przerywa rozmowę.

2. Błędne przekierowania 301 i duplikaty URL. Przed startem zrób crawling Screaming Frog na starej i nowej domenie, po starcie sprawdź w Google Search Console raporty „Strony” i „Indeksowanie”. Zasada: każde stare URL ma prowadzić jednym skokiem 301 na istniejącą stronę z kodem 200. Łańcuch 301 → 301 → 200 spowalnia użytkownika i rozmywa sygnały. Różnice między kodami wyjaśnia dokumentacja HTTP: Hypertext Transfer Protocol.

3. Niedziałające płatności lub kurierzy na produkcji. Sandbox na koncie testowym to za mało. Testuj na koncie produkcyjnym w trybie testowym operatora: jedno zamówienie za 1 zł każdą metodą płatności, potem pełny zwrot, potem etykieta kuriera. Sprawdź, czy wraca webhook i czy status zamówienia zmienia się samoczynnie.

4. Rozjazd stanów magazynowych z ERP. Weź 20 losowych SKU i porównaj stan w PrestaShop, w ERP i w BaseLinkerze. Jeśli różnice dotyczą więcej niż 2 pozycji, nie uruchamiaj sklepu – najpierw ustal, kto jest źródłem prawdy. Zakres takich prac opisaliśmy przy wdrożeniach i migracjach PrestaShop w Zamościu, a wariant dla mniejszych miejscowości przy wdrożeniach i migracjach PrestaShop w Szczebrzeszynie.

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

Lista kontrolna do odklikania

• Backup bazy i plików — Wykonaj bezpośrednio przed każdą większą zmianą i przetestuj odtworzenie na kopii. Backup, którego nie sprawdziłeś, nie jest backupem.
• Obniżone TTL dla DNS — Ustaw TTL na 300 sekund minimum 24–48 godzin przed przełączeniem, żeby ewentulany rollback był szybki.
• Certyfikat SSL — Sprawdź ważność dla domeny i wersji z www, wymuszenie HTTPS oraz brak mieszanej treści na stronie produktu i w koszyku.
• Wersja PHP — PrestaShop 8 wymaga nowszego PHP niż 7.4. Sprawdź zgodność modułów na środowisku testowym, zanim zmienisz wersję na produkcji — konfigurację opisuje dokumentacja PrestaShop.
• Zadania cron — Sprawdź, czy crony PrestaShop i modułów (faktury, statusy, e-maile, synchronizacje) wykonują się o właściwych porach po zmianie serwera.
• Testy płatności na produkcji — Po cutoverze zrób jedno zamówienie na każdą metodę: BLIK, przelew, karta, PayPal. Sprawdź powrót do sklepu i status w panelu.
• Testy kurierów — Wygeneruj etykietę dla każdego kuriera, sprawdź paczkomaty i zmianę statusu przesyłki w zamówieniu.
• E-maile transakcyjne — Sprawdź potwierdzenie zamówienia, zmianę statusu i reset hasła. Zweryfikuj SPF, DKIM i DMARC oraz to, czy wiadomości nie trafiają do spamu.
• Faktury i podatki — Sprawdź numerację faktur, stawki VAT i obsługę sprzedaży zagranicznej (OSS), jeśli wysyłasz poza Polskę.
• Przekierowania 301 — Przejdź losowo 20–30 starych adresów produktów i kategorii. Każdy powinien prowadzić na odpowiadający mu nowy URL, nie na stronę główną.
• sitemap.xml, robots.txt i canonical — Wygeneruj nową sitemapę, dodaj ją w Google Search Console i upewnij się, że robots.txt nie blokuje niczego poza środowiskiem testowym.
• Plan rollback i okno serwisowe — Ustal godzinę startu poza szczytem sprzedaży, osobę decyzyjną, czas na decyzję „wracamy czy nie” i procedurę powrotu.
• Core Web Vitals przed i po — Zapisz wartości LCP, CLS i INP przed migracją, żeby mieć punkt odniesienia. Kryteria opisuje dokumentacja Google Search Central.
• Monitoring po starcie — Przez minimum dwa tygodnie sprawdzaj codziennie raport 404 i 500 w Search Console oraz logi serwera.

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
• MDN Web Docs – HTTP