Czym jest utrzymanie i opieka techniczna sklepu – definicja bez marketingowego bełkotu

Najczęstszy błąd przy podpisywaniu umowy to wrzucenie do jednego worka trzech różnych rzeczy: hostingu, utrzymania i rozwoju. Na fakturze wyglądają podobnie, ale odpowiadają za co innego i inne są za nie stawki.

• Hosting (infrastruktura) – serwer, dysk, poczta, certyfikat SSL, kopie na poziomie całego konta. Dostawca odpowiada za to, że maszyna działa.
• Utrzymanie (aplikacja) – PrestaShop lub WooCommerce: baza danych, moduły, wtyczki, szablon, konfiguracja bezpieczeństwa. Za to odpowiada wykonawca opieki, nie hosting.
• Rozwój (nowe funkcje) – nowy moduł, integracja z ERP, przebudowa szablonu, nowa bramka płatności. To projekt wyceniany osobno, nie część stałego abonamentu.

Granica bywa płynna i tu robi się najwięcej sporów. Awaria bazy danych to utrzymanie. Przekroczenie limitu miejsca na serwerze to hosting. Wolno działający sklep, gdy w katalogu są 302 produkty — najczęściej wina konfiguracji aplikacji, czyli utrzymania.

Sześć filarów opieki, które powinny znaleźć się w każdej ofercie dla sklepu w Biłgoraju:

1. Kopie zapasowe — pliki i baza, przechowywane poza serwerem produkcyjnym.
2. Aktualizacje — rdzeń, moduły, szablon, w kontrolowanej kolejności.
3. Bezpieczeństwo — WAF, limity logowania, skan malware.
4. Wydajność — czas ładowania, cache, baza, obrazy.
5. Monitoring — dostępność i błędy, z alertami.
6. Wsparcie — kanał kontaktu z określonym czasem reakcji.

Czego opieka nie obejmuje: dodawania produktów, prowadzenia kampanii marketingowych, zmian graficznych i treściowych. Nie dlatego, że wykonawca tego nie umie — te zadania zajmują czas, którego nie ma w abonamencie. Bez zapisu w umowie po dwóch miesiącach okaże się, że „opieka” oznacza dla klienta 40 opisów produktów i banner na święta, a dla wykonawcy pięć godzin pracy nad kopiami. Zakres pracy nad aplikacją ustalasz osobno, zlecenia dodatkowe osobno. Jak wygląda to punkt po punkcie, widać w zestawieniu opieki nad sklepem w Zamościu.

Co wchodzi w zakres opieki technicznej sklepu – rozbicie na konkretne czynności

Zakres opieki najłatwiej porównać, gdy rozpiszesz go na czynności z częstotliwością. Poniżej realny rytm pracy dla sklepu na PrestaShop lub WooCommerce z kilkuset zamówieniami miesięcznie.

Kopie zapasowe. Minimum raz dziennie, w praktyce dwa elementy: pliki i dump bazy. Retencja 30 dni — dłużej rzadko ma sens, bo rośnie koszt przechowywania. Kopia musi leżeć poza serwerem produkcyjnym. Raz na kwartał wykonaj test odtworzenia: wgraj kopię na staging i sprawdź, czy sklep startuje, czy koszyk działa i czy ostatnie zamówienia są w bazie. Kopia, której nikt nie odtworzył, nie jest kopią.

Aktualizacje. Kolejność: rdzeń → moduły/wtyczki → szablon. Zasada: najpierw staging, potem produkcja. Jeden moduł na raz, z zapisem numeru wersji sprzed zmiany. Moduły PrestaShop potrafią nadpisywać pliki w /themes, dlatego po aktualizacji sprawdza się kartę produktu, koszyk i płatność, a nie tylko stronę główną. Po wdrożeniu na produkcję: kopia i zamówienie testowe.

Bezpieczeństwo. WAF przed sklepem (najczęściej Cloudflare), limit prób logowania do panelu, np. 5 prób na 15 minut, 2FA dla kont administratora, skan malware i kontrola sum kontrolnych plików — w WooCommerce robi to wp core verify-checksums, w PrestaShop porównanie plików z repozytorium. Osobny alert na zmianę .htaccess i utworzenie nowego konta admina.

Wydajność. Punkt odniesienia: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — progi opisane w dokumentacji Web Vitals od web.dev. W praktyce: cache (LiteSpeed Cache, moduł cache PrestaShop), CDN, porządki w bazie (indeksy, tabele statystyk, porzucone koszyki), konwersja obrazów do WebP.

