Czym naprawdę jest utrzymanie i opieka techniczna sklepu

Opieka techniczna to powtarzalny zestaw czynności wykonywanych na serwerze i w samej aplikacji sklepu. Kampanie Google Ads, opisy produktów, link building i praca nad widocznością fraz to zupełnie inny zakres – inne kompetencje, inny budżet, inne efekty. Jeśli agencja wrzuca to wszystko na jedną fakturę pod hasłem „kompleksowa opieka”, w praktyce nie wiadomo, ile płacisz za bezpieczeństwo, a ile za marketing.

Opieka reaktywna zaczyna się w momencie awarii: klient dzwoni, że nie działa płatność, i ktoś siada do naprawy. Opieka proaktywna działa wcześniej – monitoring sprawdza dostępność co kilka minut, kopie zapasowe lecą codziennie, aktualizacje wchodzą w oknie serwisowym, certyfikat SSL jest odnawiany, zanim wygaśnie. Reaktywna wygląda taniej na fakturze, ale kosztuje więcej w dniu awarii: sklep stoi, zamówienia uciekają, a naprawa startuje od zera, bo dostawca nie zna konfiguracji.

Czego opieka techniczna nie obejmuje: budżetu reklamowego i prowadzenia kampanii, tworzenia i optymalizacji treści, pozycjonowania fraz, a także dużych prac rozwojowych – nowego szablonu, integracji z ERP, migracji na wyższą wersję platformy. To zadania projektowe, wyceniane osobno, z własnym harmonogramem.

Przykład z życia: sklep na PrestaShop 1.7 z 40 modułami. Pierwszy tydzień opieki wygląda tak: inwentaryzacja modułów i sprawdzenie, które nie są rozwijane od lat, kopia bazy i plików zdjęta poza serwer produkcyjny, postawienie kopii na stagingu, przegląd logów błędów PHP i serwera, porównanie wersji PHP z wymaganiami modułów. Dopiero po tym kroku wiadomo, czy aktualizacje da się w ogóle robić bezpiecznie. Różnice w zakresie bywają spore – zobacz, co obejmuje opieka techniczna sklepów Krasnobród, i porównaj to z ofertą, którą dostałeś.

Co wchodzi w pakiet opieki – 7 obszarów bez lania wody

Poniższa lista to wzorzec, z którym siadasz do dowolnej oferty. Jeśli brakuje któregoś punktu, pytaj wprost, ile kosztuje jego dopisanie do pakietu.

• Backupy. Codziennie pełna kopia bazy i plików, retencja 30 dni, kopia trzymana poza serwerem produkcyjnym – inne konto, inny dostawca, najlepiej inny region. Raz na kwartał test odtworzenia na stagingu, bo backup, którego nie sprawdziłeś, nie jest backupem.
• Aktualizacje. Rdzeń, moduły/wtyczki i wersja PHP, w oknie serwisowym (np. wtorek 2:00–4:00), zawsze najpierw na stagingu, potem na produkcji. Przed każdą aktualizacją zrzut bazy.
• Monitoring. Dostępność co 1–5 minut, certyfikat SSL z alertami 30, 14 i 7 dni przed wygaśnięciem, wolne miejsce na dysku, zużycie RAM, kolejka e-maili, zadania cron.
• Wydajność. Core Web Vitals (LCP, INP, CLS), TTFB, skuteczność cache, CDN, waga i format obrazów. Bez pomiaru co miesiąc nie ma punktu odniesienia – a bez niego nie da się powiedzieć, czy zmiana pomogła. Metryki i progi opisuje dokumentacja web.dev – Core Web Vitals.
• Bezpieczeństwo. WAF, limit prób logowania na /admin, zmieniony adres panelu, 2FA, skan malware, procedura reagowania na incydent z kimś, kto realnie podejmuje decyzje.
• Poprawki i drobne zmiany. Pakiety zawierają zwykle 2–5 godzin miesięcznie. Płatne ekstra: nowe funkcje, nowe integracje, migracje, prace nad szablonem.
• Kanał zgłoszeń. E-mail i panel dla spraw zwykłych, telefon dla awarii krytycznych, imienny opiekun po drugiej stronie.

