Wdrożenie a optymalizacja WooCommerce — co naprawdę kupuje firma ze Szczecina

Zanim poprosisz o wycenę, ustal jedną rzecz: czy potrzebujesz wdrożenia, czy optymalizacji. To dwa różne projekty, z innym budżetem, innym zespołem i innym sposobem odbioru prac.

Wdrożenie to zbudowanie sklepu od podstaw. W praktyce oznacza: środowisko (PHP 8.2 lub 8.3, MySQL 8 albo MariaDB 10.6+, Object Cache, poprawnie działający cron), strukturę katalogu (kategorie, atrybuty filtrowalne, produkty wariantowe), podatki (stawki VAT, klasy podatkowe, ceny netto i brutto), strefy wysyłek (regiony, metody, progi darmowej dostawy), płatności (Przelewy24, PayU, Stripe, BLIK) oraz integracje kurierskie przez API (InPost, DPD, DHL). Typowy zakres: 90–180 godzin.

Optymalizacja dotyczy sklepu, który już sprzedaje, ale za wolno. Pracuje się na trzech warstwach: czas odpowiedzi serwera (TTFB), Core Web Vitals (LCP, INP, CLS) oraz ścieżka koszyka — liczba kroków, liczba pól w formularzu, komunikaty o błędach. Typowy zakres: 20–60 godzin. Metryki, o których mowa, opisuje dokumentacja Web Vitals.

Trzy sygnały, że potrzebujesz optymalizacji, a nie kolejnego wdrożenia:

• LCP powyżej 4 s na mobile. Sprawdzisz to w PageSpeed Insights albo w raporcie CrUX dla swojej domeny. Jeśli różnica między desktopem a mobilem jest dwukrotna, problem jest w obrazach i renderowaniu, nie w koncepcji sklepu.
• Porzucenia koszyka skupione na kroku dostawy. Jeżeli z analityki wynika, że ze 100 wejść do koszyka 25 osób dochodzi do wyboru wysyłki, a zamawia 8 — problem siedzi w strefach wysyłek, wtyczce kurierskiej albo niejasnych kosztach, nie w szacie graficznej.
• Baza danych powyżej 200 MB bez czyszczenia. Sprawdź w phpMyAdmin rozmiar tabel wp_posts i wp_options. Setki tysięcy rewizji wpisów i zalegające transienty to typowy skutek dwuletniej eksploatacji bez przeglądu.

Migracja z innego systemu bywa tańsza niż łatanie. Jeżeli masz ponad 15 wtyczek, motyw bez aktualizacji od roku, bazę powyżej 500 MB i brak stagingu, to każda naprawa kupuje ci pół roku spokoju. Wtedy warto policzyć migrację z PrestaShop do WooCommerce jako projekt docelowy, a nie kolejną łatę.

7 etapów wdrożenia WooCommerce — od briefu do pierwszego zamówienia

Dobre wdrożenie to sekwencja, w której każdy etap ma termin i konkretny dowód odbioru. Poniżej realne czasy dla sklepu 500–3000 SKU.

1. Brief i inwentaryzacja (2–5 dni roboczych). Odbior: dokument z listą kategorii, atrybutów, metod wysyłki, metod płatności i integracji. 2. Środowisko staging (1–2 dni). Odbior: adres stagingowy z wyłączonym wysyłaniem maili, płatnościami w trybie sandbox i blokadą indeksowania. 3. Konfiguracja produktów, podatków i wysyłek (5–15 dni). Odbior: katalog z poprawnie naliczanym VAT, strefami wysyłek i progami darmowej dostawy. 4. Integracje płatności i kurierów (3–10 dni). Odbior: zamówienie testowe opłacone i wygenerowana etykieta kurierska. 5. Import danych i mapowanie URL-i (2–7 dni). Odbior: przekierowania 301 ze starych adresów na nowe, najczęściej przez wtyczkę Redirection albo reguły w .htaccess. 6. Testy zamówień i obciążeniowe (3–5 dni). Odbior: raport z 20–30 scenariuszy zakupowych i próba obciążeniowa. 7. Start z monitoringiem (1–2 dni). Odbior: dostęp do monitoringu dostępności, kopie zapasowe i ustalony czas reakcji na awarie.

Od klienta potrzebujemy pięciu rzeczy: danych produktowych z cenami i stanami w ustalonym formacie (CSV lub arkusz), zdjęć w docelowych proporcjach, regulaminu i polityki prywatności, danych do umów z kurierami i operatorem płatności oraz osoby decyzyjnej po stronie firmy. Brak choćby jednego z tych elementów zatrzymuje etap, a nie cały projekt — dlatego warto ustalić je przed startem, o czym piszemy szerzej przy wdrożeniach sklepów internetowych.

