Wdrożenia WooCommerce w Bydgoszczy — dla kogo ma sens, a dla kogo nie

O wyborze platformy nie decyduje liczba produktów, a model sprzedaży i to, kto obsługuje zamówienia po wdrożeniu. Poniżej różnice, które realnie widać w projektach.

Kryterium	WooCommerce	PrestaShop
Wielkość katalogu	do ok. 3 000 SKU bez kombinowania	10 000+ SKU z dziesiątkami wariantów — lżejszy natywnie
Sprzedaż B2B	cenniki i role zwykle przez wtyczki (Wholesale Suite, B2B King)	grupy klientów i cenniki w rdzeniu
Koszt wejścia	niższy — WordPress + Woo na jednym hostingu	wyższy — osobny CMS, więcej pracy przy szablonie
Czas startu	3–6 tygodni dla prostego sklepu	typowo 6–12 tygodni

WooCommerce wygrywa, gdy: katalog to 100–3 000 SKU, sprzedajesz głównie detalicznie, a konkretne funkcje (subskrypcje, rezerwacje, program lojalnościowy) dokładasz wtyczką punktowo. Ma też sens, jeśli strona firmowa i blog już stoją na WordPressie — nie utrzymujesz wtedy drugiego CMS-a ani drugiego hostingu. Szczegóły techniczne znajdziesz w dokumentacji WooCommerce (link w źródłach) oraz w naszym opisie WooCommerce.

PrestaShop bywa lepszy, gdy: katalog przekracza 10 000 SKU, handel B2B to większość obrotu (indywidualne cenniki, limity kredytowe, role pracowników widzących różne ceny) albo potrzebujesz wielosklepowości z osobnymi domenami i magazynami. Wtedy wtyczkowe obejścia w Woo przestają się liczyć — płacisz mniej za wdrożenia i utrzymanie PrestaShop. Wariant dla Bydgoszczy opisujemy osobno.

Przykład z rynku lokalnego: firma sprzedająca części i akcesoria, 4 000 SKU, 60% obrotu detalicznego i 40% od warsztatów z rabatem 15%. Rekomendacja: WooCommerce + wtyczka B2B + integracja z systemem magazynowym. Gdyby proporcje były odwrotne i każdy kontrahent miał własny cennik, taniej wyszłoby wdrożenie PrestaShop. Zakres wdrożeń po stronie sklepu zobaczysz też w sekcji sklepy internetowe.

Ile trwa i ile kosztuje wdrożenie WooCommerce dla firmy w Bydgoszczy?

Wycena nie opiera się na cenniku „za sklep”, tylko na godzinach pracy. Poniżej widełki z projektów, przy stawce 120–180 zł/h netto.

Wariant	Godziny pracy	Czas kalendarzowy	Budżet netto (120–180 zł/h)
Prosty sklep B2C, do ok. 300 SKU	60–100 h	3–6 tygodni	7 200–18 000 zł
Średni sklep: warianty, 1–2 integracje	120–220 h	6–12 tygodni	14 400–39 600 zł
B2B z ERP, cenniki kontrahenckie, 5 000+ SKU	250–450 h	12–20 tygodni	30 000–81 000 zł

Do tego dochodzą koszty stałe: hosting 500–1 500 zł/rok, domena, certyfikat SSL zwykle w pakiecie hostingu. Płatności to prowizja od transakcji, nie opłata wdrożeniowa.

Co podnosi budżet najbardziej:

• Import produktów — 6–15 h na 1 000 prostych SKU z pliku CSV, ale 20–40 h, jeśli dochodzą warianty, tłumaczenia i uzupełnianie opisów po Twojej stronie.
• Integracja z systemem księgowo-magazynowym — 60–120 h przy bezpośrednim API (Subiekt przez Sferę, Comarch Optima), 20–40 h, jeśli idziesz przez pośrednika typu Baselinker.
• Migracja z istniejącego sklepu — 20–60 h: klienci, historia zamówień, mapowanie przekierowań 301 i odtworzenie pozycjonowanych adresów.
• Niestandardowy checkout — 20–40 h: pola NIP i VAT UE, walidacja numerów, osobny krok dla B2B, własne statusy zamówień.