SLA w praktyce – jak czytać umowę, żeby się nie naciąć

Najczęstsza pomyłka przy porównywaniu ofert to czytanie „czas reakcji 1 godzina” jako „naprawa w godzinę”. To dwie różne liczby. Czas reakcji (response) to moment, w którym człowiek odbierze zgłoszenie i potwierdzi, że nad nim pracuje. Czas usunięcia (resolution) to moment, w którym sklep znowu działa i przyjmuje zamówienia. W ofercie muszą być podane oba parametry – jeśli jest tylko jeden, dopytaj o drugi na piśmie.

Drugi parametr to okno obowiązywania SLA. Standard „8:00–16:00 w dni robocze” oznacza, że awaria w sobotę o 22:00 jest obsługiwana w poniedziałek rano. Dla sklepu sprzedającego w weekendy to poważna luka – warto dopłacić za tryb 24/7 albo przynajmniej za dyżur weekendowy. Ustal też, od kiedy liczy się zegar: od wysłania zgłoszenia czy od potwierdzenia priorytetu przez dostawcę.

Trzeci element: co się dzieje przy niedotrzymaniu SLA. Realne zapisy to kredyty na kolejny okres rozliczeniowy (np. 5% abonamentu za każde rozpoczęte 30 minut zwłoki w P1, z limitem 50%) albo rabat na następną fakturę. Bez takiego zapisu SLA jest obietnicą bez konsekwencji. Egzekwowanie wymaga własnego rejestru zgłoszeń z datą i godziną – bez dokumentacji nie udowodnisz przekroczenia.

Sprawdź też listę wyłączeń. Awarie po stronie hostingodawcy, operatora płatności czy firmy kurierskiej zwykle nie liczą się do SLA dostawcy opieki i to jest uczciwe – problem pojawia się wtedy, gdy lista wyłączeń zjada całe zobowiązanie. Kolejne punkty do porównania, w tym rozbicie na pakiety, znajdziesz w materiale o utrzymaniu i opiece technicznej sklepów Hrubieszów.

Ile kosztuje utrzymanie sklepu w Chełm i okolicach – realne widełki

Zanim poprosisz agencję o ofertę, ustal rząd wielkości. Stawki abonamentowe na rynku chełmskim i w okolicach (Zamość, Hrubieszów, Krasnystaw) wyglądają tak: mały sklep do 500 SKU bez własnego kodu w motywie – 400–900 zł netto miesięcznie. Średni sklep 500–5000 SKU z integracjami (ERP, kurierzy, płatności) – 1200–3500 zł netto miesięcznie. Powyżej 5000 SKU i przy custom code abonament przestaje mieć sens, częściej rozlicza się pakiet godzin.

Model godzinowy to 180–320 zł/h netto. Dolna granica to freelancer robiący WooCommerce, górna – firma z osobą od PrestaShop i własnym zapleczem DevOps. Różnica nie jest przypadkowa: przy 320 zł/h płacisz też za czas reakcji i odpowiedzialność, nie tylko za roboczogodzinę.

Co realnie podnosi cenę: liczba modułów (powyżej 25–30 aktywnych wtyczek w WooCommerce każda aktualizacja to loteria), custom code w child theme, który blokuje aktualizacje szablonu, integracje z InPost ShipX, DPD, DHL, Subiektem GT/nexo, Comarch Optimą i bramkami płatności – każda ma własny cykl zmian API – oraz ruch (50 tys. wizyt miesięcznie wymaga innego monitoringu i cache niż 3 tys.).

Najczęstsza pułapka to „darmowa opieka”. Agencja dolicza 10–20 godzin opieki do wyceny wdrożenia (np. 15 h × 200 zł = 3000 zł) i rozkłada je na pierwszy rok. Po dwunastu miesiącach pula się kończy, a Ty podpisujesz abonament, bo sklep „jest już w systemie”. Przed podpisaniem zapytaj wprost: ile godzin opieki wliczono, na jaki okres i co dzieje się z niewykorzystanymi. Warto porównać to z zasadami rozliczeń i czasem reakcji opisanymi dla utrzymania i opieki technicznej sklepów z Hrubieszowa – to dobry punkt odniesienia przy negocjacjach.

