Wdrożenie i optymalizacja WooCommerce — co to właściwie obejmuje, a czego nie

W praktyce „wdrożenie WooCommerce” oznacza jedno z trzech zadań — każde ma inny zakres prac, inny budżet i inne ryzyko.

• Wdrożenie od zera — nowy sklep na czystym WordPressie: instalacja, konfiguracja katalogu, płatności, wysyłki, szablony e-mail, testy. Startuje z pustą bazą.
• Migracja z innej platformy — przeniesienie produktów, klientów, zamówień i adresów URL z PrestaShop, Shopera, Magento czy IdoSell. Dochodzi mapowanie danych, przekierowania 301 i okres, w którym oba sklepy działają równolegle.
• Optymalizacja istniejącego sklepu — praca na działającym serwisie: cache, baza danych, obrazy, wersja PHP, porządki we wtyczkach. Zakres zamknięty i mierzalny efekt.

Druga rzecz, która najczęściej się rozjeżdża: WooCommerce to wtyczka, a WordPress to CMS. Hosting, bezpieczeństwo i wydajność zależą od obu warstw jednocześnie. Aktualizacja WooCommerce bez testów na kopii potrafi wyłączyć płatności w środku dnia, a motyw dociążający stronę psuje wyniki szybciej niż sama wtyczka. Dlatego przy wdrożeniu patrzy się na cały stos — PHP, bazę, motyw, wtyczki — a nie tylko na panel sklepu. Zakres samej wtyczki opisuje jej dokumentacja.

Czego wdrożenie nie obejmuje domyślnie: treści i opisów produktowych, zdjęć, księgowości i fakturowania, strategii marketingowej, decyzji o cenach, kosztach dostawy i polityce zwrotów. To zostaje po stronie firmy — i tu najczęściej leży przestój projektu.

WooCommerce wygrywa przy katalogu do ok. 5–20 tys. produktów, w firmach B2B (cenniki grupowe, zamówienia na zapytanie) oraz w sklepach usługowych. Gdy od pierwszego dnia potrzebny jest rozbudowany magazyn wielosklepowy z natywnymi funkcjami, PrestaShop bywa szybszym startem — kosztem mniejszej społeczności i węższego rynku wykonawców w Polsce. Jeśli budujesz katalog lub łączysz sklep z treściami, zobacz, jak podchodzimy do sklepów internetowych.

Realny czas pierwszego wdrożenia sklepu do 200 produktów, bez niestandardowych integracji: 40–80 godzin.

Ile trwa i ile kosztuje wdrożenie WooCommerce — realne widełki

Typowa stawka za pracę deweloperską przy WooCommerce w Polsce to 90–160 zł/h netto. Poniżej cztery scenariusze, które pokrywają większość zapytań, z przeliczeniem na kwoty końcowe.

Poza robocizną doliczyć trzeba: licencję motywu (często jednorazowo, kilkaset złotych), wtyczki premium (subskrypcja roczna za każdą), hosting lub VPS (od około 100 do 400 zł miesięcznie przy sklepie z realnym ruchem), certyfikat SSL (darmowy Let’s Encrypt wystarcza w większości sklepów; płatny wildcard to kilkaset złotych rocznie), dostęp do API kurierów (zwykle abonament albo opłata za paczkę — aktualny cennik sprawdzaj u przewoźnika), moduł fakturowania (subskrypcja miesięczna). Do sklepu startowego dolicz realnie 1 000–3 000 zł na licencje i pierwszy rok hostingu.

Godziny czy pakiet. Pakiet ma sens, gdy zakres jest zamrożony po analizie. Jeśli w umowie widzisz „sklep z integracjami, 15 000 zł”, a nie ma listy funkcji, pakiet działa na twoją niekorzyść: wykonawca ma interes w tym, żeby każdą zmianę w trakcie traktować jako aneks, a ty nie wiesz, ile godzin faktycznie poszło. Przy rozliczeniu godzinowym z limitem żądaj cotygodniowego raportu czasu. Punkt odniesienia do porównania ofert znajdziesz w materiale wycena wdrożenia WooCommerce.

Własny moduł kontra kolejna wtyczka premium. Wtyczka za 300–500 zł rocznie to 600–1 000 zł w 24 miesiącach, plus czas na aktualizacje i konflikty po każdej zmianie WooCommerce. Prosty moduł robiący jedną rzecz (niestandardowa reguła wysyłki, dodatkowe pole w koszyku) to 4–10 h, czyli 400–1 600 zł jednorazowo. Uczciwie: własny kod też trzeba utrzymywać. Opłaca się wtedy, gdy funkcja jest nietypowa, a żadna z testowanych wtyczek nie działa stabilnie.

