Wdrożenie czy optymalizacja? Jak wybrać właściwą ścieżkę dla sklepu

Pierwsze pytanie w projekcie nie brzmi „ile to kosztuje”, ale „naprawiamy czy budujemy od zera”. Odpowiedź da się ustalić na jednym spotkaniu, jeśli spojrzysz na cztery rzeczy: stabilność ruchu, konwersję, liczbę SKU i stan wtyczek.

Optymalizacja ma sens, gdy zachodzą co najmniej trzy warunki:

• Ruch jest stabilny — od 3 miesięcy widzisz powtarzalne sesje, a nie skok po jednej kampanii. Optymalizacja bez ruchu to zgadywanie, którego nie zmierzysz.
• Konwersja mieści się w normie branżowej — w sklepach detalicznych to zwykle 0,8–2%. Jeśli jesteś w tej widełce, wąskim gardłem jest szybkość i ścieżka zakupu, nie oferta.
• Katalog to mniej niż 300 SKU i nie rośnie skokowo o tysiące pozycji.
• Wtyczki są aktywnie wspierane — ostatnia aktualizacja w ciągu 6 miesięcy, zgodność z aktualnym WordPressem i wersją PHP.

Wdrożenie od zera lub migracja będzie tańsze, gdy:

• Sklep trzyma zamówienia w starym storage — brak HPOS (High-Performance Order Storage) przy kilkudziesięciu tysiącach zamówień oznacza wolne raporty i blokady tabel.
• Masz tysiące produktów wpisanych ręcznie, bez atrybutów i wariantów — uporządkowanie tego w miejscu kosztuje więcej niż czysty import.
• Wtyczki nie mają wsparcia od lat, a część to dodatki pisane „na chwilę” przez poprzedniego wykonawcę.
• Baza ma duplikaty zamówień, klientów i wpisów meta — każda aktualizacja kończy się błędem.

Zasada kosztu ukrytego: godzina przy nowym wdrożeniu zostaje w projekcie. Godzina przy naprawie starego sklepu często kończy się cofnięciem zmiany, bo kolejny błąd w bazie wychodzi po dwóch dniach. Praktyczny punkt opłacalności wypada wtedy, gdy szacowany czas naprawy zbliża się do połowy czasu wdrożenia od zera — od tego momentu płacisz dwa razy: raz za łatę, raz za obejście.

Pełny zakres prac po stronie wykonawcy znajdziesz w sekcji usługi WooCommerce — traktuj go jako punkt wyjścia do porównania ofert.

Wdrożenie WooCommerce krok po kroku — 7 etapów i realny czas

Widełki poniżej to czas pracy zespołu (wdrożeniowiec, front, dev od integracji), nie czas kalendarzowy. Dla standardowego sklepu sumują się do 52–126 godzin. Każdy etap ma definicję ukończenia — bez niej etapu nie da się rozliczyć.

• 1. Audyt i zakres — 4–8 h. Spis wtyczek, mapowanie procesów (koszyk, płatność, dostawa, faktury, e-maile transakcyjne), lista integracji i kryteria akceptacji. Zamknięte, gdy istnieje dokument z zakresem i wyraźnym poza-zakresem.
• 2. Środowisko i hosting — 6–10 h. Osobna produkcja i staging, PHP zgodne z wymaganiami WooCommerce, WP-CLI, poprawny cron, kopie zapasowe, SSL, przekierowania. Zamknięte, gdy staging jest kopią produkcji i obie instancje mają działający backup.
• 3. Konfiguracja bazowa i szablon — 12–20 h. Waluty, strefy podatkowe, strefy wysyłki, metody dostawy, e-maile, strony regulaminowe, szablon. Zamknięte, gdy pełna ścieżka testowa „produkt → koszyk → zamówienie” przechodzi bez błędów.
• 4. Integracje płatności i kurierów — 10–24 h. Bramki płatności i API kurierskie w trybie sandbox. Zamknięte, gdy każda metoda ma wykonaną transakcję testową oraz test zwrotu i anulowania.
• 5. Dane produktowe — 8–40 h. Import z pliku, warianty, atrybuty, stany, zdjęcia. Zamknięte, gdy liczba pozycji w sklepie zgadza się z plikiem źródłowym, a losowa próba 20 produktów przechodzi kontrolę.
• 6. Testy i odbiór — 8–16 h. Testy na urządzeniach, wydajność, koszyk porzucony, formularze. Zamknięte po podpisaniu checklisty odbioru.
• 7. Start i monitoring — 4–8 h. Przeniesienie na produkcję, indeksacja, monitoring błędów i czasu odpowiedzi. Zamknięte, gdy pierwsze realne zamówienie przechodzi całą ścieżkę.

