Wdrożenie WooCommerce w firmie to projekt, który ma zakres, harmonogram, właściciela po stronie klienta i moment odbioru — nie instalacja wtyczki. Prosty sklep zajmuje 2–3 tygodnie, sklep z integracjami 4–8 tygodni, a wdrożenie z ERP 2–4 miesiące. W tym tekście porządkujemy stronę organizacyjną: co powinno być w umowie, kto podejmuje decyzje, ile godzin musi wygospodarować Twój zespół i po czym poznać, że wykonawca zaniżył kalkulację. Jeśli szukasz konkretów o wdrożeniach i optymalizacji WooCommerce w Zwierzyńcu dla firmy — poniżej masz listę kontrolną, którą można wykorzystać jeszcze przed podpisaniem umowy.
Instalacja WooCommerce to kilkanaście kliknięć: wtyczka, kreator, kraj, waluta, jedna metoda płatności. Zamyka się w 30 minutach. Wdrożenie produkcyjne to 40–300+ godzin pracy rozłożonej na pięć filarów, z których żaden nie jest opcjonalny.
Product i Offer, canonicale, mapa XML, poprawne adresy URL.Warto zweryfikować w dokumentacji WooCommerce, co jest w rdzeniu, a co wymaga wtyczki — to pierwszy argument w rozmowie o zakresie i najczęstsze źródło rozjazdu między ofertą a rzeczywistością.
Kiedy WooCommerce, a kiedy PrestaShop? Decydują liczby, nie preferencje wykonawcy:
| Kryterium | WooCommerce | PrestaShop |
|---|---|---|
| Liczba SKU | Wygodnie do kilku tysięcy; przy dziesiątkach tysięcy potrzebna optymalizacja bazy i wydajniejsze wyszukiwanie | Mocniejszy natywnie przy bardzo dużym katalogu |
| Warianty produktu | Do ok. 50 kombinacji na produkt; setki kombinacji obciążają panel i front | Natywne kombinacje, generator wariantów |
| Model B2B | Grupy klientów, cenniki i ukrywanie cen zwykle przez wtyczkę | Wbudowane grupy cenowe i reguły rabatowe |
| Wielojęzyczność | WPML lub Polylang — licencja i dodatkowe obciążenie | Natywne tłumaczenia treści |
| Integracje z polskimi systemami | Bardzo szeroka dostępność wtyczek | Węższa, ale mocna w części ERP |
Harmonogram dzieli się na siedem etapów. Każdy ma wejście, wyjście i osobny czas. Jeśli w ofercie jest tylko data publikacji, nie da się rozliczyć wykonawcy z niczego poza tą datą.
Realny czas całości: prosty sklep 2–3 tygodnie, sklep z integracjami 4–8 tygodni, z ERP 2–4 miesiące. Klient musi wygospodarować 10–25 godzin: decyzje, dane produktowe, akceptacje, testy. Bez tego projekt stoi i to jest najczęstsza przyczyna opóźnień — nie praca dewelopera.
Nie ma sensownego cennika „sklep od X zł”. Jest liczba godzin pomnożona przez stawkę, a tę można porównać między ofertami. Trzy poziomy wdrożenia:
Stawka rynkowa w Polsce na 2024/2025 to 120–200 zł netto za godzinę pracy dewelopera. Przy 150 zł/h prosty sklep to 6 000–12 000 zł, wdrożenie z integracjami 12 000–24 000 zł, a projekt z ERP startuje od 24 000 zł. To widełki, nie oferta — pełne rozbicie kosztów znajdziesz w materiale o organizacji projektu wdrożenia WooCommerce.
Czego wycena nie zawiera i co trzeba zapisać w umowie jako osobną pozycję:
Sygnały zaniżonej kalkulacji: brak etapu testów w harmonogramie, brak środowiska staging, brak godzin po stronie klienta, jedna kwota ryczałtowa „za wszystko” i deklaracja, że 5 integracji zamknie się w tygodniu. Każdy z tych punktów oznacza, że różnicę dopłacisz w trakcie.
| Poziom | Godziny | Wartość przy 150 zł/h netto |
|---|---|---|
| Prosty sklep | 40–80 h | 6 000–12 000 zł |
| Sklep z integracjami | 80–160 h | 12 000–24 000 zł |
| Sklep z ERP i modułami własnymi | 160–300+ h | od 24 000 zł |
Zacznij od pomiaru, nie od włączania kolejnej wtyczki cache. Progi Core Web Vitals są jednoznaczne: LCP poniżej 2,5 s, INP poniżej 200 ms i CLS poniżej 0,1 — liczone dla 75. percentyla ruchu mobilnego, nie dla Twojego laptopa. Weryfikuj je w raporcie Core Web Vitals w Search Console oraz w PageSpeed Insights, ale zawsze na adresie karty produktu i listy kategorii, nie strony głównej. W praktyce właśnie te dwa szablony wypadają najgorzej, bo dociągają galerię, warianty i filtry.
Druga warstwa to serwer. Poniżej tych parametrów optymalizacja kodu nie ma sensu: PHP 8.2 lub 8.3, włączony OPcache, 2–4 vCPU, 4 GB RAM, dysk NVMe SSD oraz MySQL 8 albo MariaDB 10.6+. Na hostingu współdzielonym za kilkanaście złotych miesięcznie tych progów nie osiągniesz — to nie kwestia konfiguracji, a limitów współdzielonego środowiska.
Diagnostyka w trzeciej kolejności, konkretnymi narzędziami:
Kolejność prac (serwer → cache → szablony → wtyczki) opisujemy szerzej przy okazji organizacji wdrożenia WooCommerce w Zwierzyńcu.
| Wskaźnik | Próg | Gdzie sprawdzić | Co robić, gdy przekroczony |
|---|---|---|---|
| LCP | < 2,5 s (75. percentyl mobile) | Search Console / PageSpeed Insights | Kompresja obrazów do WebP/AVIF, cache stron, szybszy hosting |
| INP | < 200 ms | Search Console | Usunąć ciężkie skrypty z koszyka i filtrów, odroczyć JS |
| CLS | < 0,1 | Search Console | Rezerwować miejsce na obrazy i banery, nie wstawiać pop-upów nad treścią |
| autoload w wp_options | < 800 KB | Query Monitor / zapytanie SQL | Usunąć osierocone opcje po wtyczkach |
| Liczba wtyczek | < 25 | Panel WP / WP-CLI | Wyłączyć i usunąć wtyczki nieużywane, scalić funkcje |
W firmowym sklepie większość godzin wdrożenia pochłaniają integracje, nie wygląd. Informacja o tym, gdzie trafia paczka i czy wpłynęła płatność, jest ważniejsza niż slider na stronie głównej.
Płatności. Minimum to BLIK, karta i przelew online — w praktyce Przelewy24, PayU lub Stripe, czasem dwie bramki równolegle. O wyborze decydują cztery rzeczy: stawka od transakcji (typowo od około 1% do 2,5%, zależnie od obrotu i warunków umowy — potwierdź w aktualnym cenniku operatora), czas wypłaty środków, obsługa zwrotów i chargebacków oraz dostępność BLIK-a i płatności odroczonych. Płatności odroczone mają wyższą prowizję, ale przy koszykach powyżej kilkuset złotych realnie podnoszą konwersję. Technicznie najważniejsze są webhooki: bez poprawnej obsługi powiadomień o statusie klient zapłaci, a zamówienie zostanie w statusie „oczekujące na płatność”.
Przesyłki. InPost ShipX, DPD i DHL mają gotowe integracje, ale sprawdź przed zakupem: czy działają na Twoim typie umowy, czy generują etykietę bez logowania do panelu kuriera, czy punkty odbioru działają w koszyku i czy zwrot klienta tworzy przesyłkę zwrotną.
ERP i księgowość. Subiekt, Comarch, WF-Mag, Fakturownia — kierunek synchronizacji ustala się przed pierwszym uruchomieniem. Dwa źródła prawdy o stanie magazynowym kończą się sprzedażą towaru, którego fizycznie nie ma. Podstawę techniczną znajdziesz w dokumentacji WooCommerce, a kolejność podłączania integracji opisujemy w materiale o wdrożeniu WooCommerce z integracjami dla firmy.
| Obszar | Co musi działać | Typowa pułapka |
|---|---|---|
| Płatności | BLIK, karta, przelew online, zwroty, webhooki statusów | Brak webhooka — zamówienia wiszą jako „oczekujące na płatność” |
| Przesyłki | Etykiety InPost ShipX / DPD / DHL, punkty odbioru, statusy, zwroty | Konfiguracja przetestowana na koncie testowym zamiast produkcyjnego |
| ERP i księgowość | Stany magazynowe, faktury, numery dokumentów | Dwa źródła prawdy o stanie magazynu i ręczne poprawki po każdym dniu |
| Płatności odroczone | Odrębna prowizja, inny cykl rozliczeń | Włączone bez korekty marży na produkcie |
Zasada jest prosta: jeśli funkcja jest standardowa i występuje w tysiącach sklepów, kup wtyczkę. Koszyk, płatność, generowanie etykiety kuriera, podstawowe rabaty procentowe — to gotowe rozwiązania i pisanie ich od zera to wyrzucanie pieniędzy. Wtyczkę wybierasz też wtedy, gdy funkcja jest dodatkiem, a nie rdzeniem procesu, i gdy akceptujesz, że utrzymuje ją zewnętrzny zespół.
Moduł autorski ma sens, gdy logika jest Twoja, nie rynkowa:
Rachunek kosztu policz na subskrypcjach, które moduł zastępuje, nie na jednej. Trzy wtyczki po 80 zł miesięcznie to 2880 zł rocznie. Moduł to 30–80 godzin pracy, czyli przy 150 zł za godzinę od 4500 do 12 000 zł — próg opłacalności wypada więc realnie między 12 a 24 miesiącem. Przy jednej wtyczce za 40 zł miesięcznie ten sam moduł zwróci się dopiero po kilku latach. Punktem wyjścia są dla nas koszty wdrożenia WooCommerce i cennik prac wdrożeniowych — oba liczone od godzin, nie od „pakietów”. Pamiętaj też o koszcie ukrytym: wtyczka może zniknąć z rynku albo przestać działać po aktualizacji WooCommerce. Moduł autorski tego ryzyka nie usuwa, ale przenosi odpowiedzialność na wykonawcę wdrożenia — pod warunkiem, że kod i dokumentacja są Twoje.
| Kryterium | Gotowa wtyczka | Moduł autorski |
|---|---|---|
| Zakres funkcji | Standardowy, powtarzalny w wielu sklepach | Specyficzny dla Twojego procesu |
| Koszt | 40–120 zł/mies. za wtyczkę | 30–80 h pracy jednorazowo |
| Utrzymanie | Aktualizacje po stronie autora wtyczki | Odpowiedzialność wykonawcy wdrożenia |
| Ryzyko | Konflikt po aktualizacji WP/WooCommerce, zniknięcie autora | Wymaga dokumentacji i przekazania kodu |
| Kiedy się opłaca | Jedna funkcja, jeden proces | Gdy zastępuje 2–3 subskrypcje, próg 12–24 miesiące |
Typowy scenariusz po starcie nowego sklepu: zamówienia przychodzą, a po 3–4 tygodniach ruch z Google spada o 30–40%. Winowajców jest zwykle kilku naraz i wszyscy siedzą w warstwie technicznej.
Przekierowania 301. Zanim wyłączysz stary sklep, przygotuj plik CSV w układzie: stary URL, nowy URL, kod. Każdy adres, który miał ruch albo linki, dostaje 301 — nie 302, bo 302 nie przekazuje sygnałów. Przy katalogu 3 tys. produktów mapa przekierowań ma realnie 4–8 tys. wierszy, bo dochodzą kategorie, tagi i adresy z parametrami. Kontrola: Search Console → „Indeksowanie stron” → sekcje „Nie znaleziono (404)” i „Przekierowanie ze strony”.
Parametry filtrów i paginacja. Filtry WooCommerce tworzą adresy typu /sklep/?filter_kolor=czerwony, sortowanie ?orderby=price, a dodanie do koszyka ?add-to-cart=123. To tysiące duplikatów. Ustaw noindex dla tych widoków i nie łącz tego z blokadą w robots.txt — jeśli robot nie wczyta strony, nie zobaczy znacznika noindex i zostawi ją w indeksie. Paginacja /page/2/ powinna wskazywać canonical na siebie, nie na stronę pierwszą.
Blokady indeksowania. Sprawdź, czy noindex mają: /koszyk/, /checkout/ i /zamowienie/, /moje-konto/, wewnętrzna wyszukiwarka ?s= oraz tagi produktów, jeśli generują opisy identyczne z kategoriami. Te ostatnie najczęściej robią duplikaty na setki adresów.
Dane strukturalne. Typy Product i Offer muszą zawierać price, priceCurrency i availability, a przy opiniach aggregateRating. Po wdrożeniu przepuść 20–30 reprezentatywnych adresów przez Rich Results Test, potem pilnuj raportu danych strukturalnych w Search Console. Zakres typów obsługiwanych przez Google opisuje dokumentacja Google o danych strukturalnych.
Kolejność tych prac wpisuje się w szerszy plan — zobacz, jak wygląda organizacja wdrożenia i optymalizacji WooCommerce w Zwierzyńcu.
| Co sprawdzić | Gdzie | Sygnał problemu |
|---|---|---|
| Stare URL-e | Search Console → Indeksowanie stron | 404 na adresach z linkami |
| Filtry i sortowanie | robots.txt + meta robots | Setki adresów z ?filter_, ?orderby |
| Koszyk, checkout, konto | meta robots na podstronach | Adresy transakcyjne w indeksie |
| Paginacja | canonical na /page/2/ | Canonical wskazuje stronę pierwszą |
| Product / Offer | Rich Results Test | Brak price lub availability |
Po starcie sklep nie przestaje być projektem. Wtyczki wychodzą w nowych wersjach kilka razy w miesiącu, serwer dostaje aktualizacje PHP, a bramka płatnicza zmienia API raz na rok lub dwa. Bez opieki pierwszy poważny problem pojawia się zwykle w 2.–3. miesiącu — i wtedy okazuje się, że nikt nie ma dostępu do kopii z przedwczoraj.
SLA to liczby, nie obietnice. Wpisz do umowy: czas reakcji 4 h w godzinach pracy (8:00–16:00), przy awarii krytycznej reakcję w 1 h i usunięcie do 4 h, jeden kanał zgłoszeń (skrzynka lub system ticketowy), ścieżkę eskalacji i rabat za przekroczenie czasu. Zapisy „postaramy się” nie są SLA.
Zakres opieki. Aktualizacje WordPressa, WooCommerce i wtyczek wykonuje się najpierw na kopii staging, potem testuje: dodanie produktu do koszyka, zamówienie testowe, wysyłka maila, poprawność płatności. Dopiero potem produkcja, najlepiej w okno niskiego ruchu. Backupy: codzienne, pełne, trzymane poza serwerem, retencja 30 dni, plus test odtworzenia raz na kwartał. Bez testu odtworzenia backup to tylko plik.
Monitoring. Dostępność sklepu sprawdzana co 1 minutę, alert przy czasie odpowiedzi powyżej 3 s, brak jakiejkolwiek transakcji przez 60 minut w godzinach handlowych oraz nieudana synchronizacja z ERP więcej niż dwa razy pod rząd — każde z tych zdarzeń powinno generować zgłoszenie, nie czekać na telefon od klienta.
Zanim podpiszesz umowę, porównaj stawki z tym, co składa się na koszt utrzymania i rozwoju sklepu.
Mechanikę aktualizacji i konfiguracji sklepu opisuje dokumentacja WooCommerce.
| Parametr | Minimum w umowie | Jak zweryfikować |
|---|---|---|
| Czas reakcji | 4 h w dni robocze 8:00–16:00 | Testowe zgłoszenie przed podpisaniem |
| Awaria krytyczna | Usunięcie do 4 h | Raport incydentów za kwartał |
| Backup | Codziennie, retencja 30 dni, kopia poza serwerem | Logi i test odtworzenia |
| Monitoring | Dostępność co 1 min, alert płatności i ERP | Dostęp do panelu lub raport mailowy |
| Aktualizacje | Raz w miesiącu, najpierw staging | Lista zmian i wynik testów |
Przejście z PrestaShop, Shoper, IdoSell albo ze sklepu stacjonarnego rozliczanego w ERP ma jedną stałą kolejność: dane → URL-e → integracje → testy → przekierowania → publikacja. Odwrotna kolejność, czyli „najpierw postawmy nowy sklep, potem zobaczymy”, kończy się utratą ruchu i ręcznym poprawianiem 5 tys. adresów.
Dane. W PrestaShop eksport idzie z tabel produktów i kategorii (SQL lub moduł eksportu), w Shoper i IdoSell przez eksport XML/CSV lub API, ze sklepu stacjonarnego z systemu fakturowania. Ustal z góry: czy migrują zamówienia historyczne, klienci z hasłami (hasła i tak trzeba zresetować), opinie i stany magazynowe.
Minimalizacja przestoju. Sklep testowy stawiasz równolegle, na subdomenie, z wyłączonym indeksowaniem. Na 24 h przed przełączeniem zamrażasz dane: blokada dodawania produktów i zmian stanów albo skrypt liczący różnice i dosyłający je w dniu startu. Dzień wcześniej obniż TTL rekordu DNS do 300 s — bez tego rollback zajmie godziny zamiast kilkunastu minut. Procedura wycofania: stary sklep zostaje nietknięty do momentu potwierdzenia, że zamówienia i płatności działają. Publikacja w oknie o niskim ruchu, np. 1:00–5:00, nigdy w piątek przed świętami.
Pytania do wykonawcy. Kto jest właścicielem kodu i czy dostanę repozytorium? Kto robi backup i gdzie leży? Na kogo są licencje wtyczek i motywu? Co się dzieje po zakończeniu umowy — czy dostanę dostępy, dokumentację i bazę? Odpowiedzi wpisz do umowy razem z zakresem prac; szerszy wzór znajdziesz w opisie organizacji projektu wdrożenia WooCommerce.
| Pytanie | Dobra odpowiedź | Sygnał ostrzegawczy |
|---|---|---|
| Kto jest właścicielem kodu? | Klient, kod w jego repozytorium | Kod tylko na serwerze wykonawcy |
| Czy dostanę repozytorium? | Tak, dostęp od pierwszego etapu | Dopiero po zakończeniu umowy |
| Kto robi backup? | Wykonawca, kopia poza serwerem | „Serwer robi sam” |
| Na kogo licencje wtyczek? | Na klienta, opłaty widoczne w fakturze | Licencje zbiorcze wykonawcy |
| Co po zakończeniu umowy? | Przekazanie dostępów i dokumentacji | Brak zapisu w umowie |
Zakup WooCommerce i szablonu potraktowany jako całe wdrożenie — brakuje zakresu, integracji i testów.
Jak wykryć: W ofercie nie ma podziału na etapy, nie ma liczby godzin ani listy integracji. Pojawia się zdanie „sklep gotowy w tydzień”.
Jak naprawić: Zażądaj oferty w formacie: etap → liczba godzin → efekt → kto odpowiada. Porównaj ją z zakresem 5 filarów wdrożenia (hosting, konfiguracja, integracje, treść i SEO techniczne, przekazanie).
Brak osoby decyzyjnej po stronie klienta.
Jak wykryć: Na pytanie o ceny, regulamin albo politykę zwrotów odpowiada kilka osób i zdania są sprzeczne. Decyzje wracają po dwóch tygodniach.
Jak naprawić: Wyznacz jedną osobę z prawem do zatwierdzania zakresu i budżetu. Ustal stały slot 30–60 minut w tygodniu na status projektu.
Praca bezpośrednio na produkcji, bez środowiska staging.
Jak wykryć: Wykonawca pyta, czy może „szybko coś sprawdzić” na działającym sklepie, albo testuje płatności na produkcyjnej bazie.
Jak naprawić: Wymagaj osobnego środowiska testowego z kopią bazy i blokadą wysyłki maili oraz indeksacji. Publikacja zmian wyłącznie przez staging.
Wtyczki i szablon kupowane przez wykonawcę na jego konto.
Jak wykryć: Nie masz dostępu do panelu licencji, a faktury za wtyczki wystawia agencja jako subskrypcję.
Jak naprawić: Wszystkie licencje i konta (domena, hosting, płatności, kurierzy, wtyczki premium) powinny być zarejestrowane na dane firmy. Wykonawca dostaje dostęp techniczny, nie własność.
Brak testów przed publikacją: płatności, maile, etykiety, stany magazynowe.
Jak wykryć: Po starcie wychodzą błędy w mailach potwierdzających, etykieta InPost generuje się pusta, a płatność odroczona nie tworzy zamówienia.
Jak naprawić: Zaplanuj scenariusz testowy: zamówienie z opłatą online, BLIK, za pobraniem, z kodem rabatowym, z produktem na wyczerpanym stanie, zwrot, faktura. Każdy scenariusz podpisany przez klienta jako sprawdzony.
Zaniżona wycena ryczałtowa bez zdefiniowania liczby poprań i zakresu integracji.
Jak wykryć: Kwota jest o 40–60% niższa od pozostałych ofert, a w umowie nie ma liczby godzin ani zakresu ERP.
Jak naprawić: Rozbij wycenę na godziny i stawkę. Ustal limit poprań w etapie szablonu (np. dwie rury po 5 godzin) i stawkę za godziny dodatkowe.
Organizacyjnie wdrożenie WooCommerce to trzy rzeczy: zakres zapisany jako lista, osoba decyzyjna po stronie klienta i rozliczenie oparte na godzinach, a nie na jednej kwocie z sufitu. Porównuj oferty po liczbie godzin (40–80, 80–160, 160–300+) i stawce 120–200 zł netto za godzinę. Pamiętaj, że szablon, hosting, licencje, zdjęcia i teksty są poza wyceną wdrożenia — zapisz to w umowie. Sklep, który startuje bez testów płatności, maili i etykiet, kosztuje więcej po publikacji niż przed nią.
Prosty sklep to 2–3 tygodnie, sklep z integracjami płatności i kurierów 4–8 tygodni, a projekt z ERP i modułami własnymi 2–4 miesiące. Terminy liczy się od momentu, w którym masz gotowe dane produktowe i dostępy — nie od daty podpisania umowy. Jeśli dane schodzą się przez sześć tygodni, cały harmonogram przesuwa się o sześć tygodni.
Zaplanuj 10–25 godzin na cały projekt: decyzje, dostarczenie danych produktowych, akceptacje na stagingu i testy przed publikacją. To nie jest czas jednorazowy — rozkłada się na kilka spotkań i wiadomości. Jeśli nie ma kto tego zrobić, projekt stoi niezależnie od tempa pracy wykonawcy.
Standardowo nie. Koszt szablonu, hostingu, licencji wtyczek, zdjęć, opisów produktowych i tłumaczeń jest poza wyceną godzinową wdrożenia. Wpisz to wprost do umowy jako pozycje wyłączone, żeby uniknąć sporu przy fakturze końcowej.
Przy dużym katalogu (kilka tysięcy SKU), wielu wariantach na produkt, rozbudowanym B2B z cennikami klienta i wielojęzycznością PrestaShop bywa tańszy w utrzymaniu niż dokładanie modułów do WooCommerce. WooCommerce wygrywa tam, gdzie liczy się elastyczność treści, blog i integracja z WordPressem. Decyzję podejmij po policzeniu SKU i wariantów, nie po opiniach z forów.
Prosty sklep na gotowym szablonie z dwiema integracjami da się uruchomić samemu — kosztem czasu i ryzyka błędów w konfiguracji podatkowej, płatnościach i SEO technicznym. Wdrożenia z ERP, nietypową logiką cenową B2B albo migracją z innego systemu zwykle wymagają programisty. Sensowny kompromis to samodzielna konfiguracja treści i oddanie integracji oraz wydajności wykonawcy.
Najbezpieczniejszy model to płatność za etapy: analiza i zakres, konfiguracja, integracje, testy, publikacja. Każdy etap ma zdefiniowany efekt i liczbę godzin, więc widzisz, za co płacisz. Ryczałt bez zakresu i bez limitu poprań prawie zawsze kończy się albo dopłatami, albo niedokończonym projektem.
Podstawy (hosting, PHP 8.2/8.3, OPcache, cache obiektowy, liczba wtyczek) ustala się na etapie wdrożenia, bo później są droższe do naprawy. Pomiar i dopracowanie Core Web Vitals robi się po starcie, gdy jest realny ruch i dane z Search Console. Progi, do których warto dążyć, opisuje dokumentacja web.dev oraz Google Search Central.
Jeśli chcesz porównać swoją ofertę z realnym zakresem wdrożenia i liczbą godzin, napisz do nas — powiemy, co jest w niej policzone, a czego brakuje. Zajmujemy się wdrożeniami i optymalizacją WooCommerce dla firm, od konfiguracji po integracje i wydajność.