Wdrożenie WooCommerce w Narolu i okolicach — co realnie wpływa na przebieg projektu

Narol leży w powiecie lubaczowskim, kilkadziesiąt kilometrów od przejścia granicznego w Hrebennem. To nie ozdobnik — przygraniczne położenie realnie zmienia zakres projektu, bo dochodzą wersje językowe, wagi produktów i wysyłka za granicę. Zanim ktoś poda ci cenę, powinien zapytać o trzy rzeczy: liczbę produktów, liczbę stref dostawy i liczbę metod płatności.

Trzy sylwetki klientów, które widzimy najczęściej w tym rejonie:

• Sklep lokalny — 50–300 produktów, odbiór osobisty, jedna lub dwie strefy kurierskie, płatność za pobraniem i zwykły przelew. Taki projekt zamyka się w 40–50 godzinach.
• B2B z katalogiem na zapytanie — ceny widoczne tylko dla zalogowanych, rola klienta hurtowego, ceny netto, minimalna wartość zamówienia, faktura z odroczonym terminem. Tu schodzi 60–80 godzin.
• Firma sprzedająca transgranicznie — wysyłka na Słowację, Węgry albo do Niemiec, wersje językowe, wagi do kalkulacji kosztu, stawki VAT UE. 80–120 godzin.

Każda strefa dostawy to osobny zestaw reguł: zakres kodów pocztowych, próg darmowej dostawy, cennik wg wagi. Do tego dochodzi integracja z kurierem — InPost Paczkomaty, DPD, DHL. Sprawny, oficjalny moduł to 3–5 godzin na kuriera. Porzucony moduł albo brak API to 8–12 godzin, bo trzeba pisać własne łączenie i mapować statusy przesyłek. Trzy strefy i trzech kurierów potrafią więc zjeść 20 godzin, zanim dotkniesz produktów.

Sklep z 50 produktami prostymi robi się ręcznie w kilka godzin. 5000 SKU to zupełnie inna praca: zwykle 200 produktów nadrzędnych i po 20–25 wariantów, generowanych z atrybutów. Import z pliku CSV z wariantami wymaga poprawnych kolumn nadrzędnych, inaczej dostajesz 5000 osobnych produktów do ręcznego scalania. Podobny zakres w innych gminach regionu opisujemy przy okazji wdrożenia WooCommerce w Bełżecu oraz wdrożenia WooCommerce w Józefowie — warto porównać, bo różnice wynikają głównie z liczby stref i wariantów, a nie z samej miejscowości.

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

Zamiast ceny „od” podajemy godziny. To jedyny sposób, żebyś mógł porównać dwie oferty bez zgadywania, co siedzi w środku. Trzy realne przedziały: prosty sklep MŚP 40–60 h, sklep z integracjami i logiką B2B 60–80 h, sklep z wariantami i wielojęzycznością 80–120 h.

Na co schodzą te godziny w typowym projekcie 40–60 h:

• konfiguracja WordPressa i WooCommerce (sklep, waluty, podatki, maile transakcyjne) — 6–8 h,
• szablon kupiony i dopasowany — 6–10 h; szablon pisany od zera to 25–40 h,
• produkty: 50 pozycji ręcznie to 3–5 h, import z CSV to 4–8 h plus 3–10 h na przygotowanie samego pliku,
• płatności: każda bramka (Przelewy24, PayU, Stripe) to 3–5 h z testami,
• kurier: pierwszy 4–6 h, każdy kolejny 2–3 h,
• testy zamówień, szkolenie z obsługi i krótka dokumentacja — 7–12 h.

Co podnosi wycenę najbardziej: moduł pisany na zamówienie (15–60 h), migracja z działającego sklepu na innej platformie (10–30 h, zależnie od jakości danych), integracja z ERP typu Subiekt czy Comarch Optima (20–60 h) oraz import z CSV o złej strukturze — brak kolumn dla wariantów, ceny z przecinkiem, duplikaty SKU. To ostatnie potrafi dodać 10–20 godzin czyszczenia, których nikt nie policzył na starcie. Podobne różnice widać przy projektach we Frampolu i w Biłgoraju, gdzie kluczowa okazała się nie liczba produktów, a liczba integracji.

Rozliczenie godzinowe jest dla klienta bezpieczniejsze niż sztywna cena „pod klucz”. Przy stałej cenie wykonawca, który się pomylił, ma dwie drogi: ucina zakres albo dopisuje „prace dodatkowe” po fakcie. Przy rozliczeniu godzinowym widzisz kartę pracy i wiesz, za co płacisz — a jeśli budżet się kończy, po prostu zatrzymujesz projekt na ustalonym etapie i wracasz do niego później.