Wdrożenie WooCommerce krok po kroku: 8 etapów od hostingu do startu

Kolejność, którą da się rozliczać tydzień po tygodniu. Czasy dotyczą sklepu do 200 produktów — więcej o organizacji wdrożenia WooCommerce piszemy osobno.

• Etap 1 — hosting/VPS (0,5–1 dzień). PHP 8.2+, MySQL 8 lub MariaDB 10.6+, min. 2 vCPU i 4 GB RAM przy sklepie, który ma rosnąć, dysk SSD, WP-CLI, kopie zapasowe poza serwerem. Tani hosting współdzielony to najczęstsza przyczyna wolnego WooCommerce.
• Etap 2 — staging (2–4 h). Subdomena staging., kopia bazy i plików, noindex, blokada hasłem, wyłączone wysyłki e-mail. Wszystkie zmiany robisz na kopii, nie na produkcji.
• Etap 3 — WordPress i WooCommerce (0,5–1 dzień). Waluta PLN, jednostki (szt., kg), strefy wysyłki, klasy podatkowe i stawki VAT, przypisanie stron sklepu do właściwych szablonów.
• Etap 4 — struktura katalogu (2–3 dni). Kategorie maksymalnie dwa poziomy, atrybuty globalne, warianty, widoczność w katalogu i wynikach wyszukiwania. Zmiana struktury po imporcie oznacza powtórzenie pracy.
• Etap 5 — płatności (0,5–1 dzień). Przelewy24, PayU lub Stripe. Najpierw klucze sandbox i test pełnej ścieżki, w tym zwrotu. Klucze produkcyjne wgrywasz dopiero po testach.
• Etap 6 — kurierzy (1–2 dni). InPost ShipX, DPD, DHL: sandbox, mapowanie usług na strefy wysyłki, generowanie etykiet z panelu, punkty odbioru.
• Etap 7 — treści i produkty (2–4 dni). Import przez CSV i WP All Import partiami po 500–1000 wierszy, szablony e-mail, regulamin, polityka zwrotów i informacja o prawie odstąpienia w 14 dni. Ten etap najczęściej stoi z powodu braku opisów i zdjęć.
• Etap 8 — testy i start (1–2 dni). Zamówienie testowe: płatność, etykieta, faktura, e-mail. Przekierowania 301 ze starych URL-i jako mapa 1:1, bez łańcuchów. Pomiar Core Web Vitals przed publikacją.

Jeśli któryś etap trwa dłużej niż tydzień bez wyraźnego powodu, harmonogram się rozjeżdża. Pytaj wtedy nie „kiedy skończycie”, ale „na co konkretnie czekacie”.

Optymalizacja WooCommerce: gdzie jest największy zysk w wydajności

Kolejność prac ma znaczenie. Jeśli zaczniesz od frontendu, a serwer zostawisz na koniec, część roboty wykonasz dwa razy. Największy zwrot z godziny daje warstwa serwera, potem baza danych, obrazy, frontend, a na końcu wtyczki.

Serwer. Włącz OPcache (opcache.enable=1, memory_consumption 128–256 MB, max_accelerated_files min. 10000). Przejście z PHP 7.4 na 8.2/8.3 skraca czas wykonywania skryptów o kilkadziesiąt procent — to najtańsza zmiana w całym projekcie. Dołóż HTTP/2 i kompresję Brotli (o kilkanaście procent mniej transferu niż Gzip). Cache stron (Varnish albo LiteSpeed) ustaw z twardymi wykluczeniami: koszyk, zamówienie, /?wc-ajax=, zalogowani użytkownicy. Dołóż cache obiektowy (Redis/Memcached) — bez niego WooCommerce odtwarza te same zapytania przy każdym żądaniu. Sprawdź autoload w wp_options: suma opcji z autoload='yes' powinna być liczona w setkach kB, nie megabajtach.

Baza. Włącz slow query log i szukaj zapytań powyżej 0,5 s. Typowe braki to indeksy na wp_postmeta (post_id, meta_key) i wp_wc_order_stats. Wyczyść wygasłe transienty i ukończone zadania Action Scheduler — potrafią urosnąć do setek tysięcy wierszy. HPOS włączasz w WooCommerce → Ustawienia → Zaawansowane → Funkcje, ale najpierw na kopii: część starszych wtyczek raportowych i księgowych czyta wprost z wp_posts i po migracji przestaje widzieć zamówienia. Kolejność testów opisuje dokumentacja WooCommerce.

