Co obejmuje wdrożenie WooCommerce w Lublinie — i czym różni się od instalacji wtyczki

Wtyczka WooCommerce instaluje się w 2–4 godziny. Po tym czasie sklep „technicznie działa”, ale nie jest gotowy do sprzedaży. Wdrożenie produkcyjne to 7 obszarów, z których każdy ma własne pułapki i własny budżet.

• Hosting / VPS — dobór środowiska, PHP 8.3, MySQL 8, OPcache, cron systemowy, staging, kopie zapasowe.
• Instalacja i konfiguracja WordPress — role użytkowników, WP-CLI, wyłączenie nieużywanych funkcji, polityka aktualizacji, limit prób logowania i 2FA.
• Motyw i szablon — motyw komercyjny czy własny, motyw potomny, szablony strony głównej, karty produktu, koszyka i checkoutu (wersja blokowa).
• Struktura katalogu i kategorii — drzewo kategorii, atrybuty i warianty, filtry, produkty powiązane, adresy URL.
• Płatności — Przelewy24, PayU, Autopay, BLIK, karty, pobranie, webhooki i statusy zamówień.
• Integracje kurierskie — InPost, DPD, DHL, generowanie etykiet, mapy punktów, reguły wysyłki i progi darmowej dostawy.
• Podatki i fakturowanie — stawki VAT, OSS, numeracja dokumentów, połączenie z programem księgowym (Fakturownia, wFirma, Subiekt).

Różnica w godzinach jest duża i warto ją znać, zanim usłyszysz pierwszą wycenę.

Ile realnie trwa i ile kosztuje wdrożenie WooCommerce — widełki na 2025 rok

Widełki są zbliżone u większości wykonawców, bo różnice wynikają z zakresu, nie z widzimisię. Prosty sklep do 300 SKU z gotowym motywem i dwiema płatnościami to 40–60 godzin. Sklep średni, 300–3000 SKU, z importem danych i integracjami — 80–140 godzin. Rozbudowany B2B z cennikami klienta, limitami, ERP i wieloma językami — 150 godzin i więcej. Do tego dochodzi stawka godzinowa: na rynku spotyka się przedziały 100–250 zł netto za godzinę. Sprawdź ją w konkretnej ofercie — to ona, a nie liczba godzin w prezentacji, decyduje o fakturze.

Cennik „z sufitu” nie jest zły, ale zawiera bufor ryzyka, zwykle 20–40%, i sztywne granice. Gdy w trakcie wychodzi, że potrzebny jest jeszcze eksport zamówień do ERP, każda zmiana kończy się aneksem. Rozliczenie godzinowe z tygodniowym raportem i widocznym backlogiem jest bezpieczniejsze dla klienta: płacisz za pracę, którą widzisz. Warunek to limit — np. „po przekroczeniu 8 godzin ponad wycenę deweloper pyta o akceptację”. Ustalenia zapisuj e-mailem; to, co padło w rozmowie telefonicznej, przy sporze nie istnieje.

Koszt najczęściej podnoszą:

• import z ERP (Subiekt GT, Comarch Optima, WF-Mag) — mapowanie pól, stany magazynowe: 15–40 h,
• wielowalutowość — kursy, zaokrąglenia, płatności: 10–20 h,
• ceny indywidualne i grupy klientów B2B: 15–30 h,
• wielojęzyczność (WPML, Polylang) — każda treść razy dwa: 20–40 h,
• subskrypcje i produkty złożone — najpierw sprawdź, czy wtyczka obsługuje twoją bramkę płatności: 20 h+.

Jak to wygląda w praktyce przy projektach w okolicy — zobacz organizację wdrożenia WooCommerce w Frampolu. Budżet średniego sklepu dzieli się zwykle tak:

Wymagania techniczne: hosting współdzielony, VPS czy managed WooCommerce

Minimum na 2025 rok: PHP 8.2, docelowo 8.3 — starsze wersje (7.4, 8.0) tracą wsparcie bezpieczeństwa. Baza to MySQL 8.0 lub MariaDB 10.6+. OPcache musi być włączony (opcache.enable=1, opcache.memory_consumption 128–256 MB), inaczej każdy request kompiluje PHP od zera. Ustaw memory_limit min. 256 MB, max_execution_time 300 s na czas importów, a WP-Cron zamień na cron systemowy (DISABLE_WP_CRON i zadanie co 5 minut w crontabie).