Plan wdrożenia WooCommerce krok po kroku — od hostingu do pierwszego zamówienia

Kolejność prac w naszych projektach jest stała: środowisko staging → WordPress → WooCommerce → szablon → produkty → płatności → kurierzy → testy → publikacja. Jeśli wykonawca zaczyna od produktów i szablonu, a hosting „ogarnie się później”, to znak, że testy wypadną na środowisku produkcyjnym. Tak nie powinno być.

Parametry startowe hostingu, które sprawdzamy przed pierwszym commitem:

• PHP 8.2 lub nowsze (PHP 7.4 to dziś problem z bezpieczeństwem i wydajnością),
• MySQL 8.0 albo MariaDB 10.6+,
• OPcache włączony, memory_limit minimum 256 MB, przy importach 512 MB,
• co najmniej 2 GB RAM przy katalogu 1000+ SKU,
• WP-Cron wyłączony na rzecz crona systemowego — inaczej planowane zadania odpalają się przy każdym wejściu na stronę,
• kopie zapasowe bazy codziennie, z możliwością przywrócenia jednym kliknięciem.

Staging musi mieć kopię bazy produkcyjnej, żeby dane były realistyczne: te same kategorie, te same kody pocztowe w strefach, te same wagi. Ale z wyłączonymi trzema rzeczami. Po pierwsze wysyłka do kurierów — klucze API w trybie sandbox albo moduł wyłączony, żeby test nie wygenerował prawdziwej etykiety i nie naliczył kosztu. Po drugie płatności — wyłącznie tryb testowy bramki. Po trzecie maile — wtyczka przekierowująca całą korespondencję na jeden adres testowy, żeby klient nie dostał potwierdzenia zamówienia o wartości 12 000 zł. Dodatkowo staging blokujemy w robots.txt i ustawiamy noindex, aby nie konkurował z docelową stroną.

Kryteria akceptacji przed publikacją są krótkie i mierzalne: pusty debug.log, poprawne maile transakcyjne (nowe zamówienie, zmiana statusu, anulowanie), działający druk etykiety kurierskiej, poprawnie liczony koszt dostawy w każdej strefie oraz złożone zamówienie testowe jako gość i jako zalogowany klient. Dopiero po tym klikamy publikację. Ten sam schemat stosujemy przy wdrożeniach WooCommerce w Lublinie i w Zwierzyńcu — różni się tylko liczbą stref i modułów.

Optymalizacja WooCommerce — 7 miejsc, które najczęściej spowalniają sklep

Zanim zaczniesz cokolwiek przyspieszać, ustal, gdzie realnie tracisz sekundy. Poniżej siedem miejsc, które najczęściej psują czas ładowania sklepu na WooCommerce — każde z narzędziem do wykrycia.

1. Wolne zapytania do wp_postmeta i brak indeksów. Filtry po atrybutach przy 10 tys. produktów generują zapytania po 0,8–2 s. Włącz Query Monitor (zakładka Queries, sortowanie po czasie) oraz slow query log (long_query_time = 1). Powtarzalny wzorzec w logu → indeks na meta_key i cache wyniku w transient na 15–30 min. Testuj na kopii bazy, nie na produkcji.
2. Koszyk i checkout z blokami oraz nadmiarem wtyczek. Mierz WebPageTest z emulacją 3G (Moto G4, ok. 1,6 Mb/s, 300 ms RTT), osobno /cart i /checkout. Bloki koszyka dociągają React i potrafią dołożyć 1–2 s względem klasycznego szablonu.
3. Ładowanie całych bibliotek JS/CSS. Slider zaciąga Swiper (60–100 kB) na każdej podstronie, choć działa tylko na stronie głównej. Wykrycie: DevTools → Coverage (Ctrl+Shift+P → Coverage), kolumna unused bytes.
4. Obrazy bez WebP i bez srcset. PageSpeed Insights pokaże „Serve images in next-gen formats”, DevTools → Network — realny rozmiar pliku. Sprawdź, czy upload generuje warianty 300/768/1024 px i czy tag img ma atrybuty srcset oraz sizes.
5. Nieskończona paginacja i duplikaty. Infinite scroll bez zmiany URL oznacza, że Google widzi jedną stronę. Do tego ten sam produkt dostępny pod /kategoria/ i /?product_cat= oraz pod adresami z parametrami filtrów. Rozwiązanie: canonical, noindex na widoki filtrowane, normalne linki /page/2/.
6. Zewnętrzne skrypty: czaty, piksele, mapy. W waterfall sprawdź, co wypada przed LCP. Najczęściej blokują: czat w head bez defer, piksel reklamowy ładowany synchronicznie, iframe mapy Google. Fix: defer/async, lazy load iframe, czat dopiero po pierwszym scrollu.
7. Cache bez wykluczenia koszyka i logowania. Objaw: koszyk „zeruje się”, gość widzi ceny grupy B2B. Dodaj produkt i sprawdź nagłówek X-Cache na /cart — HIT oznacza błąd konfiguracji. Wykluczenia: /cart, /checkout, /my-account, cookie woocommerce_items_in_cart.