Obrazy i frontend. WebP/AVIF, poprawne srcset, lazy loading poza pierwszym ekranem, slidery kategorii ograniczone do 1–2 slajdów. Policz wtyczki dokładające CSS/JS: buildery, suwaki, wtyczki social, chatboty i newslettery ładują skrypty na każdej podstronie. Jeden mechanizm krytycznego CSS, reszta z defer.

Zakres i kolejność tych prac rozbijamy szerzej w sekcji wdrożenia i optymalizacja WooCommerce.

Jak zmierzyć wydajność sklepu: narzędzia i progi liczbowe

Bez punktu odniesienia nie rozliczysz optymalizacji. Zasada jest jedna: zapisz wyniki przed pracami i po nich, z datą i wersją wtyczek.

Progi docelowe. TTFB poniżej 200 ms dla treści serwowanych z cache, LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Trzy ostatnie to Core Web Vitals — definicje i sposób liczenia znajdziesz w materiale Web Vitals.

Dwa źródła danych. Chrome UX Report i PageSpeed Insights pokazują, co realnie mierzą użytkownicy (dane polowe z 28 dni). Osobno traktuj tryb laboratoryjny — jest powtarzalny, ale nie oddaje telefonu z wolnym łączem. Raportuj oba, bo klient patrzy na lab, a sprzedaż na pole.

Query Monitor. Na karcie produktu sprawdź liczbę zapytań SQL, ich czas i wtyczkę, która je generuje. Karta produktu powinna zamykać się w kilkudziesięciu zapytaniach; jeśli widzisz 300+, źródłem prawie zawsze są wtyczki, nie sam WooCommerce.

Waterfall dwa razy. Pierwsza wizyta (zimny cache) i powrót użytkownika (cache) to dwie różne historie. Do raportu wchodzą obie — inaczej łatwo pokazać poprawę, której nie ma.

Koszyk i zamówienie osobno. Żadne cache nie może obejmować koszyka, sesji ani endpointów wc-ajax. Testuj dodanie do koszyka, zmianę ilości, kod rabatowy, kilka metod płatności i powrót z bramki płatniczej. Dla sklepów z nietypową logiką koszyka te testy trzeba powtarzać po każdej zmianie konfiguracji.

Integracje, które najczęściej wywalają harmonogram wdrożenia

Harmonogram rzadko wywracają błędy w kodzie sklepu. Wywracają go integracje.

Kurierzy. InPost ShipX, DPD i DHL różnią się nie tylko API. Sprawdź: generowanie etykiet pojedynczo i masowo, listę punktów odbioru, śledzenie przesyłki i mapowanie statusów na zamówienie („w realizacji” → „wysłane” z numerem), obsługę zwrotów. Najczęstszy błąd to brak mapowania statusów — magazyn pracuje, klient nie dostaje informacji.

Płatności — zawsze pierwsze. Kolejność: sandbox → testy scenariuszy błędów (odrzucona karta, przerwane 3DS, timeout, zwrot i korekta) → klucze produkcyjne. Sprawdź, czy webhooki dochodzą i co się dzieje, gdy nie dojdą. Płatności odroczone (PayPo, Klarna) mają osobną ścieżkę zwrotu — to nie to samo co zwrot z karty.

Fakturowanie. Fakturownia, wFirma czy Subiekt: ustal, gdzie stoi stawka VAT, jak numerujesz dokumenty i kiedy faktura się wystawia — przy statusie „zrealizowane” czy „wysłane”. Bez tej decyzji nie wdrożysz integracji, a przy szybkich zmianach statusów wystawisz dokument podwójnie.

ERP. Subiekt GT/Nexo, Comarch ERP, WF-Mag: synchronizacja stanów, cen i zamówień. Punkt zapalny to sprzedaż równoległa — sklep i kasa offline schodzą do zera w tej samej sekundzie. Ratunek: bufor stanu, rezerwacje, kolejka synchronizacji. BaseLinker upraszcza pracę przy kilku kanałach i kurierach, ale przy nietypowych cennikach B2B bywa wąskim gardłem.

Kolejność: płatności, wysyłka, fakturowanie, ERP. Powód jest prosty — bez płatności nie ma zamówienia, wysyłka potrzebuje danych z zamówienia, faktura zależy od statusów, a ERP dotyka wszystkich trzech. Wpływa to też bezpośrednio na koszt wdrożenia WooCommerce.

12 błędów przy wdrożeniach WooCommerce i jak je wykryć w 5 minut