Staging z anonimizowaną kopią danych produkcyjnych skraca testy o kilka dni. Kopiujesz realne produkty, ceny i konta klientów, podstawiając fikcyjne dane osobowe, wyłączasz wysyłkę maili i płatności na żywo. Zamiana adresów to jedno polecenie WP-CLI: wp search-replace ze starym i nowym adresem. Bez tego testujesz na wymyślonych produktach i pierwsze realne zamówienie i tak wywala błąd.

Ile trwa i ile kosztuje wdrożenie WooCommerce dla firmy — widełki, nie cennik z sufitu

Wycena wdrożenia to liczba godzin pomnożona przez stawkę. Dla prac wdrożeniowych w małych i średnich firmach stawki w 2025 roku mieszczą się w przedziale 120–220 zł netto za godzinę. Typowy projekt 500–3000 SKU z dwiema metodami płatności i dwoma kurierami to 90–180 godzin. Arytmetyka skrajna daje 10 800 zł (90 h × 120 zł) i 39 600 zł (180 h × 220 zł), ale najwięcej projektów tej klasy ląduje w przedziale 12 000–35 000 zł netto — skrajnie niska stawka rzadko idzie w parze z bardzo szerokim zakresem.

Poproś wykonawcę o rozbicie wyceny na etapy z tabeli powyżej. Oferta, która podaje jedną kwotę bez godzin i bez podziału, nie da się porównać z żadną inną.

Co podnosi budżet: niestandardowe moduły (konfigurator, kalkulator dostawy), migracja z zachowaniem wszystkich adresów URL, wielojęzyczność, cenniki grupowe B2B z indywidualnymi rabatami, integracja z ERP (Subiekt, Comarch Optima, SAP B1). Każda z tych rzeczy to zwykle 15–40 dodatkowych godzin. Co obniża: sprawdzony stack (jeden motyw i zestaw wtyczek, których wykonawca już używał), dane produktowe przygotowane przez klienta w ustalonym formacie, brak zmian zakresu w trakcie prac. Zmiana koncepcji w połowie projektu to najdroższy element, jaki można sobie zafundować.

Płatności rozliczaj etapami powiązanymi z odbiorem, nie z kalendarzem: np. 30% po briefie i starcie stagingu, 40% po konfiguracji katalogu i integracjach, 30% po testach i starcie. Nie płać całości z góry — przy projekcie 150-godzinnym to kilkanaście tysięcy złotych zamrożone na dwa miesiące. Jeżeli po starcie chcesz jeszcze popracować nad widocznością sklepu, to osobny budżet; zobacz SEO techniczne i optymalizację szybkości, którą zwykle planuje się 2–3 miesiące po wdrożeniu, gdy zbierzesz dane z realnego ruchu.

Optymalizacja WooCommerce: 6 obszarów, które dają mierzalny efekt

Kolejność prac ma większe znaczenie niż ich liczba. Poniżej sześć obszarów uszeregowanych od największego zwrotu — od infrastruktury po porządki w kodzie.

1. Stack. PHP 8.2 lub 8.3, włączony OPcache (opcache.enable=1, opcache.memory_consumption na 256 MB, opcache.validate_timestamps=0 na produkcji) oraz object cache oparty na Redis albo Memcached. Na sklepie z 3000 SKU samo przełączenie object cache z domyślnego backendu na Redis potrafi ściąć czas generowania strony o 30–50% bez zmiany choćby linijki kodu. Warunek: rozszerzenie php-redis na serwerze i wtyczka object cache faktycznie wskazująca na ten backend — inaczej „włączony Redis” nic nie robi.

2. Baza danych. Trzy pierwsze porządki: wygasłe transjenty (wp_options rośnie wtedy do setek tysięcy wierszy), tabele sesji WooCommerce (_wc_session_expires) i wp_options z autoload='yes' — powyżej około 1000 takich wierszy każda strona wczytuje je do pamięci. Dalej slow query log (long_query_time=1) i indeksy pod najczęstsze zapytania do metadanych zamówień.

3. HPOS. High-Performance Order Storage przenosi zamówienia z wp_posts i wp_postmeta do dedykowanych tabel. Przy katalogu powyżej 5000 zamówień różnicę widać w liście zamówień, raportach i eksportach. Warunek: każda wtyczka i integracja musi deklarować zgodność — tryb zgodności włącza się na próbę, przed pełnym HPOS. Warto sprawdzić to w dokumentacji WooCommerce, zanim przełączy się środowisko produkcyjne.

