Czym jest sklep internetowy WooCommerce i kiedy ma sens w Warszawie

WooCommerce to wtyczka do WordPressa, a nie osobna platforma SaaS. Praktyczna konsekwencja: pliki, baza danych i kod siedzą na hostingu, który wybierasz, w repozytorium Git, które kontrolujesz. Nie płacisz abonamentu platformy ani prowizji od obrotu. Płacisz za hosting, domenę, wtyczki premium i pracę wdrożeniową.

To nie znaczy, że WooCommerce pasuje każdemu. Poniżej szczere kryteria decyzyjne.

Kryterium	WooCommerce	Shopify	Sky-Shop	PrestaShop
Model	Wtyczka + WordPress na własnym hostingu	SaaS, abonament	SaaS z polskim wsparciem	Open source, własny hosting
Prawo własności kodu	Pełne — kod u Ciebie	Kod u dostawcy, motyw z ograniczeniami	Brak dostępu do kodu	Pełne
Koszt stały	Hosting + wtyczki	Abonament rosnący z obrotem	Abonament	Hosting + płatne moduły
Integracje ERP/CRM	Przez API i wtyczki — wymaga pracy	Przez aplikacje, ograniczone	Gotowe konektory PL	Moduły, często płatne

Typowe profile, w których WooCommerce wygrywa: B2B z cennikami grupowymi i limitami kredytowymi (hurtownie, dystrybutorzy), D2C z katalogiem 200–5000 SKU, sklepy migrujące ze starej platformy, gdzie trzeba przenieść historię zamówień i klientów bez utraty pozycji w Google.

Kiedy WooCommerce przestaje wystarczać: katalog 50 000+ SKU (produkty trzymane w tabelach postmeta zaczynają mulic panel admina i wyszukiwarkę), wielojęzyczność na 5 rynkach z osobnymi cennikami i podatkami, nietypowa logika magazynowa (rezerwacje, partie, współdzielone stany między kanałami). Wtedy taniej wychodzi platforma z tym wbudowanym.

Siedziba firmy nie musi być w Warszawie — pracujemy zdalnie na wspólnym środowisku staging i w Git. Zasady organizacji wdrożenia opisaliśmy też przy okazji projektu sklepu WooCommerce w Łodzi; różni się miasto, nie metodyka. Dokumentację wtyczki znajdziesz w oficjalnej dokumentacji WooCommerce.

Ile trwa i ile kosztuje wdrożenie WooCommerce — realne widełki

Wycena bez inwentaryzacji wtyczek i zakresu integracji jest wróżeniem z fusów. Poniżej liczby z projektów, które prowadziliśmy — traktuj je jako punkt odniesienia, nie ofertę.

Typ wdrożenia	Zakres	Godziny	Koszt przy 120–220 zł/h
Podstawowy	Motyw, płatności, wysyłka, 1–2 integracje, do 300 SKU	60–120 h	7 200–26 400 zł
Średni z integracjami	ERP/CRM, kurierzy, faktury, katalog 300–3000 SKU	150–300 h	18 000–66 000 zł
Rozbudowany B2B	Cenniki grupowe, limity, multi-store, migracja	350–600 h	42 000–132 000 zł

Stawka zależy od typu pracy: konfiguracja wtyczek i motywu 120–150 zł/h, moduł pisany pod Ciebie 180–220 zł/h, migracja i czyszczenie danych 150–200 zł/h. Mieszanie tego w jedną stawkę ukrywa, gdzie naprawdę idzie budżet.

Podział budżetu na typowym projekcie: konfiguracja 40%, integracje 30%, treści i migracja 20%, testy 10%. Jeśli testy schodzą do 2%, pierwsze zamówienie od klienta zwykle ujawnia błędy w koszyku i płatnościach.

Co realnie podnosi koszt: import z niestandardowymi SKU (warianty, jednostki miary, znaki w kodach), multi-store z osobnymi magazynami, indywidualne moduły (konfigurator, kalkulator dostawy), współdzielone stany magazynowe między kanałami sprzedaży.

Dlaczego ryczałt „z sufitu” kończy się dopłatami? Bo wykonawca nie wie, ile wtyczek jest w projekcie, czy stara baza ma duplikaty klientów i czy ERP przyjmuje zamówienia przez API, czy przez plik CSV. Wycena po godzinach z rejestrem prac działa inaczej: dostajesz tygodniowy raport godzin, a gdy zakres rośnie, widać to przed fakturą, nie po. Integracje to zwykle najdroższy element — przykład rozpisaliśmy w tekście o tym, jak zintegrować sklep internetowy z CRM.