Klient dostarcza przed startem: dane produktowe (CSV/XML z SKU, ceną, stanem, atrybutami), zdjęcia w docelowej rozdzielczości, regulaminy i politykę prywatności, dane do faktur, dostępy do domeny i DNS.

Środowisko staging jest obowiązkowe, podobnie jak zasada: żadna zmiana nie wchodzi na produkcję bez testu na kopii z danymi. Sandbox płatności nie wystarczy — testuj na klonie z realnymi zamówieniami, bo tam wychodzą błędy podatków i wysyłek. Szczegóły techniczne znajdziesz w dokumentacji WooCommerce, a szerszy kontekst projektu w sekcji zakres wdrożenia sklepu internetowego.

Ile kosztuje wdrożenie i optymalizacja WooCommerce? Widełki, nie cennik z sufitu

Wycena jednej kwoty „za sklep” jest nieweryfikowalna. Weryfikowalna jest liczba godzin pomnożona przez stawkę. Poniższe widełki wynikają z sumy siedmiu etapów opisanych wyżej, przy założeniu, że etap danych produktowych skaluje się razem z katalogiem. Traktuj je jako planowanie budżetu, nie jako ofertę.

Co podnosi wycenę najbardziej:

• liczba integracji — każde API płatności, kuriera, magazynu czy księgowości to osobne prace i osobne testy,
• moduły niestandardowe — np. konfigurator produktu albo indywidualny kalkulator dostawy,
• migracja danych ze starej platformy — wymaga mapowania pól i czyszczenia bazy przed importem,
• wielojęzyczność — podwaja pracę przy treściach, e-mailach i podatkach,
• nietypowe reguły dostawy i rabatów — darmowa dostawa od progu łączonego z kodem rabatowym to klasyczne miejsce na błędy.

Dlaczego rozliczenie z godzin chroni klienta: zakres zmienia się w prawie każdym projekcie. Przy stałej kwocie wykonawca albo zataja zmianę, albo ucina zakres, żeby zmieścić się w budżecie. Przy rozliczeniu godzinowym widzisz, ile kosztuje każda zmiana, zanim zostanie wykonana. W umowie wymagaj dwóch rzeczy: limitu godzin na etap (żeby projekt nie uciekł w nieskończoność) oraz pisemnej listy zmian w zakresie — każda zmiana zatwierdzona przed wykonaniem, z podaną liczbą godzin.

W miesięczne utrzymanie wchodzi zwykle: aktualizacje WordPressa, WooCommerce i wtyczek, kopie zapasowe, monitoring dostępności i czasu odpowiedzi, poprawki błędów po stronie wykonawcy, podstawowe wsparcie.

Ekstra rozliczane są: nowe funkcje i moduły, dodatkowe integracje, migracje, kampanie sezonowe (np. przygotowanie sklepu pod Black Friday), prace wydajnościowe poza budżetem utrzymania.

Optymalizacja WooCommerce: co realnie przyspiesza sklep, a co jest mitem

Zanim ruszysz motyw, wtyczki czy obrazy, zmierz punkt startowy. W Search Console otwórz raport „Core Web Vitals” i zapisz, ile adresów jest w grupie „do poprawy” na mobile. Potem PageSpeed Insights na trzech reprezentatywnych stronach: główna, kategoria z kilkudziesięcioma produktami, karta produktu z wariantami. Do tego TTFB z serwera (np. curl -s -o /dev/null -w '%{time_starttransfer}') oraz liczba zapytań SQL na stronę produktu i kategorii — Query Monitor pokaże je w stopce razem z czasem i źródłem. Jeśli kategoria generuje 250–300 zapytań, żadna kompresja zdjęć tego nie naprawi.

