Wdrożenia i optymalizacja WooCommerce w Zwierzyniu sprowadzają się do trzech decyzji: co dokładnie zamawiasz, ile godzin to zajmie i co przygotujesz przed startem. Lokalizacja nie podnosi ceny — praca w większości i tak odbywa się zdalnie, a dojazd z Zamościa czy Lublina to zwykle jedno lub dwa spotkania po 2 godziny. Poniżej znajdziesz podział wdrożenia na cztery bloki z własną pulą godzin, listę materiałów i decyzji do przygotowania przed pierwszą godziną pracy oraz harmonogram, po którym można pilnować wykonawcy. Jeśli chcesz najpierw uporządkować same założenia projektu, zobacz, jak wygląda organizacja wdrożenia WooCommerce w Zamościu.
Wdrożenie WooCommerce w Zwierzyniu to nie „instalacja wtyczki”. To cztery bloki pracy, każdy z osobną pulą godzin — dopiero ich suma daje budżet.
Skala projektu w liczbach: prosty sklep do 300 SKU z jedną metodą płatności i dwoma kurierami to zwykle 40–80 godzin. Sklep z konfiguratorem produktu, cenami B2B i integracją ERP to 150–250 godzin. Różnica nie bierze się z lokalizacji, tylko z liczby decyzji, które trzeba zakodować w systemie.
Mit pierwszy: Zwierzyniec podnosi cenę. Nie podnosi. Praca w większości odbywa się zdalnie — wystarczy dostęp do hostingu, repozytorium i panelu sklepu. Z Zamościa to około 30 km, z Lublina niecałe 90 km, więc w praktyce mówimy o jednym lub dwóch spotkaniach po 2 godziny na miejscu. To mieści się w stawce. Jeśli wykonawca dolicza kilometrówkę jako osobną pozycję, zapytaj, dlaczego — bo organizacja wdrożenia WooCommerce w Zamościu wygląda dokładnie tak samo.
Mit drugi: „mamy WooCommerce, więc sklep jest gotowy”. Instalacja zajmuje pół godziny. Gotowy sklep to skonfigurowane wysyłki, przetestowane płatności, opisy produktów, polityka zwrotów i działające etykiety kurierskie.
Specyfika Roztocza wymusza różne konfiguracje. Agroturystyka sprzedaje pobyty — potrzebny kalendarz i rezerwacja terminu. Producenci miodu i przetworów — wysyłkę szkła i produktów z datą ważności. Rękodzieło — unikaty ze stanem 1 sztuki. Wypożyczalnie sprzętu — kaucję i termin zwrotu. Standardowy szablon obsłuży może dwa z tych modeli.
Sezon maj–wrzesień zmienia priorytety. Sklep nastawiony na ruch w lipcu powinien mieć zapas mocy hostingu planowany pod lipiec, a nie pod listopad: więcej procesów PHP, wyższe limity, cache i CDN przetestowane w czerwcu. Test obciążeniowy w środku sezonu to proszenie się o wyłączony koszyk.
| Blok wdrożenia | Pula godzin | Co zawiera |
|---|---|---|
| Konfiguracja bazowa | 12–20 h | Hosting, PHP, SSL, strefy wysyłki, podatki, statusy zamówień |
| Warstwa treści i szablon | 20–40 h | Motyw, strona główna, karty produktów, kategorie, teksty |
| Integracje zewnętrzne | 20–60 h | Płatności, kurierzy i etykiety, faktury, ERP, newsletter |
| Testy i odbiór | 8–16 h | Zamówienia testowe, sandbox, etykiety próbne, mobile, szybkość |
Zamiast pytać „ile to kosztuje”, poproś o liczbę godzin na etap. Poniższe widełki pozwalają porównać dwie oferty na tym samym poziomie szczegółowości.
Zasada wyceny jest prosta: liczba godzin × stawka. Nie ma „pakietu za 2999 zł”, bo nie wiadomo, co jest w środku. Dobra oferta dzieli pracę na etapy i fakturuje je po odbiorze, z krótkim protokołem: co zostało zrobione, co przetestowane, co zostaje na następny etap.
Co najczęściej podnosi koszt po stronie klienta:
Koszt utrzymania wtyczek zewnętrznych warto policzyć w skali roku. Trzy abonamenty po 200–800 zł to 600–2400 zł rocznie i rosną z każdą kolejną funkcją. Jeśli złożony moduł da się napisać w 20–40 godzin, po dwóch–trzech latach własne rozwiązanie wychodzi taniej i nie zniknie, gdy wydawca wtyczki zakończy projekt.
Wskaźnik zaniżonej oferty: brak pozycji „testy i odbiór” w kosztorysie. Ktoś te testy wykona — albo wykonawca po godzinach, albo Ty po premierze, już bez wsparcia. Podobny sygnał to brak informacji o hostingu. Sklep zoptymalizowany pod Core Web Vitals na słabym serwerze nadal będzie wolny.
Podobne rozbicie stosuje się w innych miastach regionu, np. przy wdrożeniach i optymalizacji WooCommerce w Krasnobrodzie — różni się tylko lista integracji, nie metoda wyceny.
| Etap | Pula godzin | Od czego zależy |
|---|---|---|
| Konfiguracja bazowa | 12–20 h | Hosting, SSL, podatki, strefy wysyłki, statusy zamówień |
| Motyw lub szablon + dopasowanie | 20–40 h | Gotowy szablon vs projekt, liczba podstron i szablonów produktu |
| Płatności | 4–8 h | Liczba bramek, BLIK, raty, tryb sandbox |
| Kurierzy i etykiety | 6–12 h | Liczba przewoźników, generowanie etykiet, punkty odbioru |
| Import produktów | 2–10 h | 500 SKU, jakość danych, liczba wariantów |
| Integracja ERP | 40–120 h | API vs pliki, stany magazynowe, faktury, ceny |
| Optymalizacja szybkości | 10–25 h | Stan wyjściowy, liczba wtyczek, moc hostingu |
Każda godzina przepracowana przez klienta przed startem to zwykle godzina mniej na fakturze. Kolejność ma znaczenie — bez dostępów nie ruszy konfiguracja, bez decyzji nie ruszy warstwa treści.
Ten ostatni punkt bywa lekceważony, a wpływa wprost na konfigurację statusów zamówień. Jeśli faktury wystawia księgowa z zewnątrz, sklep musi wysyłać dane w ustalonym formacie — inaczej ktoś będzie je przepisywał co miesiąc. Jeśli zwroty obsługuje jedna osoba, warto ustawić osobny status i powiadomienie zamiast zostawiać je w „Zrealizowane”.
Przy pliku produktowym najczęściej wracają te same braki: zdjęcia bez nazw zgodnych z SKU, waga podana w gramach razem z kilogramami, brak wymiarów przy produktach wysyłanych kurierem, kategorie wpisane po ludzku zamiast jednego spójnego drzewa. Uzupełnienie tego po fakcie kosztuje więcej niż przygotowanie raz.
Jeśli przenosisz sklep z innego systemu, przygotowania są szersze — opisuje to lista rzeczy do zaplanowania przy migracji z PrestaShop do WooCommerce. Przy migracji dochodzi eksport zamówień, klientów i adresów URL do przekierowań.
| Kolumna w pliku produktowym | Uwaga praktyczna |
|---|---|
| SKU | Unikalny identyfikator, ten sam na fakturze i w magazynie |
| nazwa | Bez skrótów wewnętrznych, które nic nie mówią klientowi |
| cena | Jasno oznacz, czy netto czy brutto — to najczęstsze źródło pomyłek |
| stan | Liczba; przy unikatach wpisz 1 i zdecyduj, czy ukrywać po sprzedaży |
| waga i wymiary | W kilogramach i centymetrach — od tego zależy wycena kuriera |
| kategoria | Jedna spójna ścieżka, np. „Miód > Lipowy”, nie dwa drzewa |
| zdjęcia | Nazwa pliku równa SKU, np. MIOD-LIP-500-1.jpg |
Osiem etapów, każdy z własną pulą godzin i punktem kontrolnym. Po zamknięciu etapu wykonawca pokazuje efekt na stagingu (demo 15–30 minut) i wysyła mail z potwierdzeniem odbioru. Bez tego uwagi zbierają się na końcu, a poprawki zjadają zaplanowany budżet.
Razem daje to 50–105 godzin pracy, zależnie od liczby produktów, liczby integracji i tego, czy treści oraz zdjęcia są gotowe. Sposób podziału na bloki opisujemy szerzej w artykule o organizacji wdrożenia WooCommerce w Zamościu.
Praca nigdy nie odbywa się na produkcji. Staging to klon bazy i plików, zabezpieczony hasłem i ustawieniem noindex. Bez tego Google zaindeksuje wersję roboczą i po wdrożeniu będziesz mieć dwa adresy z tym samym opisem produktu.
Testy obowiązkowe przed odbiorem:
Odbiór techniczny: lista 12 testów podpisana przez obie strony plus nagranie szkoleniowe z obsługi panelu (30–60 minut) — dodanie produktu, zmiana ceny, obsługa zamówienia, wystawienie faktury, wygenerowanie etykiety. Nagranie zostaje u klienta, więc nowa osoba w firmie nie dzwoni do wykonawcy przy każdej zmianie ceny.
| Etap | Czas | Punkt kontrolny / demo |
|---|---|---|
| 1. Środowisko i hosting (staging) | 2–4 h | Klon bazy, hasło, noindex, certyfikat SSL |
| 2. Instalacja i konfiguracja WooCommerce | 4–8 h | Waluta, podatki, strefy, maile transakcyjne |
| 3. Struktura kategorii i atrybutów | 3–6 h | Zatwierdzona mapa kategorii i filtry |
| 4. Motyw i wygląd | 20–40 h | Widoki: home, kategoria, produkt, koszyk, checkout |
| 5. Import produktów | 2–10 h | Próbka 20 produktów + raport błędów |
| 6. Płatności i kurierzy | 10–20 h | Test 1 zł na każdej metodzie |
| 7. Testy | 6–12 h | Lista 12 testów, mobile i desktop |
| 8. Wdrożenie na produkcję i szkolenie | 3–5 h | Nagranie szkoleniowe, przekazanie dostępów |
WooCommerce traci sekundy w miejscach, których nie widać w panelu. Punktem odniesienia są Core Web Vitals mierzone na telefonie i na stronie produktu — nie na stronie głównej, która bywa lżejsza niż kategoria z filtrami i sortowaniem.
Narzędzia: PageSpeed Insights i dokumentacja web.dev o Core Web Vitals do pomiaru w terenie, Query Monitor do liczby zapytań SQL i hooków na konkretnym widoku, log slow query w MySQL dla zapytań dłuższych niż 1 s oraz k6 albo ab do testu obciążeniowego przed sezonem.
Najczęstsze przyczyny spadku w WooCommerce:
Prosty test rozstrzygający: jeśli strona kategorii generuje więcej niż 100 zapytań SQL, problem jest w motywie albo filtrach, a nie w hostingu. Zmiana serwera tego nie naprawi. Podobnie sprawdzasz się co roku przed sezonem — opisujemy to przy okazji optymalizacji WooCommerce w Krasnobrodzie.
Kolejność działań: najpierw baza i cache obiektowy (indeksy, czyszczenie wp_postmeta, Redis), potem obrazy (WebP/AVIF plus wpisane wymiary, żeby nie skakał layout), na końcu CDN i lazy loading. Odwrotna kolejność maskuje przyczynę — CDN przykryje wolne TTFB, ale wolne zapytania zostaną.
| Metryka | Cel | Gdzie mierzyć |
|---|---|---|
| LCP | poniżej 2,5 s | strona produktu, mobile |
| INP | poniżej 200 ms | dodawanie do koszyka, filtry kategorii |
| CLS | poniżej 0,1 | kategoria, karta produktu |
| TTFB | poniżej 600 ms | kategoria, produkt, koszyk |
Zanim podpiszesz umowę, ustal trzy rzeczy: które metody płatności wchodzą w zakres, których przewoźników obsługujesz i kto płaci za etykiety testowe.
Paczkomaty. Wybór punktu musi działać w checkoucie, bez wychodzenia do osobnej karty. Sprawdź trzy rzeczy: punkt zapisuje się w zamówieniu i w mailu (sama nazwa „Paczkomat” to za mało), kod punktu trafia do API w formacie wymaganym przez przewoźnika (spacje, małe litery albo nazwa zamiast kodu to najczęstsza przyczyna błędu „nieprawidłowy punkt”), a po powrocie do koszyka wybór nie znika. Osobno ograniczenie rozmiaru: jeśli sprzedajesz rzeczy ponad gabaryt skrytki, checkout musi to blokować.
Kurierzy. Cennik stoi na wadze i gabarytach produktu, więc te pola muszą być wypełnione w każdym produkcie. Strefy wysyłki (kraj, UE, reszta świata) z własnymi tabelami, pobranie jako osobna metoda z dopłatą. Etykiety generowane z panelu zbiorczo, nie po jednej przy 40 zamówieniach. Statusy zwrotne przez API albo webhooki, inaczej numery przesyłek wklejasz ręcznie.
Płatności. BLIK, przelew online, karta, płatność odroczona — każda metoda potrzebuje sandboxa i obsługi webhooka. Bez webhooka zamówienie zostanie w statusie „oczekuje na płatność”, mimo że pieniądze są już na koncie.
Pułapka na pierwszy tydzień po starcie: zamówienie opłacone bez zmiany statusu. Sprawdź log webhooków i uprawnienia klucza API — najczęściej brakuje uprawnienia do zmiany statusów albo adres powiadomień jest wpisany bez HTTPS.
Zwroty. Temat pomijany w ofertach, a generujący najwięcej maili. Ustal od razu: formularz zwrotu, etykieta zwrotna, kto pokrywa koszt i jak status zwrotu wraca do sklepu.
Migracja zaczyna się od inwentaryzacji adresów, nie od instalacji WooCommerce. Wyeksportuj sitemap.xml ze starego sklepu i niezależnie od niej listę adresów z panelu — to dwa różne źródła i mapa bywa niekompletna. Zbierz trzy pliki: produkty, kategorie, wpisy blogowe. W każdym wierszu dopisz nowy adres w WooCommerce i decyzję o przekierowaniu 301. Przy 500–3000 adresów praca idzie w arkuszu, nie ręcznie w .htaccess.
Zasada, która ratuje ruch: adres stary i nowy muszą prowadzić do tej samej treści. Produkt „miód spadziowy 400 g” ma trafić na swoją nową kartę, nie na stronę główną. Masowe przekierowanie wszystkiego na „/” to najczęstszy błąd migracji — Google interpretuje to jako soft 404, pozycje spadają w ciągu kilku tygodni, a odzyskanie ich zajmuje dłużej niż zrobienie przekierowań od razu. Wyjątek: towar trwale wycofany — wtedy 301 na najbliższą kategorię albo 410, jeśli nigdy nie wróci.
| Element | Przenosimy do WooCommerce | Zostaje w archiwum eksportu |
|---|---|---|
| Opisy i zdjęcia produktów | Tak, w całości — sprawdź alt i nazwy plików | — |
| Opinie | Tak, jeśli mają datę i autora | Opinie bez źródła — pomijamy |
| Kody śledzące (GA4, Meta Pixel) | Tak, plus test zdarzenia purchase po starcie | — |
| Konta klientów | Tak, z wymuszonym resetem hasła | Alternatywa: zostają i wysyłasz kampanię resetu |
| Historia zamówień | Tylko stan od dnia startu | Pełna historia zostaje jako archiwum księgowe |
Dane strukturalne to nie ozdoba. Bez Product i Offer na karcie produktu Google nie pokaże ceny i dostępności w wyniku rozszerzonym — a to często kilkanaście procent kliknięć przy tej samej pozycji. Na stronie głównej dodaj Organization z nazwą, logo, adresem i profilem w Google Business. W WooCommerce najprościej generować to wtyczką (Yoast SEO, Rank Math), ale po włączeniu sprawdź w Rich Results Test, czy cena i availability nie dublują się, gdy drugi moduł dorzuci własny blok. Rodzaje znaczników obsługiwanych przez Google masz wypisane w dokumentacji danych strukturalnych.
Struktura URL: krótkie, bez parametrów sesji w rodzaju ?sid= i bez duplikatów /product/ oraz /produkt/ jednocześnie. Canonical musi być poprawny w filtrach i paginacji — filtrowanie po atrybutach potrafi wygenerować setki adresów z tym samym zestawem produktów. Dla widoków z wieloma parametrami ustaw noindex,follow, indeksowanie zostaw paginacji.
| Strona | Typ danych | Co sprawdzić przed publikacją |
|---|---|---|
| Karta produktu | Product + Offer | Cena, waluta, availability, brak duplikatu bloku |
| Strona główna | Organization | Nazwa, logo, adres, profil GBP |
| Kategoria | BreadcrumbList | Ścieżka zgodna z faktyczną nawigacją |
Backup bez testu odtworzenia nie jest backupem. Wymagaj kopii dziennej z retencją minimum 30 dni oraz udokumentowanego testu odtworzenia na środowisku staging — raz na kwartał, z datą i zrzutem ekranu. Sam zapis „robimy backupy” nic nie znaczy, dopóki nie wiadomo, ile trwa przywrócenie i czy sklep po nim działa z płatnościami i stanami magazynowymi.
Aktualizacje WordPressa, WooCommerce i wtyczek w okienku serwisowym poza szczytem ruchu, z możliwością cofnięcia. Wtyczki aktualizuj partiami po 3–5, po każdej partii test koszyka i płatności — jedna aktualizacja potrafi zdjąć metodę płatności i nikt tego nie zauważy do pierwszego zamówienia.
Monitoring dostępności co minutę plus alerty o błędach PHP i wzroście czasu odpowiedzi — nie tylko informacja, że sklep „nie działa”. Progi ustaw na konkret: LCP powyżej 2,5 s przez trzy kolejne pomiary, wzrost TTFB o 50% względem średniej z tygodnia. Punkt odniesienia znajdziesz w opisie Web Vitals.
| Typ zgłoszenia | Czas reakcji | Przykład |
|---|---|---|
| Awaria blokująca sprzedaż | 1 godzina | Błąd 500 w koszyku, niedziałająca bramka płatności |
| Błąd nieblokujący | 1 dzień roboczy | Literówka w mailu potwierdzającym, brak alt w galerii |
| Zgłoszenie rozwojowe | 3 dni robocze | Wycena i analiza nowej funkcji |
Kosztorys bez pozycji „testy i odbiór”, potraktowany jako oszczędność 10–15 godzin.
Jak wykryć: Wypisz z oferty wszystkie pozycje i sprawdź, czy obok konfiguracji, motywu i integracji jest etap testów, odbioru i szkolenia. Jeśli nie ma — oferta jest niekompletna.
Jak naprawić: Poproś o dopisanie etapu testów z liczbą godzin i kryteriami odbioru (płatności w trybie testowym, etykiety kurierskie, mail do klienta, faktura, zwrot).
Traktowanie instalacji WooCommerce jako gotowego sklepu.
Jak wykryć: Jeśli po instalacji ktoś pokazuje Ci pusty sklep z domyślnym motywem i uznaje to za koniec prac — zakres został źle zrozumiany po obu stronach.
Jak naprawić: Ustal zakres na piśmie w czterech blokach: konfiguracja bazowa, warstwa treści i szablon, integracje zewnętrzne, testy i odbiór. Dopiero całość to działający sklep.
Dane produktowe przekazane w PDF-ach albo w mailach zamiast w jednym pliku.
Jak wykryć: Jeśli nie potrafisz wskazać jednego pliku CSV/XLSX, z którego da się zaimportować 500 SKU, dane nie są gotowe.
Jak naprawić: Zbierz produkty w jeden arkusz: SKU, nazwa, cena, stan, waga, wymiary, kategoria. Import 500 SKU to zwykle 2–10 godzin pracy, ręczne przepisywanie z PDF-a może wydłużyć to o kilka dni.
Odkładanie decyzji o płatnościach, kurierach i progach darmowej dostawy na czas wdrożenia.
Jak wykryć: Jeśli po dwóch tygodniach projektu nadal nie wiesz, który operator płatności i który kurier wchodzą w grę, prace staną w miejscu.
Jak naprawić: Ustal to przed startem. Płatności to 4–8 godzin, konfiguracja kurierów i etykiet 6–12 godzin — bez decyzji nie da się tych etapów zamknąć.
Hosting dobrany pod listopadowy ruch, gdy sklep ma szczyt maj–wrzesień.
Jak wykryć: Sprawdź, czy limit CPU, pamięci i liczby procesów był szacowany pod lipiec, a nie pod średnią roczną.
Jak naprawić: Zaplanuj zapas mocy na lipiec i przetestuj sklep obciążeniowo przed sezonem. Awaria w środku sezonu kosztuje więcej niż wyższy plan hostingu na trzy miesiące.
Brak dostępów do domeny, DNS i starego sklepu w dniu startu.
Jak wykryć: Zadaj pytanie, kto ma hasło do panelu DNS i do panelu hostingu. Odpowiedź „kolega, który to kiedyś robił” oznacza ryzyko opóźnienia.
Jak naprawić: Zbierz dostępy w jednym miejscu przed pierwszym spotkaniem i sprawdź, czy działają. Odzyskiwanie dostępu do domeny potrafi zająć dłużej niż samo wdrożenie.
Wdrożenia i optymalizacja WooCommerce w Zwierzyniu nie różnią się stawką od projektów w Zamościu czy Lublinie — różni się tylko logistyka spotkań, którą można zamknąć w dwóch wizytach po 2 godziny. Budżet policzysz sam, mnożąc godziny z podziałem na etapy przez stawkę, a nie zgadując, co kryje się pod hasłem „pakiet”. Największe oszczędności nie wynikają z tańszego wykonawcy, ale z przygotowanych danych produktowych, podjętych decyzji o płatnościach i wysyłce oraz z hostingu dobranego pod lipcowy szczyt. Jeśli w ofercie brakuje etapu testów i odbioru, to nie jest kompletna wycena. Warto też sprawdzić, jak wygląda organizacja wdrożenia w podobnych projektach, np. w Krasnobrodzie.
Prosty sklep do 300 SKU to zwykle 40–80 godzin pracy, czyli kilka tygodni kalendarzowo. Sklep z konfiguratorem, cenami B2B i integracją ERP to 150–250 godzin. Tempo zależy w dużej mierze od tego, jak szybko po stronie klienta zapadają decyzje i pojawiają się dane produktowe.
Nie stosujemy ukrytej kilometrówki dorzuconej do stawki. Standard to praca zdalna z Zamościa lub Lublina plus jedno albo dwa wyjazdy po około 2 godziny na konsultacje na miejscu. Jeśli liczba wyjazdów ma być większa, ustalamy to z góry w kosztorysie.
Budżet liczy się jako liczba godzin razy stawka, z podziałem na etapy fakturowane po odbiorze. Widełki na start: konfiguracja bazowa 12–20 h, motyw lub szablon z dopasowaniem 20–40 h, płatności 4–8 h, kurierzy i etykiety 6–12 h, import 500 SKU 2–10 h, integracja ERP 40–120 h, optymalizacja szybkości 10–25 h. Dzięki temu można porównywać oferty na tym samym poziomie szczegółowości.
Tak, przy typowym sklepie całość da się zrobić zdalnie. Jedno lub dwa spotkania na miejscu pomagają jednak przy ustalaniu procesów — kto wystawia faktury, kto obsługuje zwroty, kto odpisuje na maile. Te ustalenia przekładają się bezpośrednio na konfigurację statusów zamówień.
Najlepiej jesienią lub zimą, żeby zdążyć z testami przed sezonem. Wiosną zostaje już tylko czas na poprawki i sprawdzenie wydajności hostingu pod lipcowy szczyt. Wdrożenie zakończone na dwa tygodnie przed sezonem to zbyt mały margines na wykrycie problemów z płatnościami czy wysyłką.
Osobny etap 10–25 godzin ma sens po uruchomieniu sklepu, gdy zbierzesz realne dane o ruchu, a nie na podstawie odczuć. Punktem odniesienia są wskaźniki opisane w dokumentacji Web Vitals oraz w materiałach Google o Core Web Vitals. Warto też pamiętać, że szybkość zależy od hostingu i liczby wtyczek, więc część problemów rozwiązuje się przy okazji konfiguracji, a nie osobnym projektem.
Nie zawsze. Przy małej liczbie zamówień wystarczy ręczne wystawianie faktur i integracja ERP może poczekać. Przy większym wolumenie, kilku kanałach sprzedaży i magazynie integracja za 40–120 godzin zwraca się szybciej niż praca ręczna. Decyzję warto podjąć przed startem, bo wpływa na kolejność etapów.
Jeśli chcesz wiedzieć, ile godzin zajmie Twój sklep i co przygotować przed startem, napisz do nas — odpowiemy widełkami na piśmie, z podziałem na etapy.