Monitoring i kontakt. Uptime sprawdzany co minutę, alerty na błędy 500 i na spadki konwersji, kanał zgłoszeń z czasem reakcji — np. 4 h w dni robocze. Bez tego opieka jest reaktywna i o awarii dowiadujesz się od klienta. Ten sam rytm pracy stosujemy przy opiece nad sklepami w Józefowie.

Ile kosztuje utrzymanie sklepu w Biłgoraju i na Lubelszczyźnie – realne widełki 2025

Pakiety opieki w Biłgoraju i okolicy mieszczą się w 2025 roku w trzech progach. Wszystkie ceny to stawki netto miesięcznie.

Poza pakietem zostają prace interwencyjne: zwykle 120–220 zł netto za godzinę. Jeśli wykonawca daje w pakiecie za 1000 zł pulę 5 godzin, efektywnie płacisz 200 zł/h, ale z gwarancją reakcji i znajomością systemu. To zwykle lepsza opcja niż szukanie firmy w dniu, w którym sklep przestał przyjmować zamówienia.

Co wpływa na cenę: liczba modułów (sklep na PrestaShop z 12 modułami to inny zakres testów niż z 45), miesięczny ruch, liczba integracji (ERP, Subiekt, Baselinker, płatności, kilku kurierów), obecność środowiska staging, liczba języków i walut. Każdy moduł to osobne ryzyko konfliktu przy aktualizacji — mechanizm nadpisywania szablonów przez moduły opisuje dokumentacja deweloperska PrestaShop.

Uwaga o ofertach „opieka za 99 zł/mies.”. Za 99 zł da się kupić płatny monitoring uptime i automatyczną kopię w chmurze — i na tym budżet się kończy, bo to około 30–40 minut pracy specjalisty. Nie ma w tym testu odtworzenia kopii, nie ma pracy przy aktualizacjach modułów i nie ma nikogo, kto reaguje na błąd 500 w piątek po 16:00. Jeśli oferta jest bardzo tania, zapytaj wprost: kto i kiedy wykonuje kopie, gdzie leży reguła WAF i jaki jest czas reakcji. Dla porównania z sąsiednim rynkiem zobacz, jak wyglądają stawki w zestawieniu opieki WordPress w Lublinie: ceny i zakres.

SLA i czas reakcji – co powinno być w umowie, żeby działało

W umowie o opiekę techniczną liczą się dwie liczby i jedno zdanie definiujące. Pierwsza liczba to czas reakcji (response) – ile czasu mija od zgłoszenia do momentu, w którym ktoś realnie zaczyna pracę i odpisuje. Druga to czas naprawy (resolution) – kiedy problem jest usunięty. Zapis „reakcja do 2 godzin” bez drugiej liczby nic nie znaczy: reakcja może być natychmiast, a naprawa dopiero za tydzień.

Druga pułapka to brak definicji priorytetu. „Incydent krytyczny” trzeba opisać wprost: sklep nie przyjmuje zamówień, płatność kończy się błędem, strona główna zwraca 500, brak dostępu do panelu administracyjnego. Spowolnienie strony o 30% nie jest incydentem krytycznym – i dobrze, żeby tak było zapisane, bo inaczej każdy telefon staje się krytyczny. Zwróć też uwagę na godziny: „reakcja do 2 h” w dni robocze 8:00–16:00 oznacza, że zgłoszenie z piątku 15:30 może zostać obsłużone w poniedziałek rano. To nie oszustwo, to zapis – ale trzeba go przeczytać przed podpisaniem umowy. Opieka 24/7 kosztuje zwykle 2–3 razy więcej i w sklepie z kilkunastoma zamówieniami dziennie rzadko się zwraca.

Priorytet	Co się dzieje	Czas reakcji	Czas naprawy
Krytyczny	Sklep nie sprzedaje: błąd płatności, 500 na stronie głównej, brak dostępu do panelu	1–2 h w godzinach pracy	do 8 h roboczych
Wysoki	Nie działa część funkcji: np. jeden kurier, jeden formularz	4 h	do 2 dni roboczych
Normalny	Poprawki kosmetyczne, zmiany treści, drobne błędy wizualne	1 dzień roboczy	następne wydanie prac

Kanał zgłoszenia musi być zapisany. Trzy warianty: wspólny adres e-mail, telefon jako eskalacja oraz panel ticketowy. Tylko panel daje rejestr – z datą, godziną i historią zdarzenia. Zgłoszenie telefoniczne bez wpisu w systemie nie istnieje w rozliczeniu, więc jeśli wykonawca nie prowadzi ticketów, nie masz czym udowodnić przekroczenia SLA.

