Wdrożenie WooCommerce dla firmy z Torunia to nie instalacja wtyczki i wgranie logo. To projekt, w którym trzeba najpierw ustalić zakres, policzyć godziny i rozliczyć każdy etap — od briefu do dnia startu. Poniżej znajdziesz część organizacyjną: typowe błędy, listę kontrolną przed uruchomieniem i odpowiedzi na pytania, które najczęściej dostajemy od właścicieli sklepów. Stronę techniczną zbieramy w hubie WooCommerce, a jeśli dopiero wybierasz platformę, porównaj ją z resztą rynku w sekcji sklepy internetowe. Zakres typowy dla Torunia i kujawsko-pomorskiego opisujemy tutaj: wdrożenia i optymalizacja WooCommerce Toruń.
Instalacja WooCommerce to kilkanaście minut: hosting z WordPressem, wtyczka z repozytorium, kreator konfiguracji, dwie strony — koszyk i zamówienie. Efekt to sklep, który sprzeda pierwszą sztukę i nic więcej.
Wdrożenie dla firmy zaczyna się tam, gdzie kończy się instalacja. Trzeba ustalić siedem obszarów:
| Platforma | Kiedy wygrywa | Na co uważać |
|---|---|---|
| WooCommerce | Firma już na WordPressie, blog i treści eksperckie, nietypowy katalog, kontrola nad kodem | Hosting, aktualizacje i bezpieczeństwo zostają po Twojej stronie |
| PrestaShop | Duży katalog, rozbudowana logika cen i promocji, zespół znający PHP | Więcej pracy przy treściach i SEO, mniejszy ekosystem wtyczek contentowych |
| Shoper | Szybki start, gotowy hosting i wsparcie, brak osoby do serwera | Abonament rośnie z liczbą dodatków, ograniczona ingerencja w kod |
Poniższe liczby traktuj jako punkt odniesienia do weryfikacji ofert, nie jako cennik. Pokazują, czego szukać w wycenie i gdzie pojawiają się braki.
Stawka godzinowa pracowni wdrożeniowej w Polsce to zwykle 120–200 zł netto. Jeśli jedna oferta jest o połowę tańsza od pozostałych, prawie zawsze brakuje w niej elementu z listy kontrolnej — najczęściej migracji, testów płatności albo szkolenia.
Co podnosi koszt najbardziej:
Zakres typowy dla Torunia i kujawsko-pomorskiego, gdzie działa sporo firm produkcyjnych i handlowych, opisujemy tutaj: wdrożenia i optymalizacja WooCommerce Toruń.
Proces, który da się rozliczyć, ma osiem etapów i konkretny efekt po każdym z nich.
Lista kontrolna przed startem:
Role: właściciel decyduje o zakresie i cenach, deweloper odpowiada za kod i konfigurację, księgowość za stawki, numerację i fakturowanie, magazyn za stany i sposób pakowania. Bez tych czterech osób przy jednym stole wdrożenie rozjeżdża się najczęściej na stawkach VAT i strefach wysyłki. Szczegóły techniczne konfiguracji opisuje dokumentacja WooCommerce. Jeśli działasz poza Toruniem, nasze podejście opisaliśmy też dla Bydgoszczy: wdrożenia i optymalizacja WooCommerce dla firmy w Bydgoszczy.
Optymalizację WooCommerce zaczynamy od pomiaru, nie od włączania kolejnej wtyczki cache. Progi, które mają sens: LCP poniżej 2,5 s, TTFB poniżej 600 ms, CLS poniżej 0,1 i INP poniżej 200 ms. Dane laboratoryjne sprawdzisz w PageSpeed Insights, ale o tym, co widzi Google, decydują dane polowe z raportu Core Web Vitals w Search Console — same progi opisuje dokumentacja Web Vitals.
Kolejność działań jest zawsze taka sama — od dołu do góry:
fetchpriority="high" i żadnego lazy loadingu.Baza danych to druga połowa roboty. Produkty i ich metadane siedzą w wp_posts i wp_postmeta. Sprawdź autoload zapytaniem SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes' — wynik powyżej 1 MB spowalnia każdą stronę. Wyczyść przeterminowane transients (wp transient delete --expired), usuń osierocone wiersze wp_postmeta po skasowanych produktach i dodaj indeksy na meta_key dla atrybutów używanych w filtrach. Powyżej 10 000 zamówień włącz HPOS — trzyma zamówienia we własnych tabelach. Wolne zapytania wyłapiesz przez Query Monitor; każde powyżej 50 ms trafia do naprawy. Reszta checklisty jest w naszym hubie wdrożenia i optymalizacja WooCommerce.
| Metryka | Próg | Gdzie mierzyć | Co najczęściej zawodzi |
|---|---|---|---|
| LCP | < 2,5 s | PageSpeed Insights + dane polowe | Obraz hero z lazy loadingiem |
| TTFB | < 600 ms | Search Console, k6 | Brak object cache, tani hosting |
| CLS | < 0,1 | Lighthouse | Brak wymiarów obrazów, banery cookie |
| INP | < 200 ms | CrUX, dane polowe | Ciężkie skrypty filtrów i sliderów |
Zestaw integracji dla firmy sprowadza się do trzech grup: płatności, kurierzy i system magazynowo-księgowy. Każda ma inny koszt utrzymania i inne ryzyko.
Płatności. BLIK to nie bramka, tylko metoda dostępna w Przelewy24, PayU czy Tpay. Realny minimalny zestaw to BLIK, szybki przelew i karta (Stripe albo bramka lokalna). Policz prowizje: przy koszyku 80 zł opłata stała potrafi zjeść więcej marży niż sam procent. Sama integracja to 8–24 godziny pracy plus testy w piaskownicy, obsługa zwrotów i ponowień płatności.
Kurierzy. InPost ShipX, DPD WebAPI, DHL24 — generowanie etykiet z poziomu zamówienia, statusy zwrotne i link do śledzenia w mailu. Najczęstsza pułapka to punkty odbioru: lista paczkomatów wymaga regularnego odświeżania, inaczej klient wybierze nieaktywny punkt.
ERP i magazyn. Subiekt, Comarch Optima, wFirma, często z BaseLinkerem jako pośrednikiem. Synchronizacja stanów co 5–15 minut w obie strony, ceny, dokumenty WZ i faktury. Konieczna idempotencja: po numerze zamówienia, żeby jedno zamówienie nie wpadło do ERP dwa razy.
Własny moduł czy płatna wtyczka. Jeśli gotowa wtyczka pokrywa ok. 80% procesu i ma wsparcie autora — kupuj. Jeśli trzeba trzech obejść i pisania hooków — taniej wyjdzie własny moduł: 40–120 godzin wdrożenia i 2–6 godzin miesięcznie na utrzymanie. Ryzyko własnego kodu to aktualizacje WooCommerce i PHP — bez testów regresji każda większa wersja może zatrzymać zamówienia. Jeśli dopiero wybierasz platformę pod te integracje, porównaj opcje w sekcji sklepy internetowe. Dokumentację techniczną wtyczek znajdziesz w dokumentacji WooCommerce.
| Obszar | Przykłady | Typowy czas wdrożenia | Najczęstsza pułapka |
|---|---|---|---|
| Płatności | Przelewy24, PayU, Stripe, BLIK | 8–24 h | Brak obsługi nieudanych płatności i zwrotów |
| Kurierzy | InPost, DPD, DHL | 8–16 h | Nieaktualna lista punktów odbioru |
| ERP / magazyn | Subiekt, Comarch Optima, BaseLinker, wFirma | 24–80 h | Podwójne zamówienia, rozjazd stanów |
| Własny moduł | procesy nietypowe, B2B, własna logistyka | 40–120 h + 2–6 h/mies. | Brak testów przy aktualizacji WooCommerce |
SEO techniczne w WooCommerce zaczyna się od struktury adresów. Ustaw /kategoria/nazwa-produktu/ i usuń z URL /product/ oraz ?p=123. Produkt z wariantami ma jeden adres i canonical na wersję główną. Widoki filtrowane (?filter_color=, ?orderby=) dostają noindex, follow — inaczej generujesz setki duplikatów i marnujesz budżet indeksowania. Paginację zostaw jako index, follow z self-canonical.
Na karcie produktu wgraj dane strukturalne Product i Offer, a przy realnych opiniach AggregateRating. Breadcrumbs i Organization z adresem w Toruniu domykają całość. Pełną listę obsługiwanych typów znajdziesz w dokumentacji danych strukturalnych Google. Schema bez zgodności z treścią strony to błąd — nie wpisuj ocen, których nie masz.
Lokalnie liczy się spójność NAP: ta sama nazwa firmy, adres i telefon w stopce, w Google Business Profile i w katalogach. Do GBP dodawaj zdjęcia produktów i wpisy o dostawach. Treści pisz pod realne zapytania: dostawa w Toruniu, odbiór osobisty, wysyłka w kujawsko-pomorskim (Bydgoszcz, Włocławek, Grudziądz) — z konkretnymi terminami i kosztami, nie ogólnikami.
Linkowanie wewnętrzne buduj wokół hubów: strona kategorii prowadzi do poradnika, poradnik do karty produktu, a wpisy lokalne do strony usługi. Całą organizację projektu — brief, etapy, odbiór — opisujemy na stronie wdrożenia i optymalizacja WooCommerce Toruń, a wersję dla sąsiedniego rynku w materiale o Bydgoszczy.
| Problem | Rozwiązanie | Gdzie ustawić |
|---|---|---|
| Duplikaty z filtrów | noindex, follow | Wtyczka SEO lub kod w functions.php motywu pochodnego |
| Warianty jako osobne adresy | Canonical na produkt główny | Ustawienia produktu / wtyczka SEO |
| Brak zaufania w SERP | Schema Product + Offer + Breadcrumbs | Szablon produktu, dane strukturalne |
| Słaba widoczność lokalna | Spójny NAP + GBP + treści regionalne | Stopka, GBP, strony dostawy |
Dzień startu to dopiero początek. W pierwszych 30 dniach wychodzą rzeczy, których nie widać na stagingu: skok ruchu z kampanii, błąd bramki płatności, aktualizacja wtyczki psująca szablon. Dlatego zakres opieki ustalamy w umowie razem z wdrożeniem — organizacja wdrożenia WooCommerce w Toruniu obejmuje również ten etap.
Backup w modelu 3-2-1. Trzy kopie danych, dwa różne nośniki, jedna poza serwerem produkcyjnym. W praktyce: zrzut bazy co 6–12 godzin, zrzut plików raz na dobę, oba wypychane do zewnętrznego storage (S3, Backblaze, macierz poza serwerownią sklepu). Raz na kwartał robimy test odtworzenia na stagingu. Kopia, której nie odtworzyłeś, nie jest kopią — to plik zajmujący miejsce.
Staging i okno serwisowe. Aktualizacje idą najpierw na kopię środowiska produkcyjnego — ta sama wersja PHP, ta sama baza, ten sam motyw. Na produkcji wdrażamy je w oknie serwisowym, np. wtorek 2:00–4:00, poza szczytem zamówień, po zapisaniu punktu przywrócenia i z wyczyszczonym cache po zmianie.
Dostęp. WAF przed sklepem (Cloudflare albo reguły OWASP na serwerze), 2FA dla każdego konta administratora, limit prób logowania, wyłączony XML-RPC i edytor plików w panelu. Konta zakładamy imiennie — wspólne konto „admin” to brak informacji, kto zmienił cenę albo metodę wysyłki.
SLA i monitoring. Czas reakcji 4/8/24 h zależnie od pakietu, monitoring 24/7 (dostępność, certyfikat SSL, błędy 5xx, czas odpowiedzi), raport miesięczny: co zaktualizowano, jakie były incydenty, czasy reakcji, wynik testu kopii. Typowe koszty utrzymania sklepu WooCommerce w Polsce to 300–1500 zł/mies. netto, zależnie od zakresu:
| Pakiet | Czas reakcji | Co zawiera | Koszt miesięczny (netto) |
|---|---|---|---|
| Podstawowy | 24 h | kopie 3-2-1, aktualizacje 1×/mies., monitoring dostępności | 300–500 zł |
| Standard | 8 h | jak wyżej + staging, WAF, 2FA, raport miesięczny | 600–900 zł |
| Rozszerzony | 4 h | + aktualizacje 2×/mies., test odtworzenia kopii co kwartał, dyżur 24/7 | 1000–1500 zł |
Większość problemów ze sklepem nie bierze się z kodu, tylko z decyzji podjętych przy wdrożeniu. Cztery pułapki zdarzają się najczęściej — poniżej objawy i narzędzia, którymi je złapiesz, zanim zobaczy je klient.
Przeciążony hosting. Sklep na hostingu współdzielonym z limitem 1 vCPU i 512 MB RAM, PHP 7.4 bez OPcache i Redis. Objaw: TTFB powyżej 1,2 s na stronie kategorii, koszyk ładuje się 3–4 s. Wykrycie: Query Monitor pokazuje liczbę zapytań do bazy (powyżej 200 na stronę to sygnał ostrzegawczy) i zapytania dłuższe niż 0,5 s; w logach PHP szukasz wpisów „Allowed memory size exhausted”.
Konflikt wtyczek. Dwie wtyczki od cache, dwie od wysyłki, trzy dopisujące się do koszyka. Objaw: biały ekran, błąd 500, znikające pola formularza zamówienia. Wykrycie: włącz WP_DEBUG i WP_DEBUG_LOG w wp-config.php, czytaj wp-content/debug.log, potem metoda połowienia — wyłączasz połowę wtyczek, sprawdzasz, zawężasz zakres.
Brak stagingu. Testowanie na żywych zamówieniach. Jeśli wykonawca przed startem nie potrafi podać adresu środowiska testowego, to nie ma stagingu.
Migracja bez mapowania URL. Stary sklep miał /produkt/nazwa, nowy ma /produkt/nazwa-produktu i 40% wejść z Google ląduje na 404. Potrzebna mapa 1:1 i przekierowania 301 na poziomie serwera. Przy migracji z PrestaShop lub Shopera przenosisz też zdjęcia (nazwy plików, atrybuty ALT, waga), zamówienia (jako archiwum ze statusami) i klientów — hasła nie migrują, więc każdy dostaje mail z resetem.
Lighthouse uruchom po wyłączeniu cache wtyczki i na stagingu z danymi produkcyjnymi; progi Core Web Vitals opisuje dokumentacja web.dev. Na koniec test zamówienia od A do Z: dodanie do koszyka, kupon, płatność, mail potwierdzający, faktura, zmiana statusu, zwrot. Cały cykl przechodzisz sam, nie tylko wykonawca. Szczegóły konfiguracji znajdziesz w materiałach o wdrożeniach i optymalizacji WooCommerce.
| Pułapka | Typowy objaw | Czym to wykryć |
|---|---|---|
| Przeciążony hosting | TTFB > 1,2 s, wolny koszyk | Query Monitor, logi PHP |
| Konflikt wtyczek | błąd 500, znikające pola w koszyku | WP_DEBUG_LOG, metoda połowienia |
| Brak stagingu | błędy widoczne dopiero u klientów | brak adresu staging przed startem |
| Migracja bez mapy URL | spadek ruchu, dziesiątki 404 | Search Console, mapa przekierowań 301 |
Zapytaj o trzy rzeczy, zanim podpiszesz cokolwiek: kto koduje, jak liczysz godziny i co robisz po starcie.
Kto realnie pracuje. Jeśli agencja sprzedaje, a wdrożenie robi podwykonawca, ustal, z kim masz kontakt i kto odpowiada za błędy. Poproś o nazwiska osób przy projekcie i dwa–trzy sklepy, które nadal działają. Lista 30 logotypów nic nie wnosi, jeśli żadnego z tych sklepów nie da się dziś otworzyć.
Widełki godzinowe. Konkretna stawka (rynek to zwykle 120–250 zł/h netto zależnie od specjalizacji) i lista zadań z szacunkiem godzin. „Sklep od 3000 zł” bez zakresu oznacza, że integracja z Subiektem, kurierem albo ERP będzie „dodatkiem płatnym”. Poproś też o to, ile godzin przewidziano na migrację treści — to najczęściej zaniżana pozycja.
Co po wdrożeniu. Czas reakcji w SLA, monitoring, kopie zapasowe, mapa przekierowań, dokumentacja konfiguracji, dostępy do serwera, repozytorium i paneli. Zapytaj, ile kosztuje godzina pracy po zakończeniu projektu — brak tej stawki w umowie to pułapka na przyszłość.
Czerwone flagi:
Model pracy z Torunia. Realnie 90% projektu da się zrobić zdalnie: brief na wideorozmowie, wspólna tablica zadań, staging do klikania i komentarzy. Spotkania na miejscu mają sens przy warsztacie zakresu na starcie i przy odbiorze. Do bieżących poprawek dojazd zwykle nie wnosi nic poza kosztem. Inaczej jest przy konfiguracji kasy fiskalnej, integracji z systemem magazynowym czy szkoleniu zespołu z obsługi zamówień — wtedy godzina na miejscu bywa szybsza niż 30 minut tłumaczenia na czacie. Jeśli dopiero porównujesz platformy, zacznij od przeglądu rozwiązań sklepowych.
Start prac bez briefu — zamiast zakresu funkcji kupowana jest lista wtyczek „na zapas”.
Jak wykryć: Policz wtyczki przy starcie i po pierwszym tygodniu. Jeśli lista rośnie, a nikt nie umie powiedzieć, która wtyczka realizuje którą funkcję, briefu nie było.
Jak naprawić: Spisz zakres: role użytkowników, płatności, kurierzy, podatki, dokumenty sprzedaży. Każda wtyczka ma mieć przypisany powód instalacji i osobę odpowiedzialną. Wtyczki bez właściciela wypadają z projektu.
Prace prowadzone bezpośrednio na produkcji, bez środowiska staging.
Jak wykryć: Zapytaj o adres testowy oddzielony od sklepu i zabezpieczony hasłem. Jeśli wszystkie zmiany lądują od razu na domenie głównej, stagingu nie ma.
Jak naprawić: Wydziel kopię sklepu na osobnym hostingu lub subdomenie, wdrażaj tam zmiany i przenoś na produkcję dopiero po testach akceptacyjnych z Twoim udziałem.
Migracja tylko produktów — bez zamówień, klientów i przekierowań starych adresów URL.
Jak wykryć: Przed startem pobierz listę adresów z Google Search Console. Po migracji sprawdź, czy stare adresy zwracają 301, a nie 404.
Jak naprawić: Przygotuj mapę 301 (stary URL → nowy URL), przenieś klientów i zamówienia, jeśli mają być widoczne w panelu, i wyślij aktualną sitemap do Search Console.
Płatności testowane wyłącznie w trybie sandbox, bez realnej transakcji na produkcji.
Jak wykryć: Poproś o zrzut ekranu z realnej płatności oraz z jej zwrotu, wykonanych po przełączeniu bramki w tryb produkcyjny.
Jak naprawić: Test końcowy: jedna transakcja na 1 zł, zwrot częściowy i pełny, sprawdzenie e-maila potwierdzającego i faktury wystawionej automatycznie.
Brak pomiaru wydajności przed wdrożeniem, więc nie ma do czego porównać efektów optymalizacji.
Jak wykryć: Jeśli wykonawca nie pokazał wyników LCP i TTFB sprzed startu prac, każda późniejsza deklaracja „przyspieszyliśmy” jest niesprawdzalna.
Jak naprawić: Zmierz LCP, TTFB i CLS przed i po, zapisz wyniki z datą i miejscem pomiaru. Uczciwe porównanie to te same narzędzia i ten sam typ urządzenia.
RODO i księgowość uregulowane na końcu projektu, tuż przed startem.
Jak wykryć: Sprawdź, czy istnieje umowa powierzenia przetwarzania danych z hostingiem i wykonawcą, polityka prywatności oraz zgody przy zapisie do newslettera.
Jak naprawić: Zamknij temat dokumentów w trakcie konfiguracji, a nie w dniu startu. Ustal też z księgowością, jakim kanałem będą trafiać faktury i eksporty sprzedaży.
Wdrożenie WooCommerce dla firmy z Torunia rozlicza się godzinami i etapami, nie deklaracjami o „nowoczesnym sklepie”. Mały projekt to 40–80 godzin i 8–18 tys. zł, średni z integracjami 120–250 godzin i 25–60 tys. zł — a każda pozycja powinna mieć punkt akceptacji. Najczęstsze problemy nie wynikają z kodu, tylko z braku briefu, stagingu, pomiaru wydajności i przekierowań 301. Jeśli wykonawca nie chce pokazać tych czterech rzeczy na piśmie, szukaj dalej.
W praktyce rozliczamy to w godzinach, nie w tygodniach kalendarza. Mały sklep to zwykle 40–80 godzin, średni z integracjami 120–250 godzin, a projekt B2B z ERP i logiką cenową 250–500 godzin i więcej. Przy pracy częściowo równoległej mały sklep domyka się w 3–5 tygodni, średni w 2–4 miesiące.
Orientacyjne widełki to 8–18 tys. zł za mały sklep i 25–60 tys. zł za średni z integracjami płatności, kurierów i magazynu. Cena rośnie przy migracji z innej platformy, imporcie dużej bazy produktów, wielojęzyczności i modułach pisanych na zamówienie. Traktuj te liczby jako punkt odniesienia do weryfikacji ofert, a nie jako cennik.
Wtedy, gdy potrzebujesz nietypowej logiki: ceny zależne od kontrahenta, integracja z Subiektem lub Optimą, treści sprzedażowe obok sklepu albo rozbudowany blog. Shoper wygrywa, gdy chcesz gotowy sklep bez zaplecza technicznego i nie planujesz niestandardowych integracji. PrestaShop ma sens, jeśli już na nim pracujesz i nie chcesz migrować. Wybór platformy opisujemy szerzej w sekcji sklepy internetowe.
Tak, ale migracja to zwykle najdroższa pozycja w projekcie. Przenosimy produkty, zdjęcia, kategorie, klientów i zamówienia, a przede wszystkim przekierowania 301 ze starych adresów. Bez mapy przekierowań tracisz pozycje wypracowane w Google — i najczęściej to kosztuje więcej niż samo przeniesienie danych.
Na start przy kilkudziesięciu zamówieniach miesięcznie często wystarczy dobry hosting z PHP 8.2 lub nowszym. Przy sklepie z tysiącami produktów i ruchem z reklam potrzebny jest VPS albo hosting dedykowany dla WooCommerce, z Redis lub Memcached i CDN przed domeną. Tanie współdzielone serwery zapychają się na bazie danych i wtedy rośnie TTFB, a spada konwersja.
Wdrożenie nie kończy się w dniu uruchomienia. Potrzebne są aktualizacje w oknie serwisowym, staging do ich testowania, monitoring dostępności, kopie zapasowe i raport miesięczny. Koszt utrzymania w rozsądnym zakresie to 300–1500 zł miesięcznie, zależnie od liczby integracji i tego, jak szybko ma reagować wykonawca. Czas reakcji ustalasz w SLA — typowo 4, 8 albo 24 godziny.
Cztery role: właściciel lub osoba decyzyjna, która zatwierdza zakres i wygląd, deweloper po stronie wykonawcy, księgowość przy podatkach i fakturach oraz magazyn przy stanach i wysyłce. Brak choćby jednej z tych osób na etapie ustaleń kończy się poprawkami po starcie, które kosztują więcej niż zaplanowanie ich wcześniej. Po drugiej stronie domeny opisujemy to samo podejście m.in. dla Bydgoszczy.
Jeśli chcesz porównać swoją sytuację z typowym zakresem wdrożenia, napisz do nas — powiemy wprost, ile godzin realnie potrzebujesz i czego nie ma sensu robić w pierwszej kolejności. Możesz też zacząć od przeglądu naszego podejścia do WooCommerce.