Wdrożenie czy optymalizacja WooCommerce — co jest potrzebne w Chełmie?

Decyzję podejmuje się na podstawie trzech liczb, nie przeczuć. Pierwsza: czas ładowania (LCP i TTFB z PageSpeed Insights lub Lighthouse). Druga: liczba zamówień w miesiącu. Trzecia: czy zamówienia trafiają ręcznie do ERP, czy systemem. Pierwsze dwie sprawdzisz w kwadrans, trzecia to pytanie do osoby, która wystawia faktury.

Typowe problemy sklepów MŚP z Chełma i okolic, które widzimy najczęściej: wolne ładowanie na hostingu współdzielonym bez OPcache i bez object cache, koszyk porzucany na etapie wyboru dostawy (koszt pojawia się dopiero na końcu), brak integracji z systemem magazynowym i fakturą (przepisywanie zamówień ręcznie), a także brak danych strukturalnych produktu i ceny — bez nich Google nie pokaże ceny i dostępności w wynikach.

• Nowy sklep — nie ma platformy albo jest to landing z formularzem. Kierunek: wdrożenie od zera.
• Migracja — sklep działa na starym systemie bez aktualizacji i bez dokumentacji. Kierunek: wdrożenie z audytem danych i mapą przekierowań.
• Sklep już działający na WooCommerce — proces sprzedaży działa, ale ładowanie i konwersja spadły. Kierunek: najpierw optymalizacja.

Optymalizacja wystarczy, gdy sklep stoi na WooCommerce, wtyczki są aktualizowane, proces zamówień jest obsługiwany, ale TTFB przekracza 800 ms, a LCP 4 s. Wtedy 10–40 godzin pracy zwykle wraca w wynikach i w koszykach. Nowe wdrożenie jest konieczne, gdy platforma jest autorska i nie ma dostępu do kodu, gdy liczba produktów przekracza kilka tysięcy, a struktura kategorii i atrybutów jest nie do naprawy, gdy ERP wymaga synchronizacji dwukierunkowej albo gdy szablon z 2016 roku nie działa poprawnie na PHP 8.2. Zanim wybierzesz kierunek, warto porównać zakres z tym, co robimy przy wdrożeniach i optymalizacji WooCommerce w Hrubieszowie oraz przy optymalizacji WooCommerce w Narolu — skala sklepu zmienia listę zadań, nie zmienia kolejności.

Ile kosztuje wdrożenie i optymalizacja WooCommerce w Chełmie? Widełki 2025

Punkt wyjścia to stawka godzinowa za pracę deweloperską: 120–200 zł netto za godzinę. Dolny przedział dotyczy prac konfiguracyjnych i wdrożeniowych (ustawienia wtyczek, strefy dostawy, płatności), górny — pisania kodu: własne wtyczki, integracje API, modyfikacje szablonu w child theme.

Typowy zakres godzinowy: wdrożenie nowego sklepu 40–120 godzin, optymalizacja istniejącego 10–40 godzin. Optymalizacja rzadko przekracza 40 godzin, bo powyżej tego progu zwykle taniej jest przebudować konkretny element niż łatać go dalej. Hosting, licencje wtyczek i szablon kupujesz osobno — nie wliczaj ich do stawki za pracę, bo rozliczenie robi się nieczytelne.

• Liczba produktów i wariantów — 200 prostych produktów to inna praca niż 2000 z wariantami i atrybutami.
• Migracja danych — czyszczenie bazy, mapowanie kategorii, przekierowania 301. Brak przekierowań to utrata pozycji w Google i ruchu z linków zewnętrznych.
• Integracje: ERP (Subiekt, Comarch, WFirma), płatności (Przelewy24, PayU, Stripe, BLIK), kurierzy (InPost, DPD, DHL) — każda to osobne zadanie i osobny test.
• Szablon — zakup gotowego to 1–3 godziny konfiguracji, custom design to kilkadziesiąt godzin.