Kluczowe pytanie brzmi: co się dzieje, gdy SLA nie jest dotrzymane? Realne warianty są trzy: kara umowna (np. 5% miesięcznego abonamentu za każde rozpoczęte 24 godziny opóźnienia), kredyt godzinowy (nieodpłatne godziny prac w kolejnym miesiącu) albo wyłącznie przeprosiny. Pierwsze dwa da się policzyć i wyegzekwować. Dobra umowa zawiera też raport miesięczny: liczbę zgłoszeń, średni czas reakcji, liczbę przekroczeń SLA i listę wykonanych kopii oraz aktualizacji. Ten sam zestaw punktów kontrolnych stosujemy, opisując zakres opieki technicznej sklepów w Zamościu – warto zestawić ze sobą zapisy z kilku ofert, zanim cokolwiek podpiszesz.

PrestaShop vs WooCommerce – co zmienia się w codziennym utrzymaniu

Utrzymanie to nie jedna usługa, a zestaw czynności, którego zakres zależy od platformy. W PrestaShop aktualizacja modułu z panelu to często jeden klik – ale za tym klikiem stoi realne ryzyko. Wielu wykonawców nadpisywało pliki rdzenia w katalogu override/, a aktualizacja potrafi te nadpisania unieważnić albo wywołać konflikt z nową wersją modułu. Do tego cache Smarty: po zmianie szablonu trzeba go wyczyścić, inaczej edytujesz pliki, których sklep nie używa. Zmiana wersji PHP (np. z 7.4 na 8.1) wymaga wcześniejszego sprawdzenia kompatybilności modułów i szablonu, bo część starszych rozszerzeń po prostu przestaje działać.

WooCommerce działa odwrotnie: samo jądro aktualizuje się sprawnie, ale 20–30 wtyczek to 20–30 osobnych powierzchni ataku i źródeł konfliktów. Typowe przypadki: dwie wtyczki modyfikujące koszyk, plugin cache walczący z koszykiem i sesją, wtyczka rabatowa przeliczająca ceny dopiero na stronie kasy. Wydajność to osobny temat – tabela wp_postmeta rośnie do setek tysięcy wierszy, a zapytania po meta_key bez indeksu potrafią odpowiadać za większość czasu generowania strony. Uwaga też na WP-Cron: odpala się przy ruchu, więc na sklepie z niskim ruchem nocne zadania (maile, synchronizacje stanów magazynowych) po prostu się nie wykonują.

Obszar	PrestaShop	WooCommerce
Aktualizacje	Moduły z panelu, ryzyko konfliktów z override/	Jądro bezproblemowe, ryzyko w wtyczkach
Wydajność	Cache Smarty, kompilacja szablonów	wp_postmeta, WP-Cron zależny od ruchu
Bezpieczeństwo	Moduły z marketplace, stare wersje PHP	Wtyczki z różnych źródeł, porzucone rozszerzenia
Rollback	Snapshot plików + zrzut bazy	Snapshot plików + zrzut bazy

Niezależnie od platformy obowiązuje ten sam schemat pracy: staging, test po aktualizacji, rollback. Test to nie kliknięcie „aktualizuj” i zamknięcie przeglądarki – to złożenie zamówienia testowego, przejście płatności w trybie sandbox, sprawdzenie maila potwierdzającego i statusu w panelu. Po wdrożeniu warto sprawdzić indeksację: czy wtyczka SEO nie dodała przypadkiem noindex, czy nie zmieniły się adresy kategorii i czy dane strukturalne nadal się walidują.

Jest też moment, w którym łatanie przestaje się opłacać. Sygnały: wersja PrestaShop nie obsługuje już wspieranej wersji PHP, moduł płatności przestał być aktualizowany, bo operator zmienił API, a dostawca szablonu nie odpowiada na zgłoszenia. Wtedy migracja – na nowszą wersję albo inną platformę – bywa tańsza niż kolejny rok doraźnych poprawek.

Najczęstsze problemy sklepów z Biłgoraja i okolic – i jak je wykryć wcześniej

Te objawy wracają w sklepach z Biłgoraja i okolic w podobnej kolejności. Każdy z nich da się sprawdzić samodzielnie, jeszcze przed rozmową z wykonawcą – potrzebny jest dostęp do panelu hostingu, logów i Search Console.