PrestaShop czy WooCommerce – co trudniej utrzymać

Nie ma sensu pytać, co jest lepsze. Sensowne pytanie brzmi: ile kosztuje utrzymanie tego, co już masz. PrestaShop to monolit – rdzeń obejmuje katalog, zamówienia, podatki i magazyn. Aktualizacja rdzenia (np. z linii 1.7 do 8.x) potrafi wyłączyć moduł płatności albo rozsypać szablon. Konflikty między modułami są częste, bo wielu dostawców nadpisuje te same hooki. Migracje PHP bolą podwójnie: sklep na PHP 7.4 z modułami pisanymi pod 5.6 wymaga albo aktualizacji modułów, albo ich przepisania. Efekt: koszt utrzymania PrestaShop jest zwykle wyższy o 20–40% niż porównywalnego WooCommerce.

WooCommerce ma odwrotny problem – nie monolit, a 30–50 niezależnych wtyczek, każda aktualizowana w swoim tempie. WordPress aktualizuje się sam, jeśli włączysz auto-update dla wersji minor, ale wtyczka do płatności po cichej aktualizacji potrafi przestać wysyłać webhooki. Błąd nie zawsze kończy się białym ekranem – czasem klient nie dostaje maila i dowiadujesz się o tym po tygodniu. Zaletą jest rynek: dewelopera od WooCommerce znajdziesz w każdym większym mieście województwa, od PrestaShop – znacznie trudniej.

Proces aktualizacji wygląda w obu przypadkach podobnie i ma cztery kroki:

1. Kopia bazy i plików, potem kopia na staging (osobna subdomena i osobna baza, np. staging.twojsklep.pl).
2. Aktualizacja na stagingu: rdzeń, a następnie moduły po kolei – nie wszystko naraz, żeby wiedzieć, co zepsuło sklep.
3. Test zamówienia: produkt → koszyk → płatność w trybie piaskownicy → mail → status w panelu.
4. Wdrożenie na produkcję w oknie niskiego ruchu (np. 2:00–5:00) i ponowny test płatności kwotą 1 zł z natychmiastowym zwrotem.

Migracja ma sens w trzech sytuacjach: sklep stoi na wersji bez wsparcia, koszt utrzymania przekracza 3500 zł miesięcznie bez rozwoju, albo potrzebujesz funkcji, których platforma nie daje bez customizacji za kilkanaście tysięcy złotych. Jeśli sklep działa i generuje zamówienia, migracja to najczęściej zbędny wydatek rzędu 5–15 tys. zł plus 2–3 miesiące destabilizacji. Zakres czynności w pakietach porównaj z tym, co obejmuje opieka techniczna nad sklepami z Narola. Warto też zajrzeć do oficjalnej dokumentacji dla deweloperów PrestaShop i sprawdzić, czy Twoja wersja jest jeszcze wspierana.

12-punktowa checklista audytu sklepu – do odklikania raz w miesiącu

Checklista nie wymaga dostępu do kodu ani wiedzy technicznej – wystarczy panel sklepu, skrzynka mailowa i 40–60 minut raz w miesiącu. Pierwsze przejście zajmie dłużej, bo trzeba ustalić hasła do hostingu i panelu kuriera.