Dźwignie, które realnie zmieniają wynik, w kolejności zwrotu z nakładu:

• cache obiektowy (Redis lub Memcached) — największy efekt na kartach produktu i koszyku. Wymaga pliku object-cache.php i poprawnego WP_CACHE_KEY_SALT, inaczej staging i produkcja będą mieszać dane.
• HPOS (High-Performance Order Storage) — zamówienia w dedykowanych tabelach zamiast w wp_posts i wp_postmeta. Najpierw test na staging, bo starsze wtyczki potrafią czytać zamówienia po metadanych i przestają działać.
• Czyszczenie wp_options z autoload i tabel transients — w sklepie działającym trzy lata to często setki MB. Ustaw limit i zadanie cron, żeby problem nie wrócił po miesiącu.
• WebP/AVIF generowane na serwerze, nie tylko podmieniane w przeglądarce wtyczką.
• Lazy loading dla zdjęć poniżej pierwszego ekranu. Nigdy na obrazie LCP — to najczęstszy błąd po tanich audytach.
• CDN dla statyków i cache stron dla niezalogowanych.

Progi, do których warto dążyć: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 dla 75. percentyla realnych użytkowników. Kolejność prac ma znaczenie: najpierw serwer i baza (PHP, MySQL, cache obiektowy), potem kod i motyw (nieużywane wtyczki, własne zapytania), na końcu front-end. Odwrotna kolejność oznacza, że za dwa tygodnie i tak wrócisz do punktu wyjścia, tylko z mniejszym budżetem. Przed włączeniem cache sprawdź na staging: koszyk po dodaniu produktu, aktualność ceny po zmianie w panelu, stany magazynowe po zamówieniu, stronę „moje konto” dla zalogowanego klienta. Cache stron dla zalogowanych to najprostsza droga do gubionego koszyka i nieaktualnych cen — wyłapiesz to tylko ręcznym testem, nie audytem. Zakres takich prac opisujemy w sekcji WooCommerce.

Integracje: płatności, InPost/DPD/DHL i ERP — co zrobić raz i dobrze

Integracja psuje się nie w dniu wdrożenia, a trzy tygodnie później — przy pierwszym zwrocie albo przy zamówieniu z płatnością odroczoną. Dlatego zacznij od mapy statusów, nie od wtyczki. Statusy WooCommerce, płatności i przesyłki to trzy różne słowniki i muszą mieć jawne przełożenie. Każdy stan, który nie mapuje się jednoznacznie, jest z definicji obsługiwany ręcznie — i lepiej policzyć teraz, ile takich zamówień będzie dziennie, niż odkryć to w poniedziałek rano.

Kierunek przepływu danych w integracji z ERP ustal na piśmie. Zwykle ERP jest źródłem prawdy o stanie magazynowym, ale nie zawsze o cenie sprzedaży — jeśli sklep trzyma promocje, import ceny z ERP je skasuje. Zapisz, kto wygrywa w każdym polu, i z jaką częstotliwością leci synchronizacja: stany co 5–15 minut, kartoteka raz na dobę, zamówienia natychmiast. Przy sprzedaży równoległej (sklep + kanał offline) synchronizacja raz na godzinę kończy się nadprzedażą i reklamacjami.

Zachowanie przy niedostępności API: żadne zamówienie nie może zniknąć. Potrzebna jest kolejka z ponowieniami (np. 3 próby: 1 min, 5 min, 30 min), zapisem błędu i powiadomieniem na maila obsługi. Jeśli kurier nie odpowiada, zamówienie zostaje w statusie „przetwarzane” z flagą „etykieta do wygenerowania” — nie w „wysłane”. Jeśli ERP nie odpowiada, sklep sprzedaje dalej na ostatnim znanym stanie i przyjmuje ryzyko nadprzedaży albo blokuje produkty poniżej progu.