Kolejność prac i podział na etapy opisujemy przy okazji organizacji wdrożenia WooCommerce w Bełżcu. Same progi metryk, do których warto się odwoływać, znajdziesz w dokumentacji Web Vitals.

Hosting, cache i CDN — co ma sens przy skali MŚP, a co jest przepalaniem budżetu

Warstwa infrastruktury to najłatwiejsze miejsce na przepalenie budżetu. Zasada jest prosta: dobierasz hosting do liczby produktów i ruchu, nie do ambicji.

Shared hosting wystarcza, gdy masz do 1000–2000 produktów, do 30–50 tys. odsłon miesięcznie i nie robisz importów z ERP. Warunki, których nie odpuszczaj: PHP 8.1 lub nowszy, OPcache, MySQL 8 albo MariaDB 10.4+, HTTP/2, minimum 1 GB RAM na proces. Zapytaj dostawcę o limit IOPS i max_children — one kończą się pierwsze przy skoku ruchu.

VPS z Nginx i PHP-FPM wchodzi, gdy sklep ma ponad ok. 5000 produktów, cron importujący stany, niestandardowe moduły albo gdy shared przewraca się przy 20 równoczesnych użytkownikach. Przy 4 GB RAM policz pm.max_children z realnego zużycia procesu PHP (np. 4 GB / 80 MB ≈ 40–50), ustaw pm=dynamic, opcache.memory_consumption=256 i włącz fastcgi_cache.

CDN — przy klientach z Narola, Lubaczowa i Zamościa serwer w Warszawie odpowiada w 10–30 ms. CDN tego w widoczny sposób nie skróci; 30–100 zł miesięcznie nic nie zmieni. Ma sens, gdy serwer stoi za granicą, gdy masz setki zdjęć produktowych, gdy ruch idzie z całej Polski albo gdy potrzebujesz osłony przed DDoS.

Pełnostronicowy cache konfiguruj z wykluczeniami od pierwszego uruchomienia: /cart, /checkout, /my-account, /?add-to-cart=, cookies woocommerce_items_in_cart i woocommerce_cart_hash, a także dla zalogowanych. Bez tego pierwszy test po włączeniu cache kończy się pustym koszykiem.

Kopie zapasowe: baza codziennie (retencja 14–30 dni), pliki — uploads, motywy, wtyczki — raz w tygodniu, wszystko poza serwerem: S3, Backblaze lub inny dostawca. Raz na kwartał odtwórz kopię na subdomenie testowej i sprawdź, czy sklep wstaje. Kopia, której nie odtworzyłeś, nie istnieje. Konfigurację środowiska dla mniejszych sklepów pokazujemy przy WooCommerce w Zwierzyńcu, a warianty dla większego ruchu — przy organizacji wdrożenia WooCommerce w Lublinie. Progi czasu odpowiedzi serwera opisuje Google Search Central — Core Web Vitals.

Integracje, które decydują o działaniu sklepu: kurierzy, płatności, ERP

Integracje to miejsce, w którym sklep przestaje być sklepem, a zaczyna być systemem. Tu też najczęściej wraca pytanie: gotowa wtyczka czy własny moduł.

Punkty odbioru InPost i wysyłka DPD/DHL. Różnica nie jest kosmetyczna. API (ShipX, WebAPI DPD, DHL24) pozwala utworzyć przesyłkę z panelu sklepu, dostać etykietę PDF od razu i cyklicznie odpytywać statusy. Plik CSV to eksport zamówień i ręczne wgrywanie do panelu kuriera — sensowne do ok. 10 przesyłek dziennie, powyżej zjada czas i generuje pomyłki. Najczęstszy błąd przy punktach InPost: kod punktu nie zapisuje się w metadanych zamówienia, gdy klient zmieni metodę dostawy już po wyborze punktu.

Statusy i numery przesyłek. Reguły ustal przed startem: opłacone → „W realizacji”, nadanie → „Wysłane” plus numer w mailu i w panelu klienta. Ręczne przepisywanie numeru to 40–60 s na zamówienie; przy 30 zamówieniach dziennie daje 20–30 minut. To najbardziej opłacalna automatyzacja w całym sklepie.