Przykładowe budżety 2025 dla sklepów z Chełma i okolic: prosty sklep (do 100 produktów, gotowy szablon, dwie płatności, jeden kurier) 6–12 tys. zł; średni (100–1000 produktów, integracja z fakturą i magazynem, kilka stref dostawy) 12–25 tys. zł; rozbudowany (tysiące produktów, B2B, ERP, kilka magazynów) 25–50 tys. zł i więcej. Sama optymalizacja to zwykle 1,2–8 tys. zł.

Trzy pułapki w kosztorysach: brak etapu testów (płatności i dostaw testuj przed startem, nie po), brak zapisanej liczby iteracji w projekcie szablonu oraz brak zakresu na piśmie — każdy dodatek poza umową generuje godziny. Zobacz, jak wygląda to przy wdrożeniach WooCommerce w Lublinie i przy wdrożeniach i optymalizacji WooCommerce w Biłgoraju — zakresy są podobne, różni się skala katalogu.

Optymalizacja WooCommerce: 7 miejsc, które najczęściej zabijają szybkość

Kolejność sprawdzania jest stała, bo każde następne ogniwo zależy od poprzedniego. Robienie cache strony na wolnym hostingu nic nie da poza ukryciem problemu.

1. Hosting lub VPS. Pierwszy pomiar to TTFB. Powyżej 800 ms przy stronie produktu zwykle brakuje zasobów CPU albo serwer obsługuje zbyt wiele sklepów. Minimum dla WooCommerce to 2 vCPU i osobna baza.

2. PHP 8.2+ i OPcache. Starsze PHP to wolniejsze wykonanie i brak wsparcia bezpieczeństwa wtyczek. OPcache z domyślnym opcache.validate_timestamps warto skonfigurować świadomie, nie zostawiać na domyślnych wartościach.

3. Object cache: Redis lub Memcached. Bez tego WooCommerce odpytuje bazę dziesiątki razy na jedno wejście do koszyka. Sprawdź redis-cli info memory i monitoruj evicted_keys — jeśli rośnie, limit pamięci jest za niski.

4. Cache stron. Uwaga na koszyk i strony zalogowanych użytkowników: fragmenty koszyka muszą być wyłączone z cache, inaczej klient zobaczy cudzy koszyk. To najczęstszy błąd przy włączaniu cache na sklepie.

5. CDN i kompresja. Statyki z CDN, teksty kompresowane Brotli (z fallbackiem Gzip). Sprawdź nagłówek content-encoding na CSS i JS.

6. Obrazy WebP lub AVIF. Konwersja z JPG potrafi ściąć wagę strony produktu o połowę. Pilnuj też width i height w tagach, żeby nie generować przesunięć layoutu (CLS).

7. Baza danych i wtyczki śledzące. wp_postmeta i wp_options rosną latami. Użyj WP-CLI: wp transient delete --expired, wp db optimize, a w wp_options sprawdź tabelę autoload. Wtyczki analityczne i piksele reklamowe wczytujące skrypty w każdym miejscu to typowy powód pogorszenia INP.

Cele: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1. Warto to monitorować w Search Console, bo Google oficjalnie podaje te progi jako punkt odniesienia dla wyników wyszukiwania (web.dev – Web Vitals). Przykład podobnego przeglądu znajdziesz przy organizacji wdrożeń WooCommerce we Frampolu i przy wdrożeniach i optymalizacji WooCommerce w Bełżcu.

Migracja do WooCommerce z PrestaShop lub starego sklepu — lista kontrolna dla Chełma

Kolejność działań ma większe znaczenie niż wybór narzędzi. Migracja prowadzona „na żywym” sklepie kończy się zwykle utratą ruchu na 2–6 tygodni, bo Google potrzebuje czasu na przetworzenie setek przekierowań. Poniżej kolejność, która się sprawdza.