1. Test zamówienia end-to-end. Produkt testowy (ukryty z katalogu, cena 1 zł) → koszyk → płatność → mail potwierdzający → przekazanie do InPost/DPD/DHL → faktura. Sprawdź, czy numer przesyłki pojawił się w panelu kuriera, nie tylko w sklepie.
2. Test płatności online minimum raz w miesiącu, w tym jeden z realnym zwrotem. Zapłać 1 zł i wykonaj zwrot z panelu bramki. Zwrot to operacja, która regularnie psuje się po cichu – klient dostaje pieniądze, ale zamówienie zostaje w statusie „opłacone”.
3. Sprawdzenie backupu. Nie wystarczy, że plik istnieje – otwórz archiwum i sprawdź, czy w środku jest zrzut bazy SQL i katalog plików. Raz na kwartał odtwórz kopię na stagingu i uruchom sklep.
4. Certyfikat SSL i ważność domeny. Minimum 30 dni zapasu na obu. Kto tego nie pilnuje, budzi się z przekierowaniem na parking domeny albo ostrzeżeniem „niezabezpieczona” w Chrome.
5. Logi błędów. Logi PHP i odpowiedzi 5xx z ostatnich 30 dni. Pojedyncze wpisy są normalne, powtarzający się ten sam błąd – nie.
6. Statusy zamówień. Czy nie ma zamówień zawieszonych w „oczekiwanie na płatność” starszych niż 24 h.
7. Stany magazynowe. Czy ERP i sklep pokazują tę samą liczbę sztuk dla trzech losowych produktów.
8. Maile transakcyjne. SPF, DKIM, DMARC – czy sklep nie trafia do spamu. Test na Gmailu i Outlooku.
9. Miejsce na dysku i rozmiar bazy. 90% zapełnienia to sygnał do działania, nie ciekawostka.
10. Wydajność. LCP, INP i CLS – pomiar według definicji Core Web Vitals na web.dev i raport w Search Console.
11. Wersje. PHP, rdzeń platformy, wtyczki – czy nic nie jest poza wsparciem producenta.
12. Uprawnienia. Konta byłych pracowników, stare klucze API, liczba kont administratora.

Jeśli któryś punkt wypada źle, nie naprawiaj go samodzielnie w piątek wieczorem na produkcji. Standardowy zakres takich prac opisuje utrzymanie sklepów w Krasnobrodzie, a różnice w pakietach widać w zakresie opieki nad sklepami z Frampola.

Najczęstsze awarie w sklepach MŚP i jak je wyłapać wcześnie

W sklepach MŚP zwykle nie wybucha cały serwer — psuje się jeden element i nikt tego nie widzi przez kilka dni. Poniżej pięć sytuacji, które wracają najczęściej, oraz miejsce, w którym warto sprawdzić w pierwszej kolejności.

1. Błąd 500 po aktualizacji modułu. W PrestaShop to prawie zawsze brakująca klasa albo niezgodność z wersją PHP. Zanim napiszesz do wykonawcy: ustaw _PS_MODE_DEV_ na true w config/defines.inc.php, zajrzyj do katalogu var/logs/ (plik z najświeższą datą), error_log PHP oraz logu błędów Nginxa/Apache. W /modules znajdź katalog z najświeższą datą modyfikacji — to zwykle sprawca. Zmień jego nazwę na nazwa_off i sprawdź, czy sklep wstaje. Zestawianie wersji modułu z wersją PHP opisuje dokumentacja dla deweloperów PrestaShop. Podział na zgłoszenia krytyczne i zwykłe bywa rozpisany w umowie — zobacz, jak wygląda opieka techniczna sklepów Hrubieszów – SLA.

2. Płatności, które padają tylko części użytkowników. Bramka potrafi odrzucać wyłącznie karty, a przepuszczać BLIK. W GA4 porównaj liczby zdarzeń begin_checkout, add_payment_info i purchase — jeśli spadek jest na jednym kroku i jednej metodzie, to nie problem z ruchem ani z cenami. Zestaw to z webhookami i kodami błędów bramki; 3DS wysypuje się czasem dopiero po stronie banku.

3. Zamówienia bez etykiety kurierskiej. Dwóch pierwszych podejrzanych: wygasły token API i przekroczony limit zapytań. Sprawdź, czy cron w ogóle się uruchamia, przejrzyj logi modułu kuriera i statusy zamówień. Osobno zweryfikuj duplikaty numerów przesyłek — pojawiają się po ręcznym ponowieniu generowania etykiety.