Praktyczna zasada: jeśli któraś z tych czterech pozycji nie jest w ofercie wyceniona osobno, to najprawdopodobniej nie została policzona. Wzór wyceny opartej na godzinach znajdziesz w opisie wdrożenia i optymalizacja WooCommerce. Jeśli po analizie okaże się, że lepszy jest inny system, godziny liczy się podobnie — zobacz wdrożenia i migracje PrestaShop Bydgoszcz dla firmy.

Jak wygląda proces wdrożenia WooCommerce krok po kroku

Wdrożenie dzielimy na osiem etapów. Każdy kończy się odbiorem — bez podpisu na liście kryteriów kolejny etap nie startuje.

1. Discovery (2–6 h). Warsztat: katalog, kanały sprzedaży, integracje, kto i czym obsługuje zamówienia. Wyjście: zakres, lista integracji, mapa procesów.
2. Hosting i instalacja (4–10 h). PHP 8.2+, MySQL 8, WordPress i WooCommerce, SSL, kopie zapasowe, środowisko staging na subdomenie, cron systemowy zamiast WP-Cron. Odbiór: sklep działa na staging, masz dostępy.
3. Szablon i UX (20–60 h). Lekki motyw bez ciężkich page-builderów, karta produktu, koszyk, checkout, wersja mobilna. Odbiór: klikalny widok wszystkich kluczowych podstron.
4. Produkty i kategorie (10–40 h). Drzewo kategorii, atrybuty, warianty, jednostki, stany magazynowe, zdjęcia w WebP, opisy. Odbiór: 100% katalogu z poprawnymi cenami i stanami.
5. Płatności (4–12 h). Przelewy24, PayU lub Stripe, BLIK, tryb testowy, webhooki potwierdzające wpłatę, faktury. Odbiór: transakcja testowa i zwrotna.
6. Kurierzy i dostawa (4–12 h). InPost ShipX, DPD, punkty odbioru, waga gabarytowa, darmowa dostawa od progu. Odbiór: etykieta generuje się z panelu bez ręcznego przepisywania danych.
7. Testy (8–20 h). Wyłącznie na staging: pełna ścieżka zakupu z telefonu, maile transakcyjne przez SMTP z rekordami SPF i DKIM, LCP poniżej 2,5 s zgodnie z wytycznymi Core Web Vitals, dane strukturalne Product i Offer, mapa przekierowań 301. Odbiór: lista błędów z właścicielem i statusem.
8. Launch i opieka (6–16 h). Przepięcie DNS, weryfikacja w Search Console, zdjęcie „noindex”, monitoring dostępności, harmonogram aktualizacji. Odbiór: sklep przyjmuje zamówienia, backup się wykonuje.

Rola po stronie klienta	Co musi dostarczyć	Kiedy
Właściciel / decydent	akceptacja zakresu, ceny, treści i wyglądu	discovery, odbiór szablonu, przed launchem
Księgowość	stawki VAT, zasady fakturowania, dane do integracji	etap płatności i integracji
Logistyka / magazyn	wymiary i wagi paczek, reguły wysyłki, dane kurierów	etap kurierów
Marketing	treści, zdjęcia, kody promocyjne, dostęp do Analytics i Search Console	etap produktów i launch

Testy na produkcji to najczęstszy błąd organizacyjny — zamówienia testowe mieszają się z prawdziwymi, a wyłączanie wtyczek na żywym sklepie kończy się spadkiem pozycji. Zakres takiego procesu dla różnych platform opisujemy w wdrożeniach sklepów internetowych.

Optymalizacja WooCommerce: szybkość, baza danych i HPOS

Optymalizację zaczynamy od serwera, nie od wtyczki do cache. Ustawiamy PHP 8.2 lub 8.3 — przy katalogu 3–10 tys. produktów to zwykle 30–40% krótszy czas generowania strony niż na PHP 7.4 — plus OPcache z wyłączonym sprawdzaniem daty plików na produkcji. Baza: MySQL 8 (albo MariaDB 10.6+) na InnoDB. MySQL 8 nie ma query cache, więc zamiast tego włączamy object cache: Redis lub Memcached, podpięte wtyczką taką jak Redis Object Cache. Na kartach kategorii to często spadek liczby zapytań do bazy o 40–70%.