1. Inwentaryzacja URL-i. Crawl starego sklepu (Screaming Frog w wersji darmowej obsłuży 500 adresów — przy 2–3 tys. produktów potrzebna jest licencja) plus eksport z Google Search Console: Wydajność → Strony. Z GSC dowiesz się, które adresy realnie zbierały kliknięcia — te muszą dostać przekierowanie w pierwszej kolejności. W PrestaShop adresy produktów i kategorii siedzą w tabelach ps_product_lang i ps_category_lang, więc mapę da się wygenerować z bazy, a nie klikać ręcznie.

2. Mapa przekierowań 301. Jeden stary URL → dokładnie jeden nowy. Produkt na produkt, kategoria na kategorię, paginacja z ?p=2 na /page/2/. Reguły w .htaccess lub w konfiguracji nginx, przed WordPressem — nie we wtyczce, bo każde 301 przez PHP to zbędne obciążenie. Sprawdzaj łańcuchy: A → B → C to najczęstszy błąd po migracji.

3. Backup i praca na kopii. Dump bazy (mysqldump) i pliki przez rsync/SSH, staging na subdomenie z wpisem Disallow: / w robots.txt i hasłem na poziomie serwera. DNS zmieniasz dopiero po testach, nie odwrotnie.

4. Płatności i kurierzy. Przelewy24, PayU lub Stripe: jedna realna transakcja, potem zwrot. InPost (Paczkomat i kurier), DPD, DHL: generowanie etykiety, numer przesyłki, waga i gabaryty, pobranie, wybór punktu na mapie w koszyku.

5. Po starcie. Zgłoś nową sitemap w Search Console, sprawdź pokrycie indeksu, przetestuj dane strukturalne i wycofaj starą sitemap. Sklepy z sąsiednich miejscowości przechodzą identyczną ścieżkę — opisaliśmy ją przy okazji wdrożeń i optymalizacji WooCommerce w Bełżcu, gdzie skala była porównywalna.

Integracje z ERP, płatnościami i kurierami — kiedy własny moduł, a kiedy gotowa wtyczka?

Najczęściej integrujemy sklepy z Subiektem GT/nexo, Comarch Optimą lub XL, InPost ShipX, DPD i DHL oraz bramkami Przelewy24, PayU i Stripe. Pierwsze pytanie nie brzmi „jaka wtyczka”, tylko „jak wygląda obieg danych”: kto jest źródłem prawdy o stanie magazynu, cenie i statusie zamówienia.

Kiedy gotowa wtyczka wystarcza. Jeden magazyn, jedna cena detaliczna, jeden cennik, standardowa wysyłka. Wtedy wtyczka za kilkaset złotych rocznie robi robotę i nie ma sensu pisać modułu.

Kiedy gotowa wtyczka kosztuje więcej. Cztery sygnały ostrzegawcze: (1) subskrypcja roczna rozliczana od liczby SKU albo zamówień — przy 10 tys. produktów plan „enterprise” potrafi kosztować więcej niż jednorazowy moduł; (2) kod zakodowany ionCubem, więc nie poprawisz nawet literówki w szablonie dokumentu; (3) brak wsparcia po aktualizacji WooCommerce — wtyczka działa, dopóki nie klikniesz „aktualizuj”; (4) dane zamówień przechodzą przez serwer zewnętrznego dostawcy, co trzeba opisać w rejestrze czynności i umowie powierzenia.

Kryterium praktyczne: koszt w 3 latach. Wtyczka za 1 200 zł/rok to 3 600 zł plus czas na obejścia. Własny moduł na zamówienie to zwykle jednorazowo 6–10 tys. zł i 800–1 500 zł rocznie na utrzymanie, ale dostajesz kod, SLA i dopasowanie do nietypowej logiki (kilka magazynów, ceny klienta, jednostki miary). Punkt równowagi wypada najczęściej przy nietypowych procesach albo wysokim planie subskrypcyjnym.

Przy sklepach z mniejszych miejscowości ten sam schemat sprawdziliśmy przy wdrożeniach WooCommerce w Narolu — tam decydująca okazała się nie cena wtyczki, a czas synchronizacji stanów magazynowych.

