Czym jest wdrożenie WooCommerce i co dokładnie obejmuje

Wdrożenie WooCommerce to projekt rozliczany w godzinach, podzielony na siedem etapów. Każdy z nich kończy się konkretnym artefaktem: dokumentem, działającym środowiskiem albo przetestowanym zamówieniem.

1. Analiza i decyzje — warsztat 2–4 h. Efekt: notatka z sześcioma rozstrzygnięciami: platforma (WooCommerce czy SaaS), hosting, motyw, bramki płatności, kurierzy, system księgowy. Bez tego etapy 4–5 rozjeżdżają się na poprawkach.
2. Środowisko i hosting — staging na subdomenie, osobna baza danych, SSL, harmonogram kopii zapasowych, wyłączone indeksowanie stagingu (nagłówek X-Robots-Tag lub blokada w robots.txt).
3. Instalacja i konfiguracja — WordPress, WooCommerce, strefa czasowa, waluta, stawki VAT, strefy wysyłki, e-maile transakcyjne z poprawnymi rekordami SPF, DKIM i DMARC, żeby potwierdzenia zamówień nie wpadały do spamu.
4. Katalog i treści — import CSV, kategorie, atrybuty i warianty, zdjęcia, opisy, metadane SEO dla kategorii.
5. Integracje — Przelewy24, PayU lub Stripe, InPost ShipX, DPD, DHL, program do faktur, ERP.
6. Testy zamówienia i zwrotu — pełna ścieżka: koszyk, płatność, mail, zmiana statusu, faktura, zwrot, korekta, powrót towaru na stan magazynowy.
7. Przekazanie z dokumentacją — dostępy, instrukcja obsługi, szkolenie 1–2 h.

Realny czas: 2–4 tygodnie dla sklepu do 300 produktów i 6–10 tygodni dla katalogu 1000+ SKU z integracjami. Różnicę robi nie liczba produktów, a liczba systemów, z którymi sklep musi się synchronizować.

Od zamawiającego potrzebne są: zdjęcia min. 1500×1500 px, opisy, kategorie, atrybuty oraz dostępy do domeny (DNS) i do paneli płatności oraz kurierów. Materiały dostarczone po terminie przesuwają odbiór o tyle samo dni — to najczęstsza przyczyna opóźnień w tego typu projektach, podobnie jak przy wdrożeniach i optymalizacji WooCommerce w Biłgoraju. Zakres funkcji rdzenia znajdziesz w dokumentacji WooCommerce.

Ile trwa i ile kosztuje wdrożenie oraz optymalizacja WooCommerce

Wycena to godziny razy stawka. Jeśli oferta podaje wyłącznie kwotę końcową, poproś o rozbicie na etapy — inaczej nie masz jak porównać dwóch propozycji.

Praktyczne widełki wyglądają tak: prosty sklep 40–70 h, średni 80–140 h, rozbudowany z ERP i B2B 160–260 h. Optymalizacja istniejącego sklepu to osobna kategoria: najpierw audyt (6–10 h), który daje listę wąskich gardeł, potem wdrożenie poprawek (20–60 h). Bez audytu poprawki robi się na wyczucie i często przepisuje się je dwa razy.

Co podnosi koszt: migracja danych ze starego sklepu (dla 1000 SKU licz 8–16 h na samo przygotowanie plików i import), własne moduły, np. niestandardowy kalkulator dostawy, wielojęzyczność — każda wersja językowa to osobne treści i metadane, cenniki grupowe B2B z przypisaniem klientów do grup, integracja magazynu lub ERP (Subiekt, Comarch, wFirma) w zależności od dostępności API.

Jak czytać ofertę? Sprawdź cztery rzeczy: stawkę godzinową, szacunek godzin dla każdego etapu, listę „poza zakresem” i to, kto płaci za poprawki po odbiorze. Standardem jest 30 dni na usuwanie błędów wykonawcy; nowe funkcje to nowe zlecenie i nowe godziny. Zapisz w umowie, ile godzin wsparcia dostajesz po odbiorze. Identyczny sposób rozliczania stosujemy przy wdrożeniach i optymalizacji WooCommerce w Lublinie oraz w projektach takich jak optymalizacja WooCommerce w Józefowie.