Hosting współdzielony przestaje wystarczać w trzech momentach: gdy filtr katalogu generuje zapytania trwające 1–2 s, gdy import 3000 SKU jest zabijany przez limit CPU, oraz gdy nie masz SSH i WP-CLI, więc każdą aktualizację robisz klikając w panelu. Praktyczna granica: powyżej 500–1000 SKU i przy pierwszej planowanej kampanii reklamowej przechodź na VPS albo hosting managed.

Optymalizacja wydajności WooCommerce: kolejność, która daje efekt

Kolejność prac ma większe znaczenie niż liczba wtyczek. Jeśli serwer odpowiada w 1,5 s (TTFB), żadna wtyczka cache nie zrobi z tego szybkiego sklepu. Sprawdzona kolejność: hosting → cache strony → obrazy → baza i zapytania → frontend (CSS/JS) → zewnętrzne skrypty. Każdy kolejny krok jest tańszy we wdrożeniu i daje mniejszy efekt niż poprzedni, dlatego nie zaczynamy od optymalizacji CSS.

• Hosting: PHP 8.2+, OPcache, object cache (Redis), dysk NVMe. Cel: TTFB strony produktu poniżej 600 ms. Na hostingu współdzielonym za 30 zł/mies. dalsze kroki to strata czasu.
• Cache strony: pełnostronicowy, na poziomie serwera (FastCGI Cache, LiteSpeed, Varnish), z wykluczeniem /koszyk, /zamowienie, /moje-konto. Wtyczka cache w WordPress przy koszyku opartym o sesję i tak jest pomijana w tych miejscach.
• Obrazy: WebP lub AVIF i ograniczenie liczby generowanych rozmiarów. WordPress tworzy domyślnie 5–8 kopii każdego pliku — przy 3 000 SKU i pięciu zdjęciach to kilkanaście tysięcy plików i kilka GB do backupu i migracji.
• Baza: tabela wp_postmeta puchnie od meta zdjęć, wariantów i wtyczek. Zmierz: SELECT COUNT(*) FROM wp_postmeta; — przy 5 000 SKU wynik 400 000–800 000 wierszy to norma. Powyżej ~1 mln usuwamy osierocone wpisy, dodajemy indeksy i skracamy zapytania, zamiast dokładać kolejną wtyczkę.
• Frontend i skrypty zewnętrzne: warunkowe ładowanie CSS/JS wtyczek oraz odroczenie skryptów czatu, pikseli i popupów.

Core Web Vitals: LCP psuje najczęściej banner lub zdjęcie główne bez fetchpriority="high" i z włączonym lazy loadingiem; INP — ciężki JavaScript wtyczek (popupy, czat, filtry AJAX); CLS — obrazy i reklamy bez zarezerwowanych wymiarów. Definicje i progi zebrano w materiałach web.dev – Core Web Vitals.

HPOS włączasz, gdy WooCommerce wspiera to rozwiązanie, masz aktualny backup, a żadna wtyczka ani integracja nie czyta zamówień bezpośrednio z wp_posts. Odkładasz, gdy ERP lub stary moduł księgowy odwołuje się do tabel posts/postmeta — przełączenie ich zepsuje. Dwa mity warto odsiać od razu: „wtyczka do cache załatwi sprawę” (cache miss na koszyku daje zero korzyści) i „im więcej wtyczek, tym wolniej” (liczy się nie liczba, a liczba zapytań i kilobajtów na każdym żądaniu; sprawdzisz to Query Monitorem, filtrując zapytania powyżej 50 ms). Zakres takich prac opisaliśmy przy wdrożeniach i optymalizacji WooCommerce w Biłgoraju oraz WooCommerce w Józefowie.

Integracje, które najczęściej decydują o sukcesie sklepu

Demo sklepu różni się od działającego biznesu przede wszystkim w integracjach.

Kurierzy. InPost (ShipX API) — punkt odbioru jako mapa w koszyku, generowanie etykiet, statusy przesyłek odbierane webhookiem. DPD i DHL — analogicznie, z cennikami przypisanymi do konta. Sprawdź trzy rzeczy: czy wybrany punkt zapisuje się w zamówieniu, czy etykieta generuje się z listy zamówień, i czy status „doręczona” wraca do sklepu automatycznie. Bez tego drugiego punktu obsługa ręcznie odpowiada na maile „gdzie moja paczka”.