Drugi krok to HPOS, czyli przechowywanie zamówień w dedykowanych tabelach zamiast w wp_posts. Włączamy w WooCommerce → Ustawienia → Zaawansowane → Funkcje. Przed przełączeniem klikamy kontrolę zgodności — WooCommerce pokaże listę wtyczek ze statusem zgodna, niezgodna, niepewna. Jeśli status jest inny niż „zgodna”, nie przełączamy: najpierw wymieniamy wtyczkę. Po włączeniu HPOS sprawdzamy Action Scheduler (WooCommerce → Status → Zaplanowane akcje). Zakładki „nieudane” i „oczekujące” to najczęstsza przyczyna dławienia się sklepu — kilkaset zaległych akcji potrafi obciążyć bazę na tyle, że checkout zwalnia.

Dopiero potem cache stron z wykluczeniami koszyka i kasy, CDN, WebP/AVIF, lazy loading (ale nie dla głównego obrazu — ten pobieramy od razu).

Trzy pułapki, które widzimy najczęściej:

• Autoload w wp_options. Zapytanie: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'. Wynik powyżej 1 MB ładuje się przy każdym żądaniu. Sprawcą bywają wtyczki, które po odinstalowaniu zostawiają po sobie dane.
• WP-Cron odpalany przy wizycie użytkownika. Wyłączamy go w wp-config.php i ustawiamy systemowy cron co 5 minut.
• Nadmiar wtyczek. Każda dodaje zwykle 1–3 zapytania i własny CSS/JS; 30 aktywnych wtyczek to 60+ zapytań na wejściu.

Mierzymy na mobile, na 75. percentylu użytkowników: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Te progi i sposób interpretacji opisuje dokumentacja Core Web Vitals. Zakres tych prac opisujemy w usłudze wdrożenia i optymalizacja WooCommerce.

Integracje, które decydują o firmowym WooCommerce: płatności, kurierzy, ERP

Integracje dzielimy na trzy grupy i każdą zamykamy osobnym testem. Zaczynamy od wysyłki, bo tam błędy widać najszybciej u klienta.

Kurierzy. InPost (Paczkomaty i kurier), DPD, DHL to zwykle 2–3 umowy, więc konfigurujemy strefy wysyłki po metodzie, nie po kraju: inaczej klient z Bydgoszczy widzi w koszyku opcje, których nie powinien. Sprawdzamy trzy rzeczy: generowanie etykiety z panelu WooCommerce, zapis numeru tracking do zamówienia i wysyłkę tego numeru w mailu „zamówienie wysłane”, oraz mapę punktów odbioru. Widget mapy ładujemy dopiero po wybraniu metody — bez tego dokłada 300–500 KB JS na każdym wejściu do kasy.

Płatności. Przelewy24, PayU, tpay, Stripe i BLIK. BLIK musi być widoczny bez rozwijania listy — to najczęściej wybierana metoda w Polsce. Kluczowa zasada: potwierdzenie płatności opieramy na webhooku, nie na powrocie klienta na stronę. Klient zamknie kartę i wróci za godzinę — zamówienie i tak musi mieć status „przetwarzanie”.

ERP. Subiekt, Comarch Optima, WF-Mag, Fakturownia. Ustalamy kierunki i częstotliwość: stany magazynowe co 5–15 minut, ceny raz na dobę lub przy zmianie, zamówienia i faktury na bieżąco. Synchronizacja musi być idempotentna — powtórne pobranie danych nie może tworzyć duplikatów faktur.