Wymagania techniczne: hosting, PHP i baza pod WooCommerce

Poniżej tych progów optymalizacja frontendu nie przyniesie efektu — wąskim gardłem będzie serwer, a nie motyw czy wtyczki.

Zacznij od PHP 8.2 lub 8.3. PHP 7.4 nie ma wsparcia bezpieczeństwa od listopada 2022 — trzymanie sklepu na tej wersji to nie tylko wolniejsze działanie, ale i realne ryzyko. Baza: MySQL 8.0 lub MariaDB 10.6+, tabele InnoDB, kodowanie utf8mb4 (nie „utf8”, który jest aliasem utf8mb3 i nie obsługuje emoji ani części znaków).

memory_limit 256 MB to minimum, 512 MB przy importach i masowych aktualizacjach cen. max_execution_time 300 s dla importu CSV i generowania faktur zbiorczych; przy 30 s import 5000 SKU po prostu się przerwie. Zwiększ też upload_max_filesize i post_max_size do 64 MB oraz max_input_vars do 5000 — bez tego duże menu i importy atrybutów potrafią ucinać dane bez komunikatu błędu.

OPcache włączony, do tego object cache: Redis albo Memcached. Przy katalogu z filtrami to najczęściej największy pojedynczy zysk. Dalej: HTTP/2 lub HTTP/3, kompresja Brotli z fallbackiem gzip, SSL z nagłówkiem HSTS.

Kopie zapasowe poza serwerem. Jeśli backup leży na tym samym koncie hostingowym, zniknie razem z hostingiem. Trzymaj kopie w S3 lub Backblaze, codziennie, z retencją minimum 30 dni. Efekt tych ustawień widać w metrykach: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — progi opisane w Web Vitals. Te same wymagania stawiamy projektom w mniejszych miejscowościach, np. przy wdrożeniach WooCommerce w Zwierzyńcu.

Optymalizacja wydajności WooCommerce — liczby, do których warto dążyć

Progi z tabeli poniżej to nie cel marketingowy, a punkt rozliczenia prac. Przyjmuje się je dla 75. percentyla wejść mobilnych, czyli dla danych polowych, a nie jednego przebiegu Lighthouse na szybkim laptopie. Zanim ktokolwiek dotknie motywu, ustal wspólną metodę pomiaru — inaczej po miesiącu nie da się porównać stanu „przed” i „po”.

Иnarzędzia, które realnie się do tego używa:

• PageSpeed Insights — pokazuje dane polowe z CrUX i test laboratoryjny. Interesuje Cię zakładka mobilna i rozkład 75. percentyla, nie zielone kółko.
• Query Monitor — działa tylko dla zalogowanego administratora, pokazuje liczbę zapytań SQL, zapytania wolne i duplikaty na konkretnym adresie. Limit ≤ 60 zapytań na stronie kategorii jest osiągalny przy włączonym cache obiektowym i bez page buildera.
• Blackfire lub New Relic — wchodzą do gry, gdy Query Monitor pokazuje setki zapytań, ale nie widać, która wtyczka je generuje. Profilowanie wskazuje stos wywołań.

Po stronie frontu największy zwrot dają trzy rzeczy. Obrazy w WebP/AVIF generowane przy uploadzie — 3000-pikselowy JPG z hurtowej paczki potrafi zjeść cały budżet LCP. Lazy loading dla wszystkiego poniżej pierwszego ekranu, przy czym obraz LCP ma zostać ładowany normalnie, z atrybutem fetchpriority='high'. Preload fontu i usunięcie nieużywanego CSS — ile go jest, sprawdzisz w DevTools w zakładce Coverage (Ctrl+Shift+P → „Coverage”).

Cache stron włączaj wyłącznie dla niezalogowanych i z wykluczeniami: /koszyk, /zamowienie, /moje-konto oraz endpointy ?wc-ajax= i akcje add-to-cart. Bez tych wykluczeń klient zobaczy koszyk innej osoby albo pusty koszyk po dodaniu produktu — to najczęstszy błąd przy agresywnym cache na WooCommerce. Definicje i progi metryk znajdziesz w dokumentacji Web Vitals.