Poniższe dwanaście punktów to najczęstsze pułapki, które znajdujemy w audytach sklepów już po wdrożeniu. Każdą da się wykryć w kilka minut, bez czytania kodu — wystarczy panel hostingu, WP-CLI i dwa zapytania do bazy.

Trzy komendy warto zapamiętać. Rozmiar autoloadu: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'; — wynik powyżej 1 MB oznacza, że coś ładuje się do pamięci przy każdym żądaniu, także tym, które nie jest zamówieniem. Liczba wtyczek: wp plugin list --status=active i porównanie z liczbą katalogów w /wp-content/plugins. Cron: wp config get DISABLE_WP_CRON oraz crontab -l na koncie serwera.

Koszyk testuj na pięciu adresach jednocześnie: Warszawa 00-001, wieś pod Zamościem, kod 00-000, odbiorca zagraniczny, adres bez kodu pocztowego. Jeśli w którymkolwiek przypadku pojawia się komunikat o braku dostępnych metod wysyłki, to błąd do naprawy przed startem, a nie po pierwszej reklamacji. Płatności sprawdzaj w piaskownicy bramki: karta odrzucona, karta z 3DS, przerwanie połączenia przed powrotem do sklepu. Zamówienie nie może zostać w statusie oczekiwania na płatność bez adnotacji. Kolejność tych prac opisujemy w sekcji organizacja wdrożenia WooCommerce, a zakres techniczny w dziale wdrożenia WooCommerce. Aktualizacje samego WooCommerce wykonuj najpierw na kopii — oficjalna dokumentacja WooCommerce opisuje proces, ale nie zastąpi testu odtworzenia backupu.

Hosting, VPS i administracja — co musi być pod spodem sklepu

Wydajność sklepu rzadko zależy od wtyczki cache. Zależy od tego, ile mocy CPU dostanie PHP, jak szybko odpowiada dysk i czy baza ma osobny bufor. Progi, które stosujemy przy planowaniu:

• do około 300 produktów i do 10 000 wizyt miesięcznie — hosting współdzielony wystarcza, jeśli ma dysk NVMe, PHP 8.2 lub nowsze i włączony OPcache;
• 300–3000 produktów, 10–60 tys. wizyt miesięcznie, regularne kampanie — VPS z 4 vCPU, 8 GB RAM i dyskiem NVMe;
• powyżej 3000 produktów albo ruch skokowy z reklam — serwer dedykowany lub VPS z bazą i Redisem na osobnej maszynie.

Przed podpisaniem umowy poproś operatora na piśmie o: limit CPU (nie fair use), gwarantowany RAM, IOPS, dostęp SSH, możliwość zmiany wersji PHP z panelu, wsparcie dla Redis lub Memcached oraz informację, czy stosuje dzienny limit zapytań SQL.

Administracja to osobna usługa, nie dodatek do hostingu: planowe aktualizacje systemu i PHP z możliwością wycofania, monitoring PHP-FPM, MySQL, zajętości dysku i ważności certyfikatu, fail2ban, rotacja logów, kopie zapasowe. Bezpieczeństwo zaczyna się od WAF, limitu prób logowania (np. 5 prób na 15 minut) i dwuskładnikowego uwierzytelniania na wszystkich kontach administratora. Zasada minimalnych uprawnień oznacza, że osoba redagująca treści nie potrzebuje roli administratora.

Kopie zapasowe: zasada 3-2-1, przy sklepie z codziennymi zamówieniami kopia bazy minimum raz na dobę i dodatkowo przed każdą aktualizacją. W umowie zapisz czas odtworzenia jako element SLA — kopia, której nikt nie testował, nie jest backupem. Zaplecze hostingowe wybieramy razem z tym, co opisujemy w dziale sklepy internetowe, bo zmiana serwera po starcie jest zawsze droższa niż wybór właściwego na początku.

Czego nie robić: instalować sklepu na najtańszym pakiecie z limitem procesów i liczyć, że wtyczka cache naprawi wydajność. Cache pomaga, ale nie skróci czasu odpowiedzi bazy ani nie doda rdzeni.

Start sklepu i opieka po wdrożeniu: co powinno być w umowie

Go-live to nie moment kliknięcia publikuj. Checklista, którą warto przejść punkt po punkcie:

• przekierowania 301 zmapowane ze starej mapy URL na nową — bez łańcuchów i pętli;
• usunięty znacznik noindex z całego sklepu, mapa strony zgłoszona, robots.txt bez blokady katalogów sklepu;
• dane firmowe, regulamin, polityka prywatności i zwrotów — aktualne i widoczne w stopce;
• test płatności na produkcji realną kwotą, z pełnym zwrotem po testach;
• test wysyłki dla pięciu różnych adresów, w tym jednego poza Polską;
• e-maile transakcyjne z poprawnymi rekordami SPF, DKIM i DMARC.