Integracja z ERP. Ustal kierunek przepływu i zapisz go jako zasadę: stany magazynowe idą z ERP do sklepu, zamówienia ze sklepu do ERP. Dopasowanie po SKU albo EAN — bez tego powstaną duplikaty pozycji. Ryzyko nadpisania: jeśli sklep sam odejmuje stan przy zamówieniu, a ERP synchronizuje się co 15 minut, stany się rozjadą. Rozwiązanie: magazyn zarządzany wyłącznie przez ERP, w sklepie blokada edycji stanu. Synchronizuj kolejką, nie zapytaniem przy każdym wejściu na kartę produktu.

Kiedy własny moduł ma sens: brak wsparcia wtyczki (6–12 miesięcy bez aktualizacji), specyficzne B2B — cenniki per klient, limity kredytowe, zamówienia zbiorcze — albo integracja z wewnętrznym systemem, którego nie da się podłączyć gotowym konektorem. Koszt to zwykle 40–120 godzin pracy plus 15–20% rocznie na utrzymanie. Warto, gdy oszczędność czasu albo różnica w procesie sprzedaży jest policzalna. Podstawy konfiguracji znajdziesz w dokumentacji WooCommerce, a przykłady wdrożeń w mniejszych firmach — przy Wdrożeniach WooCommerce w Frampolu i organizacji wdrożenia w Józefowie.

Bezpieczeństwo i administracja — czego nie widać, dopóki nie zabraknie sklepu

Sklep, który działa, nie znaczy sklep, który jest utrzymywany. Najdroższe awarie w WooCommerce wynikają zwykle z trzech rzeczy: nieaktualizowanej wtyczki, konta administratora bez drugiego czynnika i braku monitoringu. Żadna z nich nie daje objawów aż do dnia, w którym sklep przestaje przyjmować zamówienia.

Aktualizacje. WordPressa, WooCommerce i wtyczek nie aktualizuje się na produkcji. Najpierw staging — kopia sklepu z tą samą wersją PHP i kopią bazy produkcyjnej (jeśli zawiera dane klientów, zanonimizowaną). Kolejność pracy: kopia bazy i plików, aktualizacja, test koszyka, płatności, maili i etykiet. Dopiero potem produkcja, w oknie niskiego ruchu. Standard: przegląd aktualizacji raz w miesiącu plus reakcja na krytyczne łatki bezpieczeństwa w ciągu 24–48 godzin.

Dostępy. Weryfikacja dwuetapowa obowiązkowa dla każdego konta z rolą Administrator. Kont na tej roli maksymalnie dwa — jedno techniczne, jedno właścicielskie. Do codziennej pracy wystarcza rola Shop Manager: zamówienia, produkty, kupony, bez dostępu do wtyczek, motywu i plików. Dostęp byłego pracownika lub agencji to najczęstsza przyczyna „niespodziewanych” zmian w sklepie. Odbieraj go tego samego dnia, w którym kończy się współpraca.

Monitoring. Cztery rzeczy do mierzenia: dostępność (test co 1–5 minut, alert SMS), czas odpowiedzi serwera, błędy PHP oraz kolejka maili transakcyjnych. Ta ostatnia jest niedoceniana — Action Scheduler potrafi się zapchać i wtedy zamówienia są, a potwierdzeń nie ma. Sprawdź, ile zadań czeka w kolejce i czy wysyłka nie stoi.

SLA wpisz do umowy: czas reakcji (np. 4 godziny w dni robocze), czas naprawy, kanał zgłoszeń i osoba po drugiej stronie. Obietnica w mailu nie zadziała, gdy w piątek o 18:00 padnie bramka płatności. Zakres funkcji zamówień, maili i harmonogramu zadań opisuje dokumentacja WooCommerce — warto ją przejrzeć przed podpisaniem umowy utrzymaniowej.

Pułapki przy wdrożeniach i optymalizacji — objaw, przyczyna, sprawdzenie, naprawa

Zanim wezwiesz pomoc, sprawdź logi. W większości przypadków odpowiedź jest w slow query log, w logu wtyczki płatności albo w logu integracji — nie w kodzie szablonu. Cztery sytuacje, które wracają najczęściej:

Kiedy WooCommerce przestaje wystarczać — sygnały do zmiany lub migracji

Nie każdy rosnący sklep potrzebuje zmiany platformy. Ale istnieją progi, po których rozwijanie WooCommerce staje się droższe niż uporządkowana migracja.

