Wdrożenie WooCommerce to nie instalacja wtyczki, tylko projekt: analiza asortymentu, środowisko testowe, konfiguracja produktów, podatków, płatności i wysyłek, integracje, testy i dopiero na końcu start produkcyjny. W Zamościu i okolicach najczęściej dotyczy to firm, które mają już katalog w Excelu, Subiekcie albo w plikach od dostawców, a sprzedaż chcą prowadzić równolegle B2C i B2B. Poniżej porządkujemy zakres prac, sposób wyceny i kolejność optymalizacji, żeby dało się porównać oferty bez zgadywania. Punkt wyjścia jest zawsze ten sam: liczba SKU i wariantów, model sprzedaży i lista systemów, z którymi sklep ma się łączyć.
Wdrożenie WooCommerce w firmie z Zamościa i okolic rozbijamy na siedem etapów. Każdy kończy się sprawdzalnym efektem — dzięki temu da się porównać oferty i wiedzieć, za co się płaci.
X-Robots-Tag: noindex), kopia bazy do testów. Efekt: adres, na którym pracujemy bez ryzyka dla sprzedaży.WooCommerce ma sens przy katalogu do około 2–5 tys. SKU, gdy potrzebne są elastyczne modele sprzedaży — B2C równolegle z B2B na indywidualnych cennikach — i gdy zależy nam na kontroli nad kodem. Przy kilkunastu tysiącach SKU, wielu magazynach i rozbudowanym B2B natywnie lepiej wypada PrestaShop; opisujemy to w materiale o wdrożeniach i migracjach PrestaShop w Zamościu. SaaS bywa tańszy na start, ale przy nietypowych integracjach z ERP koszt wraca w abonamentach i ograniczeniach.
Wycena zmienia się najbardziej pod wpływem kilku odpowiedzi z briefu: liczba SKU i wariantów, sprzedaż B2B/B2C, sposób wystawiania faktur, liczba magazynów, języki i waluty. Bez tych danych każda oferta jest zgadywaniem. Punkt wyjścia u nas to organizacja wdrożenia WooCommerce w Zamościu — brief, zakres i podział na etapy.
| Kryterium | WooCommerce | PrestaShop | SaaS (Shopify, Shoper) |
|---|---|---|---|
| Katalog | do ~2–5 tys. SKU | kilkanaście tys.+ SKU | dowolny, ale rosną koszty |
| B2B z cennikami | wtyczki dodatkowe | natywnie, mocny obszar | zwykle ograniczone |
| Integracja z ERP | duża swoboda | duża swoboda | przez API/pośrednika |
| Kontrola nad kodem | pełna | pełna | brak |
Widełki, które podajemy klientom z Zamościa i powiatu, są zbliżone do rynkowych: podstawowy sklep B2C w WooCommerce to 40–70 godzin pracy, a sklep B2B z cennikami grupowymi i integracją ERP to 120–250 godzin. Sklep z 300 SKU, jedną strefą wysyłkową i dwiema bramkami płatniczymi domyka się bliżej dolnej granicy. Ten sam sklep plus warianty, import z Subiekta i automatyczne faktury — bliżej górnej.
| Etap | B2C (h) | B2B + ERP (h) |
|---|---|---|
| Brief i analiza asortymentu | 4–8 | 12–25 |
| Staging i konfiguracja bazowa | 6–10 | 10–18 |
| Produkty, warianty, podatki | 10–18 | 25–50 |
| Płatności i wysyłki | 6–10 | 12–25 |
| Integracje | 8–14 | 40–90 |
| Testy scenariuszowe + start | 6–10 | 20–40 |
Nakład mnożą: import z nietypowych źródeł (XML bez dokumentacji, eksport z Subiekta, pliki od dostawców w różnych kodowaniach), moduły niestandardowe (kalkulator ilości palet, konfigurator), wielojęzyczność z WPML — bo podwaja liczbę miejsc do testowania — oraz indywidualne rozliczenia wysyłek łączące wagę gabarytową, strefy i palety.
Podział kosztów jest prosty: jednorazowo płacisz za prace wdrożeniowe, miesięcznie za hosting (ok. 50–150 zł za sensowny hosting współdzielony, 200–500 zł za VPS), licencje wtyczek (od ok. 100 zł do ponad 1000 zł rocznie za moduł) i opiekę techniczną obejmującą aktualizacje, kopie i monitoring. Najczęstsza pułapka: klient kupuje wtyczkę „na zawsze”, a po roku nie ma aktualizacji i wsparcia, bo licencja wygasła.
Sygnały ostrzegawcze w ofercie: brak rozbicia na godziny, brak etapu testów albo „testy w cenie” bez listy scenariuszy, brak zapisu o przekazaniu dostępów i dokumentacji, brak wskazania, kto fizycznie wykonuje import danych. Przykład z regionu: sklep w Hrubieszowie z 600 SKU i eksportem z Subiekta — wdrożenie WooCommerce dla podobnego asortymentu zamyka się w zbliżonych godzinach, jeśli dane źródłowe są czyste.
Zacznij od pomiaru, nie od włączania kolejnej wtyczki. Progi, do których warto dążyć: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 (Core Web Vitals) oraz TTFB poniżej 600 ms na hostingu współdzielonym i poniżej 300 ms na VPS. Mierz na mobile i desktopie, na realnym ruchu (dane CrUX w PageSpeed Insights) i w laboratorium (GTmetrix).
| Metryka | Próg | Czym mierzyć |
|---|---|---|
| LCP | < 2,5 s | PageSpeed Insights, GTmetrix |
| INP | < 200 ms | dane CrUX, Search Console |
| CLS | < 0,1 | PageSpeed Insights, web-vitals |
| TTFB | < 600 ms / < 300 ms | curl -o /dev/null -s -w '%{time_starttransfer}' |
Kolejność działań według wpływu: 1) cache stron plus cache obiektowy (Redis albo Memcached) — to zwykle największy skok; 2) kompresja Brotli/Gzip i formaty WebP/AVIF; 3) krytyczny CSS i odroczenie JS; 4) lazy loading poza pierwszym ekranem, ale nigdy na obrazie LCP; 5) CDN, jeśli ruch jest rozproszony geograficznie.
Pułapki typowe dla WooCommerce: nieindeksowane zapytania po wp_postmeta (filtrowanie po meta_value bez indeksu potrafi zamrozić kategorię), wtyczki ładujące skrypty na całej stronie — slider z homepage na stronie kontaktu, koszyk AJAX odpalany globalnie (fragment_cart na każdej podstronie), tysiące wariantów wpisane jako osobne produkty (10 tys. produktów to 10 tys. rekordów w wp_posts).
Do diagnozy: Query Monitor pokazuje wolne zapytania i hooki, slow query log w MySQL wskazuje konkretne zapytania, a przez WP-CLI sprawdzisz autoload opcji: wp option list --autoload=on --format=count. Jeśli autoloadowany zestaw przekracza 1 MB, masz problem do naprawy przed optymalizacją frontu. Podobny zakres prac opisujemy przy optymalizacji WooCommerce w Chełmie. Same progi i sposób interpretacji wyników są zgodne z tym, jak Google opisuje Core Web Vitals w web.dev oraz w dokumentacji Core Web Vitals dla wyników wyszukiwania.
W praktyce integracje zajmują 30–40% czasu wdrożenia i są najczęstszą przyczyną przesunięcia startu. Powód jest banalny: połowa konfiguracji leży po stronie sklepu, a połowa po stronie umów i paneli zewnętrznych, na które nie masz wpływu. Dlatego zakres organizacji wdrożenia WooCommerce w Zamościu ustalamy razem z listą systemów, a nie po fakcie.
Kurierzy. InPost (Paczkomaty + kurier), DPD i DHL wymagają dwóch rzeczy naraz. Po stronie sklepu: integracja z API przewoźnika, mapa punktów w koszyku, strefy wysyłki i klasy wysyłki, waga oraz gabaryty produktu, opłata za pobranie i próg darmowej dostawy. Po stronie przewoźnika: podpisana umowa, identyfikatory dostępowe do API, cennik wgrany do systemu i zgoda na etykiety generowane z panelu. Najczęstsza pułapka: produkt bez wagi i wymiarów — sklep liczy koszt dostawy „na oko” i dokładasz do każdej paczki. Konfigurację stref i metod wysyłki opisuje oficjalna dokumentacja WooCommerce.
Płatności. Przelewy24, PayU, Stripe, BLIK i płatności odroczone mają jedną wspólną cechę: o statusie zamówienia decyduje webhook zwrotny, a nie powrót klienta na stronę. Trzeba więc przetestować cztery scenariusze: udana płatność, porzucenie koszyka, nieudana transakcja i zwrot. Bez tego zamówienia zostają w statusie „oczekuje na płatność”, a klient dzwoni z reklamacją.
ERP i księgowość. Subiekt GT/nexo, Comarch Optima i Fakturownia synchronizują się w dwóch kierunkach: stany i ceny (ERP → sklep), zamówienia i faktury (sklep → ERP). Ustal jedną stronę będącą „właścicielem” ceny i bufor stanów, np. 2 szt. Przy błędzie API zamówienie nie może zniknąć — musi zostać w sklepie z widoczną flagą do ręcznej obsługi.
Zasada nadrzędna: każda integracja musi mieć log zdarzeń i widoczny status ostatniej synchronizacji w panelu. Awaria bez logu wychodzi dopiero z reklamacji klienta, zwykle po kilku dniach.
| Integracja | Kierunek | Co się dzieje przy błędzie | Minimum po stronie firmy |
|---|---|---|---|
| InPost / DPD / DHL | sklep → przewoźnik | brak etykiety, zamówienie wisi w „przygotowanie do wysyłki” | umowa, dane API, cennik, aktualna waga i gabaryty produktów |
| Przelewy24 / PayU / Stripe / BLIK | operator → sklep (webhook) | zamówienie zostaje w statusie „oczekuje na płatność” | konto firmowe, poprawny adres zwrotny, test nieudanej transakcji |
| Subiekt GT/nexo, Comarch Optima | dwukierunkowo | stany się rozjeżdżają, faktura duplikuje się | ustalony bufor stanów i właściciel ceny |
| Fakturownia | sklep → dokument | faktura nie powstaje, klient nie ma dokumentu | dane firmy, stawki VAT, schemat numeracji |
Migracja z PrestaShop, Shopera czy sklepu pisanego na zamówienie to projekt na 2–6 tygodni, a nie „przepisanie bazy”. Największe ryzyko to nie produkty, tylko adresy URL i płatności. Punkty styku z PrestaShopem zebraliśmy osobno w materiale o migracjach z PrestaShop w Zamościu.
Adresy URL i przekierowania. Zanim cokolwiek przeniesiesz, zrób zrzut wszystkich adresów — crawlerem albo z sitemap.xml. Mapowanie robisz raz: reguła dla wzorca /kategoria/produkt → nowy adres, 301 dla kategorii, tagów i stron informacyjnych. Tam, gdzie struktura się powtarza, użyj reguł w .htaccess lub wtyczki do przekierowań; ręczna lista 3 000 adresów to tydzień pracy i gwarancja literówek. Sprawdź też, czy nie tworzą się łańcuchy 301 → 301 → 200.
Kolejność migracji: kategorie → produkty → warianty i stany → klienci → zamówienia historyczne → treści i zdjęcia. Klientów przenosisz tylko z ustaloną podstawą z RODO (umowa albo prawnie uzasadniony interes); haseł nie da się przenieść, więc wymuszasz reset przy pierwszym logowaniu. Zdjęcia zostaw na koniec, bo to zwykle największy wolumen plików.
Test na kopii produkcyjnej. Po imporcie porównaj liczbę SKU, liczbę wariantów, sumę zamówień, stany i ceny. Wylosuj 20 produktów i sprawdź ręcznie cenę, stan, opis, zdjęcia i warianty — to szybsze niż wiara w raport importera. Po przeniesieniu odtwórz dane strukturalne produktów zgodnie z wykazem formatów obsługiwanych przez Google.
Okno wdrożenia. Praca na stagingu, zamrożenie zmian na starym sklepie na 24–48 h przed startem, obniżenie TTL DNS do 300 s dzień wcześniej i gotowy rollback — stary sklep zostaje pod adresem tymczasowym, więc powrót zajmuje kilkanaście minut.
| Etap | Co przenosimy | Kontrola po imporcie |
|---|---|---|
| Kategorie | drzewo, opisy, znaczniki | liczba kategorii, brak „sierot” |
| Produkty i warianty | nazwy, ceny, stany, SKU | porównanie liczby SKU i sumy stanów |
| Klienci | dane kontaktowe i adresy (RODO) | liczba kont, wymuszony reset hasła |
| Zamówienia | historia transakcji i statusy | suma zamówień ze starego sklepu |
| Treści i zdjęcia | strony, wpisy, media | liczba plików, teksty alternatywne, 404 |
Utrzymanie sklepu sprowadza się do trzech rzeczy: kopia, którą da się odtworzyć, aktualizacje, które nie wyłączają sprzedaży, i monitoring, który wie o awarii przed klientem. Poniżej standard, który stosujemy również w sklepach obsługiwanych w okolicach Narola.
Kopie zapasowe. Pełny backup (pliki + baza) co 24 h, retencja minimum 14 dni, kopia poza serwerem sklepu — S3, Backblaze B2 albo macierz w biurze. Raz w miesiącu odtwarzasz kopię na stagingu i sprawdzasz, czy sklep wstaje, czy logowanie działa i czy zamówienia się wyświetlają. Kopia, której nigdy nie testowałeś, nie jest kopią.
Higiena WordPressa. Aktualizacje rdzenia, wtyczek i motywu najpierw na stagingu, potem na produkcji — z kopią przed każdą serią. 2FA dla wszystkich kont administratora, limit prób logowania (np. 5 prób na 15 minut), ograniczenie dostępu do /wp-login.php i /wp-admin po IP lub hasłem na poziomie serwera. W wp-config.php ustaw DISALLOW_FILE_EDIT na true, żeby nikt nie edytował plików z panelu. Usuń nieużywane wtyczki i motywy — każdy to potencjalna luka.
Monitoring. Uptime sprawdzany co 1 minutę, alert przy błędzie PHP 500, pilnowanie terminu certyfikatu SSL (alert 30 dni przed wygaśnięciem) i alert przy zapełnieniu dysku powyżej 85%. Log błędów WooCommerce (WooCommerce → Status → Logi) przeglądasz po każdym nieudanym zamówieniu — tam od razu widać, czy problem jest w płatności, czy w integracji kurierskiej.
Kiedy VPS zamiast hostingu współdzielonego. Gdy ruch przekracza ok. 50 tys. odsłon miesięcznie, potrzebujesz Redisa (object cache), crona uruchamianego co minutę zamiast WP-Cron przy każdym wejściu, niestandardowych rozszerzeń PHP (imagick, intl) albo własnych reguł serwera.
| Element | Standard minimum | Jak sprawdzić |
|---|---|---|
| Backup | co 24 h, retencja 14 dni, kopia offsite | test odtworzenia na stagingu raz w miesiącu |
| Aktualizacje | staging → produkcja, kopia przed serią | lista zmian i data wdrożenia |
| Dostęp | 2FA, limit logowań, DISALLOW_FILE_EDIT | przegląd kont administratora raz na kwartał |
| Monitoring | uptime 1 min, błędy PHP, SSL, dysk | alert na e-mail lub SMS |
| Logi WooCommerce | przegląd po nieudanym zamówieniu | WooCommerce → Status → Logi |
Indeksacja ustawiana „po starcie” to najdroższy scenariusz. Jeśli sklep wyjedzie na produkcję z otwartymi filtrami i koszykiem w indeksie, po miesiącu masz w Search Console tysiące adresów i kilka tygodni sprzątania. Nie chodzi o estetykę — chodzi o crawl budget i o to, żeby Google trafiał na strony kategorii, a nie na 40 kombinacji tego samego filtra. To element projektu wdrożeniowego, tak samo jak podatki czy wysyłki; szerzej opisujemy go w materiale o organizacji wdrożenia WooCommerce w Zamościu.
Indeksacja. Do indeksu mają trafić produkty i kategorie. Poza nim zostaw: koszyk, stronę zamówienia i podziękowania, moje konto, wyniki wyszukiwarki wewnętrznej (?s=) oraz wszystkie adresy z parametrami filtrów (?filter_, ?min_price, ?orderby, ?add-to-cart). Najprościej robi się to wtyczką SEO (Yoast, Rank Math), a wpis w robots.txt traktuje jako zabezpieczenie — blokuje crawling, ale nie usuwa URL-a z indeksu, jeśli już tam trafił.
Duplikaty. Atrybuty produktu (kolor, rozmiar, moc) mają działać jako filtry w obrębie kategorii, a nie jako osobne kategorie typu „kurtki czarne”. Każda taka kategoria to kolejny zestaw tekstów do napisania i konkurent dla kategorii głównej. Produkty zmienne zostawiają jeden URL bazowy, ale kombinacje wariantów potrafią generować adresy z parametrami — ustaw dla nich canonical na produkt nadrzędny albo noindex. Paginację (/page/2/) zostaw z self-canonical i tylko stronę 1 zgłoś w sitemapie.
Dane strukturalne. Minimum to Product, Offer i BreadcrumbList, a przy realnych opiniach AggregateRating. Dwie pułapki wracają w co drugim sklepie: cena w schema podana netto, gdy na stronie widnieje brutto (rozjazd z danymi w Merchant Center i ostrzeżenia w Search Console), oraz availability = InStock przy produkcie, który realnie schodzi 14 dni od dostawcy. Oceny dodawaj tylko wtedy, gdy są widoczne na stronie i pochodzą od klientów. Zakres obsługiwanego markupu sprawdzasz w dokumentacji Google o danych strukturalnych.
Wydajność to też SEO. TTFB 2–3 s przy 5 000 SKU oznacza rzadsze wizyty bota i wolniejsze wykrywanie zmian cen. Cel: TTFB kategorii poniżej 500 ms, cache obiektowy i stronicowy, obrazy w WebP.
| Ustawienie | Wartość przed startem | Dlaczego |
|---|---|---|
| /koszyk/, /zamowienie/, /moje-konto/ | noindex, follow | strony transakcyjne nie mają wartości wyszukiwania |
| ?s=, ?filter_, ?min_price, ?orderby | noindex | jedna kategoria generuje setki kombinacji URL |
| Paginacja /page/2/ | self-canonical, tylko strona 1 w sitemapie | unika kanibalizacji kategorii |
| Warianty produktu | canonical na produkt nadrzędny | cztery kolory to nie cztery produkty w indeksie |
| Sitemap produktów i kategorii | zgłoszona w Search Console, liczba URL = liczba SKU | kontrola przed startem, nie po nim |
SLA podpisane jako „20 godzin miesięcznie” bez rozbicia na reakcję i naprawę to zaproszenie do sporu w pierwszym tygodniu po awarii. Cztery parametry trzeba mieć w umowie: czas reakcji liczony od zgłoszenia, czas naprawy dla awarii krytycznej, zakres godzin wsparcia i kanał zgłoszeń. Realny przykład do wpisania: reakcja 4 h w dni robocze 8:00–16:00, naprawa awarii krytycznej (sklep nie przyjmuje zamówień, błąd 500, padła brama płatnicza) w 8 h roboczych od potwierdzenia, zgłoszenia na dedykowany adres e-mail zapisywany w systemie ticketowym, a nie w Messengerze.
Podział prac. Utrzymanie prewencyjne to aktualizacje WordPressa, wtyczek i motywu (najpierw staging, potem produkcja), backup dzienny z retencją 30 dni i kopią poza serwerem, monitoring uptime z alertem oraz przegląd logów PHP i wc-logs. Raz na kwartał warto wykonać test odtworzenia kopii — backup, którego nikt nie sprawdził, nie jest backupem. Prace rozwojowe (nowy moduł, integracja z Subiektem, zmiana szablonu kategorii) idą poza pakietem i powinny być wyceniane osobno, żeby nie zjadały godzin przeznaczonych na utrzymanie. Jeśli prowadzisz firmę w okolicy, podobny zakres prac opisujemy dla firm z Hrubieszowa, a przy porównywaniu platform — dla wdrożeń i migracji PrestaShop.
Przekazanie po wdrożeniu. Dostępy: hosting, WP admin, DNS, Search Console, panel płatności i kuriera. Dokumentacja konfiguracji: stawki VAT, strefy wysyłek, progi darmowej dostawy, statusy zamówień, reguły zwrotów. Lista wtyczek z licencjami i terminami odnowień — jedna wtyczka Premium zapomniana na rok to częsty powód błędów po aktualizacji. Do tego krótka instrukcja obsługi zamówień dla osoby, która nie zajmuje się sklepem na co dzień.
Jak mierzyć jakość opieki. Proś o jednostronicowy raport miesięczny: liczba incydentów, średni czas przywrócenia po awarii, odsetek aktualizacji wykonanych w terminie, liczba nieudanych backupów.
| Element SLA | Wartość do wpisania | Jak weryfikować |
|---|---|---|
| Czas reakcji | 4 h w dni robocze | znacznik czasu pierwszego zgłoszenia w ticketach |
| Naprawa awarii krytycznej | 8 h roboczych | raport miesięczny z czasem przywrócenia |
| Godziny wsparcia | 8:00–16:00, pon.–pt. | zapis w umowie |
| Godziny rozwojowe | np. 5 h/mies. | miesięczne rozliczenie wykorzystania |
| Backupy | dziennie, retencja 30 dni, kopia offsite | test odtworzenia raz na kwartał |
Traktowanie wdrożenia jako instalacji wtyczki WooCommerce i kilku dodatków.
Jak wykryć: W ofercie jest jedna pozycja „instalacja i konfiguracja sklepu”, brak etapu testów, importu danych i przekazania dokumentacji.
Jak naprawić: Poproś o rozbicie prac na etapy z liczbą godzin: brief, staging, produkty i podatki, płatności i wysyłki, integracje, testy scenariuszowe, start. Wtedy widzisz, co realnie kupujesz.
Praca bezpośrednio na produkcji, bez środowiska staging.
Jak wykryć: Każda zmiana ceny, wtyczki czy szablonu jest natychmiast widoczna w działającym sklepie, a wykonawca nie podaje adresu testowego.
Jak naprawić: Wymagaj stagingu z kopią bazy i osobnymi dostępami oraz ustalonej procedury wdrożenia na produkcję (kopia bazy, okno serwisowe, plan wycofania zmian).
Integracje doklejane na końcu projektu.
Jak wykryć: Umowa nie mówi, kto konfiguruje InPost, Przelewy24 czy ERP, a testy webhooków zwrotnych nie są nigdzie zaplanowane.
Jak naprawić: Wypisz integracje już w briefie: nazwa systemu, po czyjej stronie leży konfiguracja, kto dostarcza klucze API i kto odpowiada za test płatności oraz statusów zamówień.
Import produktów z pliku bez przygotowania danych po stronie firmy.
Jak wykryć: W arkuszu ceny są zapisane jako „12,50 zł”, brakuje SKU, nazwy zdjęć nie odpowiadają produktom, a warianty są opisane w komórkach zbiorczych.
Jak naprawić: Ustal jeden arkusz wzorcowy: SKU, nazwa, opis, cena netto i brutto, stawka VAT, stan magazynowy, kategoria, waga, wymiary, nazwa pliku zdjęcia. Konwersję robi się raz, a nie przy każdej aktualizacji.
Brak jednej osoby decyzyjnej po stronie zamawiającego.
Jak wykryć: Pytania o zdjęcia, opisy i akceptację wyglądu wracają tygodniami, bo odpowiada kilka osób, a każda inaczej.
Jak naprawić: Wyznacz jedną osobę do akceptacji i wpisz do harmonogramu terminy na dostarczenie treści oraz zasadę, że brak decyzji w terminie przesuwa start.
Kupowanie licencji wtyczek jako kosztu jednorazowego.
Jak wykryć: Kosztorys pokazuje opłatę za wtyczkę raz, a po roku wtyczka przestaje się aktualizować i pojawiają się problemy po aktualizacji WordPressa.
Jak naprawić: Rozdziel w budżecie koszt jednorazowy wdrożenia od kosztu stałego: hosting, licencje wtyczek, opieka techniczna. To druga pozycja jest stała, nie pierwsza.
Wdrożenie WooCommerce dla firmy to projekt z jasno określonymi etapami, a nie instalacja wtyczki. Największy wpływ na czas i koszt mają trzy rzeczy: liczba SKU i wariantów, model sprzedaży (B2C, B2B, oba) oraz lista integracji z płatnościami, kurierami i ERP. Rozdziel w budżecie koszt jednorazowy od stałego, a w umowie pilnuj etapu testów, przekazania dostępów i dokumentacji. Jeśli artykuł łączy się z Twoją sytuacją, zajrzyj do omówienia organizacji wdrożeń WooCommerce w Zamościu.
Czas zależy od liczby produktów i integracji, nie od miejsca. Proste wdrożenie B2C to zwykle kilkadziesiąt godzin pracy, sklep B2B z cennikami i integracją ERP to już kilkaset godzin, rozłożonych na kilka tygodni. Do tego dochodzi czas po stronie firmy na dostarczenie danych, zdjęć i decyzji — to najczęstszy powód opóźnień.
Tak, jeśli katalog mieści się w rozsądnej skali, a sprzedaż opiera się na elastycznych modelach: warianty, indywidualne cenniki B2B, nietypowe metody dostawy. Przy katalogu zbliżonym do kilku tysięcy SKU kluczowe staje się uporządkowanie danych i wtyczek, bo tam powstaje większość problemów z wydajnością. Jeśli model sprzedaży jest mocno katalogowy i powtarzalny, warto porównać alternatywy, np. PrestaShop.
Nie. Jednorazowo płacisz za prace wdrożeniowe, a stałe koszty wracają co miesiąc lub co rok: hosting, licencje wtyczek, certyfikat SSL, opieka techniczna. Warto zapisać to w budżecie osobno, bo licencja wtyczki bez odnowienia to działająca wtyczka bez aktualizacji i wsparcia.
Trzy sygnały: brak rozbicia wyceny na godziny, brak etapu testów scenariuszowych i brak zapisu o przekazaniu dostępów oraz dokumentacji. Dodatkowo sprawdź, czy wykonawca pyta o liczbę SKU, wariantów i integracje — jeśli nie, albo nie planuje projektu, albo doliczy to później.
Od pomiaru, nie od wtyczki. Zmierz LCP, INP, CLS i TTFB na prawdziwym katalogu, a potem poprawiaj po kolei: cache stron i obiektowy (Redis lub Memcached), kompresja i formaty WebP/AVIF, krytyczny CSS, lazy loading poza pierwszym ekranem, CDN. Progi, do których warto dążyć, opisuje dokumentacja web.dev.
PageSpeed Insights lub GTmetrix do oceny z zewnątrz, Query Monitor do sprawdzenia zapytań i haczyków w WordPressie, slow query log na serwerze do wyłapania wolnych zapytań MySQL. Autoload opcji sprawdzisz przez WP-CLI, co przydaje się, gdy baza rośnie po każdej nowej wtyczce.
Testy scenariuszowe na stagingu (zamówienie gościa, kod rabatowy, płatność nieudana, zwrot), poprawne stany magazynowe, działające webhooki płatności i kurierów, kopie zapasowe oraz przekazane dostępy. Start bez tej listy oznacza, że pierwsze błędy naprawiasz na oczach klientów.
Jeśli chcesz przejść przez brief, wycenę i harmonogram bez zgadywania, napisz do nas — powiemy wprost, co ma sens w Twoim asortymencie, a czego nie warto robić.