Test na realnym zamówieniu: płatność 1 zł, wygenerowanie etykiety, wydruk, zwrot, faktura korygująca, anulowanie po opłaceniu. Pułapki, które widzimy najczęściej: duplikaty przesyłek przy ponowieniu requestu, brak idempotencji po stronie kuriera, nieaktualne stany przy dwóch zamówieniach w tej samej minucie i brak obsługi zamówień zagranicznych (inne formaty adresu, inne ceny przesyłek, VAT OSS). Punkt wyjścia do prac integracyjnych opisujemy w sekcji sklepy internetowe. Dokumentację mechanizmów zamówień i statusów znajdziesz w dokumentacji WooCommerce.

Migracja na WooCommerce bez utraty pozycji w Google

Pozycje zabiera nie sama zmiana platformy, a brak mapy adresów. Przed przeniesieniem czegokolwiek wyeksportuj pełną listę URL-i: z Search Console (raporty „Wydajność” i „Indeksowanie stron”), z sitemap.xml oraz crawlem — Screaming Frog na 500–2000 adresów, zależnie od wielkości sklepu. Na liście muszą być nie tylko produkty i kategorie, ale też filtry (?filter_...), paginacja, wpisy blogowe i strony statyczne. Każdy adres dostaje jeden wiersz: stary URL → nowy URL → typ reguły (1:1, wzorzec, brak odpowiednika).

Przekierowania 301 wdrażaj na poziomie serwera — w nginx albo .htaccess, nie wtyczką w WordPressie. Wtyczka dokłada zapytanie do bazy przy każdym wejściu na nieistniejący adres i przy kilku tysiącach przekierowań sama staje się wąskim gardłem. Filtry i paginację obsłuż inaczej niż produkty: filtrom ustaw noindex i canonical na wersję bez parametrów, paginację zostaw jako linki do kolejnych stron z self-canonical.

Najczęstszy błąd: przekierowanie wszystkich starych adresów na stronę główną. To kasuje widoczność kategorii — zamiast strony kategorii z 200 produktami Google dostaje sygnał, że temat już nie istnieje, a użytkownik ląduje na stronie bez treści, której szukał. Drugi błąd to przekierowanie wyłącznie produktów bez kategorii i wpisów blogowych, które generują ruch informacyjny.

Kolejność: staging → testy przekierowań (crawl po wdrożeniu) → wdrożenie na produkcję z przekierowaniami w tym samym momencie → zgłoszenie sitemap.xml w GSC → 30 dni monitoringu z cotygodniowym raportem 404. Po migracji sprawdź linki wewnętrzne (czy nie prowadzą do starych adresów), dane strukturalne typu Product i Offer zgodnie z dokumentacją Google, canonical oraz czas ładowania strony kategorii — po przejściu na nowy motyw kategoria potrafi zwolnić o sekundę. Harmonogram takich migracji rozpisujemy w sekcji wdrożenia i optymalizacja WooCommerce — organizacja.

SEO techniczne i widoczność lokalna sklepu (Toruń i kujawsko-pomorskie)

Pierwsze 30 dni po wdrożeniu to okres, w którym sprawdzasz nie „czy SEO działa”, ale cztery konkretne raporty w Search Console — i to na właściwości domenowej, nie na prefiksie URL. Filtr geograficzny pokazuje kraj, nie miasto, więc frazy lokalne łapiesz, dopisując „Toruń” i „kujawsko-pomorskie” do raportu zapytań i pilnując ich osobno. Tydzień po starcie nie zobaczysz tam 20 zapytań z samego Torunia i żaden wykonawca nie powinien Ci tego obiecywać.

Core Web Vitals liczone są z realnych sesji użytkowników (75. percentyl), więc przy kilkudziesięciu odsłonach dziennie próbka jest za mała, by wyciągać wnioski — pomocniczo użyj testu pojedynczego adresu. Jeśli LCP na karcie produktu przekracza 2,5 s, sprawdź po kolei: zdjęcia wgrane w oryginalnym rozmiarze, wtyczki ładowane globalnie na każdej podstronie, brak cache dla zalogowanych klientów. Metodologię i progi opisuje dokumentacja Core Web Vitals w Google Search Central.