Sygnały. Pierwszy: katalog powyżej 10 000 SKU z wariantami. Przy kilkudziesięciu tysiącach wariantów tabela postmeta rośnie do milionów wierszy, a filtrowanie po atrybutach wymaga własnych indeksów, cache obiektowego (Redis) i cache pełnostronicowego z wykluczeniami. Drugi: kilka tysięcy zamówień miesięcznie — pomaga włączenie HPOS, ale raporty, eksporty i księgowość nadal obciążają bazę. Trzeci: rozbudowana logika B2B — ceny per klient, grupy cenowe, limity kredytowe, faktury, zatwierdzanie zamówień. W WooCommerce da się to zbudować wtyczkami, ale każda dokłada zapytania i kolejny punkt awarii.

Jak policzyć próg opłacalności. Zestaw koszt utrzymania i rozwoju w 12 miesiącach z kosztem migracji. Migracja przy 5 000 SKU to realnie 150–400 godzin: katalog, szablon, integracje, płatności, testy. Jeśli dziś wydajesz 2 000–3 000 zł miesięcznie na doraźne naprawy wydajności, rocznie to 24 000–36 000 zł. Gdy migracja zwraca się w 12–18 miesięcy i zdejmuje problem, którego nie da się rozwiązać konfiguracją, warto ją zaplanować. Kalkulację roboczą znajdziesz też w materiałach o wdrożeniach WooCommerce w Lublinie.

Bezpieczna migracja. Kolejność: inwentaryzacja adresów URL (sitemap, logi serwera, crawl), mapowanie stary → nowy adres w arkuszu, przekierowania 301 dla każdego adresu, testy na staging — minimum 200 zamówień różnymi metodami płatności, z kodem rabatowym, zwrotem i fakturą. Dopiero potem przełączenie DNS. Po starcie sprawdź dane strukturalne produktów — to one sterują tym, jak sklep wygląda w wynikach wyszukiwania.

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

Lista kontrolna do odklikania

• Model sprzedaży — Ustal przed wyceną: sklep B2C, katalog B2B na zapytanie czy sprzedaż transgraniczna. Każdy z nich to inny zakres prac.
• Liczba SKU i wariantów — Policz osobno produkty proste i produkty z wariantami. Sklep 5000 SKU z wariantami to inna skala bazy niż 50 produktów prostych.
• Strefy dostawy i kurierzy — Spisz, które firmy wchodzą w grę (np. InPost, DPD, DHL) i ile stref cennikowych potrzebujesz. Sprawdź to przed wyceną, bo to wpływa na czas wdrożenia.
• Metody płatności — Ustal operatora płatności, przelew tradycyjny i opcję za pobraniem. Zweryfikuj, czy masz już konto i umowę z operatorem.
• Hosting i parametry serwera — Wymagaj PHP 8.2 lub nowszego, MySQL 8 albo MariaDB 10.6, włączonego OPcache i minimum 2 GB RAM przy katalogu 1000+ SKU.
• Środowisko staging — Sprawdź, czy wykonawca ma staging oddzielony od produkcji i czy staging korzysta z kopii bazy produkcyjnej.
• Domeny i DNS — Ustal, kto ma dostęp do domeny i strefy DNS oraz kto robi przekierowanie po publikacji.
• Struktura katalogu — Zatwierdź drzewo kategorii i liczbę poziomów. Przy 5000 SKU głębokość kategorii ma znaczenie dla nawigacji i adresów URL.
• Źródło danych produktowych — Ustal, czy dane przyjdą w CSV, XML czy przez API i kto je przygotuje. Zła struktura pliku to dodatkowe godziny, których nikt nie lubi dopisywać.
• Integracje zewnętrzne — Wypisz systemy, z którymi sklep ma się łączyć: ERP, magazyn, księgowość, program pocztowy. Ustal, kto udostępnia dostępy i dokumentację API.
• Wielojęzyczność i waluty — Zaplanuj języki i waluty przed wyceną, nie po. To jeden z czynników, który najczęściej przesuwa projekt z widełek 60–80 h do 80–120 h.
• Dokumenty i zgodność — Zbierz regulamin, politykę prywatności, wzór faktury i informacje o administratorze danych. Bez tego nie ma czego publikować.
• Kryteria akceptacji — Sprawdź przed publikacją: logi bez błędów krytycznych, maile transakcyjne docierają, testowe zamówienie przechodzi całą ścieżkę, etykieta kurierska się drukuje.
• Przekazanie i szkolenie — Ustal, kto po wdrożeniu obsługuje produkty i zamówienia. Zapytaj, czy szkolenie jest wliczone w godziny i w jakiej formie dostaniesz dokumentację.

Najczęściej zadawane pytania

Źródła i materiały

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