Ten sam zestaw progów stosujemy w projektach regionalnych — zobacz, jak wygląda organizacja wdrożeń i optymalizacji WooCommerce w Lublinie.

Baza danych i cron — gdzie WooCommerce najczęściej się dławi

Najczęstszy powód, dla którego sklep na WooCommerce po roku „sam z siebie” zwalnia, to nie motyw, a baza i harmonogram zadań.

1. wp_options z autoload = 'yes'. Te opcje wczytują się przy każdym żądaniu, także przy zwykłym odsłonie strony. Rozmiar sprawdzisz tak: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes'; Realny próg to 1–2 MB. Powyżej rośnie czas każdej strony, nie tylko panelu administracyjnego. Winowajcę znajdziesz, sortując tę tabelę po LENGTH(option_value) DESC — zwykle to wtyczka zapisująca całą konfigurację jako jedną wielką tablicę.

2. Osierocone wp_postmeta i stare transienty. Po odinstalowanych wtyczkach zostają wiersze bez odpowiednika w wp_posts. Policz je przed czyszczeniem: SELECT COUNT(*) FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL; Transientów szukaj przez SELECT COUNT(*) FROM wp_options WHERE option_name LIKE '%transient%', a przeterminowane usuń przez wp transient delete --expired. Kolejność: zrzut tabeli → test na stagingu → czyszczenie na produkcji.

3. HPOS (High-Performance Order Storage). Kolejność włączenia ma znaczenie: backup bazy → włączenie HPOS w WooCommerce → Ustawienia → Zaawansowane → Funkcje → przez 2–4 tygodnie pozostawiona synchronizacja ze starymi tabelami posts → weryfikacja liczby zamówień, raportów i integracji (płatności, kurierzy, ERP) → dopiero potem wyłączenie synchronizacji. Tabel posts nie usuwaj przez co najmniej 30 dni, bo to jedyna szybka droga wycofania. Procedurę opisuje dokumentacja WooCommerce.

4. wp_wc_order_stats i raporty. Panel zamówień bywa wolniejszy niż sklep, bo raporty liczą agregaty z tabel analitycznych. Gdy liczby nie zgadzają się ze stanem faktycznym, regeneracja tabel w WooCommerce → Stan → Narzędzia (nazwa narzędzia różni się między wersjami).

5. WP-Cron. Domyślny cron odpala się przy wizycie użytkownika — na małym ruchu kolejka Action Scheduler rośnie i zadania zalegają. Wpisz define('DISABLE_WP_CRON', true); do wp-config.php i dodaj w crontab zadanie co 5 minut wywołujące wp-cron.php?doing_wp_cron, podstawiając własny adres domeny.

Jeśli nie chcesz dotykać produkcyjnej bazy bez zabezpieczenia, kolejność prac dla mniejszych katalogów opisaliśmy w wdrożeniach i optymalizacji WooCommerce w Biłgoraju.

7 pułapek przy wdrożeniu WooCommerce i jak je wykryć

Poniższe siedem rzeczy sprawdzisz sam, w mniej niż godzinę i bez dostępu do serwera. To dobry sposób, żeby zweryfikować gotowy sklep albo ocenić ofertę wykonawcy przed podpisaniem umowy.