4. Wyciek z formularza kontaktowego lub rejestracji. Sygnały: setki POST-ów do plików spoza index.php, skoki 404/403 na /wp-login.php lub adres panelu, wysyp kont z domen jednorazowych, wpisy klientów bez zamówień. W access logu szukaj powtarzalnego user-agenta i jednego adresu IP.

5. Wolniejszy sklep po zmianie PHP lub cache. Sprawdź TTFB, pulę PHP-FPM, OPcache (czy jest aktywny po restarcie) i slow query log MySQL. Migracja z 7.4 na 8.1 bez testu modułów to klasyczna przyczyna.

Opieka techniczna sklepu w Chełm i okolicach – jak to działa lokalnie

Zapytanie „utrzymanie i opieka techniczna sklepów Chełm” brzmi lokalnie, ale w praktyce 95% zgłoszeń załatwia się zdalnie. Lokalność zmienia nie zakres prac, a sposób kontaktu i czas reakcji.

Co realnie da się zrobić zdalnie. Aktualizacje PrestaShop i WooCommerce, kopie zapasowe, monitoring, poprawki PHP/CSS/JS, konfiguracja płatności i wysyłki, odnowienia SSL, DNS, optymalizacja wydajności, czyszczenie bazy — to wszystko robi się przez SSH, panel hostingu i repozytorium. Wizyta na miejscu ma sens w trzech przypadkach: wdrożenie sprzętowe (drukarka fiskalna, terminal, czytnik kodów, stanowisko pakowania), integracja z lokalnym ERP działającym w wersji desktopowej bez API oraz posprzątanie dostępów i sieci, gdy hasła zna tylko osoba, która odeszła.

Czas reakcji. Chełm, Zamość, Krasnystaw, Hrubieszów — jedna strefa czasowa i brak pośrednika przez zagraniczny helpdesk, który przyjmuje zgłoszenie i przekazuje je dalej po 24 godzinach. Realny model: 8:00–16:00 w dni robocze, zgłoszenie krytyczne (sklep nie działa, płatności nie przechodzą) — reakcja w ciągu 1 godziny, ważne (błąd w koszyku, brak etykiet) — 8 godzin, zwykłe — 24 godziny. To powinien być zapis w umowie, nie dobra wola. Zakres bywa rozpisany w pakietach, np. utrzymanie i opieka techniczna sklepów Narol albo to, co obejmuje utrzymanie sklepów Bełżec.

Pierwszy miesiąc. Tydzień 1: audyt startowy (moduły i ich pochodzenie, wersje PHP/MySQL, kto ma dostępy, stan kopii). Tydzień 2: uporządkowanie backupów — trzy kopie, dwa nośniki, jedna poza serwerem, plus test odtworzenia na stagingu. Tydzień 3: monitoring uptime co minutę, alerty i pomiar TTFB oraz Core Web Vitals (progi opisuje web.dev – Core Web Vitals). Dopiero tydzień 4 to pierwsze zmiany rozwojowe. Odwrotna kolejność to najczęstszy błąd.

Jak wybrać wykonawcę – 8 pytań, które warto zadać przed podpisaniem umowy

Rozmowa z potencjalnym wykonawcą trwa zwykle 20 minut. Osiem pytań poniżej wystarczy, żeby w tym czasie odsiać firmy, które „opiekę” rozumieją jako czekanie na awarię.