Dane strukturalne, które realnie się wyświetlają: Product i Offer na karcie produktu, AggregateRating wyłącznie z opinii zbieranych we własnym sklepie, LocalBusiness z adresem punktu i godzinami. Nie oznaczaj gwiazdek, których nie masz, i nie wklejaj ocen z Allegro czy Ceneo — to najkrótsza droga do ręcznego działania.

Elementy lokalne działają na konwersję, nie na pozycje: strona dostawy i płatności z deklarowanym czasem dostawy dla Torunia i Bydgoszczy (np. 1–2 dni robocze), lista punktów odbioru, identyczne dane firmy w stopce, na stronie kontaktu, w LocalBusiness i na dokumentach sprzedaży.

Najczęstszą przyczyną braku widoczności jest jednak treść: opisy producenta skopiowane w całości na 400 produktów i puste kategorie bez ani jednego zdania. Jeśli dokładasz opisy i porządkujesz strukturę kategorii jako osobny etap, zakres takich prac rozbijamy na kroki w organizacji wdrożenia i optymalizacji WooCommerce.

10 pułapek po wdrożeniu WooCommerce i jak je wykryć w 15 minut

Poniższą listę przechodzisz zaraz po odbiorze prac, na produkcji, bez zaglądania w kod. Każdy wiersz to objaw, prawdopodobna przyczyna, narzędzie do diagnozy i szybka naprawa.

Objaw	Prawdopodobna przyczyna	Narzędzie	Szybka naprawa
Zamówienia z płatnością online zostają w statusie „Oczekująca na płatność”, maile nie wychodzą	Zadania cykliczne WP nie odpalają się — brak ruchu na stronie lub DISABLE_WP_CRON w wp-config.php	WP Crontrol: lista zadań i kolumna „następne uruchomienie”	Przełączyć na cron systemowy co 5 minut, wyłączyć WP-Cron w wp-config.php
Koszyk pusty po dodaniu produktu, u innej osoby działa	Page cache obejmuje /cart, /checkout, /moje-konto	Nagłówki odpowiedzi (HIT/MISS) + Query Monitor	Wykluczyć te adresy oraz ciasteczka woocommerce_cart_hash i woocommerce_items_in_cart
Jedna płatność, dwa zamówienia	Klient ponowił płatność lub webhook przetworzył się dwukrotnie	Panel operatora płatności (historia transakcji) vs lista zamówień	Porównać ID transakcji, dodać blokadę duplikatów po identyfikatorze płatności
Promocja -20% startuje dzień wcześniej wieczorem	Strefa czasowa WordPressa inna niż strefa serwera, harmonogram zapisany w UTC	Ustawienia → Ogólne + ustawienia harmonogramu we wtyczce	Ustawić Europe/Warsaw i przeliczyć daty startu oraz końca promocji
Baza rośnie o kilkaset MB miesięcznie bez nowych zamówień	Wygasłe rekordy w tabeli wp_options (transients)	WP-CLI: wp transient list --expired	Wyczyścić, znaleźć wtyczkę tworzącą transienty bez daty wygaśnięcia, wyłączyć ją
Biały ekran tylko na jednej karcie produktu	Błąd PHP przy wyłączonym WP_DEBUG_DISPLAY	Log błędów PHP na serwerze + Query Monitor	Włączyć logowanie, poprawić błąd, ustawić memory_limit zgodnie z wymaganiami WooCommerce
Klient nie dostaje potwierdzenia, w panelu zamówienie jest	Maile idą funkcją mail() i trafiają do spamu	Log wysyłki wtyczki SMTP, test SPF/DKIM	Skonfigurować SMTP z domeny sklepu i wysłać test na Gmaila oraz Outlooka
Checkout nie przechodzi dalej, bez komunikatu	Błąd JavaScript blokujący skrypt podsumowania	Konsola błędów przeglądarki i zakładka Network	Wyłączyć wtyczkę modyfikującą checkout, poprawkę wdrożyć najpierw na stagingu
Stany magazynowe rozjeżdżają się z magazynem	Brak synchronizacji z panelem kuriera lub ERP albo podwójne odejmowanie przy anulowaniu	Panel kuriera + historia zmian stanu produktu	Ustalić jedno źródło prawdy dla stanów i wyłączyć zapis w pozostałych miejscach
Sklep był niedostępny 40 minut i nikt o tym nie wiedział	Brak monitoringu i backupu	Sprawdź, czy istnieje zewnętrzny uptime monitor i data ostatniej kopii	Włączyć monitor co minutę i backup dzienny z retencją 30 dni