Hosting, VPS i infrastruktura pod sklep WooCommerce

Najczęstsza przyczyna „wolnego sklepu” to nie motyw ani wtyczki, tylko hosting bez zapasu mocy. Minimum techniczne w 2025 roku: PHP 8.2 lub nowsze, MySQL 8 albo MariaDB 10.6+, OPcache włączony, HTTP/2 lub HTTP/3.

Skala	Infrastruktura	Parametry
do ~300 SKU, do 10 000 wizyt/mies.	Hosting współdzielony	PHP 8.2+, 2 vCPU, 2–4 GB RAM, NVMe SSD
10 000–50 000 wizyt/mies.	VPS lub hosting managed pod WooCommerce	4 vCPU, 8 GB RAM, Redis, osobna baza
50 000+ wizyt, B2B, multi-store	Serwer dedykowany lub managed z SLA	8 vCPU, 16 GB RAM+, oddzielny serwer bazy

Cache musi być selektywny. LiteSpeed Cache albo WP Rocket na warstwie stron, Redis Object Cache na warstwie obiektów (plik object-cache.php w wp-content). Kluczowe są wykluczenia: /koszyk, /checkout, /moje-konto oraz cart-fragments.js muszą omijać cache. Zle cachowane fragmenty koszyka to klasyczne źródło zgłoszeń typu „koszyk sklep internetowy nie działa” — klient widzi pusty koszyk mimo dodanych produktów. Nonce przy cache to ten sam problem w innej odsłonie.

Backupy w modelu 3-2-1: trzy kopie, dwa nośniki, jedna poza serwerem. Retencja minimum 30 dni. Ważniejsze niż sama kopia jest odtworzenie — testuj je raz na kwartał na stagingu i zmierz czas do przywrócenia sklepu. Kopia, której nikt nie odtworzył, nie jest kopią, tylko plikiem.

Serwer w UE upraszcza RODO: dane osobowe nie wyjeżdżają poza EOG. Podpisz umowę powierzenia z hostingiem, prowadź rejestr czynności przetwarzania i zapisz, gdzie trzymasz logi oraz backupy. Gdy hosting dławi sklep, ratunek bywa pilny — opisujemy to w artykule o tym, co zrobić, gdy hosting blokuje ruch. Parametry, które Google bierze pod uwagę przy szybkości, zebrano w dokumentacji Web Vitals.

Płatności i kurierzy — konfiguracja, która nie gubi zamówień

Największa część porzuconych koszyków i reklamacji nie wynika z ceny, tylko z tego, że klient zapłacił, a sklep nie wie, że ma zamówienie. Status „pending” po udanej płatności to klasyka konfiguracji, nie błąd WooCommerce. Najczęstsza przyczyna: bramka nie ma ustawionego webhooka albo webhook wraca na adres, który przestał działać po wyłączeniu trybu testowego. Sprawdź w panelu operatora dwa adresy — URL powrotu klienta i URL webhooka — a potem zrób realny test: jedno zamówienie za 1 zł na każdej bramce i każdej metodzie wysyłki, na produkcji, nie na stagingu. Po teście zwróć środki i sprawdź, czy zwrot poprawnie zmienił status i czy stan magazynowy wrócił. Jeśli po zapłacie nic się nie zapisuje, opisujemy to w tekście sklep internetowy nie zapisuje zamówień — warto przejść tę listę przed startem, nie po pierwszej reklamacji.

Porównując Przelewy24, PayU, Autopay i Stripe, nie opieraj się na stawkach z blogów sprzed dwóch lat. Prowizje są negocjowane i zależą od obrotu, struktury transakcji i tego, kto ponosi koszt zwrotu. BLIK-a nie wdraża się „bezpośrednio” — obsługuje go operator płatności, więc pytanie brzmi: u kogo masz BLIK i ile to kosztuje w pakiecie. Zapytaj dostawcę o cztery rzeczy: czas księgowania i wypłaty środków, koszt zwrotu i chargebacku, sposób informowania o zmianach w API oraz to, czy webhook jest ponawiany, gdy serwer nie odpowie. Ostatni punkt decyduje o tym, czy zamówienia z nocy nie zostaną na „pending” do rana.