Test 50 zamówień. Minimum po 10 na każdą kombinację płatność-dostawa, plus scenariusze błędów: brak odpowiedzi API (timeout, kolejka ponowień), błędny NIP przy fakturze dla firmy (walidacja przed wystawieniem, korekta kosztuje więcej niż blokada), zwrot i wymiana. Kontrolujemy też, czy wpisany numer tracking pojawia się w panelu klienta i w mailu. Dokumentacja integracji WooCommerce jest punktem startowym dla tych prac, a szerszy kontekst znajdziesz w opisie sklepów internetowych.

Bezpieczeństwo, hosting i administracja VPS pod WooCommerce

Hosting współdzielony wystarcza do około 50–100 zamówień miesięcznie, jeśli sklep nie ma integracji z ERP. Sygnały, że czas na VPS: brak object cache w planie, limit 1 vCPU, brak dostępu SSH, brak możliwości ustawienia systemowego crona. VPS z 4 vCPU, 8 GB RAM i dyskiem NVMe obsłuży kilka tysięcy zamówień dziennie przy poprawnym cache — pod warunkiem, że ktoś nim administruje, a nie tylko go opłaca.

Backup. Zasada 3-2-1: trzy kopie, dwa nośniki, jedna poza serwerem. Codziennie baza i pliki, retencja minimum 30 dni, a raz na kwartał odtworzenie kopii na stagingu. Backup, którego nie odtworzyłeś, to nie backup, a nadzieja.

Staging to kopia na subdomenie z noindex i hasłem. Bez niej każda aktualizacja to test na klientach.

Bezpieczeństwo. WAF przed sklepem (np. Cloudflare), rate limiting na wp-login.php i xmlrpc.php, blokada logowania po kilku nieudanych próbach, 2FA dla administratorów. Do tego monitoring: uptime sprawdzany co minutę z alertem na błędy 5xx, osobne sprawdzenie adresu kasy, alert na TTFB powyżej 600 ms.

Aktualizacje. Drobne wersje WordPressa mogą iść automatycznie. Wtyczki i WooCommerce — najpierw staging, przejście testowego zamówienia, potem produkcja, w oknie poza szczytem. Wtyczki płatności i kurierów aktualizujemy razem z WooCommerce, nie osobno.

SLA. Ustalamy pisemnie dwie kategorie: awaria krytyczna (sklep nie przyjmuje zamówień) i zgłoszenie zwykłe, z czasem reakcji np. 4 h w godzinach 8–18 i 24 h dla pozostałych. Opieka zdalna działa tak samo niezależnie od tego, czy klient jest z Bydgoszczy, czy z Lubelszczyzny — pracujemy przez SSH i VPN, różnicy nie widać. Zakres takiej opieki opisujemy przy organizacji wdrożeń i optymalizacji WooCommerce.

Migracja do WooCommerce z innej platformy — pułapki i sposoby ich wykrycia

Migracja z PrestaShop, Shopera, Magento czy autorskiego CMS-a wygląda podobnie: przenieść dane, zachować adresy URL, nie zgubić klientów. Pierwszy krok to eksport do CSV — osobno produkty, kategorie, atrybuty, klienci, zamówienia. Zanim cokolwiek zaimportujesz, zrób mapowanie kolumn: SKU, EAN/GTIN, cena netto i brutto, stan magazynowy, jednostka miary, stawka VAT. Jeśli w starym sklepie SKU to wewnętrzne ID, a EAN-u nie ma wcale, ustal to teraz — dorabianie kodów po starcie oznacza ręczną pracę przy każdym produkcie i rozjazd stanów między sklepem a magazynem.

Zdjęcia przenoś w oryginalnej rozdzielczości, nie z miniatur. WooCommerce sam wytnie rozmiary w Ustawienia → Media. Warto zostawić nazwy plików oparte na SKU — łatwiej potem znaleźć, który obrazek nie wszedł do galerii.

Przekierowania 301 to najczęstsze miejsce utraty ruchu. Wyciągnij z Search Console listę adresów z wyświetleniami (Raport wydajności → eksport) i dołóż adresy z logów serwera. Zrób mapę 1:1 na nowe URL-e, także dla kategorii i filtrów, które generowały ruch. Bez tego tracisz pozycje na 3–6 miesięcy. Audyt SEO przed startem obejmuje title, description, H1, canonical, sitemap.xml, robots.txt oraz dane strukturalne Product i Offer — ich zakres opisuje dokumentacja Google Search Central.