Płatności. Przelewy24, PayU, tpay, Stripe. BLIK obsługują przede wszystkim polscy operatorzy — przed wyborem bramki zweryfikuj aktualną listę metod w jej dokumentacji, bo zmienia się co kilka miesięcy. Płatności odroczone mają wyższą prowizję i sens głównie przy koszykach powyżej kilkuset złotych.

ERP i księgowość. Subiekt GT/nexo, Comarch Optima, Fakturownia, inFakt. Ustal jedno źródło prawdy o stanie magazynowym — jeśli WooCommerce i ERP liczą stany niezależnie, dojdzie do nadspzedaży. Do mapowania wracaj zawsze przy tych samych polach: SKU, cena, VAT, jednostka, numeracja faktur, kolejność wysyłki e-maili.

Własny moduł czy płatna wtyczka. Licencja 800 zł/rok przez trzy lata to 2 400 zł. Własny moduł to zwykle 25–40 godzin pracy, ale bez ryzyka, że autor porzuci wtyczkę po zmianie API operatora. Moduł wygrywa, gdy wtyczka realizuje 20% Twojego procesu, a resztę obchodzisz ręcznie.

Allegro. Synchronizacja ofert i stanów ma sens od kilkuset SKU i przy stałej sprzedaży w obu kanałach. Przy 30 produktach ręczna aktualizacja jest szybsza i tańsza. Punktem startowym dla hooków i wtyczek pozostaje dokumentacja WooCommerce. Ten sam układ integracji powtarza się w mniejszych projektach — patrz WooCommerce Frampol i WooCommerce Krasnobród.

Migracja na WooCommerce z PrestaShop, Shoper lub sklepu własnego

Migracja to projekt na 2–6 tygodni, zależnie od liczby SKU i historii zamówień. Kolejność, która chroni ruch i zamówienia:

• Audyt starego sklepu — liczba produktów, kategorii, klientów, zamówień, opinii, struktura URL, parametry filtrów i paginacji. Z Search Console wyciągnij adresy z wyświetleniami i sprawdź, ile stron jest zaindeksowanych.
• Mapowanie danych — SKU jako klucz łączący, warianty na product variations, atrybuty na taksonomie, kategorie z hierarchią. Klientów przenosisz bez haseł, z wymuszonym resetem. Zamówienia przenosisz z datami i statusami, inaczej raporty sprzedaży startują od zera.
• Import — WP All Import lub własny skrypt SQL. Przy 5 000 SKU sam import to 2–6 godzin plus weryfikacja losowej próbki 20–30 produktów.
• Testy — test zamówienia end-to-end: koszyk → płatność w trybie sandbox → e-mail potwierdzający → faktura → etykieta → status kuriera. Powtórz go dla trzech scenariuszy: kurier, punkt odbioru, płatność odroczona.
• Mapa 301 — gotowa PRZED startem, jeden stary URL = jedna reguła, bez łańcuchów A→B→C. Po wdrożeniu testujesz każdą regułę i sprawdzasz, że cel zwraca 200, a nie kolejne 301.
• Start i monitoring — przez dwa tygodnie codziennie: raport indeksowania, nowe 404, skoki 5xx w logach serwera, pozycje na frazy transakcyjne. Spadek liczby zaindeksowanych adresów w 3.–4. tygodniu to sygnał do reakcji, nie do czekania.

Co przenieść obowiązkowo: produkty, kategorie, klientów, historię zamówień, treści (strony i wpisy) oraz opinie — te ostatnie mają wartość SEO i sprzedażową. Przy produktach przenieś też dane strukturalne: cenę, dostępność, oceny. Typy obsługiwane przez wyszukiwarkę znajdziesz w dokumentacji danych strukturalnych Google.

Najczęstsza pułapka: zmiana adresów URL, które nie musiały się zmieniać. Jeśli struktura kategorii może zostać, zostaw ją i ogranicz mapę przekierowań do realnie zmienionych adresów. Procedura jest powtarzalna niezależnie od skali — sprawdziliśmy ją przy wdrożeniach i optymalizacji WooCommerce w Zwierzyńcu oraz WooCommerce w Szczebrzeszynie.