Osobno wykonaj test zamówienia end-to-end na produkcji, na kwotę 1 zł, własną kartą: dodanie produktu do koszyka, kod rabatowy, płatność, wygenerowanie etykiety w panelu kuriera, mail do klienta, dokument sprzedaży (faktura lub paragon). Każdy krok zapisz z godziną i wynikiem. W raporcie odbioru powinny znaleźć się: wynik tego testu, lista znanych ograniczeń (np. „integracja z magazynem działa tylko w godzinach 6–22”), potwierdzenie podłączenia monitoringu wraz z dostępem do niego oraz wskazanie, kto odbiera powiadomienia o awarii. Mechanika zadań cyklicznych WooCommerce opisana jest w dokumentacji WooCommerce.

Opieka po wdrożeniu i wybór wykonawcy — pytania, SLA, koszty

Zanim podpiszesz umowę, zadaj dziesięć pytań i zapisz odpowiedzi w mailu:

1. Kto po odbiorze ma dostępy do serwera, WordPressa i panelu płatności — czy ja również?
2. Jak wygląda przekazanie pracy: lista wtyczek z wersjami, dokumentacja, dane w menedżerze haseł?
3. Kto wykonuje aktualizacje WP, wtyczek i PHP — najpierw na stagingu czy bezpośrednio na produkcji?
4. Jak zgłaszam awarię: mail, formularz, telefon — w jakich godzinach?
5. Jaki jest czas reakcji i czym różni się od czasu naprawy?
6. Co obejmuje abonament, a co jest płatne dodatkowo (nowa funkcja, migracja, integracja)?
7. Gdzie są backupy, jak często i jaka jest retencja?
8. Kiedy ostatnio odtwarzaliście kopię na środowisku testowym i jaki był wynik?
9. Czy dostanę raport miesięczny: dostępność, wykonane prace, czasy reakcji?
10. Co się dzieje, gdy nie przedłużam abonamentu — w jakim stanie zostaje sklep?

SLA nie musi być rozbudowane, ale musi mieć rozróżnienie priorytetów i kanał zgłoszeń. Typowy podział wygląda tak:

Priorytet	Przykład	Czas reakcji (do)
Krytyczny	Sklep nie przyjmuje zamówień lub nie działa płatność	2 h w godzinach 8–18
Wysoki	Błędne ceny, część metod płatności nie działa	4 h w dniu roboczym
Normalny	Błąd wyświetlania, literówka w treści	1 dzień roboczy
Niski	Drobna zmiana lub nowa funkcja	3–5 dni roboczych

Kiedy abonament jest tańszy niż etat? Licz w godzinach, nie w złotówkach. Pełny etat to około 160 godzin miesięcznie, a typowa opieka nad sklepem to 5–15 godzin. Jeśli regularnie potrzebujesz ponad 40 godzin prac rozwojowych miesięcznie, taniej wychodzi własny specjalista albo freelancer na godziny — ale wtedy Ty odpowiadasz za backup, aktualizacje i monitoring. Abonament kupujesz wtedy, gdy potrzebujesz kogoś, kto odpowie o 9:00 w poniedziałek.