• Wysyłka: InPost ShipX, DPD i DHL udostępniają API do generowania etykiet. Bez tego pakowanie zamówień ręcznie zjada godziny dziennie i generuje pomyłki w numerach nadania.
• Mapy paczkomatów i punktów odbioru w Warszawie wstawiaj jako widget operatora (np. Geowidget InPost), nie jako własną listę — punkty zmieniają się co tydzień.
• Reguły kosztów: waga gabarytowa, a nie rzeczywista, próg darmowej dostawy, metoda warunkowa po kodzie pocztowym (np. dostawa tego samego dnia tylko dla wybranych dzielnic), dopłata za pobranie.
• Nie zostawiaj wszystkich metod wysyłki „włączonych wszędzie”. Dla 20-kilogramowej pralki i koperty z akcesorium to dwie różne umowy z kurierem.

Integracje z ERP, CRM i magazynem — jak nie doprowadzić do oversellingu

Overselling prawie nigdy nie wynika z awarii. Wynika z dwóch rzeczy: dwóch kanałów sprzedaży patrzących na ten sam stan magazynowy i synchronizacji, która „zaraz się wykona”. Zanim wybierzesz wtyczkę, ustal jedno: co jest źródłem prawdy. W praktyce działa to tak — katalog, ceny, stany i faktury wychodzą z systemu ERP (Subiekt GT/nexo, Comarch Optima, WF-Mag, wFirma) do sklepu, a zamówienia, dane klientów i płatności idą ze sklepu do ERP. Odwrotny kierunek dla stanów kończy się tym, że magazyn i strona pokazują dwie różne liczby.

Synchronizacja co 5–15 minut przez cron wystarcza w większości sklepów z jednym kanałem sprzedaży. Real-time i rezerwacja stanu w bazie są potrzebne w dwóch sytuacjach: gdy te same sztuki sprzedajesz równolegle na Allegro lub w sklepie stacjonarnym, albo gdy produkt występuje w pojedynczych egzemplarzach. Wtedy zamówienie powinno blokować dostępną ilość na 15–30 minut, a po tym czasie rezerwacja wygasa. Bez tego dwie osoby kupią ostatnią sztukę w odstępie dwóch minut.

• SKU to klucz mapowania. Jeśli ERP ma inne kody niż dotychczasowy sklep, przygotuj przed importem tabelę: sklep_sku, erp_sku, jednostka, stawka VAT. Kod z ERP trzymaj w polu meta produktu, nie nadpisuj SKU sklepowego.
• Po pierwszym zamówieniu nie zmieniaj SKU. Rozjedzie ci się historia zamówień i zwrotów.
• Kolejność wdrożenia: katalog → stany → zamówienia → faktury → księgowość. Nigdy odwrotnie. Jeśli zaczniesz od faktur, będziesz integrował dokumenty z katalogiem, który jeszcze się nie zgadza.
• Zanim ruszysz z ERP, przejdź przez temat integracji sklepu internetowego z CRM — kolejność jest ta sama, zmienia się tylko zakres danych.

SEO techniczne i szybkość sklepu przed startem

Szybkość to część wdrożenia, nie dodatek na później. Progi, które warto wpisać do umowy z wykonawcą, są znane: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — mierzone na mobile, dla 75. percentyla ruchu. Wartości i sposób pomiaru opisuje dokumentacja web.dev – Core Web Vitals. Zanim cokolwiek zmigrujesz, ustal strukturę URL produktów i kategorii. Raz na zawsze: albo /kategoria/nazwa-produktu/, albo /nazwa-produktu/. Bez identyfikatora produktu w adresie, bez /?p=1234. Zmiana struktury po imporcie 3000 produktów to praca podwójna — import plus mapowanie przekierowań.

Przekierowania 301 przygotuj na dzień przed przełączeniem domeny. Każdy stary adres, również strony paginacji i adresy z filtrami, które zdążyły się zaindeksować. Dane strukturalne: Product, Offer, Organization i BreadcrumbList. Uwaga na najczęstszą pułapkę — wtyczka SEO, motyw i dodatkowa wtyczka potrafią wygenerować trzy znaczniki Product na jednej stronie. Sprawdź to testerem wyników Rich Results przed startem i wyłącz nadmiarowe źródła.

• Sitemap, plik robots.txt i podłączenie Google Search Console w dniu startu. Nie blokuj w robots.txt katalogu /wp-content/uploads/ ani plików CSS i JS.
• Monitoruj błędy indeksowania: 404, „Wykryte, ale obecnie nie zaindeksowane”, adresy z parametrami filtrów.
• Obrazy: WebP lub AVIF, wymiary w atrybutach width/height zamiast skalowania w CSS, lazy loading tylko poniżej pierwszego ekranu. Obraz LCP nigdy nie może być leniwie ładowany.
• Po migracji sprawdź, czy serwer nie dławi ruchu — typowy scenariusz opisujemy w tekście hosting blokuje ruch w sklepie internetowym.