SEO techniczne i szybkość — co sprawdzić przed i po wdrożeniu WooCommerce

Sklep może być szybki i niewidoczny albo wolny i wysoko — ale nie da się być wysoko długo z LCP powyżej 4 s. Kolejność sprawdzania jest zawsze taka sama.

Indeksacja. Zacznij od raportu Pokrycie w Search Console i zapytania site:twojadomena.pl. W WooCommerce śmieci indeksują się z filtrów i sortowań: ?orderby=, ?filter_, ?min_price=, ?s=. Te adresy blokuj przez noindex albo wykluczaj w robots.txt. Koszyk, stronę „moje konto” i podziękowanie po zamówieniu ustaw na noindex — nigdy nie zostawiaj tam indeksowalnych stron.

Sitemap i robots.txt. Sitemapę generuje Yoast lub Rank Math (sitemap_index.xml). Wywal z niej tagi produktowe i puste kategorie — tysiąc adresów z jednym produktem nie pomaga. W robots.txt nie blokuj /wp-content/ ze stylami i skryptami, bo Google renderuje stronę i zobaczy pusty layout.

Kanoniczne URL-e. Jeden adres na produkt: bez parametrów, bez wariantu z index.php, spójny z przekierowaniem 301. Paginacja nie potrzebuje rel=next/prev, ale musi mieć czyste, unikalne adresy.

Dane strukturalne. Minimum to Product z Offer (cena, waluta, dostępność, SKU, GTIN), BreadcrumbList oraz LocalBusiness z adresem i godzinami, jeśli prowadzisz punkt w Chełmie. Zakres typów obsługiwanych przez Google masz w dokumentacji Google Search Central. Opinie w AggregateRating dodawaj tylko wtedy, gdy są prawdziwe.

Szybkość. Cele Core Web Vitals opisuje web.dev: LCP do 2,5 s, INP do 200 ms, CLS do 0,1. W WooCommerce najczęściej zabijają to niekompresowane zdjęcia produktów i ciężkie wtyczki do filtrów.

Lokalnie. Wizytówka Google z kategorią i obszarem działania (Chełm i powiat chełmski), spójny NAP na stronie i w wizytówce, treści lokalne (odbiór osobisty, dostawa w Chełmie). Linkowanie wewnętrzne kieruj też na strony obsługiwanych miast, np. WooCommerce w Lublinie i Hrubieszowie — to naturalny sposób na pokrycie regionu bez tworzenia zaplecze.

Opieka techniczna po wdrożeniu — co powinno być w SLA?

Uruchomienie sklepu to moment, w którym praca się nie kończy, a zaczyna. Zakres opieki trzeba opisać w umowie punkt po punkcie, bo zapis „aktualizacje i wsparcie” bez szczegółów znaczy zwykle „zrobimy, gdy ktoś zadzwoni”.

Backupy. Minimum: codziennie, automatem, z retencją 30 dni i kopią poza hostingiem (inny dostawca, np. S3 lub Backblaze B2). Kopia musi obejmować bazę, pliki i katalog /wp-content/uploads. Raz na kwartał przetestuj odtworzenie na stagingu — backup, którego nikt nie sprawdził, nie jest backupem, tylko plikiem.

Aktualizacje. WordPress core, WooCommerce, wtyczki, motyw i PHP. Najpierw staging, potem produkcja w okienku serwisowym (np. wtorek, 6:00), żeby klient nie trafił na błąd 500 w środku dnia. PHP trzymaj na wspieranej gałęzi — 8.1/8.2 to dziś rozsądne minimum pod WooCommerce, 7.4 to ryzyko i brak łat bezpieczeństwa.