4. Frontend. Konwersja zdjęć do WebP lub AVIF, lazy loading poza pierwszym ekranem (obraz LCP ładuje się normalnie), krytyczny CSS inline, defer/async dla skryptów i realne ograniczenie liczby wtyczek — każda dokłada własny CSS i JS na każdej stronie.

5. Zapytania w kodzie. Najczęstszy grzech to wzorzec N+1 w pętlach produktów: osobne zapytanie o meta dla każdego produktu na liście. Dalej zapytania w hookach ładowanych na każdej podstronie i brak cache fragmentów dla bloków powtarzalnych. Ten etap warto robić po stacku i bazie, bo dopiero wtedy widać prawdziwe wąskie gardło — porządek prac opisujemy szerzej przy wdrożeniach i optymalizacji WooCommerce.

6. Konfiguracja. Cron systemowy zamiast WP-Cron odpalany ruchem (DISABLE_WP_CRON i zadanie w crontabie co minutę), CDN dla statyków, wyłączenie funkcji, których sklep nie używa.

Jak zmierzyć efekt optymalizacji — liczby, które mają znaczenie

Optymalizacja bez pomiaru to wymiana opinii. Trzy narzędzia wystarczą do większości wniosków: PageSpeed Insights z danymi CrUX, Query Monitor oraz GA4.

Progi Core Web Vitals. Patrz na 75. percentyl, nie na średnią ani na wynik z jednego testu. LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — to warunki oceny „dobre” w metrykach Web Vitals. Do tego TTFB poniżej 600 ms przy hostingu w Polsce. Jeśli TTFB skacze powyżej 1 s, dalsza praca nad CSS i JS to strata czasu — najpierw serwer, PHP i object cache.

Sklep pod obciążeniem, nie demo. Koszyk i checkout powinny odpowiadać w mniej niż sekundę na koncie testowym z 3000 SKU i ponad 5000 zamówień. Test na demo z dziesięcioma produktami nie pokaże niczego — indeksy, HPOS i cache dopiero tam zaczynają pracować.

Query Monitor. Dwie liczby: zapytania SQL na stronę (cel poniżej 50) i czas generowania strony (cel poniżej 300 ms). Jeśli lista produktów wykonuje 180 zapytań, problem jest w kodzie lub wtyczkach, a nie w hostingu.

Miara biznesowa. Zapisz w GA4 konwersję, przychód i porzucenia koszyka z 30 dni przed zmianami i porównaj po. Spadek LCP o sekundę bez ruchu w konwersji oznacza, że zoptymalizowano nie to miejsce. Ten sam zakres prac — obrazy, CSS, TTFB — przekłada się też na pozycje, dlatego warto spinać go z SEO technicznym i optymalizacją szybkości w Szczecinie.

Integracje, bez których polski sklep nie działa: płatności, InPost, DPD, DHL, ERP

Wygląd sklepu klient ocenia raz. Integracje ocenia codziennie — przy pakowaniu, księgowaniu i reklamacjach.

Płatności. Przelewy24, PayU, Autopay, BLIK, karta i pay-by-link. Kluczowe nie jest „czy się łączy”, ale co dzieje się z webhookami: czy są weryfikowane podpisem, czy są idempotentne (ten sam callback dwa razy nie tworzy dwóch zamówień) i co sklep robi ze statusem „pending”, który nigdy nie wraca. Bez logowania żądań i odpowiedzi nie ustalisz, czy problem jest po stronie bramki, czy sklepu.

Kurierzy. InPost ShipX (Paczkomaty i kurier), DPD WebAPI, DHL. Zakres: generowanie etykiet z panelu zamówień, przekazanie numeru przesyłki do klienta i aktualizacja statusu, obsługa zwrotów. Tu najczęściej brakuje kolejki zadań — gdy API kuriera nie odpowiada, zamówienie powinno trafić do ponowienia, a nie zniknąć z komunikatem błędu na ekranie pracownika.

ERP i księgowość. Subiekt GT/Nexo, Comarch Optima, WF-Mag. Ustal kierunek synchronizacji, zanim cokolwiek podłączysz: stany i ceny idą z ERP do sklepu, zamówienia ze sklepu do ERP. Częstotliwość zależy od rotacji towaru — przy szybko rotujących pozycjach synchronizacja co 5–15 minut, przy pozostałych wystarczy rzadsza. Zła kolejność (sklep nadpisuje stany w ERP) kończy się bałaganem w magazynie.