• Sklep spowalnia w sezonie (świąteczny, Black Friday). Objaw: TTFB rośnie z 400 ms do 2–4 s, pojawiają się błędy 502 i 504. Diagnoza: error.log i access.log Nginx lub Apache, slow query log MySQL, wykres CPU i liczba procesów PHP-FPM w panelu. Mierz TTFB w godzinach szczytu, nie w nocy – progi tych wskaźników opisuje web.dev – Web Vitals.
• Stare moduły płatności i kurierów po cichu psują zamówienia. Objaw: rosnąca liczba transakcji ze statusem „oczekiwanie na płatność”, mimo że klient twierdzi, że zapłacił. Diagnoza: logi webhooków w panelu operatora płatności, porównanie statusów w sklepie ze statusami po stronie operatora, harmonogram zadań cron. Raz w miesiącu zrób zamówienie testowe za 1 zł i przejdź całą ścieżkę – to najtańszy test dostępny dla sklepu.
• Hosting współdzielony i limity inode/CPU. Objaw: losowe błędy 500 bez związku z ruchem. Diagnoza: statystyki konta w DirectAdmin lub cPanel (zajętość inode, CPU, Entry Processes), dziennik błędów. Często winne są cache i miniatury – same wygenerowane pliki potrafią zjadać setki tysięcy inode.
• Wycieki danych lub spam w formularzach. Objaw: skoki ruchu na /administrator, wp-login.php i xmlrpc.php. Diagnoza: filtrowanie access.log po zapytaniach POST, konfiguracja fail2ban z jail dla tych ścieżek, przegląd kont administratorów i włączenie 2FA.
• Niewidoczne spadki pozycji po aktualizacji. Objaw: spada liczba zaindeksowanych adresów. Diagnoza: Search Console (raporty pokrycia, kontrola adresów URL), robots.txt, meta robots, sitemap.xml oraz logi crawl Googlebota – najczęstsza przyczyna to przypadkowe noindex dodane przez wtyczkę SEO.

Zakres i ceny takich prac rozpisujemy m.in. dla sklepów w Zwierzyńcu – warto porównać to z ofertą lokalnego wykonawcy punkt po punkcie, a nie tylko po cenie miesięcznej.

Checklista miesięcznej opieki technicznej sklepu – do odklikania

Checklista ma jedno zadanie: po miesiącu opieki chcesz zobaczyć artefakty, a nie zapewnienie „wszystko działa”. Rozdziel ją na część automatyczną i rutynową – pierwsza działa bez człowieka, druga wymaga czyjegoś czasu.

Automatyczne (24/7, bez twojej ingerencji)

• Backup bazy i plików: minimum raz na dobę, retencja 30 dni, kopia poza serwerem produkcyjnym. OK: masz dostęp do panelu i widzisz datę ostatniej kopii. Do poprawy: kopie leżą na tym samym serwerze co sklep.
• Monitoring dostępności: sprawdzenie co 1–5 minut, alert e-mail/SMS do wykonawcy i do ciebie. OK: w raportach widać alerty z ostatniego miesiąca. Do poprawy: awarię wykrywa pierwszy klient.
• SSL i domena: alert 30 dni przed wygaśnięciem certyfikatu. OK: termin odnowienia nie jest trzymany „na pamięć” w kalendarzu jednej osoby.
• Błędy 5xx i kolejka mailowa: OK, gdy nie ma setek nieudanych wysyłek potwierdzeń zamówień.

Rutynowe (człowiek, zwykle 1–3 h miesięcznie)

• Przegląd logów: PrestaShop – var/logs/, WordPress – debug.log przy włączonym WP_DEBUG_LOG. Szukasz powtarzalnych błędów modułów, nie pojedynczych ostrzeżeń.
• Pomiar Core Web Vitals (LCP, INP, CLS) w danych od realnych użytkowników, nie tylko w laboratorium.
• Przegląd kolejek: zamówienia bez statusu, płatności „oczekujące”, zgłoszenia zwrotów.
• Testowe zamówienie raz w miesiącu – cała ścieżka: koszyk → dane → dostawa i płatność → status „wysłane” → mail z numerem przesyłki. Kwota 1–5 zł, potem anulowanie i zwrot. Jeśli płatność nie przechodzi, dowiesz się ty, a nie klient.

Jak wygląda taki zakres w podobnych sklepach, opisaliśmy przy okazji utrzymania i opieki technicznej sklepów w Zamościu.

Jak wybrać wykonawcę opieki – 7 pytań na pierwszą rozmowę

Na pierwszej rozmowie nie pytaj o cenę pakietu. Zadaj siedem pytań i słuchaj, czy odpowiada osoba, która realnie dotknie twojego sklepu.

