Wdrożenie PrestaShop w Krasnobrodzie rzadko zawodzi z powodu kodu. Zawodzi na kolejności decyzji: wersja, hosting, zakres, integracje, SEO. Problemy ujawniają się dopiero po starcie, kiedy przebudowa oznacza utratę ruchu i ponowne wdrożenie. Poniżej część organizacyjna: co ustalić przed pierwszym klikiem, jak policzyć zakres w godzinach i czego dopilnować, zanim sklep wyjdzie na produkcję.
Instalacja PrestaShop zajmuje kilkanaście minut. Decyzje, które ją poprzedzają, decydują o tym, czy za pół roku nie będziesz robić drugiego wdrożenia. Poniżej sześć rzeczy ustalanych przed startem.
Kolejność tych decyzji rozpisaliśmy szerzej w materiale o organizacji wdrożenia PrestaShop w Zamościu. Wersje i wymagania techniczne weryfikuj w dokumentacji deweloperskiej PrestaShop – dla konkretnej wersji, bo różnice między 8.0 i 8.1 są realne.
Migracja to nie jeden import, tylko siedem warstw danych, z których każda zachowuje się inaczej. Poniżej realny podział.
Mapowanie URL-i. Wyeksportuj adresy ze starego sklepu – z Google Search Console (raport Pages) albo crawlem typu Screaming Frog – do pliku CSV z kolumnami: stary URL, nowy URL, kod. Każdy adres, który miał ruch lub linki zewnętrzne, dostaje 301. Reguły wpisujesz w .htaccess albo w module przekierowań. Nie stosuj 302 i nie przekierowuj masowo na stronę główną – Google odczyta to jako soft 404 i wyczyści widoczność.
Historia zamówień. Nie przenosi się automatycznie i nie powinna. Struktury tabel zamówień w starym sklepie i w PrestaShop różnią się, a błąd w zamówieniu to błąd w księgowaniu. Standard: zamówienia zostają w starym sklepie na subdomenie archiwum (noindex, dostęp dla klienta i księgowości), plus eksport zbiorczy do CSV lub PDF.
Test na stagingu – 12 punktów po imporcie: liczba produktów, liczba kombinacji, zdjęcia i ich kolejność, drzewo kategorii, URL-e i przekierowania, ceny i podatki, stany magazynowe, klienci i logowanie, opinie, strony CMS, zamówienie testowe end-to-end, sitemap i robots.txt.
Po starcie: przepięcie domeny, 301, monitoring 404 w Search Console przez 4–6 tygodni i dopisywanie brakujących przekierowań. Przykład takiego planu w praktyce: migracja PrestaShop w Zwierzyńcu.
| Warstwa danych | Jak przenosi się | Ryzyko / uwagi |
|---|---|---|
| Produkty | Skryptem (eksport z bazy starego sklepu, import CSV) | Mapowanie pól: SKU, EAN, waga, stawka VAT – literówka w EAN psuje integrację kurierską |
| Zdjęcia | Skryptem, katalog /img, potem regeneracja miniatur | Kolejność i przypisanie do kombinacji trzeba sprawdzić ręcznie |
| Kategorie | Skryptem | Drzewo i ID zależą od kolejności importu – zaplanuj ją przed importem |
| Klienci | Skryptem, ale bez haseł | Hasła są hashowane inaczej – klienci dostają reset hasła |
| Historia zamówień | Ręcznie lub archiwum | Nie wchodzi 1:1, ryzyko księgowe – zostaw stary sklep na subdomenie |
| Opinie i oceny | Częściowo skryptem | Zależne od modułu, który je zbierał w starym sklepie |
| Strony CMS | Ręcznie | Regulamin i polityki i tak wymagają aktualizacji przy zmianie koszyka |
Kolejność integracji nie jest przypadkowa: najpierw to, bez czego nie da się sprzedać, potem to, co oszczędza czas.
Kryterium: gotowy moduł czy własny. Gotowy płatny moduł kupujesz, gdy logika jest standardowa – bramka płatnicza, etykieta kuriera, eksport faktury. Własny moduł ma sens, gdy reguły są Twoje: ceny B2B z progami ilościowymi, rabaty kaskadowe, stawki wysyłki zależne od grupy klienta i wagi palety. Policz to wprost: gotowy moduł to zwykle kilkaset złotych rocznie, własny to 40–120 godzin pracy plus utrzymanie. Jeśli niestandardowa logika dotyczy więcej niż dwóch procesów, własny zwraca się szybciej – jeśli jednego, nie kombinuj.
Punkty styku z ERP. Cztery: stany magazynowe, ceny, statusy zamówień, faktury. Stany synchronizuj co 5–15 minut albo zdarzeniowo – przy 100 zamówieniach dziennie cron co 5 minut jest tańszy niż ręczne korekty po sprzedaży towaru, którego nie ma. Ceny raz na dobę w nocy. Statusy i faktury po zdarzeniu, żeby klient nie czekał do rana.
Testy przed startem – cztery scenariusze: złożenie zamówienia, anulowanie, zwrot, faktura korygująca. Każdy przechodzisz na stagingu z realnymi danymi i sprawdzasz, co poszło do ERP i do przewoźnika. Zamówienie testowe na produkcji zrób jeszcze raz po przepięciu domeny.
Więcej o kolejności prac: integracje z PrestaShop – organizacja wdrożenia, PayPal w PrestaShop krok po kroku oraz integracja Allegro i PrestaShop.
| Kolejność | Integracja | Kiedy wdrażać |
|---|---|---|
| 1 | Płatności online (Przelewy24, PayU, PayPal) | Przed startem, z testem produkcyjnym na małej kwocie i zwrotem |
| 2 | Kurierzy (InPost Paczkomaty, DPD, DHL) | Przed startem – potrzebne umowy i numery klienta u przewoźnika |
| 3 | Faktury i ERP | 1–2 tygodnie przed startem, po ustabilizowaniu statusów zamówień |
| 4 | Marketplace (Allegro i podobne) | Po starcie sklepu, gdy stany magazynowe są już spójne z ERP |
Te ustawienia robi się przed pierwszym publicznym uruchomieniem. Po indeksacji każda zmiana struktury URL-i oznacza setki przekierowań 301 i kilka tygodni wahań w wynikach.
Adresy i HTTPS. Panel PrestaShop: Parametry sklepu → Ruch w sklepie (SEO i URL) → „Przyjazne adresy URL” na TAK. Struktura typu /kategoria/podkategoria/nazwa-produktu.html musi być zatwierdzona przed importem katalogu — decyzja o zostawieniu ID w adresie zapada raz. Równolegle: certyfikat SSL, przekierowanie 301 z http na https i wybór jednej wersji domeny (z www albo bez). Bez tego Google widzi cztery warianty tego samego sklepu.
Indeksacja. Staging: blokada hasłem i noindex, a po starcie sprawdzenie, czy noindex nie został na produkcji — to najczęstszy błąd przy kopiowaniu bazy. robots.txt nie może blokować CSS i JS. Sitemap.xml (moduł Google Sitemap) zgłaszasz w Search Console. Filtry i paginacja (?q=, ?page=) dostają noindex i canonical do kategorii głównej — inaczej tysiące kombinacji zjadają budżet indeksacji.
Wydajność. Cele: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 (Web Vitals – web.dev). W praktyce: konwersja zdjęć do WebP, lazy loading dla obrazów poniżej pierwszego ekranu, OPcache i cache szablonów, CDN dla statyków oraz usunięcie ze strony głównej modułów, które tam nic nie robią — karuzel, „polecanych” z 20 produktami, wtyczek social.
Dane strukturalne. Product, Offer, BreadcrumbList i Organization to minimum, które Google realnie wykorzystuje w wynikach. Kolejność podłączania modułów płatności i marketplace opisujemy w materiale o integracjach z PrestaShop — warto ją zaplanować razem z SEO, bo każdy moduł dorzuca skrypty do szablonu.
Pomiar. GA4 i Search Console weryfikujesz przez DNS jeszcze przed przełączeniem domeny — dane z pierwszych 48 godzin są potrzebne do diagnozy.
| Element | Gdzie ustawić | Wartość docelowa |
|---|---|---|
| Przyjazne adresy URL | Parametry sklepu → Ruch w sklepie | Włączone, struktura ustalona przed importem |
| HTTPS i wersja domeny | Serwer + panel | 301 z http oraz z drugiej wersji www |
| Staging | Serwer | Hasło i noindex, po starcie zdjęte |
| Filtry i paginacja | Moduł nawigacji fasetowej | noindex + canonical do kategorii |
| Core Web Vitals | Szablon, cache, CDN | LCP < 2,5 s, INP < 200 ms, CLS < 0,1 |
| Sitemap i Search Console | Moduł Google Sitemap | Zgłoszona przed przełączeniem domeny |
Punkt startowy: 40–60 godzin. Tyle zajmuje sklep do około 500 SKU, bez integracji z ERP, na gotowym szablonie, w jednym języku: konfiguracja instancji i ustawienia prawne 6–10 h, szablon i strona główna 8–16 h, import katalogu 6–12 h, płatności i dostawy 6–10 h, SEO techniczne 6–10 h, testy i uruchomienie 4–8 h, szkolenie z panelu 2–4 h.
Co podnosi zakres. Migracja z innej platformy (WooCommerce, Shoper, PrestaShop 1.6) to +30–80 h: mapowanie kategorii, atrybutów, klientów i zamówień plus przekierowania. Integracja z ERP — +40–120 h, bo dochodzi uzgadnianie słowników i testy stanów magazynowych. Logika B2B (ceny grupowe, limity, płatność odroczona) — +30–60 h. Każdy dodatkowy język i waluta — +20–40 h. Moduły pisane na zamówienie wycenia się osobno.
Czego nie ma w cenie. Hostingu, licencji płatnych modułów, zakupu szablonu, zdjęć i tekstów, certyfikatu SSL. Wypisz te pozycje w umowie — inaczej wychodzą w trakcie jako dopłata.
Model rozliczenia. Wycena z zakresu: liczba godzin × stawka, z tolerancją 10% przed aneksem. Cena „z sufitu”, bez zakresu, kończy się albo dopłatami, albo niedokończonym sklepem. Ten sam schemat organizacyjny stosujemy w innych lokalizacjach — zobacz organizację wdrożenia PrestaShop w Zamościu.
Pytania przed podpisaniem umowy:
| Etap (sklep do 500 SKU) | Widełki godzinowe |
|---|---|
| Instancja, konfiguracja bazowa, ustawienia prawne | 6–10 h |
| Szablon i strona główna | 8–16 h |
| Import katalogu i zdjęć | 6–12 h |
| Płatności i dostawy | 6–10 h |
| SEO techniczne | 6–10 h |
| Testy i uruchomienie | 4–8 h |
| Szkolenie z panelu | 2–4 h |
| Razem (część etapów się nakłada) | 40–60 h |
Te błędy wracają w niemal każdym projekcie, który trafia do nas po nieudanym starcie. Każdy da się wykryć bez czytania kodu.
Duplikaty URL-i po migracji. Objaw: w Google pojawiają się dwie wersje tego samego produktu, spada ruch na kategoriach. Wykrycie: Search Console → Indeksowanie → Strony → raport „Zduplikowana, Google wybrało inną stronę kanoniczną”, a do tego darmowy crawl do 500 adresów (Screaming Frog) i porównanie liczby zaindeksowanych URL-i z liczbą produktów.
Rozjazd stanów magazynowych po integracji z ERP. Objaw: sprzedajesz towar, którego nie ma, albo blokujesz dostępny. Test: trzy zamówienia na ten sam produkt w tym samym czasie — dwa ze sklepu, jedno z ERP — i kontrola stanu po 5, 15 i 60 minutach. Jeśli po godzinie liczby się różnią, problem jest w harmonogramie synchronizacji albo w buforze magazynowym. Ten sam mechanizm dotyczy integracji Allegro i PrestaShop.
Wolne kategorie przez filtry. Objaw: kategoria z 12 filtrami ładuje się 6 s na telefonie. Pomiar: PageSpeed Insights i Lighthouse na tym samym adresie z filtrami włączonymi i wyłączonymi. Różnica powyżej 1,5 s oznacza, że moduł fasetowy generuje zbyt wiele kombinacji — pomaga cache i ograniczenie liczby filtrów. Warto trzymać się progów opisanych w dokumentacji Core Web Vitals.
Zgubione przekierowania 301. Objaw: 404 i spadek ruchu po zmianie domeny. Test: lista 50 najważniejszych adresów ze starego sklepu (z GA4, wg sesji) i sprawdzenie każdego skryptem — kod odpowiedzi i adres docelowy.
Moduły nadpisujące szablon. Objaw: aktualizacja modułu rozsypuje wygląd. Zasada: każda aktualizacja najpierw na kopii, a pliki z motywu i katalogu override trzymane w repozytorium, żeby dało się porównać wersje.
Brak kopii zapasowej. Minimum: kopia bazy i plików przed każdą zmianą na produkcji, retencja 30 dni i test odtworzenia raz na kwartał na osobnym środowisku.
| Pułapka | Objaw | Jak to sprawdzić |
|---|---|---|
| Duplikaty URL-i | Dwie wersje produktu w Google, spadek na kategoriach | Search Console → Strony + crawl do 500 adresów |
| Rozjazd stanów z ERP | Sprzedaż towaru, którego nie ma | 3 zamówienia równolegle, kontrola po 5/15/60 min |
| Wolne kategorie | Ponad 4 s ładowania na mobile | PageSpeed Insights i Lighthouse z filtrami on/off |
| Brak przekierowań 301 | 404 i spadek ruchu po zmianie domeny | Lista 50 URL-i z GA4 sprawdzana skryptem |
| Aktualizacja modułu | Rozsypany layout po update | Test na kopii, porównanie plików override |
| Brak backupu | Brak możliwości cofnięcia zmiany | Harmonogram kopii + test odtworzenia raz na kwartał |
W Krasnobrodzie i najbliższej okolicy wybór wykonawców wdrożeń PrestaShop jest wąski — realnie szukasz w Zamościu, Lublinie albo pracujesz zdalnie z firmą z dowolnego miasta w Polsce. Lokalizacja ma znaczenie głównie w dwóch momentach: przy audycie procesów (kto przyjmuje zamówienia, kto pakuje, kto wystawia faktury) i przy integracjach z oprogramowaniem stojącym na komputerach w firmie. Poza tym większość pracy i tak odbywa się przez SSH, panel hostingu i kopię sklepu na stagingu.
Trzy modele, które spotkasz w ofertach: bezpośrednio z deweloperem, z agencją mającą zespół, przez pośrednika lub platformę freelancerską. Pośrednik nie jest zły sam w sobie — problem zaczyna się, gdy nie wiesz, kto trzyma dostępy i kto odbierze telefon, gdy po 11 miesiącach padnie moduł płatności. Zanim podpiszesz cokolwiek, zadaj pięć pytań:
Opieka zdalna nad sklepem z Krasnobrodu i okolic działa bez wizyt na miejscu: aktualizacje, backupy, poprawki szablonu, konfiguracja modułów, analiza logów, naprawa błędów 500. Nie da się tego zrobić zdalnie w dwóch przypadkach: gdy trzeba zobaczyć, jak magazynier pracuje z Subiektem lub WAPRO, oraz gdy integracja dotyczy sieci lokalnej — drukarek fiskalnych, wag, czytników kodów. Wtedy jedno spotkanie na miejscu skraca wdrożenie o tygodnie. Jeśli szukasz sąsiedniego planu organizacji, zobacz organizację wdrożenia PrestaShop w Szczebrzeszynie, a dla większego rynku — organizację wdrożenia w Zamościu. Wymagania techniczne wybranej wersji PrestaShop sprawdzaj w dokumentacji dla deweloperów PrestaShop, nie w ofercie handlowej.
| Model współpracy | Zaleta | Ryzyko | Na co uważać |
|---|---|---|---|
| Bezpośrednio z deweloperem | Krótka droga decyzyjna, niższa stawka | Pojedynczy punkt awarii — urlop, wypadek, zmiana pracy | Umowa, repozytorium na Twoim koncie, dostępy u Ciebie |
| Agencja z zespołem | Ktoś przejmuje zgłoszenie, gdy jedna osoba jest niedostępna | Wyższa stawka godzinowa, więcej narzutów | Zapisz w umowie, kto zastępuje dewelopera |
| Pośrednik / platforma freelancerska | Szybki start, szeroki wybór ofert | Nie wiesz, kto ma dostępy i kto odpowie po starcie | Weryfikuj tożsamość wykonawcy i przekazanie dostępów na koniec |
Start sklepu to seria drobiazgów, które wyglądają na formalność i psują sprzedaż pierwszego tygodnia. Przejdź tę listę przed zdjęciem hasła ze stagingu:
Opieka techniczna to nie „wsparcie”, tylko konkretny zakres: aktualizacje wersji PrestaShop i modułów, backupy z retencją (np. 7 dni dziennych, 30 dni miesięcznych), monitoring, analiza logów, poprawki błędów. Zmiany wyglądu, nowe funkcje i nowe integracje są zwykle płatne osobno — dopisz to do umowy, żeby nie było zaskoczenia. Jeśli planujesz łączenie sklepu z zewnętrznymi systemami, zaplanuj to jak w organizacji integracji z PrestaShop. W SLA rozdziel dwa parametry: czas reakcji (potwierdzenie i pierwsza diagnoza) od czasu rozwiązania.
| Priorytet | Przykład zgłoszenia | Czas reakcji | Czas rozwiązania |
|---|---|---|---|
| Krytyczny | Sklep nie działa, brak płatności lub wysyłki | do 1 h | do 4 h |
| Wysoki | Błąd blokujący złożenie zamówienia, błędne stany magazynowe | do 4 h roboczych | 1 dzień roboczy |
| Normalny | Błędny tekst, pytanie o konfigurację modułu | 1 dzień roboczy | 3 dni robocze |
| Niski | Drobna zmiana treści, sugestia usprawnienia | 3 dni robocze | do 10 dni roboczych |
Start prac bez zamkniętej listy zakresu – wycena „na oko”, potem dopłaty i przeciąganie terminu.
Jak wykryć: Brak jednego arkusza z liczbą SKU, kategorii, języków, integracji i miejsc docelowych treści. Zapytanie „to się mieści w cenie?” pojawia się po fakcie.
Jak naprawić: Rozbij zakres na pozycje i godziny (instalacja, konfiguracja, import, integracje, SEO techniczne, testy). Podpisany zakres jest punktem odniesienia przy każdej zmianie, a nie polem do negocjacji po wykonaniu pracy.
Migracja bez mapowania adresów URL i przekierowań 301.
Jak wykryć: Nie istnieje plik CSV z parą „stary URL → nowy URL”. Pierwsze tygodnie po starcie: spadek wejść z Google i rosnąca liczba błędów 404 w Search Console.
Jak naprawić: Wyeksportuj adresy z indeksu Google (i z sitemapy starego sklepu), zmapuj je na nowe adresy w PrestaShop, wgraj przekierowania 301 przed startem i pilnuj raportu 404 po przepięciu domeny.
Automatyczne przenoszenie pełnej historii zamówień i kont klientów „bo się przenosi”.
Jak wykryć: Pytanie „czy klienci zobaczą stare zamówienia w panelu” pojawia się dopiero przy testach. Import zamówień okazuje się wymagać dopasowania statusów, metod płatności i numeracji faktur.
Jak naprawić: Zdecyduj świadomie: konta klientów migrujesz (z wymuszeniem resetu hasła), historię zamówień zostawiasz w archiwum – eksport CSV/PDF ze starego sklepu i dostęp dla działu księgowości. Jeśli import zamówień jest konieczny, rób go wyłącznie jako dane archiwalne, bez wpływu na nowe statusy.
Staging widoczny w Google albo – odwrotnie – produkcja zablokowana w robots.txt po przepięciu.
Jak wykryć: Wpisanie w Google „site:” z adresem kopii testowej zwraca wyniki. Po starcie nowy sklep nie ma żadnych wejść z organika.
Jak naprawić: Na stagingu: noindex, hasło dostępu, blokada w robots.txt. Na produkcji: zdjęcie blokady, sitemap.xml, zgłoszenie w Search Console. Sprawdź to bezpośrednio po przepięciu domeny, nie następnego dnia.
Integracje robione na końcu projektu: płatności i kurierzy w ostatnim tygodniu.
Jak wykryć: Przed startem nie wykonano ani jednego testowego zamówienia z realną (lub piaskownicową) płatnością i etykietą kurierską. Każdy scenariusz sprawdzany jest na produkcji.
Jak naprawić: Ustal kolejność: płatności (Przelewy24/PayU/PayPal/PayU) → kurierzy (InPost Paczkomaty, DPD, DHL) → faktury/ERP → marketplace. Każdą integrację zamykaj testem na stagingu i dopiero wtedy przechodzisz do następnej.
Brak jednej osoby decyzyjnej po stronie klienta.
Jak wykryć: Pytania o treści, zdjęcia, cenniki i regulamin wracają tygodniami bez odpowiedzi. Prace stoją, choć technicznie nic ich nie blokuje.
Jak naprawić: Wyznacz jedną osobę decyzyjną i termin na odpowiedzi (np. 3 dni robocze). Zbierz wszystko w jednej liście materiałów wejściowych, żeby na koniec nie okazało się, że brakuje zdjęć 40 produktów.
Organizacja wdrożenia PrestaShop w Krasnobrodzie sprowadza się do trzech rzeczy: zamkniętej listy zakresu w godzinach, zaplanowanej migracji z mapowaniem adresów URL i ustalonej kolejności integracji. Największe ryzyko nie leży w kodzie, a w decyzjach podejmowanych po starcie – wtedy zmiany kosztują ruch i pieniądze. Jeśli chcesz porównać to z praktycznym planem migracji, zobacz omówienie dla Zwierzyńca. Rozwinięcie tematu organizacji pracy znajdziesz też w materiale o Zamościu.
Nie da się podać sensownej liczby bez inwentaryzacji. Czas zależy przede wszystkim od liczby SKU, wariantów, języków i kategorii, a dopiero potem od liczby modułów. Dlatego pierwszym krokiem jest rozpiska zakresu w godzinach – dopiero ona pozwala podać termin, który ma szansę się utrzymać.
Nowy sklep stawiaj na 8.x – to wersja z aktywnym wsparciem i zgodnością z aktualnym PHP. Na 1.7 zostaje się w jednym przypadku: gdy istniejący sklep działa i korzysta z modułów, których nie ma jeszcze w wersji 8.x. Wtedy najpierw sprawdź gotowość tych modułów, a potem planuj migrację.
Skryptem przenosi się zwykle produkty, zdjęcia, kategorie, klientów (z resetem haseł) i strony CMS. Ręcznie lub półautomatycznie trzeba odtworzyć mapowanie adresów URL, strukturę wariantów, grupy cenowe, reguły promocji, statusy zamówień i konfigurację modułów. Opinie i historię zamówień najczęściej zostawia się w archiwum starego sklepu.
Zwykle nie i najczęściej nie jest to konieczne. Konta klientów migruje się po to, żeby nie zakładali ich od nowa, ale historia zamówień zostaje w archiwum. Wystarczy eksport CSV/PDF ze starego sklepu i dostęp dla biura obsługi oraz księgowości. Import starych zamówień do nowego panelu komplikuje numerację faktur i statusy.
Gotowy moduł wybierasz, gdy logika jest standardowa: typowa płatność, typowa etykieta kurierska, prosty eksport faktur. Własny moduł zwraca się szybciej, gdy masz niestandardowe ceny B2B, indywidualne progi rabatowe albo proces zamówienia, którego żaden gotowy moduł nie obsłuży – wtedy „dopasowywanie” gotowca kosztuje więcej niż napisanie własnego.
Punkt wyjścia to PHP 8.1 lub nowsze (z potwierdzeniem zgodności z konkretną wersją PrestaShop), MySQL 8, włączony OPcache, minimum 2 GB RAM i dysk SSD NVMe. Wersje komponentów zawsze sprawdzaj w dokumentacji PrestaShop dla wybranej wersji sklepu, zamiast opierać się na wpisach z forów.
Pierwsze dni: sprawdź, czy produkcja nie jest zablokowana w robots.txt, czy sitemap.xml jest zgłoszona i czy w Search Console nie rośnie liczba błędów 404. Potem przejrzyj strukturę adresów, noindex na filtrach i paginacji oraz wyniki Core Web Vitals. Jeśli coś jest nie tak, lepiej poprawić to w pierwszym tygodniu niż po kwartale.
Jeśli chcesz przejść przez wdrożenie lub migrację PrestaShop bez przebudowy po starcie, napisz do DropDigital – pomożemy rozpisać zakres w godzinach i ustalić kolejność prac. Możesz też najpierw zajrzeć do naszych materiałów o integracjach i PayPal.