Typowe awarie. Brak idempotencji webhooków i duplikaty zamówień, brak kolejki przy niedostępności API, brak logów żądań i odpowiedzi, a także wykonywanie całej synchronizacji w żądaniu użytkownika — klient czeka wtedy na ERP. Standardowe integracje dla WooCommerce opisujemy w sekcji WooCommerce, a szerszy kontekst projektów e-commerce w sklepach internetowych.

Pułapki przy wdrożeniu i optymalizacji WooCommerce — jak je wykryć przed klientem

Większość „niespodzianek” po wdrożeniu nie wynika z błędów w kodzie, a z rzeczy, których nikt nie przetestował na stagingu. Poniżej lista testów do wykonania przed przekazaniem sklepu.

• Duplikaty URL-i i archiwa atrybutów po migracji. Po przejściu z PrestaShop, Shopera lub starego WooCommerce zostają archiwa typu /product-tag/, /product-category/ oraz warianty z parametrami filtrów. Efekt: tysiące adresów indeksowanych jako osobne strony. W Search Console sprawdź raport „Strony”, zwłaszcza pozycję „Zindeksowane, mimo że nie oznaczono jako kanoniczne”. Zakres minimum: eksport starych URL-i (Screaming Frog albo logi serwera), mapa przekierowań 301 w relacji 1:1, bez łańcuchów dłuższych niż dwa przeskoki, wyłączenie indeksowania archiwów atrybutów i nowa, wyczyszczona sitemapa zgłoszona w GSC. Porządek w tym obszarze to część SEO technicznego i optymalizacji szybkości dla sklepów w Szczecinie.
• Cache w konflikcie z koszykiem. LiteSpeed Cache, WP Rocket i CDN potrafią zbuforować fragment koszyka. Test: na koncie niezalogowanym dodaj produkt, usuń go, wejdź w koszyk ponownie; powtórz na koncie zalogowanym. Sygnał problemu — pusty koszyk, zła liczba sztuk albo dane innego użytkownika. Do wykluczeń z cache i CDN dodaj /koszyk/, /moj-konto/, /zamowienie/ oraz ciasteczka woocommerce_items_in_cart i wp_woocommerce_session.
• WP-Cron odpalany ruchem. Przy ruchu poniżej ok. 100 sesji dziennie kolejka maili i zmian statusów nie domyka się — zamówienia wiszą jako „oczekujące na płatność”, a integracje z kurierem czy fakturowaniem nie startują. Rozwiązanie: DISABLE_WP_CRON w wp-config.php i systemowy cron co 5 minut. Sprawdź zakolejkowane zadania w WP Crontrol oraz w Action Scheduler.
• Strefy wysyłek i progi darmowej dostawy nadpisane przez wtyczkę. Przetestuj koszyk z produktem gabarytowym (wysyłka paletowa), koszyk z trzema paczkami, zamówienie za 149 zł przy progu darmowej dostawy 150 zł i zakup ze strefy „Niemcy”. Sprawdź, czy wtyczka od wysyłek nie nadpisuje reguł z WooCommerce → Ustawienia → Wysyłka.
• Backup bez testu odtworzenia i brak stagingu. Kopia, której nikt nie przywrócił, nie jest backupem. Raz na kwartał odtwórz kopię na subdomenie staging.twojadomena.pl (noindex + Basic Auth) i przejdź przez zamówienie testowe.
• Jak wykrywać. Logi błędów PHP (WP_DEBUG_LOG tylko na stagingu), monitoring błędów i dostępności, płatności w trybie sandbox, a na koniec lista kontrolna 14 testów przed startem — od rejestracji po zwrot i fakturę.

Zakres typowych konfiguracji opisuje dokumentacja WooCommerce, ale żaden dokument nie sprawdzi za Ciebie koszyka na produkcji.

Kiedy WooCommerce przestaje wystarczać i jak wybrać wykonawcę w Szczecinie

WooCommerce skaluje się dalej, niż się powszechnie uważa, ale ma granice, które łatwo policzyć.

• Powyżej 50 000 SKU panel administracyjny, eksporty i wyszukiwanie zaczynają wymagać HPOS, wyszukiwarki zewnętrznej (Algolia, ElasticPress) i katalogu na osobnym serwerze. Część firm przechodzi wtedy na PrestaShop lub rozwiązanie marketplace’owe — porównanie znajdziesz w materiale o wdrożeniach i optymalizacji WooCommerce.
• Wielokanałowa sprzedaż B2B i B2C z indywidualnymi cennikami — cenniki per klient, limity kredytowe, płatność odroczona. Da się to zrobić wtyczkami, ale trzeba sprawdzić kolizje z rabatami, podatkami i strefami wysyłek przed zakupem, nie po.
• Zaawansowany workflow zamówień — wielu sprzedawców, podział zamówienia na przesyłki, rozliczanie prowizji. Przy kilku sprzedawcach i ręcznym rozliczaniu WooCommerce przestaje być optymalny.