Lista kontrolna przed uruchomieniem sklepu (pre-launch)

Checklistę przechodzimy na stagingu, na kopii bazy z produkcji, i powtarzamy po każdej zmianie wtyczki płatności lub szablonu. Emulator nie wystarczy — testuj na iPhonie z Safari, telefonie z Androidem i Chrome oraz na desktopie w Chrome, Firefoxie i Safari.

• Koszyk i checkout. Dodaj produkt z wariantem, zmień ilość, wpisz kod rabatowy. Zamknij przeglądarkę, odczekaj 30 minut i wróć — koszyk powinien odtworzyć się z sesji. Powtórz to samo na telefonie w trybie prywatnym. Sprawdź zamówienie jako gość i jako zalogowany klient, płatność w trybie sandbox (BLIK, Przelewy24, karta), anulowanie płatności i ponowne wejście na checkout. Gdy pozycje zaczynają ginąć, sięgnij po procedurę opisaną w tekście o tym, co zrobić, gdy koszyk w sklepie przestaje działać.
• Maile transakcyjne. Wyślij i odbierz cztery wiadomości: potwierdzenie zamówienia, zmianę statusu (w realizacji, wysłane), fakturę z PDF oraz reset hasła. Odbierz je na Gmailu, Outlooku, Onecie, WP.pl i Interii — razem z folderem spam. Jeśli coś tam trafia, brakuje SPF, DKIM i DMARC; WP Mail SMTP plus poprawny rekord DMARC załatwia większość przypadków.
• Wydajność na kopii bazy. Odpal k6, loader.io albo ab ze 100 równoległymi użytkownikami na 5–10 minut. Kryterium odbioru: zero błędów 502 i 504, dodanie do koszyka poniżej 2 s w 95. percentylu. Punkt odniesienia trzymamy z materiału o Web Vitals.
• Podatki i waluty w B2B. Zrób zamówienie na koncie hurtowym z indywidualnym cennikiem: sprawdź VAT (0% przy WDT, reverse charge przy NIP UE), kwotę netto i brutto na fakturze oraz przeliczenie waluty, jeśli sprzedajesz w EUR.

Test, o którym zapomina większość zespołów: wyłącz wtyczkę płatności i zobacz, co widzi klient. Gdy po zmianach w checkoucie sklep przestaje zapisywać zamówienia, pomaga procedura z tekstu o tym, że sklep internetowy nie zapisuje zamówień. Cała lista zajmuje 4–6 godzin i warto ją powtarzać przed każdą większą aktualizacją.

Po starcie: opieka techniczna, SLA i realne koszty utrzymania

Wdrożenie kończy się w dniu, w którym sklep zaczyna zarabiać. Standardowy pakiet opieki obejmuje: aktualizacje WordPressa, WooCommerce i wtyczek testowane najpierw na stagingu (świeża kopia produkcji), monitoring dostępności 24/7 z sondą co minutę i alertem SMS, backup bazy codziennie i plików co tydzień, retencję 30 dni poza serwerem oraz hotfixy w ramach SLA. Raz na kwartał odtwórz backup na serwerze testowym — kopia, której nigdy nie odtwarzałeś, nie jest kopią.

SLA w praktyce: reakcja 1–4 h w godzinach pracy (9:00–17:00), 2–8 h poza nimi, naprawa krytycznej awarii do 24 h. Zapytaj wykonawcę, co uznaje za krytyczne: brak możliwości złożenia zamówienia, błąd 500 na checkoucie, brak dostępu do panelu, martwa bramka płatności. Zmiana numeru telefonu w stopce krytyczna nie jest.

Najczęstsze błędy przy wdrożeniach w Warszawie i jak ich uniknąć

Większość problemów, które widzimy w projektach warszawskich, nie wynika z kodu, tylko z kolejności decyzji.