Pierwsze 30 dni ma własny plan. Dni 1–7: podgląd logów błędów PHP i kodów 500, reakcja na każdy nowy wpis. Dni 7–14: sprawdzenie indeksacji i danych w analityce — czy zdarzenia e-commerce zapisują się razem z zamówieniem. Dni 14–30: analiza porzuceń koszyka i korekty wynikające z danych, nie z przeczuć.

W umowie rozdziel zadania. Wykonawca: aktualizacje, kopie z testem odtworzenia, monitoring, poprawki błędów w ramach pakietu godzin. Klient: treści, zdjęcia, decyzje cenowe, zgłaszanie przez jeden ustalony kanał. Praca bezpośrednio z deweloperem, bez pośredników, daje jedną osobę kontaktową, jedno miejsce na zgłoszenia i historię zmian w repozytorium Git — to skraca diagnozę z godzin do minut. Osobno opisujemy koszt wdrożenia i optymalizacji WooCommerce, a przykładowy przebieg współpracy pokazujemy przy wdrożenia i optymalizacja WooCommerce — Szczebrzeszyn.

Przegląd wydajnościowy planuj po każdej dużej kampanii, po dodaniu 20% nowych produktów i po każdej aktualizacji WooCommerce. Metryki, które warto obserwować, opisuje dokumentacja web.dev — Web Vitals; w sklepie liczy się nie tylko LCP, ale też stabilność układu na kartach produktu.

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

Lista kontrolna do odklikania

• Właściciel projektu i osoba decyzyjna — Sprawdź przed startem prac: imię, nazwisko, kanał kontaktu i zakres decyzji, które może podjąć samodzielnie.
• Pisemny zakres z podziałem na etapy — Zweryfikuj, czy każdy etap ma efekt do obejrzenia i kryterium akceptacji, a nie tylko ogólny opis typu „konfiguracja sklepu”.
• Środowisko staging i zasady wdrożeń — Sprawdź adres stagingu i sposób przenoszenia zmian na produkcję — najlepiej w oknie o niskim ruchu, z kopią zapasową przed każdym wdrożeniem.
• Specyfikacja hostingu pod WooCommerce — Zweryfikuj wersję PHP (8.2 lub nowsza), MySQL 8 / MariaDB 10.6+, minimum 2 vCPU i 4 GB RAM przy rosnącym sklepie oraz czy są backupy dzienne.
• Struktura katalogu: kategorie, atrybuty, warianty — Sprawdź to przed importem produktów. Zmiana struktury po imporcie oznacza powtórzenie pracy na wszystkich kartach.
• Strefy wysyłki, stawki VAT i jednostki — Sprawdź na kilku reprezentatywnych produktach, czy cena końcowa i koszt dostawy liczą się poprawnie dla zamówienia krajowego i zagranicznego.
• Płatności na kluczach produkcyjnych — Sprawdź, czy po testach sandbox klucze zostały podmienione i czy w sklepie działa co najmniej jedna pełna transakcja testowa.
• Integracja z kurierami — Sprawdź, czy etykieta generuje się dla realnej paczki, czy waga i wymiary pobierają się z produktu i czy numer przesyłki wraca do zamówienia.
• E-maile transakcyjne — Zamów u siebie na skrzynce potwierdzenie zamówienia, zmianę statusu i wysyłkę. Sprawdź, czy nadawca i treść są poprawnie skonfigurowane, a wiadomości nie trafiają do spamu.
• Regulamin, polityka zwrotów, informacje o dostawie — Sprawdź, czy strony są opublikowane i podlinkowane w stopce oraz w koszyku, jeszcze przed startem sprzedaży.
• Przekierowania 301 ze starych adresów — Przy migracji zażądaj pliku z mapowaniem adresów i przetestuj kilkanaście najważniejszych URL-i ręcznie.
• Testy zamówień end-to-end — Wykonaj pełną ścieżkę: dodanie do koszyka, płatność, etykieta, faktura, e-mail. Wynik zapisz jako protokół odbioru z datą.
• Dostęp do analityki i Search Console — Sprawdź, czy po starcie masz dostęp do statystyk i czy dane o zamówieniach trafiają tam, gdzie mają — to warunek rozliczania skuteczności sklepu.
• Plan na pierwsze 30 dni po starcie — Ustal, kto reaguje na zgłoszenia po odbiorze i w jakim czasie. Bez tego drobne poprawki ciągną się tygodniami.

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