1. Motyw z page builderem. DevTools → Ctrl+Shift+P → „Coverage”, odśwież stronę. Zobaczysz, ile KB CSS i JS faktycznie się wykonuje i ile z tego jest nieużywane. Jeśli 300–600 KB leci przed pierwszym renderem, budżet LCP jest już przepalony.
2. Brak child theme. Wejdź do wp-content/themes i sprawdź, czy istnieje katalog motywu potomnego z plikiem style.css. Bez niego pierwsza aktualizacja nadpisuje wszystkie zmiany w plikach motywu.
3. Import bez unikalnych SKU i slugów. Sprawdź liczby: SELECT COUNT(*), COUNT(DISTINCT meta_value) FROM wp_postmeta WHERE meta_key = '_sku'; oraz duplikaty adresów: SELECT post_name, COUNT(*) FROM wp_posts WHERE post_type = 'product' GROUP BY post_name HAVING COUNT(*) > 1; Powtórzone slugi to gotowe konflikty adresów i canonicali.
4. Brak stagingu. Zapytaj wprost o adres środowiska testowego i kto je aktualizuje. Odpowiedź „testujemy na produkcji wieczorem” oznacza, że stagingu nie ma.
5. Test zamówienia bez realnej płatności. Złóż jedno zamówienie na kwotę 1 zł prawdziwą bramką, wykonaj zwrot i sprawdź, czy doszły wszystkie e-maile transakcyjne oraz korekta. Sandbox nie sprawdza ani maili, ani zwrotów.
6. Brak monitoringu 404/500 i logów PHP. Ustal, gdzie trafiają błędy i kto je czyta. Minimum to log PHP z ostatnich 7 dni i alert przy wzroście liczby błędów 500.
7. Wtyczka „do wszystkiego”. Kilka linijek własnego kodu kontra 40 opcji we wtyczce aktualizowanej raz na pół roku. Policz koszt utrzymania, zanim wybierzesz drugie rozwiązanie.

Ten sam zestaw testów stosujemy przy audytach w mniejszych miejscowościach — zobacz, jak wygląda organizacja wdrożeń i optymalizacji WooCommerce w Józefowie.

Integracje: płatności, kurierzy InPost, DPD, DHL i ERP

W polskim sklepie integracje to zwykle 30–40% budżetu projektu. Kolejność jest stała: płatności, kurierzy, na końcu ERP i księgowość — bez działającej bramki nie przetestujesz zamówienia od koszyka do faktury.

Płatności: Przelewy24, PayU, tpay, Stripe. Instalacja wtyczki to 1–2 h, drugie tyle zajmuje test. Sprawdzamy: pełny zakup w środowisku testowym z przejściem 3-D Secure (karta testowa operatora, przekierowanie do banku i powrót), czy webhook dociera do sklepu i zmienia status, czy jego ponowne wysłanie nie tworzy duplikatu zamówienia oraz jak mapują się statusy: pending na „oczekuje na płatność”, processing na „w realizacji”, refunded na „zwrócone”. Najczęstsza pułapka: sklep ustawia „w realizacji” już po autoryzacji, a pieniądze nie wpłynęły — takie zamówienia wiszą w księgowości tygodniami.

Kurierzy: InPost ShipX, DPD WebAPI, DHL24. Warunek odbioru prac: etykieta PDF jednym kliknięciem z listy zamówień, wybór punktu odbioru w koszyku (mapa i lista, także na telefonie), numer trackingu w mailu „Wysłane” i status przesyłki odświeżany co 30–60 minut. Testujemy minimum trzy przesyłki: standardową, za pobraniem i zagraniczną.

ERP i księgowość: Subiekt GT/nexo, Comarch Optima, wFirma, Fakturownia. Kierunek synchronizacji ustalamy przed startem: stany i ceny płyną z ERP do sklepu, zamówienia i faktury ze sklepu do ERP. Stany odświeżamy co 15 minut, faktury wystawiamy po zmianie statusu na „zrealizowane”. Konfigurację wtyczek opisuje dokumentacja WooCommerce.

Magazyn: jedno źródło prawdy. Wskaż jedną bazę — ERP albo WooCommerce — i zapisz to w umowie. Jeśli sklep sprzedaje równolegle na Allegro lub w punkcie stacjonarnym, ustaw bufor 1–2 szt. i kolejkę aktualizacji stanów. Sprzedaż dwóch ostatnich sztuk w odstępie 10 minut to najczęstszy błąd wdrożeń wielokanałowych.

Plan awaryjny. API padają — pytanie tylko kiedy. Wymagaj: zadań w tle przez Action Scheduler zamiast WP-Cron, kolejki z ponowieniami (3 próby), logów integracji w WooCommerce → Status → Logi, alertu po 5 błędach pod rząd oraz gotowego komunikatu dla klienta. Zakres podobnych prac opisaliśmy przy wdrożeniach WooCommerce w Lublinie.