SEO techniczne WooCommerce w Lublinie: widoczność lokalna i ogólnopolska

Dwie rzeczy psują pozycje sklepu szybciej niż słabe teksty: duplikaty z filtrów i cienkie strony kategorii. Zacznij od adresów. W Ustawienia → Bezpośrednie odnośniki ustaw produkt na „Nazwa produktu”, a bazę kategorii zamień z domyślnego „kategoria-produktu” na „sklep” (WooCommerce → Ustawienia → Produkty → Bezpośrednie odnośniki). Rób to przed startem kampanii — późniejsza zmiana to seria przekierowań 301 i kilka tygodni spadków w wynikach.

Cienkie strony powstają same: kategorie z 2 produktami, tagi, atrybuty typu „rozmiar 42”. Prosta reguła: kategoria indeksowana od 6–8 produktów w górę, atrybuty i tagi poniżej 5 produktów dostają noindex, follow. Filtry mnożą adresy w tysiące: ?filter_, ?orderby=, ?min_price=, ?paged=. Nie blokuj ich w robots.txt — zablokowanego adresu robot nie zobaczy, więc znacznik noindex nie zadziała, a strona zostanie w indeksie jako „zablokowana”. Lepiej ustawić canonical na kategorię bazową plus noindex, follow na widokach filtrowanych. Domyślny canonical WooCommerce z parametrami wymaga poprawy.

Dane strukturalne zgodne z dokumentacją Google: Product + Offer tylko na karcie produktu, z price, priceCurrency, availability, priceValidUntil i sku. Lista kategorii z 40 produktami nie może generować 40 bloków Product na jednej stronie. AggregateRating dodawaj wyłącznie z realnych, zweryfikowanych opinii. LocalBusiness ma sens na stronie kontakt (adres, NIP, godziny), nie na produkcie. FAQPage zostaw tam, gdzie faktycznie masz FAQ — od 2023 Google pokazuje rozszerzone wyniki FAQ praktycznie tylko stronom rządowym i medycznym.

Google Business Profile dla sklepu z Lublina ma sens wtedy, gdy masz punkt odbioru osobistego albo obsługę lokalną: wypełnij godziny, atrybut „Zakupy online” i link do sklepu. Sklep typowo wysyłkowy poradzi sobie bez profilu.

Linkowanie rób dwukierunkowo: z wpisu o wdrożeniu WooCommerce w Krasnobrodzie prowadź do kategorii sklepu, a z kategorii do wdrożeń WooCommerce w Zwierzyńcu i pozostałych wpisów regionalnych.

Utrzymanie i SLA po wdrożeniu — co powinno znaleźć się w umowie

Umowa bez SLA to faktura za nieokreśloną liczbę godzin. Zacznij od definicji awarii i rozdzielenia dwóch czasów: reakcji (kiedy ktoś odpisze) od naprawy (kiedy sklep działa).

Jak wybrać wykonawcę wdrożenia WooCommerce w Lublinie i regionie

Pięć pytań rozdziela dewelopera od pośrednika już w pierwszej rozmowie. Pierwsze: „Ile z tego, co proponujecie, to Wasze moduły, a ile kolejne płatne wtyczki?” Sklep oparty na 12 wtyczkach premium to 1 500–6 000 zł licencji rocznie i 12 autorów, z których każdy może przestać rozwijać produkt. Drugie: „Kto realnie pisze kod i czy mogę porozmawiać z tą osobą?”

Trzecie: „Co dostaję na koniec?” Repozytorium Git z historią commitów, dostępy do serwera, DNS i panelu płatności oraz dokumentacja wdrożenia: struktura kategorii, lista wtyczek z licencjami, zadania cron, integracje kurierskie i fakturowanie. Jeśli wykonawca „trzyma kod u siebie”, przy zmianie firmy zaczynasz od zera — przy sklepie z 3 000 SKU to kilka tygodni pracy i kilkanaście tysięcy złotych.