1. Czy opiekuje się mną deweloper, czy account manager przekazujący zgłoszenia dalej? Dobra odpowiedź: znasz z imienia osobę techniczną i wiesz, w jakich godzinach odpowiada. Czerwona flaga: „zgłoszenie trafi do zespołu” bez żadnego nazwiska i bez kanału kontaktu innego niż formularz.
2. Jak wygląda proces aktualizacji – czy jest staging i rollback? Chcesz usłyszeć: kopia środowiska, test na stagingu, aktualizacja na produkcji poza godzinami szczytu, gotowy plan przywrócenia poprzedniej wersji. W PrestaShop aktualizacje modułów potrafią rozjechać szablony, więc „aktualizujemy od razu, nigdy nie było problemu” to nie proces, a szczęście.
3. Co się dzieje z dostępami po zakończeniu umowy? Konta hostingowe, panel DNS, dostępy do bramki płatności i sklepowe konta administratora muszą być założone na twoją firmę, nie na wykonawcę. Kod i backupy to twoja własność. Poproś o to w umowie, nie w mailu.
4. Jakie masz referencje sklepów w regionie – Biłgoraj, Zamość, Lublin – i czy mogę zadzwonić do któregoś z klientów? Jeśli usłyszysz „tajemnica handlowa”, zapytaj o choć jeden kontakt z ostatnich 12 miesięcy.
5. Jaki macie czas reakcji i co dokładnie obejmuje SLA? Rozdziel „reakcja” od „naprawa”. Sensowne widełki dla małego sklepu: reakcja do 4 h w dni robocze, 24/7 tylko dla awarii krytycznej (sklep nie działa, płatności nie przechodzą).
6. Ile godzin pracy zawiera pakiet i co jest poza nim? Typowy pakiet 350–900 zł netto to najczęściej kilka godzin rutynowych prac; nowa funkcja w szablonie to osobne zlecenie. Ustal stawkę za godzinę ponad limit z góry.
7. Co dostanę co miesiąc na piśmie i kto odpowiada za wyłączenie sklepu po waszej zmianie? Raport z czasem reakcji i wykonanymi pracami to jedyny dowód, że opieka istnieje.

Podobny zestaw pytań sprawdza się przy mniejszych sklepach – zobacz utrzymanie i opiekę techniczną sklepów w Józefowie.

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

Lista kontrolna do odklikania

• Zakres opieki na piśmie — Zanim podpiszesz umowę – lista czynności miesięcznych jako załącznik do umowy, nie jako opis w ofercie handlowej.
• Backupy codziennie — Raz w miesiącu poproś o zrzut z panelu backupowego i sprawdź, czy kopie faktycznie powstają codziennie.
• Retencja kopii min. 30 dni — Sprawdź ustawienie retencji w narzędziu. Kopie trzymane 3 dni nie pomogą przy błędzie, który wyszedł po dwóch tygodniach.
• Test odtworzenia raz na kwartał — Poproś o pisemne potwierdzenie daty i wyniku testu oraz informację, na jakim środowisku go wykonano.
• Kolejność aktualizacji — Sprawdź, czy wykonawca aktualizuje najpierw rdzeń, potem moduły, na końcu szablon – i czy nie robi wszystkiego jednego dnia.
• Staging przed produkcją — Zapytaj, jak wygląda proces wdrożenia. Odpowiedź powinna zawierać środowisko testowe i moment na sprawdzenie koszyka oraz płatności po aktualizacji.
• WAF i limity logowania — Sprawdź, czy na serwerze działa firewall aplikacyjny i czy liczba prób logowania do panelu jest ograniczona.
• Skan malware i monitoring plików — Sprawdź, jak często odbywa się skan i czy porównywane są sumy kontrolne plików aplikacji (checksumy).
• Monitoring uptime co 1 minutę — Poproś o adres panelu statusowego lub zrzut historii z ostatnich 30 dni z widocznymi incydentami.
• Alerty na błędy 500 i spadki konwersji — Ustal, na jaki kanał trafiają alerty i kto je odbiera poza godzinami pracy.
• Core Web Vitals — Raz w miesiącu sprawdź LCP, INP i CLS dla najważniejszych adresów sklepu; punkt odniesienia opisuje Google w dokumentacji Core Web Vitals.
• Czas reakcji i czas naprawy w umowie — Sprawdź, czy obie liczby są zapisane osobno i czy mają przypisane poziomy priorytetów.
• Konsekwencje niedotrzymania SLA — Sprawdź, czy w umowie jest kara umowna albo kredyty godzinowe – nie tylko deklaracja „staramy się reagować szybko”.
• Rejestr dostępów do domeny i hostingu — Upewnij się, że domena, hosting i panel sklepu są zarejestrowane na Twoją firmę, a nie na wykonawcę.

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
• PrestaShop – dokumentacja dla deweloperów