SEO techniczne i widoczność lokalna sklepu z Bełżca i okolic

Techniczne SEO sklepu to nie dodanie meta tagów. Zacznij od danych strukturalnych: Product, Offer i AggregateRating to warunek wejścia do wyników produktowych z ceną, dostępnością i ocenami. Wymóg jest twardy — cena i dostępność w kodzie muszą zgadzać się z tym, co widzi klient. Jeśli nie zbierasz prawdziwych opinii, nie wpisuj AggregateRating na sztywno; niezgodność to podstawa do działań ręcznych. Listę typów obsługiwanych przez Google znajdziesz w dokumentacji Google Search Central.

Filtry i parametry facetowe. Kombinacje typu /kategoria/?filter_kolor=czerwony&filter_rozmiar=l&pa_producent=x tworzą tysiące adresów i zjadają budżet indeksowania. Reguła: pojedynczy filtr może być indeksowalny, jeśli ma ruch i unikalny opis; kombinacje dwóch i więcej parametrów dostają noindex, follow. Canonical musi prowadzić na czystą kategorię bez parametrów. Sprawdź, czy wtyczka filtrów nie nadpisuje canonicala na self-referencing.

Paginacja. /kategoria/page/2/ zostaje indeksowalna, z self-canonicalem i unikalnym tytułem („... — strona 2”). Największy błąd to canonical strony drugiej wskazujący na pierwszą — Google nie wchodzi wtedy głębiej i część produktów nie zostaje odkryta.

Mapa strony i Search Console. W pliku XML muszą znaleźć się produkty i kategorie (Yoast lub Rank Math generują osobne pliki product-sitemap.xml i product_cat-sitemap.xml). Dodaj domenę do Search Console, zgłoś mapę, a po 7 i 30 dniach sprawdź raport „Strony” oraz błędy danych strukturalnych.

Widoczność lokalna. Wizytówka Google Business Profile to najtańszy kanał dla sklepu z Bełżca i okolic. Uzupełnij kategorie, godziny, zdjęcia i produkty, a NAP (nazwa, adres, telefon) utrzymuj identyczny na stronie kontaktu, w stopce, w wizytówce i katalogach. Frazy pisz naturalnie: Bełżec, Tomaszów Lubelski, Zamość, dostawa na Lubelszczyźnie — bez upychania ich w każdym akapicie.

Linkowanie wewnętrzne. Materiały dla sąsiednich rynków — WooCommerce dla firm z Biłgoraja, wdrożenia WooCommerce w Frampolu, organizacja wdrożenia w Józefowie, WooCommerce w Zwierzyńcu i optymalizacja sklepu w Krasnobrodzie — linkuj z jednego bloku, anchorami opisującymi miasto, nie ze stopki.

Opieka po wdrożeniu: co powinno znaleźć się w SLA

SLA to dokument, który mówi, co dostajesz co miesiąc i w jakim czasie dostaniesz reakcję, gdy coś padnie. Bez niego opieka zamienia się w telefon do znajomego programisty.

Czasy reakcji. Trzy poziomy: incydent krytyczny 2–4 h, wysoki 8 h, standardowy 1 dzień roboczy. W umowie musi być definicja „krytycznego”: sklep nie przyjmuje zamówień, brama płatnicza odrzuca transakcje, strona zwraca 500 na całym katalogu. Reakcja oznacza potwierdzenie zgłoszenia i rozpoczęcie pracy — nie rozwiązanie problemu. Dopisz okno serwisowe (np. 8:00–17:00 w dni robocze) i stawkę za pracę poza nim, inaczej „2 h” stanie się obietnicą dostępności 24/7 za darmo.

Zakres rutynowy. W SLA wpisz: aktualizacje core i wtyczek wykonywane najpierw na kopii staging (z testem koszyka i płatności), kopie zapasowe dzienne z retencją 30 dni plus dodatkową kopię przed każdą aktualizacją, monitoring uptime co 1 minutę z co najmniej dwóch lokalizacji, przegląd podatności oraz porządki w bazie (rewizje, transjenty, porzucone koszyki).