Czwarte: wycena. Ryczałt ma sens tylko z listą zadań i klauzulą o zmianach zakresu. Bez rozbicia na godziny nie sprawdzisz, czy 40 godzin na motyw to realna praca, czy marża. Pytaj o stawkę godzinową i limit w pakiecie — dopiero wtedy organizacja wdrożenia sklepu we Frampolu czy wdrożenie WooCommerce w Józefowie da się porównać z konkurencyjną ofertą.

Piąte: zdalnie czy na miejscu. W praktyce zdecydowana większość prac przy WooCommerce da się zrobić zdalnie — kod, migracja, optymalizacja pod Core Web Vitals, więc poproś o wyniki pomiaru przed i po. Wizyta na miejscu w Lublinie ma sens przy szkoleniu zespołu, konfiguracji drukarki etykiet, kasy lub integracji z lokalnym systemem magazynowym. „Mamy biuro w Lublinie” bez tych elementów to marketing.

Czerwone flagi: brak środowiska staging, brak umowy na utrzymanie, brak testu płatności w trybie piaskownicy przed produkcją, „zrobimy wszystko” bez listy zadań i brak konkretnej odpowiedzi na pytanie o repozytorium.

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

Lista kontrolna do odklikania

• Zakres wdrożenia na piśmie — Lista zadań w 7 obszarach z liczbą godzin i etapami. Sprawdź przed podpisaniem umowy, nie po pierwszym tygodniu prac.
• Wersje środowiska potwierdzone przez hosting — PHP 8.2 minimum (docelowo 8.3), MySQL 8.0 lub MariaDB 10.6+, OPcache włączony. Weryfikacja: zapytanie do supportu i zrzut z phpinfo na stagingu.
• Staging i kopie zapasowe z retencją — Sprawdź, jak często powstają kopie, gdzie leżą i czy wykonano próbne odtworzenie. Test rollbacku zrób przed startem produkcji.
• Podział ról: deweloper, właściciel sklepu, księgowość — Ustal na starcie, kto dostarcza opisy i zdjęcia, kto zatwierdza teksty, kto podaje stawki VAT i dane do faktur. Bez wskazanej osoby decyzyjnej harmonogram się rozjeżdża.
• Struktura katalogu i kategorii — Sprawdź liczbę SKU, liczbę wariantów i głębokość kategorii. Przy 300–3000 SKU ustal to przed importem, bo przenoszenie kategorii po starcie generuje przekierowania.
• Atrybuty i filtry — Zaplanuj atrybuty pod filtrowanie i podstrony kategorii. Weryfikacja: wybierz 10 losowych produktów i sprawdź, czy da się je znaleźć po atrybucie.
• Płatności z realną transakcją testową — BLIK, karty i płatności odroczone przetestuj kwotą 1 zł w trybie produkcyjnym, potem zwróć. Sprawdź też e-maile potwierdzające po każdej metodzie.
• Integracje kurierskie i punkty odbioru — Wygeneruj etykietę i sprawdź, czy status przesyłki wraca do sklepu. Osobno przetestuj wybór punktu odbioru w koszyku.
• Podatki, waluty i fakturowanie — Potwierdź stawki VAT, sposób numeracji faktur i to, czy sklep ma obsłużyć sprzedaż zagraniczną. Uzgodnij to z księgowością przed startem.
• Kierunek przepływu danych w integracji z ERP — Ustal, co jest źródłem prawdy dla stanów magazynowych i faktur, i jak często działa synchronizacja. Weryfikacja: zmień stan w ERP i sprawdź, kiedy pojawi się w sklepie.
• Mierniki startowe wydajności — Zapisz wyniki przed optymalizacją: LCP, INP, CLS oraz czas generowania listy produktów. Bez punktu odniesienia nie ocenisz efektów prac.
• Rozmiar tabeli wp_postmeta — Sprawdź liczbę wierszy i rozmiar tabeli w bazie. Pomiar rób także po imporcie i po włączeniu integracji, bo tam najczęściej rośnie najszybciej.
• Kompatybilność wtyczek z HPOS — Przed włączeniem High-Performance Order Storage sprawdź listę wtyczek obsługujących zamówienia. Włączaj na stagingu i porównaj czasy działania panelu zamówień.
• Dostępy i przekazanie sklepu — Ustal, na czyich kontach stoją hosting, domena i płatności. Po odbiorze zmień hasła i włącz 2FA, żeby nie zależeć od dostępu wykonawcy.

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