Praca zdalna z firmą spoza Torunia nie jest wadą. Znaczenie mają: komunikacja (jeden kanał zgłoszeń, potwierdzenie przyjęcia zgłoszenia), SLA i dostępność w godzinach pracy Twojego sklepu. Odległość nie ma znaczenia — poza trzema sytuacjami: warsztatem ustalającym zakres, przekazaniem dostępów przy odbiorze oraz problemem z integracją sprzętową (kasa fiskalna, terminal, czytnik w magazynie). Wtedy spotkanie na miejscu skraca sprawę z dni do godzin. Zakres typowej opieki nad sklepem opisujemy przy usłudze WooCommerce.

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

Lista kontrolna do odklikania

• Zakres na piśmie — Przed podpisaniem umowy: lista funkcji, integracji, liczba SKU i wersji językowych. Brak tego dokumentu to najczęstsze źródło sporów w drugim miesiącu prac.
• 7 etapów z widełkami godzin — Sprawdź, czy oferta rozbija pracę na: audyt i zakres (4–8 h), środowisko i hosting (6–10 h), konfiguracja bazowa i szablon (12–20 h), integracje płatności i kurierów (10–24 h), dane produktowe (8–40 h), testy i odbiór (8–16 h), start i monitoring (4–8 h). Łącznie 52–126 roboczogodzin.
• Limit godzin na etap i stawka za nadwyżkę — Ustal przy podpisywaniu umowy. Bez tego każda zmiana zakresu jest negocjowana od zera, zwykle w trakcie prac, kiedy nie masz czasu na analizę.
• Środowisko staging — Weryfikuj przed pierwszym wdrożeniem kodu: poproś o adres kopii i dostęp. Kopia musi mieć dane, nie tylko wygląd — inaczej nie przetestujesz zamówienia ani faktury.
• Dostępy do domeny i DNS — Sprawdź, czy masz dane logowania do rejestratora domeny i panelu DNS. Wykonawca może je otrzymać, ale właścicielem konta powinieneś pozostać Ty.
• Dane produktowe i zdjęcia — Termin dostarczenia ustal przed startem etapu danych. Zdjęcia w docelowej rozdzielczości, opisy z cenami i stanami. Przy 300 SKU to zwykle kilka dni pracy po Twojej stronie.
• Regulaminy i dokumenty prawne — Regulamin, polityka prywatności, informacja o prawie odstąpienia. Sprawdź przed konfiguracją checkoutu — brak tych treści blokuje start, a nie jest pracą wykonawcy.
• Dane do faktur i konfiguracja podatków — Sprawdź, czy stawki VAT, kraje dostawy i dane firmy są zgodne z tym, co wysyłasz do księgowości. Test: wygeneruj fakturę na stagingu i porównaj z obecnym wzorem.
• Lista integracji: płatności i kurierzy — Ustal, które metody płatności i których kurierów wdrażacie w pierwszej wersji, a co jest na później. Każda dodatkowa integracja to osobne godziny i osobny test.
• Scenariusze testowe przed startem — Przed odbiorem: zamówienie z przedpłatą, za pobraniem, z kodem rabatowym, z darmową dostawą od progu, zwrot. Wszystkie przechodzą na stagingu bez błędów.
• Definicja ukończenia dla każdego etapu — Sprawdź, czy wykonawca podał konkretne, testowalne warunki zamknięcia etapu. Bez tego rozliczenie za etap jest kwestią uznaniową.
• Kopie zapasowe i monitoring — Ustal w etapie „start i monitoring”: częstotliwość kopii, miejsce przechowywania, kto reaguje na alert o niedostępności sklepu. Zweryfikuj, przywracając kopię na staging.
• Pomiar bazowy przed optymalizacją — Jeśli optymalizujesz istniejący sklep, zrób pomiar przed zmianami: Core Web Vitals w Search Console, PageSpeed Insights, TTFB, liczba zapytań SQL na stronie produktu i kategorii. Bez punktu odniesienia nie ocenisz efektu.
• Plan na po starcie — Ustal, kto i w jakim czasie reaguje na błędy po uruchomieniu oraz co wchodzi w miesięczne utrzymanie. Zapisz to osobno od zakresu wdrożenia.

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