Monitoring. Zewnętrzny uptime sprawdzany co 60 s z alertem SMS oraz pomiar czasu ładowania w dwóch warstwach: syntetycznej (Lighthouse/PageSpeed) i realnej od użytkowników (RUM). Próg reakcji: LCP poniżej 2,5 s. Jeśli LCP rośnie trzy dni z rzędu, reagujesz, zanim klienci zaczną porzucać koszyk. Definicje i progi opisuje dokumentacja web.dev o Web Vitals.

Czas reakcji licz od zgłoszenia, nie od momentu, gdy ktoś odczyta maila. Zdefiniuj też, co znaczy „awaria krytyczna”: sklep nie przyjmuje zamówień, błąd 500, nie działają płatności, wyciek danych.

Jak wybrać wykonawcę wdrożenia WooCommerce w Chełmie i okolicach?

Największe ryzyko przy wdrożeniu to nie technologia, a firma, która zleca całość podwykonawcy i znika z projektu. Zanim podpiszesz umowę, zadaj pięć pytań i zapisz odpowiedzi.

• Kto konkretnie pisze kod? Poproś o nazwiska osób i dwa adresy wdrożeń, które możesz otworzyć i kliknąć. Odpowiedź „mamy zespół” bez nazwisk to sygnał ostrzegawczy.
• Jak wygląda backup i rollback? Czy przed każdą zmianą powstaje kopia bazy, czy jest staging i czy możesz cofnąć wdrożenie do stanu sprzed godziny.
• Jakie SLA wchodzi w umowę? Czasy reakcji, kanał zgłoszeń, zakres po godzinach.
• Czy są ukryte koszty licencji? Które wtyczki są płatne, ile kosztują rocznie i na czyim koncie stoi licencja. Licencja przypisana do klucza wykonawcy to uzależnienie — po rozstaniu zostajesz bez aktualizacji.
• Co dostajesz na koniec? Dostępy administratora, repozytorium Git, dokumentację konfiguracji.

Czerwone flagi: brak jakichkolwiek widełek cenowych, praca wyłącznie bezpośrednio na produkcji, lista kilkunastu wtyczek premium bez analizy, czy da się to zrobić w kodzie motywu, oraz brak przekazania dostępów po odbiorze.

Lokalność ma znaczenie, gdy w grze jest integracja z ERP, fiskalizacja, drukarki i szkolenie pracowników na miejscu. Nie ma znaczenia przy samym WooCommerce — tu liczy się jakość kodu i SLA, a nie odległość. Zdalnie można prowadzić projekt tak samo dobrze, jeśli są staging, Git i cotygodniowe podsumowanie. Przykład podobnego projektu z okolic znajdziesz w materiale o wdrożeniach i optymalizacji WooCommerce w Narolu.

Podsumowanie: gotowa checklista wdrożenia i optymalizacji WooCommerce w Chełmie

Zacznij od trzech liczb: aktualny czas ładowania, liczba zamówień w miesiącu i to, czy w firmie działa ERP. One rozstrzygają, czy potrzebujesz wdrożenia od zera, migracji ze starej platformy, czy tylko naprawy wydajności.

• Zmierzone TTFB i LCP dla strony głównej, kategorii i karty produktu osobno.
• Decyzja: nowy sklep, migracja czy optymalizacja — nie robimy dwóch rzeczy naraz.
• Staging i kopia bazy przed pierwszym commitem.
• Migracja treści: produkty, warianty, kategorie, klienci, zamówienia, opinie.
• Przekierowania 301 dla starych adresów produktów i kategorii — bez tego tracisz pozycje i ruch.
• Optymalizacja: cache obiektowy, CDN, WebP, lazy loading, czyszczenie tabel wp_postmeta i transients, OPcache na PHP 8.1+.
• Testy płatności, dostaw, maili transakcyjnych i faktur — na prawdziwych zamówieniach, nie na demo.
• Umowa na opiekę techniczną z konkretnym SLA i kosztem miesięcznym.

Jeśli działasz w regionie, podobne wdrożenia prowadzimy dla firm z Lublina — zakres opisaliśmy w artykule o wdrożeniach i optymalizacji WooCommerce w Lublinie — oraz przy granicy, o czym piszemy w materiale o WooCommerce w Hrubieszowie. Zasady pomiaru progów wydajności zebrał Google Search Central w dokumentacji Core Web Vitals.