• Start z pełnym katalogiem zamiast pilotażu. Klient wrzuca 3000 SKU w 40 kategoriach przed pierwszym testem. Efekt: trzy miesiące pracy nad importem i zdjęciami, a błąd w checkoucie wychodzi dopiero po starcie. Zasada jest prostsza: 20–50 SKU, jedna kategoria, prawdziwi klienci przez 2–3 tygodnie, potem import reszty partiami po 500 pozycji.
• Dokładanie płatnych wtyczek zamiast jednego modułu. Dwanaście wtyczek (formularz, odzyskiwanie koszyka, faktury, lojalność, CRM) to 200–400 zł miesięcznie licencji i tyle samo punktów, w których aktualizacja może coś zepsuć. Lepiej jeden moduł robiący porządek w danych — sprawdź, jak wygląda integracja sklepu internetowego z CRM, zanim dokupisz kolejny plugin.
• Brak osoby decyzyjnej po stronie klienta. Każda zmiana czeka tydzień na akceptację komitetu. Ustal jedną osobę z prawem weta, okno decyzji 24 h i listę zmian wysyłaną dwa razy w tygodniu.
• Migracja bez planu 301 i bez zrzutu starej bazy. Potrzebna jest mapa URL 1:1 (kategorie, produkty, wpisy blogowe), reguły w .htaccess lub Nginx oraz zrzut starej bazy i plików z datą. Dostęp do starego hostingu zostaw na minimum 90 dni. Bez przekierowań spadek ruchu organicznego zobaczysz w Search Console w ciągu 2–4 tygodni.
• Rezygnacja z testów obciążeniowych przed kampanią. Black Friday weryfikuje wszystko. Test 2–3 tygodnie przed kampanią: 100–300 równoległych użytkowników przez 10–15 minut, z koszykiem, checkoutem i wyszukiwarką. Jeśli serwer pada przy setce, przy kampanii nie ma czego ratować.

Ten sam schemat stosujemy przy organizacji wdrożenia sklepu WooCommerce w Łodzi i zdalnie — różni się tylko lista integracji, nie kolejność działań.

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

Lista kontrolna do odklikania

• Inwentarz wtyczek z licencjami — Zrób to przed wyceną. Zwróć uwagę na wtyczki bez aktualizacji od 12 miesięcy, wygasłe licencje i duplikaty funkcji (np. trzy wtyczki do pól dodatkowych).
• Liczba SKU, wariantów i atrybutów — Eksport z obecnego sklepu albo plik od klienta. Ustal osobno: liczbę produktów prostych, liczbę wariantowych i maksymalną liczbę wariantów w jednym produkcie.
• Wypisane bramki płatności i każdego kuriera osobno — Sprawdź przy każdej metodzie, czy ma własną obsługę webhooków i mapowanie statusów. Bramka bez webhooka to zamówienia zostające na statusie pending.
• Środowisko staging — Adres z noindex i zabezpieczeniem hasłem, kopia bazy nie starsza niż tydzień. Sprawdź, czy staging nie wysyła prawdziwych maili do klientów.
• Dostęp klienta do repozytorium Git — Konto klienta jako właściciel organizacji, nie tylko zaproszony członek zespołu wykonawcy. Zweryfikuj to logując się na własne konto.
• Kopia zapasowa przed pierwszym wdrożeniem — Pliki i baza poza serwerem. Raz na kwartał odtwórz kopię na środowisku testowym — sam fakt, że plik istnieje, niczego nie dowodzi.
• Wersje PHP i bazy danych — PHP 8.2 lub nowsze, MySQL 8 albo MariaDB 10.6+. Sprawdź w panelu hostingu albo na staging przez plik z informacją o konfiguracji.
• Cache wyklucza koszyk i checkout — Test: dodaj produkt, wejdź do koszyka i odśwież stronę trzy razy. Zawartość koszyka i ceny nie mogą się zmieniać między odświeżeniami.
• Test transakcji na 1 zł dla każdej bramki i metody wysyłki — Wykonaj na produkcji przed startem. Osobno BLIK, osobno karta, osobno przelew — każda kombinacja płatność plus wysyłka.
• Dokumenty prawne i RODO — Regulamin, polityka prywatności, informacja o administratorze danych. Ustal, na jakim serwerze stoją dane i wpisz to do rejestru czynności przetwarzania.
• Ścieżka zamówienia do księgowości lub ERP — Sprawdź, czy zmiana statusu na zrealizowane uruchamia eksport i czy zwroty oraz korekty są w tej ścieżce obsłużone.
• Plan na 30 dni po starcie — Ustal, kto reaguje na błędy, w jakim czasie i na jakim kanale. Zapisz to przed uruchomieniem, nie po pierwszej awarii.

Najczęściej zadawane pytania

Źródła i materiały

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