Zanim podpiszesz umowę, zadaj sześć pytań: kto konkretnie pisze kod (imiona, nie „zespół”), jak wyceniacie — godziny czy pakiet, co zawiera SLA, jak wygląda staging i backup, kto odpowiada za aktualizacje i bezpieczeństwo, co dzieje się po zakończeniu współpracy (repozytorium, dostępy, dokumentacja).

W SLA wpisz: czas reakcji 4 h w godzinach pracy, 8 h na awarię krytyczną rozumianą jako brak możliwości złożenia zamówienia, liczbę godzin w pakiecie i stawkę za nadwyżkę. Bez tego „wsparcie” bywa wyceniane po fakcie.

Rozważ pracę bezpośrednio z deweloperem zamiast przez pośrednika — krótsza ścieżka decyzji i brak marży agencyjnej, która w praktyce wynosi 20–50%. Jeśli potrzebujesz szerszego spojrzenia na wybór platformy, zajrzyj do naszych sklepów internetowych — ale najpierw policz SKU, zamówienia dziennie i liczbę integracji.

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

Lista kontrolna do odklikania

• Ustal, czy potrzebujesz wdrożenia, czy optymalizacji — Wdrożenie to nowe środowisko, katalog, podatki, wysyłki, płatności i kurierzy. Optymalizacja to czas odpowiedzi serwera, Core Web Vitals i ścieżka koszyka. Spisz, co konkretnie nie działa — to podstawa briefu.
• Policz SKU, które realnie trafią do sklepu — Liczba produktów wpływa na import, strukturę kategorii i czas testów. Projekt 500–3000 SKU to typowy zakres dla MŚP.
• Zmierz LCP na mobile na stronie produktu — Użyj PageSpeed Insights lub danych z web.dev. Wynik powyżej 4 s na mobile to sygnał, że potrzebujesz optymalizacji, a nie kolejnego wdrożenia.
• Sprawdź wersję PHP na serwerze — Docelowo PHP 8.2 lub 8.3. Starsza wersja to najczęstsza przyczyna wolnego WooCommerce i problemów z aktualizacjami wtyczek.
• Potwierdź, że OPcache jest włączony — Sprawdź w panelu hostingu albo przez plik phpinfo(). Bez OPcache każdy request PHP wykonuje ten sam kod od nowa.
• Zapytaj o object cache (Redis lub Memcached) — Włączony object cache odciąża bazę przy koszyku i katalogu. To często największy skok wydajności bez zmiany kodu.
• Zmierz rozmiar bazy danych — Baza powyżej 200 MB bez czyszczenia to sygnał narastających transjentów, sesji WooCommerce i wierszy w tabeli wp_options z autoloadem.
• Przejrzyj tabelę wp_options pod kątem autoloadu — Zbyt duży autoload ładuje się przy każdym żądaniu. Sprawdź, które wpisy są zbędne i czy da się je ograniczyć bez psucia wtyczek.
• Przygotuj zdjęcia w docelowych proporcjach — Zanim ruszy import. Pliki w innych proporcjach niż szablon oznaczają przycinanie, dodatkową pracę i wolniejsze ładowanie.
• Dostarcz regulamin i politykę prywatności — Potrzebne przed ustawieniem checkoutu i obowiązkowych zgód. Brak tych dokumentów blokuje testy zamówień.
• Zbierz dane do umów z kurierami i operatorem płatności — Identyfikatory API, klucze, numery umów. Bez nich etap integracji stoi, bo wykonawca nie ma czego podłączyć.
• Określ, czy potrzebujesz stagingu z danymi produkcyjnymi — Staging z anonimizowaną kopią danych produkcyjnych skraca testy o kilka dni, bo łapie problemy na realnych zamówieniach, a nie na pustym katalogu.
• Ustal harmonogram płatności etapowych — Każda faktura powinna być powiązana z odbiorem etapu: środowisko, konfiguracja, integracje, import, testy, start.
• Zaplanuj monitoring po starcie — Ustal, kto i czym sprawdza dostępność sklepu, czasy odpowiedzi i błędy PHP w pierwszym tygodniu po uruchomieniu.

Najczęściej zadawane pytania

Źródła i materiały

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