Czego SLA nie obejmuje. Rozbudowy funkcji i nowych integracji. To osobne zlecenia wyceniane w godzinach — poproś o stawkę już w umowie, żeby nie negocjować jej przy pierwszej potrzebie. Ustal też sposób rozliczania drobnych prac: bloki 15-minutowe albo miesięczny budżet godzinowy, po przekroczeniu którego prace wymagają Twojego zatwierdzenia.

Raport miesięczny. Powinien zawierać: dostępność w procentach, czas ładowania (medianę i 95. percentyl), liczbę błędów PHP, liczbę zamówień, liczbę zdarzeń w integracjach (webhooki, etykiety, synchronizacje z ERP) i listę wykonanych aktualizacji. Bez tych liczb nie da się zaplanować rozwoju sklepu.

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

Lista kontrolna do odklikania

• Zakres i etapy na piśmie — Przed startem sprawdź, czy umowa wymienia siedem etapów wdrożenia i kto odpowiada za każdy z nich. Bez tego nie ustalisz, kto płaci za poprawki po odbiorze.
• Sześć decyzji podjętych przed pierwszym commitem — Platforma, hosting, motyw, płatności, kurierzy, system księgowy. Każda zmiana w trakcie projektu oznacza przeróbki i dodatkowe godziny.
• Środowisko testowe (staging) oddzielone od produkcji — Wymagaj osobnej kopii sklepu do testów. Wdrażanie wtyczek i migracji bezpośrednio na produkcji to najkrótsza droga do zniknięcia zamówień.
• PHP 8.2 lub 8.3 — Sprawdź w panelu hostingu lub przez phpinfo. PHP 7.4 nie ma wsparcia bezpieczeństwa od listopada 2022 roku.
• Baza danych: MySQL 8.0 lub MariaDB 10.6+, InnoDB, utf8mb4 — Zweryfikuj silnik tabel i kodowanie. Domyślne ustawienia części hostingów nadal odbiegają od tego progu.
• Pamięć PHP 256–512 MB i max_execution_time 300 s — Niższe wartości wyłożą import katalogu i aktualizacje. Sprawdź w panelu hostingu przed rozpoczęciem importu.
• OPcache oraz object cache (Redis lub Memcached) — Zapytaj hosting, czy oba mechanizmy są dostępne i czy są włączone dla Twojego konta. Bez object cache WooCommerce nie wykorzysta pełni możliwości serwera.
• HTTP/2 lub HTTP/3 oraz kompresja Brotli/gzip — Sprawdź nagłówki odpowiedzi w narzędziach deweloperskich. To ustawienie hostingu, nie wtyczki.
• SSL z HSTS — Certyfikat musi obejmować wszystkie subdomeny i przekierowywać HTTP na HTTPS. HSTS ustawia się dopiero, gdy przekierowania działają poprawnie na całej witrynie.
• Backup poza serwerem z testem odtworzenia — Poproś o datę ostatniego testu odtworzenia. Kopia, która nie została odtworzona, nie jest kopią.
• Liczba aktywnych wtyczek — maksymalnie 20 — Sprawdź listę wtyczek po wdrożeniu i po każdej aktualizacji. Każda kolejna wtyczka to dodatkowe zapytania do bazy i potencjalny konflikt.
• Rozmiar tabeli wp_options z autoload=yes poniżej 1–2 MB — Sprawdź przez Query Monitor lub zapytanie do bazy. Powyżej tego progu rośnie czas generowania każdej podstrony, nie tylko panelu.
• Core Web Vitals na mobile: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, TTFB ≤ 600 ms — Weryfikuj w PageSpeed Insights i w web.dev. Patrz na 75. percentyl, nie na pojedynczy pomiar z szybkiego komputera. Progi opisuje dokumentacja Google Search Central.
• Liczba zapytań do bazy na stronie kategorii — maksymalnie 60 — Sprawdź przez Query Monitor przy wyłączonym cache dla zalogowanych. To najczęstsze miejsce, w którym WooCommerce zaczyna się dławić.

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