Zamówienia i klienci: historię zamówień przenoś jako archiwum widoczne w koncie klienta, ale nie jako aktywne zamówienia wpływające na raporty sprzedaży. Hasła z PrestaShop czy Shopera są niekompatybilne z WordPressem — trzeba wymusić reset hasła mailem i uprzedzić obsługę klienta, bo po launchu poleci seria zgłoszeń „nie mogę się zalogować”.

Testy porównawcze rób na próbie 40–60 produktów, najlepiej z wariantami i promocjami. Porównaj cenę netto i brutto, stan, VAT, koszt dostawy i próg darmowej wysyłki. Rozjazd o grosz na pięćdziesięciu pozycjach oznacza błąd w całym imporcie. Jeśli migrujesz ze sklepu opartego na PrestaShop, zobacz nasz opis wdrożeń i migracji PrestaShop w Bydgoszczy — różnice w strukturze katalogu i cech są tam rozpisane punkt po punkcie.

Jak wybrać wykonawcę wdrożenia WooCommerce w Bydgoszczy — pytania i kryteria

Zadaj trzy pytania, które najszybciej pokażą różnicę między wykonawcami. Pierwsze: czy wycena jest godzinowa i jaka jest stawka? Jeśli dostajesz jedną kwotę „za całość” bez zakresu godzinowego, nie wiesz, co się stanie, gdy okaże się, że trzeba dopisać integrację z Subiektem albo przenieść 8 tys. SKU. Dobra odpowiedź to zakres prac, szacunek godzin, stawka i lista rzeczy, które nie wchodzą w cenę.

Drugie: kto pisze moduły — wasz zespół czy podwykonawca? Różnica jest praktyczna. Gdy padnie płatność w środku kampanii, chcesz mieć pod ręką osobę, która zna kod, a nie pośrednika czekającego na odpowiedź kogoś innego. Poproś o kontakt do dwóch firm, dla których wykonawca robił integrację z ERP lub systemem magazynowym.

Trzecie: jak wygląda opieka po wdrożeniu? Ustal konkret: czas reakcji (np. 2 godziny w dni robocze dla błędów krytycznych), czas naprawy, kanał zgłoszeń, kto ma dostęp do serwera i kopii zapasowych, kiedy ostatnio testowano odtworzenie backupu. „Opieka” bez SLA to mail, na który odpowiedź przychodzi po dwóch dniach.

Portfolio sprawdzaj pod kątem swojego modelu: dwa sklepy B2B (ukryte ceny, cenniki indywidualne, logowanie) i dwa B2C. Wejdź na nie z telefonu i sprawdź Core Web Vitals — LCP powyżej 4 s na mobile to sygnał, że nikt nie zajmował się wydajnością; progi i sposób pomiaru opisuje web.dev – Web Vitals. Zapytaj też o wersję PHP i hosting. Zobacz, jak wygląda nasz zakres wdrożeń i optymalizacji WooCommerce oraz co obejmuje WooCommerce w naszej realizacji.

Checklista: gotowość firmy do wdrożenia WooCommerce w Bydgoszczy

Ta lista służy do odklikania przed startem. Każdy punkt bez właściciela i terminu to opóźnienie w harmonogramie.

• Dostęp do domeny i DNS — kto trzyma dane logowania do rejestratora.
• Hosting: PHP 8.2 lub nowsze, MySQL 8 / MariaDB 10.6+, min. 2 GB RAM, SSL, automatyczne kopie zapasowe.
• Decyzja o technologii: klasyczny WooCommerce na WordPress z lekkim motywem czy builder — wpływa na wydajność i koszt utrzymania.
• Lista integracji: płatności, kurierzy, faktury, ERP/magazyn, mailing, program lojalnościowy.
• Dane produktowe w CSV: SKU, EAN, opisy, zdjęcia, warianty, waga, wymiary.
• Regulamin, polityka prywatności, cookies, zgody RODO — kto pisze i kto akceptuje.
• Konta analityczne: Google Analytics 4, Search Console, Merchant Center.
• Cennik dostawy i progi darmowej wysyłki.
• Dane firmy do faktur i stopki.
• Budżet na poprawki po launchu — realnie 10–15% wartości wdrożenia.