Wycena: liczymy godziny, nie „pakiety na oko”. Podaj liczbę produktów, obecny adres sklepu, czas ładowania z PageSpeed i zakres (wdrożenie, migracja, optymalizacja) — wrócimy z rozbiciem na etapy i stawką za godzinę. Napisz do nas lub zadzwoń; wycenę robi deweloper, który potem prowadzi projekt, nie handlowiec.

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

Lista kontrolna do odklikania

• Inwentaryzacja wtyczek i motywu — Sprawdź to przed każdą optymalizacją. Zapisz nazwę, wersję, autora i datę ostatniej aktualizacji każdej wtyczki. Wtyczki bez aktualizacji od roku to kandydaci do usunięcia.
• Pomiar Core Web Vitals przed pracami — Użyj PageSpeed Insights i danych CrUX. Zapisz LCP, INP i CLS dla wersji mobilnej. Punkt odniesienia jest potrzebny, żeby ocenić efekt po zmianach — zgodnie z wytycznymi web.dev.
• Backup i praca na kopii — Zanim cokolwiek zmienisz, zrób pełny backup plików i bazy. Optymalizację i migrację prowadź na kopii, a DNS przełączaj dopiero po testach.
• Wersja PHP i OPcache — Wymagane minimum to PHP 8.2. Sprawdź, czy OPcache jest włączony i czy pula pamięci nie jest zbyt mała — to najtańszy sposób na skrócenie czasu wykonania skryptów.
• Cache obiektowy (Redis lub Memcached) — Sprawdź, czy hosting oferuje Redis. Przy sklepie z 1000+ produktami cache obiektowy odciąża bazę bardziej niż cache stron.
• Cache stron i CDN — Zweryfikuj, czy cache stron nie jest wyłączony dla koszyka i kasy (to normalne), ale działa dla kategorii i kart produktów. CDN sprawdź na plikach statycznych.
• Kompresja Brotli lub Gzip — Sprawdź nagłówki odpowiedzi w narzędziach deweloperskich przeglądarki. Brak kompresji na HTML, CSS i JS to strata kilkudziesięciu procent transferu.
• Obrazy w WebP lub AVIF — Sprawdź wagę zdjęć produktowych w rozdzielczości rzeczywistej. Pliki powyżej 300 kB na karcie produktu to typowy powód długiego LCP.
• Czyszczenie bazy danych — Usuń osierocone wpisy w tabeli postmeta, wygasłe transients i nadmiarowe rewizje. Zrób to po backupie i po pomiarze — inaczej nie poznasz efektu.
• Mapa przekierowań 301 — Wymagane przy każdej migracji. Wyeksportuj stare URL-e (dokumentacja PrestaShop pomaga przy odczycie struktury bazy) i przygotuj mapowanie.
• Test płatności i kurierów — Przelewy24, PayU, Stripe oraz InPost, DPD, DHL — każdą integrację sprawdź na kopii i raz na produkcji po zmianie DNS, wraz z e-mailem potwierdzającym.
• Dane strukturalne i indeksacja — Po starcie zweryfikuj w Search Console sitemap, robots.txt, adresy kanoniczne oraz znaczniki Product, Offer i BreadcrumbList — lista obsługiwanych typów jest w dokumentacji Google.
• Lokalne SEO dla Chełma — Uzupełnij wizytówkę Google, dodaj adres i godziny, wpisz treści lokalne i linkowanie wewnętrzne do stron sąsiednich miast, np. Lublin.
• Zakres SLA i koszt utrzymania — Ustal czasy reakcji (4h/8h/24h), zakres backupów i miesięczny koszt 300–1500 zł netto jeszcze przed podpisaniem umowy na wdrożenie.

Najczęściej zadawane pytania

Źródła i materiały

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