Wdrożenia i optymalizacja WooCommerce w Hrubieszowie kosztują tyle, ile godzin pracy wymaga projekt — nie ma tu cennika za sztukę. Sklep do 100 SKU to zwykle 25–40 h, 100–1000 SKU to 60–120 h, a wielokanałowy z ERP i modułami pisanymi na zamówienie — 150 h i więcej. Poniżej rozkładamy na części to, co decyduje o tych widełkach, i pokazujemy, jak przygotować firmę, żeby nie płacić dwa razy za te same poprawki. To część organizacyjna: zakres, kolejność prac, dane wejściowe od klienta i podział budżetu na jednorazowe wdrożenie oraz miesięczną opiekę.
W Hrubieszowie, tak jak wszędzie, cena wdrożenia WooCommerce to liczba godzin pracy razy stawka — nie ma cennika „za sklep”. Żeby dostać sensowną wycenę, trzeba najpierw zakwalifikować projekt do jednego z trzech scenariuszy.
Scenariusz 1 — do 100 SKU (25–40 h). Gotowy szablon, 3–6 kategorii, płatności online (Przelewy24, PayU, Stripe), kurier i paczkomat, import z pliku CSV, regulaminy i polityka zwrotów. W praktyce nawet połowa tego czasu schodzi nie na konfigurację, a na doprowadzenie danych produktowych do ładu: zdjęcia w jednym formacie, opisy bez resztek z Excela, poprawne tytuły.
Scenariusz 2 — 100–1000 SKU (60–120 h). Dochodzą warianty i atrybuty, filtry, kilka metod dostawy z progami darmowej wysyłki, stany magazynowe, więcej scenariuszy testowych. Sam import 1000 produktów z weryfikacją to zwykle 4–8 h.
Scenariusz 3 — wielokanałowy z ERP (150 h+). Synchronizacja z Subiektem, Comarch ERP Optima czy WF-Mag, stany i ceny w obie strony, moduły pisane na zamówienie, wielojęzyczność, integracje magazynowe. Tu każda zmiana w ERP to potencjalny błąd w sklepie, więc dochodzi obsługa wyjątków i logi.
Wdrożenie to nie to samo co opieka. Wdrożenie jest jednorazowe. Optymalizacja i opieka to 4–12 h miesięcznie: aktualizacje WordPressa, WooCommerce i wtyczek, kopie zapasowe, monitoring dostępności, poprawki po zmianach w bramce płatniczej, drobne przyspieszanie. Bez tego po roku wracasz do punktu wyjścia.
Co podnosi budżet: import i synchronizacja z ERP, wielojęzyczność, indywidualne moduły, migracja danych i historii zamówień ze starego sklepu (mapowanie klientów, zamówień, numerów faktur). Co nie podnosi: sama liczba produktów prostych. Import 50 i 900 SKU bez wariantów różni się czasem, ale architektura sklepu, zestaw wtyczek i szablon są praktycznie takie same. Podobny rozkład prac opisujemy przy wdrożeniach WooCommerce w Lublinie.
| Scenariusz | Liczba SKU | Godziny | Co zwykle wchodzi w zakres |
|---|---|---|---|
| Prosty sklep | do 100 | 25–40 h | szablon, płatności online, 2–3 metody dostawy, import CSV, regulaminy |
| Sklep z wariantami | 100–1000 | 60–120 h | atrybuty i warianty, filtry, stany magazynowe, progi darmowej dostawy, więcej testów |
| Wielokanałowy z ERP | 1000+ | 150 h+ | synchronizacja z ERP, moduły na zamówienie, wielojęzyczność, integracje magazynowe, obsługa błędów |
Hosting to nie miejsce na oszczędzanie. Minimum: PHP 8.1 (lepiej 8.2–8.3), MySQL 8.0 lub MariaDB 10.5+, memory_limit 512 MB na proces i 1024 MB przy importach, OPcache, HTTPS, HTTP/2, dysk NVMe oraz prawdziwy cron systemowy zamiast WP-Cron. Na hostingu za kilkanaście złotych miesięcznie WooCommerce nie wyrabia niezależnie od wtyczek: zapis produktu kończy się timeoutem po 30–60 s, import pada w połowie, panel ładuje się kilka sekund.
Kolejność prac: hosting → WordPress (permalinki, użytkownicy, SMTP do maili transakcyjnych) → WooCommerce → szablon → produkty → płatności → dostawa → test pełnego zamówienia → test zwrotu → kopie zapasowe i środowisko staging. Zmiana szablonu po wgraniu 500 produktów to powtórka pracy nad kartą produktu, kategoriami i szablonami maili.
Ustawienia w pierwszej godzinie, o których najczęściej się zapomina: strefa czasowa Europe/Warsaw, waluta PLN i pozycja separatora, jednostki wagi i wymiarów (kg, cm — inaczej kurier liczy złe gabaryty), klasy podatkowe i stawki VAT 23/8/5/0, numeracja zamówień z prefiksem (nie startuj od numeru 1), dokumenty sprzedaży oraz strony koszyka, zamówienia i „Moje konto”.
Produkt wariantowy czy wiele prostych? Przy 20+ wariantach (rozmiar × kolor) wariantowy wygrywa: jeden URL, jedna karta do indeksowania, wygodniejsza edycja cen i stanów. Ale każdy wariant to kolejne wiersze w wp_postmeta — przy 2000 wariantach panel zaczyna zwalniać. Przy 2–3 wariantach prostszy bywa produkt prosty. Reguła praktyczna: jeśli klient szuka jednej rzeczy, ma trafić na jeden URL.
Test na prawdziwej bramce w trybie sandbox. Płatność za pobraniem przechodzi zawsze i niczego nie sprawdza — nie testuje webhooków, powrotu z banku, autoryzacji 3DS ani zmiany statusu zamówienia. Uruchom sandbox Przelewy24, PayU lub Stripe, złóż zamówienie kartą testową, sprawdź mail z potwierdzeniem, a na końcu wykonaj zwrot i zobacz, czy stan magazynowy wrócił na miejsce. Podobną kolejność prac stosujemy przy wdrożeniach WooCommerce w Narolu.
Najpierw pomiar. Bez baseline nie udowodnisz poprawy ani sobie, ani klientowi. Wykonaj PageSpeed Insights na mobile i zapisz LCP, INP i CLS — progi tych wskaźników opisuje web.dev. Uruchom Query Monitor i policz zapytania SQL na stronie głównej, kategorii i karcie produktu, zmierz TTFB w DevTools. Typowy sklep na przeciętnym hostingu: 60–120 zapytań na karcie produktu i TTFB 800–1500 ms.
Serwer. OPcache z podniesionym limitem, PHP 8.1+ zamiast 7.4 (10–20% szybsze wykonanie kodu), Redis lub Memcached jako object cache, cache pełnostronowy. Ten ostatni musi mieć wyjątki dla /koszyk, /zamówienie i /moje-konto — inaczej klient zobaczy cudzy koszyk. Sprawdź też, czy wtyczka cache poprawnie ustawia nagłówek Vary i nie cache'uje odpowiedzi dla zalogowanych.
Front. WebP/AVIF, lazy loading poniżej pierwszego ekranu (nigdy dla obrazu LCP), krytyczny CSS w sekcji head i asynchroniczne ładowanie reszty, ograniczenie wtyczek ładujących skrypty globalnie — slider, kreator stron, zewnętrzne fonty i ikony społecznościowe to często 8–15 dodatkowych plików na każdej podstronie.
HPOS (High-Performance Order Storage). WooCommerce → Ustawienia → Zaawansowane → Funkcje. Przenosi zamówienia z wp_posts i wp_postmeta do dedykowanych tabel. Lista zamówień w panelu i raporty przyspieszają odczuwalnie. Warto włączyć przy kilku tysiącach zamówień albo gdy lista ładuje się dłużej niż 3–5 s — ale najpierw sprawdź, czy wszystkie wtyczki deklarują zgodność z HPOS.
Higiena bazy. Osierocone wpisy w wp_postmeta, transjenty w wp_options, limit autoloadu (WordPress 6.6+ pilnuje go po swojemu, starsze wersje nie), wygasłe sesje woocommerce_session_* i porzucone koszyki. Przy 100 tys. wierszy w wp_postmeta jedno niezaindeksowane zapytanie potrafi dodać 300 ms do każdego wejścia na kartę produktu.
| Objaw | Narzędzie do wykrycia | Typowy czas naprawy |
|---|---|---|
| Wolny koszyk przy 100+ pozycjach | Query Monitor | 3–8 h |
| Karta produktu z 60+ zapytaniami SQL | Query Monitor | 4–10 h |
| Wysokie TTFB na kategorii | Query Monitor, logi PHP-FPM | 4–12 h |
| Słabe LCP na mobile | PageSpeed Insights / Lighthouse | 3–8 h |
| Przesuwający się layout (CLS) po dodaniu wtyczki | Lighthouse | 2–4 h |
| Wolne filtry i wyszukiwanie | Query Monitor, EXPLAIN w MySQL | 6–16 h |
| Wielosekundowe zapisywanie produktu w panelu | Query Monitor, slow query log | 2–6 h |
Po starcie sklepu najwięcej godzin zjada nie wygląd, a integracje. Każda ma własne pola obowiązkowe i własne scenariusze błędów, więc testuj je pojedynczo na kilku zamówieniach próbnych, a nie wszystkie naraz w dniu premiery.
InPost ShipX. Do ustawienia są cztery rzeczy: nadawanie przesyłek, zapis wybranego Punktu Obsługi do zamówienia, generowanie etykiety PDF i webhooki statusów. Punkt Obsługi zapisuj w meta zamówienia już przy jego składaniu — jeśli zrobisz to dopiero po powrocie klienta z bramki, sesja koszyka może być pusta i punkt zniknie. Etykieta ma sens tylko wtedy, gdy po jej wygenerowaniu numer przesyłki trafia do zamówienia i do maila „wysłane”. Webhooki statusów powinny same przestawiać status zamówienia, ale z weryfikacją podpisu lub nagłówka — publiczny endpoint bez sprawdzenia źródła to zaproszenie do fałszywych statusów. Największa pułapka to wysyłka masowa: pętla wysyłająca setki etykiet jedna po drugiej kończy się błędami limitu (HTTP 429) i timeoutami. Rozwiązanie: kolejka zadań (Action Scheduler albo WP-Cron), odstęp między żądaniami, ponowienia z rosnącym opóźnieniem i log każdego żądania.
DPD WebAPI i DHL24. Tu wdrożenie wywraca się na mapowaniu: każda usługa przewoźnika musi mieć przypisaną metodę wysyłki w WooCommerce, a domyślny nadawca (adres, numer klienta, konto) wpisany raz i poprawnie. Brak wagi i gabarytów na produkcie oznacza etykietę wycenioną na wartościach domyślnych. Drukowanie seryjne to osobna funkcja — zbierz etykiety w jeden PDF, bo generowanie plików pojedynczo przy 40 paczkach dziennie zajmuje pakującemu kilka minut każdego dnia.
Płatności (Przelewy24, PayU, Stripe). Osobne klucze dla sandboxa i produkcji, publiczny adres webhooka (nie schowany za logowaniem do stagingu) i test powrotu klienta z bramki. Bez zabezpieczenia tego kroku powstają podwójne zamówienia: klient cofa się przyciskiem przeglądarki, WooCommerce tworzy drugie zamówienie, a pieniądze pobrane są raz. Idempotencja po identyfikatorze koszyka i sprawdzenie w webhooku, czy zamówienie już ma status opłaconego, załatwia temat.
ERP (Subiekt GT/nexo, WF-Mag, Comarch). Jedno źródło prawdy dla stanów i cen oraz ustalony kierunek synchronizacji: stany i ceny z ERP do sklepu, zamówienia ze sklepu do ERP. Konflikt — produkt zmieniony po obu stronach między dwoma przebiegami — musi mieć regułę rozstrzygającą i log, inaczej po miesiącu nikt nie wie, która cena jest prawdziwa. Osobna sprawa: WP-Cron startuje tylko przy ruchu. W sklepie z 20 zamówieniami na dobę i nocną ciszą synchronizacja potrafi nie wystartować. Wyłącz go w wp-config.php (DISABLE_WP_CRON) i ustaw systemowy cron co minutę — tak jak przy organizacji wdrożenia WooCommerce w Narolu czy Józefowie, gdzie dopiero na produkcji widać, że zadanie się nie odpala.
| Obszar | Co ustawić przed startem | Najczęstsza poprawka po starcie |
|---|---|---|
| InPost ShipX | Punkt Obsługi w meta zamówienia, szablon etykiety, webhooki statusów z weryfikacją | Ręczne generowanie etykiet, bo kolejka nie działała przy wysyłce masowej |
| DPD WebAPI / DHL24 | Domyślny nadawca i numer klienta, mapowanie usług na metody wysyłki, waga i gabaryty | Etykiety z błędną usługą albo domyślną wagą |
| Przelewy24 / PayU / Stripe | Osobne klucze sandbox i produkcja, publiczny URL webhooka, idempotencja zamówienia | Podwójne zamówienia po powrocie klienta z bramki |
| ERP (Subiekt, WF-Mag, Comarch) | Kierunek synchronizacji i jedno źródło prawdy dla cen i stanów | Nadpisywanie stanów po obu stronach i brak logu konfliktów |
WooCommerce domyślnie generuje tysiące adresów, z których indeksować warto kilkaset. Zacznij od architektury URL: Ustawienia → Bezpośrednie odnośniki → Własne i schemat /%product_cat%/%postname%/. Jeśli produkt siedzi w trzech kategoriach, wyznacz jedną główną i pilnuj, żeby pozostałe wersje prowadziły do niej canonicalem. Koszyk, moje konto, strona zamówienia i wewnętrzne wyszukiwanie (?s=) muszą być poza indeksem.
Duplikaty robią się tam, gdzie klient filtruje: ?orderby=, ?order=, kombinacje atrybutów i paginacja /page/2/ tworzą dziesiątki adresów tej samej treści. Ustaw dla sortowania i dowolnych kombinacji filtrów noindex, follow, a paginację zostaw jako self-canonical — nie kieruj canonicala strony drugiej na pierwszą. Najczęstszy błąd to zbyt szeroki przełącznik: wtyczka SEO wyłącza indeksowanie całych archiwów kategorii razem z filtrami i wypadają prawdziwe podstrony. Wykluczaj konkretne parametry, nie całe typy stron.
Dla Hrubieszowa kluczowy jest Google Business Profile: kategoria sklepu, obszar działania obejmujący Hrubieszów oraz sąsiednie miejscowości, aktualne godziny i zdjęcia. NAP (nazwa, adres, telefon) musi być identyczny w stopce, na stronie kontaktu i w katalogach. Warto linkować do stron lokalnych — wdrożenia WooCommerce w Biłgoraju pokazują, jak wygląda sensowna strona pod miasto bez sztucznego upychania fraz; podobnie dla Zamościa, Lublina, Bełżca czy Narolu, o ile masz tam realny zasięg dostaw — Bełżec to dobry przykład miejscowości, gdzie zwykle wystarczy jedna porządna podstrona, a nie pięć.
Dane strukturalne: Product, Offer i BreadcrumbList. Pola obowiązkowe to nazwa, zdjęcie, price i priceCurrency, availability (InStock/OutOfStock), koszt i czas dostawy oraz warunki zwrotu. Braki kończą się ostrzeżeniami w Search Console i brakiem rozszerzonych wyników — pełną listę obsługiwanych typów znajdziesz w dokumentacji Google Search Central o danych strukturalnych.
| Element | Ustawienie | Błąd do uniknięcia |
|---|---|---|
| Adresy produktów | /kategoria/podkategoria/produkt, jedna kategoria główna | Ten sam produkt pod trzema adresami bez canonicalu |
| Sortowanie i filtry | noindex, follow dla ?orderby= i kombinacji atrybutów | noindex na całych archiwach kategorii |
| Paginacja | Self-canonical na każdej stronie | Canonical strony 2 wskazujący na stronę 1 |
| Dane strukturalne | Product + Offer + BreadcrumbList z ceną, walutą, dostępnością, dostawą i zwrotami | Brak shippingDetails i hasMerchantReturnPolicy |
Migracja jest groźna tylko wtedy, gdy robi się ją bez mapy przekierowań. Zacznij od pełnej inwentaryzacji starych adresów: sitemap, logi serwera plus crawl narzędziem typu Screaming Frog, żeby wyłapać URL-e, które mają ruch, choć nie ma ich w sitemapie. Do każdego dopisz odpowiednik w WooCommerce. To ma być mapa jeden do jednego, ze statusem 301 — przekierowanie trwałe. Nie testuj „na próbę” przez 302: to przekierowanie tymczasowe i inaczej opisuje je choćby RFC 9110. Produkty trwale wycofane zwracają 410, nie 301 na stronę główną.
Klienci i historia zamówień. Hasła są hashowane i przeniosą się tylko wtedy, gdy stara platforma używała tego samego schematu co WordPress. W praktyce najczęściej się nie przenoszą. Plan B: importuj konta bez haseł i wyślij mailing z linkiem „ustaw nowe hasło” przy pierwszym logowaniu. Historię zamówień przenoś razem z datą, kwotą i statusem — samo wgranie samych kont bez zamówień kończy się lawiną pytań na mailu.
Kolejność prac. Kopia zapasowa bazy, plików i starego środowiska (musi dać się odtworzyć w godzinę) → import na staging, z produkcyjnym noindex i hasłem na całym serwerze → testy płatności i dostaw w sandboxie, na zamówieniach przechodzących cały cykl → dopiero potem zmiana DNS, w oknie niskiego ruchu, najlepiej między 2:00 a 5:00 → po zmianie: zdjęcie noindex i sprawdzenie 404 oraz 5xx w logach przez pierwsze 48 godzin.
Co psuje się najczęściej: duplikaty SKU, gdy importer tworzy nowe produkty zamiast aktualizować istniejące; warianty bez zdjęć, bo stare zdjęcia były pod inne identyfikatory; zgubione statusy zamówień, gdy „w realizacji” nie ma odpowiednika w processing; i wreszcie indeksowanie sklepu w trakcie testów — jeśli staging jest publiczny i bez noindex, Google zapisze setki adresów testowych, a po starcie trzeba je wypychać miesiącami. Podobne pułapki opisujemy przy migracji i optymalizacji WooCommerce w Lublinie oraz wdrożeniach WooCommerce we Frampolu — tam również kolejność kroków decydowała o tym, czy ruch spadł na tydzień, czy w ogóle.
| Etap | Co robimy | Warunek przejścia dalej |
|---|---|---|
| Kopia zapasowa | Baza, pliki i stare środowisko w pełni działające | Da się odtworzyć stary sklep w godzinę |
| Import na staging | Produkty, klienci, zamówienia, mapa 301 | Crawl nie pokazuje 404 na adresach z ruchem |
| Testy w sandboxie | Płatności, dostawy, etykiety, maile, statusy | Zamówienie testowe przechodzi cały cykl |
| Zmiana DNS i start | Okno niskiego ruchu, zdjęcie noindex, monitoring | Brak wzrostu 404 i 5xx w logach |
Wycena w godzinach ma jedną zaletę: widzisz, za co płacisz, i możesz świadomie ciąć zakres. Dwóch wykonawców z podobną stawką może dać różnicę 100 h na tym samym sklepie — nie dlatego, że jeden jest drogi, ale dlatego, że drugi wpisał w ofertę mniej pracy, np. pominął testy zamówień albo migrację treści. Dlatego proś o rozbicie na etapy, a nie o jedną kwotę na końcu.
Typowy projekt e-commerce dla firmy z Hrubieszowa i okolic — 30–300 SKU, jedna hurtownia, kurier i paczkomat, płatności online — rozkłada się tak:
Stawkę godzinową ustala wykonawca i w całym projekcie powinna być jedna. Jeśli w ofercie pojawia się ryczałt na część prac bez podania godzin, nie masz czym porównać ofert. Uczciwy model to godziny × stawka plus bufor 10–15% na to, co wyjdzie w trakcie. Optymalizację (10–30 h) rozliczaj po pomiarze przed i po — punktem odniesienia są Core Web Vitals, a nie wrażenie, że „działa szybciej”.
Osobna decyzja: własny moduł czy trzy płatne wtyczki. Trzy wtyczki po 150–400 zł/rok to 450–1200 zł rocznie, ale prawdziwy koszt to konflikty: po aktualizacji WooCommerce jedna z nich wysypuje kartę produktu, a wsparcie producenta odpowiada po dwóch dniach. Własny moduł (8–40 h) wygrywa, gdy logika jest wąska i twoja: cennik B2B z progami, wysyłka paletowa wg wagi i strefy, konfigurator dodatków. Przegrywa z gotową wtyczką, gdy odtwarzasz funkcje standardowe — bramki płatności, faktury, integracje kurierskie.
Poza wyceną zostaje: hosting i SSL, licencje szablonu i wtyczek premium, treści, zdjęcia produktowe, przepisanie danych z kartek i Excela do CSV oraz ustalenia z księgową o VAT i OSS. To nie ukryte koszty — to prace, które ktoś musi wykonać. Zapisz je wprost i zdecyduj, czy robisz je sam, czy zlecasz. Kolejność etapów rozpisaliśmy też przy organizacji wdrożenia WooCommerce w Lublinie.
| Etap | Widełki | Co zawiera |
|---|---|---|
| Audyt i plan | 4–8 h | Przegląd hostingu, wtyczek i szablonu, mapa procesu zamówienia, lista integracji, kolejność etapów |
| Wdrożenie bazowe | 25–60 h | WordPress i WooCommerce, podatki, strefy wysyłki, płatności, szablon, checkout, migracja do ok. 300 SKU |
| Optymalizacja | 10–30 h | Cache i CDN, obrazy WebP, Core Web Vitals, zapytania do bazy, wydajność koszyka i checkoutu |
| Integracja ERP | 20–60 h | Subiekt GT/nexo, Comarch Optima, WF-Mag: stany, ceny, zamówienia, mapowanie pól i statusów |
| Moduł niestandardowy | 8–40 h | Konfigurator, cennik B2B, nietypowa wysyłka, indywidualne pola zamówienia |
Wdrożenie bez opieki to sklep, który działa do pierwszej aktualizacji.
Backup. Baza codziennie — przy kilkunastu zamówieniach dziennie co 12 h; pliki przy każdej zmianie kodu i raz w tygodniu. Retencja: 30 dni dziennych i 12 miesięcznych. Kopia musi leżeć poza serwerem produkcyjnym, u innego dostawcy albo w S3 — nie w tym samym panelu hostingu, bo awaria konta zabiera jedno i drugie. Raz na kwartał robimy test odtworzenia na stagingu i mierzymy czas. Jeśli odtworzenie zajmuje 4 godziny, to nie plan odtworzenia, tylko nadzieja.
Monitoring. Dostępność sprawdzana co minutę z zewnątrz, nie z serwera sklepu. Do tego: czas odpowiedzi (TTFB), błędy PHP w logach, kolejka zadań (WP-Cron, Action Scheduler — czy liczba wpisów „pending” nie rośnie) oraz nieudane webhooki płatności w WooCommerce → Status → Logi, w plikach woocommerce-logs. Przy diagnozie przydaje się wiedza o kodach odpowiedzi HTTP i o tym, co wolno ponowić — zobacz RFC 9110. Alerty: mail dla wszystkiego, SMS dla sytuacji krytycznych — brak odpowiedzi, 5xx na /checkout, trzy nieudane płatności w 15 minut.
Aktualizacje. Zawsze staging → test zamówienia (płatność w sandboxie, mail, faktura, zmiana statusu) → produkcja. Okno wdrożeniowe poza szczytem sprzedaży: nie w Black Friday, nie w poniedziałek o 8:00. Dla sklepu B2B sprawdza się wtorek 6:00–8:00. Przed aktualizacją kopia i zapis wersji wtyczek, żeby rollback był jedną decyzją, a nie wieczorem z dokumentacją.
SLA. Liczby ustal w umowie, nie w rozmowie. Czas reakcji liczony w godzinach pracy oznacza pierwszą reakcję, nie naprawę. Oddziel awarię krytyczną od zwykłego zgłoszenia i trzymaj jeden kanał przyjmowania zgłoszeń — mail albo formularz. Telefon do wykonawcy o 22:00 gubi się szybciej niż zgłoszenie w kolejce. Zakres opieki opisaliśmy też przy organizacji wdrożenia WooCommerce w Biłgoraju.
| Typ zdarzenia | Przykład | Czas reakcji (godziny pracy) | Kanał |
|---|---|---|---|
| Awaria krytyczna | Sklep nie odpowiada, płatności odrzucają transakcje, brak dostępu do panelu | 1–2 h | SMS + mail |
| Błąd funkcjonalny | Nie wysyła się mail z potwierdzeniem, webhook płatności wisi | do końca dnia roboczego | Zgłoszenie w kolejce |
| Drobne | Literówka, podmiana zdjęcia, korekta treści | 1–2 dni robocze | Zgłoszenie w kolejce |
| Zmiana zakresu | Nowa wtyczka, nowy moduł, przebudowa szablonu | osobna wycena godzinowa | Zgłoszenie w kolejce |
Start prac bez zamkniętego zakresu i szacunku godzinowego — „dorobimy po drodze”.
Jak wykryć: Zapytaj wykonawcę, ile godzin wycenił osobno na import produktów, migrację historii zamówień i integrację z systemem zewnętrznym. Brak tych pozycji w ofercie oznacza, że ktoś je pominął, a nie że są darmowe.
Jak naprawić: Rozpisz zakres na pozycje z liczbą godzin i podpisem klienta przed pierwszą konfiguracją. Każda zmiana zakresu po tym momencie powinna przechodzić przez aneks, nie przez e-mail.
Praca bezpośrednio na produkcji, bez środowiska testowego ze świeżą kopią bazy.
Jak wykryć: Jeśli po każdej zmianie ustawień efekty widzą od razu klienci, a płatności działają w trybie live — stagingu nie ma. Drugi sygnał: brak adresu testowego z wyłączoną wysyłką e-maili do klientów.
Jak naprawić: Postaw kopię testową i wdrażaj tam każdy nowy moduł oraz aktualizację. Na produkcję wypuszczaj dopiero po przejściu pełnego zamówienia na środowisku testowym.
Import produktów przed ustaleniem struktury kategorii, atrybutów i wariantów.
Jak wykryć: Jeśli po imporcie ktoś ręcznie scala produkty proste w wariantowe albo poprawia kategorie w panelu, struktura nie została ustalona wcześniej. Widać to też po plikach CSV — kolejne wersje mają inne nazwy kolumn.
Jak naprawić: Najpierw słownik atrybutów i wzór pliku CSV zatwierdzony przez klienta, potem import. Przy 100–1000 SKU porządek na tym etapie oszczędza kilkanaście godzin pracy.
Brak testu pełnego zamówienia na bramce płatniczej w trybie sandbox.
Jak wykryć: Zapytaj, czy ktoś złożył zamówienie kartą testową i czy doszły: e-mail potwierdzający, zmiana statusu zamówienia i dokument sprzedaży. Poleganie wyłącznie na płatności za pobraniem niczego nie sprawdza.
Jak naprawić: Przejdź całą ścieżkę: koszyk, płatność w sandbox, e-mail, faktura, zmiana statusu, zwrot i zwrot środków — zanim sklep zobaczy pierwszy klient.
Włączanie wtyczek bez limitu i bez sprawdzenia, ile skryptów ładują globalnie.
Jak wykryć: Policz wtyczki i uruchom Query Monitor na stronie głównej, kategorii i karcie produktu. Jeśli liczba zapytań SQL rośnie o dziesiątki po wejściu na stronę sklepu, problem siedzi we wtyczkach, nie w szablonie.
Jak naprawić: Ustal limit wtyczek i wyłączaj globalne ładowanie skryptów w tych, które są potrzebne tylko na wybranych podstronach. Wtyczki nieużywane usuwaj, nie dezaktywuj — zostają w bazie.
Traktowanie optymalizacji jako zadania jednorazowego, zamkniętego w dacie startu.
Jak wykryć: Sprawdź umowę i faktury: jeśli jest tylko jednorazowa pozycja wdrożeniowa i brak miesięcznej opieki, nikt nie odpowiada za aktualizacje, kopie zapasowe ani czyszczenie bazy po starcie.
Jak naprawić: Oddziel budżet wdrożeniowy od miesięcznego abonamentu obejmującego aktualizacje, kopie, przegląd czasu odpowiedzi serwera i porządek w bazie.
Koszt wdrożenia WooCommerce to liczba godzin pomnożona przez stawkę, a nie efekt marketingowy — dlatego pierwszym krokiem jest ustalenie zakresu, a nie wybór szablonu. Trzy widełki (25–40 h, 60–120 h, 150 h+) pozwalają wstępnie zaklasyfikować projekt bez rozmowy z wykonawcą. Najwięcej godzin pochłaniają integracje, migracja danych i struktura wariantów, a najmniej — sama liczba produktów prostych. Budżet wdrożeniowy warto od pierwszego dnia oddzielić od miesięcznej opieki.
Liczba godzin zależy od zakresu, nie od lokalizacji. Sklep do 100 SKU bez integracji to zwykle 25–40 h, sklep 100–1000 SKU z importem i kilkoma metodami dostawy to 60–120 h, a projekt wielokanałowy z ERP i modułami na zamówienie startuje od 150 h. Do wyceny trzeba doliczyć czas po stronie klienta: dostarczenie danych produktowych i akceptacje etapów.
Liczba SKU wpływa głównie na czas importu i sprawdzenia danych, a nie na architekturę sklepu — kategoria z 200 produktami prostymi nie wymaga innego wdrożenia niż kategoria z 20. Drożej robi się wtedy, gdy produkty mają warianty, bo trzeba ustalić atrybuty, stany magazynowe na wariant i sposób prezentacji w panelu.
High-Performance Order Storage przenosi zamówienia z tabel wp_posts/wp_postmeta do dedykowanych tabel i przyspiesza obsługę dużej liczby zamówień oraz raportów. Ma sens, gdy sklep zbiera kilkaset i więcej zamówień miesięcznie albo gdy panel administracyjny wyraźnie zwalnia. Przed włączeniem sprawdź, czy wszystkie wtyczki obsługują HPOS — część starszych modułów czyta zamówienia po staremu.
Zapisz TTFB, liczbę zapytań SQL na stronie głównej, kategorii i karcie produktu oraz wynik Lighthouse dla tych samych adresów. Po zmianach powtórz pomiar w tych samych warunkach — na serwerze, nie na telefonie w zasięgu LTE. Punkt odniesienia i opis metryk znajdziesz w dokumentacji Web Vitals oraz w materiałach Google o Core Web Vitals.
Nie, jeśli wykluczysz z cache koszyk, zamówienie, moje konto i strony z parametrami sesji. Kluczowe są nagłówki odpowiedzi — Cache-Control i Vary — które decydują, co i dla kogo wolno zapisać; ich semantykę opisuje RFC 9110. Po włączeniu cache zrób test: dodaj produkt, przejdź do koszyka, złóż zamówienie i sprawdź, czy kwoty i dane klienta się zgadzają.
Nie — konfiguracja i optymalizacja WooCommerce to praca zdalna, a spotkania można prowadzić online. Warto jednak ustalić jedną osobę decyzyjną po stronie firmy, która akceptuje etapy i pilnuje przekazania danych. W podobnych projektach pracowaliśmy m.in. dla firm z Lublina i Biłgoraja — przebieg prac wyglądał tak samo.
Wdrożenie jest jednorazowe, opieka — powtarzalna co miesiąc. W abonamencie mieszczą się aktualizacje WordPressa i wtyczek, kopie zapasowe, monitoring dostępności, przegląd czasu ładowania i czyszczenie bazy z osieroconych wpisów oraz starych sesji. Bez tej pozycji każda awaria jest osobnym, nagłym wydatkiem.
Jeśli chcesz sprawdzić, do którego scenariusza należy Twój sklep i ile godzin realnie zajmie wdrożenie lub optymalizacja, napisz do nas kilka zdań o zakresie — odpowiemy widełkami, bez zobowiązań. Pracujemy z firmami z Hrubieszowa i okolic, zdalnie lub na miejscu, jeśli projekt tego wymaga.