1. Kto konkretnie obsługuje mój sklep? Chcesz imię, nazwisko i bezpośredni kontakt, nie „zespół wsparcia”.
2. Ile sklepów ma na głowie ta osoba? Przy 20–25 sklepach na jednego opiekuna reakcja w ciągu godziny jest matematycznie mało realna.
3. Jak wygląda raportowanie? Konkretnie: miesięczny raport z wykonanych aktualizacji, wyniku testu odtworzenia kopii, czasów reakcji wobec SLA, incydentów i rekomendacji.
4. Czy staging i backup są w cenie, czy płatne ekstra? Każda aktualizacja powinna najpierw iść na kopię sklepu. Backup bez testu odtworzenia to nie backup, tylko plik, o którym nie wiadomo, czy działa.
5. Jak wygląda przejęcie sklepu po poprzedniej firmie? Powinien być jednorazowy audyt: dostępy, wersje, moduły niewiadomego pochodzenia, malware, licencje. Zapytaj, co obejmuje i jak jest wyceniany — za godziny czy ryczałtem.
6. Kto jest właścicielem kont? Domena, hosting, CDN, konta w bramkach płatniczych i u kurierów mają być zarejestrowane na Twoją firmę, a wykonawca ma być tylko użytkownikiem.
7. Jak rozliczacie godziny ponad pakiet? Stawka godzinowa, sposób akceptacji prac i limit, do którego nie trzeba pytać.
8. Jak wygląda wyjście z umowy? Kto przejmuje dostępy, w jakiej formie (eksport plików i bazy, hasła, dokumentacja) i w jakim terminie — 14 czy 30 dni.

Punkt ósmy jest najważniejszy i najczęściej pomijany. Jeśli wykonawca nie umie odpowiedzieć na pytanie o przekazanie dostępów, to znaczy, że ich nie uporządkował — a to wprost przekłada się na koszt Twojego wyjścia. Zanim podpiszesz, porównaj zakres z innymi pakietami w regionie, np. utrzymanie i opieka techniczna sklepów Frampol, i sprawdź, co zwykle wchodzi w cenę.

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

Lista kontrolna do odklikania

• Kopia poza serwerem produkcyjnym — Sprawdź miejsce docelowe kopii — inny serwer lub storage. Kopia na tym samym hostingu nie chroni przed awarią hostingu.
• Retencja 30 dni — Zapytaj, ile wersji jest trzymanych i przez ile dni. Przy aktualizacjach liczy się możliwość cofnięcia do stanu sprzed kilku dni.
• Test odtworzenia raz na kwartał — Poproś o datę i wynik ostatniego testu. Sam plik kopii bez testu odtworzenia nie jest zabezpieczeniem.
• Środowisko staging — Sprawdź, czy istnieje kopia sklepu do testów i jak często jest odświeżana danymi z produkcji.
• Okno serwisowe — Ustal, kiedy wykonuje się aktualizacje i z jakim wyprzedzeniem dostajesz informację o przerwie.
• Monitoring dostępności co 1–5 minut — Zapytaj, jaki system monitoruje sklep i kto dostaje alert — agencja czy Ty, i o której godzinie.
• Monitoring SSL i domeny — Alert przed wygaśnięciem certyfikatu i domeny. Przeterminowany SSL blokuje zakupy i generuje ostrzeżenie w przeglądarce.
• Dysk i pamięć serwera — Progi alertów na zajętość dysku i zużycie RAM. Pełny dysk to najczęstsza przyczyna nagłego wyłączenia sklepu.
• WAF, limity na /admin i 2FA — Sprawdź, czy panel administracyjny jest zabezpieczony limitem prób logowania i czy włączone jest uwierzytelnianie dwuskładnikowe.
• Skan malware i reakcja na incydenty — Ustal, jak często skan, kto podejmuje decyzję o wyłączeniu sklepu i w jakim czasie dostajesz informację o włamaniu.
• Liczba godzin w pakiecie — Ile godzin pracy wchodzi w abonament, a co jest płatne ekstra. Poproś o przykładowe rozliczenie z ostatniego miesiąca.
• Kanał zgłoszeń i opiekun — E-mail, panel czy telefon — i kto konkretnie odpowiada za Twój sklep. Bez imienia po drugiej stronie zgłoszenia giną.
• Czas reakcji vs czas usunięcia — Dwie osobne wartości dla każdego priorytetu. Jedna liczba w ofercie to znak, że nie ma prawdziwego SLA.
• Kredyty za niedotrzymanie SLA — Sprawdź, czy umowa przewiduje obniżenie abonamentu lub kary i jak się je egzekwuje. Bez zapisu zostaje tylko rozmowa.

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