Kolejność działań: decyzje biznesowe → dane i treści → integracje → migracja → testy → launch. Treści i zdjęcia dostarcza klient, bo tylko on zna produkt i jego przewagi. Teksty prawne — regulamin i politykę prywatności — pisze prawnik po stronie klienta; wykonawca wdraża je na stronę i podpina checkboxy. Konfiguracja serwera, kopie zapasowe i test odtworzenia backupu to strona wykonawcy.

Termin launchu planuj względem sezonu. Nie startuj dwa tygodnie przed szczytem — w handlu detalicznym to listopad i grudzień, w ogrodnictwie wiosna. Zostaw minimum 4 tygodnie na testy i 2 tygodnie buforu na poprawki po starcie, bo Google potrzebuje czasu na przeczołganie nowych adresów. Zobacz też, jak podchodzimy do sklepów internetowych jako całości — od wyboru platformy po opiekę powdrożeniową.

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

Lista kontrolna do odklikania

• Zakres i budżet godzinowy na piśmie — Przed podpisaniem umowy. Oferta powinna mieć tabelę etapów z liczbą godzin i stawką, a nie jedną kwotę.
• Osoby po stronie klienta — Przed startem ustal, kto decyduje (właściciel), kto podaje dane produktowe (logistyka/magazyn), kto rozlicza faktury (księgowość) i kto dostarcza treści (marketing).
• Wersje PHP i MySQL na hostingu — Sprawdź w panelu hostingu. Docelowo PHP 8.2 lub 8.3 oraz MySQL 8. Starsza wersja to wolniejszy sklep i ryzyko braku wsparcia wtyczek.
• Object cache (Redis lub Memcached) — Zapytaj dostawcę hostingu przed startem. Bez object cache każda wizyta generuje powtarzalne zapytania do bazy.
• Zgodność wtyczek z HPOS — Sprawdź na stagingu przed włączeniem HPOS na produkcji. Lista zgodności jest dostępna w panelu WooCommerce.
• Środowisko staging działa i jest aktualne — Weryfikuj przed każdą aktualizacją. Kopia starsza niż kilka tygodni przestaje być wiarygodnym testem.
• Backup 3-2-1 z testem odtworzenia — Ustal harmonogram i wykonaj próbne odtworzenie na staging. Backup, którego nie odtworzyłeś, nie jest backupem.
• Strefy kurierskie, etykiety i punkty odbioru — Test na stagingu: wygeneruj etykietę InPost, DPD i DHL, sprawdź tracking i mapę punktów w koszyku oraz na mobile.
• Płatności: sandbox, potem produkcja — Przetestuj Przelewy24 / PayU / tpay / Stripe oraz BLIK w trybie testowym, w tym płatność nieudaną i anulowaną.
• Przekierowania 301 po migracji — Przed launchem. Wyeksportuj stare adresy URL i zmapuj je na nowe — sprawdź losowo 20–30 pozycji, czy nie prowadzą do 404.
• Import produktów: ceny, stany, warianty, zdjęcia — Sprawdź po imporcie na stagingu liczbę SKU, poprawność wariantów, jednostek miary i stanów magazynowych.
• Synchronizacja z ERP lub programem do faktur — Test na realnych danych: zamówienie → faktura → stan magazynowy → status w sklepie. Sprawdź też scenariusz zwrotu.
• Metryki Core Web Vitals po optymalizacji — Zmierz LCP, INP i CLS na stagingu i na produkcji po cache oraz CDN. Cel: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1.
• Plan aktualizacji, monitoring i SLA — Ustal przed launchem: kto aktualizuje, jak często, jaki jest czas reakcji na awarię i kto odbiera zgłoszenia poza godzinami pracy.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – Core Web Vitals
• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• web.dev – Core Web Vitals
• WooCommerce – dokumentacja