Czym jest utrzymanie i opieka techniczna sklepu internetowego?

Wdrożenie sklepu ma datę końcową. Uruchamiasz sprzedaż, robisz ostatni test koszyka i projekt się zamyka. Opieka techniczna startuje dzień później i trwa tak długo, jak długo sklep ma zarabiać. To praca cykliczna: sprawdź, zaktualizuj, zabezpiecz, zareaguj — a nie jednorazowe zadanie.

Warto rozdzielić trzy warstwy, bo w rozmowach o kosztach najczęściej się je miesza:

• Administracja serwerem — dostępność maszyny, CPU, RAM, miejsce na dysku, certyfikat SSL, firewall, kopie po stronie hostingu. Zwykle odpowiada za to dostawca, ale ktoś musi mieć dostęp i wiedzieć, co sprawdzić, gdy coś siadnie.
• Utrzymanie aplikacji — rdzeń PrestaShop lub WordPress z WooCommerce, motyw, moduły, baza MySQL, konfiguracja PHP, integracje z płatnościami, kurierami i programem księgowym.
• Wsparcie i rozwój — nowy moduł, poprawka błędu, zmiana progu darmowej dostawy, nowa metoda płatności.

Opieka techniczna to nie SEO i nie content. Nikt tu nie pisze opisów produktów ani nie buduje linków. Ale wpływa na wyniki w Google pośrednio: jeśli serwer odpowiada 8 sekund albo w logach sypią się błędy 500, najlepsze teksty nie pomogą. Stabilność i wydajność to fundament — Google opisuje to wprost w dokumentacji Web Vitals.

Kiedy firma ze Zwierzyńca realnie potrzebuje takiej opieki? W czterech momentach: po wdrożeniu sklepu, po migracji (zmiana hostingu, wersji PrestaShop, dostawcy), przy skoku zamówień — sklep robiący 5 zamówień dziennie wybacza błędy, sklep z 150 zamówieniami nie — oraz gdy z firmy odchodzi osoba, która „ogarniała informatykę”. Pełny zakres opisujemy na stronie utrzymanie i opieka techniczna sklepów Zwierzyniec.

Co wchodzi w zakres opieki technicznej nad sklepem?

Zakres warto zapisać na papierze i rozdzielić odpowiedzialności. Poniżej standard, który w praktyce się sprawdza.

Kopie zapasowe. Baza i pliki raz na dobę, retencja minimum 14 dni, kopia trzymana poza serwerem produkcyjnym — najlepiej u innego dostawcy niż hosting. Test odtworzenia raz na kwartał: przywracasz sklep na środowisko staging i sprawdzasz, czy koszyk oraz płatność działają. Backup bez testu odtworzenia to plik, któremu nikt nie ufa.

Aktualizacje. PHP, MySQL/MariaDB, rdzeń PrestaShop lub WordPress z WooCommerce, moduły i wtyczki. Kolejność: staging, test koszyka, logowania i płatności, potem produkcja. Przy PrestaShop pilnuj zmian niekompatybilnych między wersjami — opisuje je dokumentacja deweloperska PrestaShop.

Monitoring. Dostępność sprawdzana co 1–5 minut pod kątem kodu HTTP i czasu odpowiedzi, alert e-mail lub SMS. Do tego logi błędów PHP, błędy 500, nieudane płatności i maile wychodzące. Osobno wydajność: LCP, INP i CLS — mierzone nie raz na rok, ale po każdej aktualizacji, żeby widzieć regresje.

Bezpieczeństwo. Skan podatności modułów, WAF, blokada /xmlrpc.php w WordPressie, limit prób logowania do panelu, 2FA i rotacja kluczy API.

Wsparcie rozwoju. Nowe moduły, integracje z ERP, poprawki po zgłoszeniach. Podział ról: klient dostarcza dostępy, treści i decyzje, wykonawca — okno serwisowe, testy i raport z wykonanych prac. Zakres dla firm z sąsiedniego Zamościa porównasz na stronie utrzymanie i opieka techniczna sklepów Zamość dla firmy.

Ile kosztuje utrzymanie sklepu w Zwierzyńcu i okolicy?

Nie ma jednej ceny. Są widełki zależne od tego, ile pracy miesięcznie realnie pochłania sklep i jak szybko masz dostać reakcję. Najczęściej rozliczenie idzie pakietem godzin — nadwyżka pracy ponad pakiet to kolejne godziny w ustalonej stawce.

Orientacyjnie: pakiety startowe to 2–4 godziny miesięcznie, średnie 6–10 godzin, rozbudowane 15–30 godzin, a sklepy z ERP i kilkoma integracjami schodzą w okolice 40 godzin i więcej. Stawka godzinowa za pracę doraźną jest wyższa niż stawka efektywna w pakiecie. Ostateczna kwota zawsze wynika z audytu sklepu — bez niego każda liczba jest zgadywaniem.

Co podnosi koszt:

• Liczba integracji: ERP i księgowość, magazyn, kurierzy, płatności, porównywarki, feedy.
• Moduły własne — każda aktualizacja rdzenia wymaga testu regresji.
• Duży ruch: CDN, optymalizacja zapytań MySQL, praca poza godzinami.
• Krótkie SLA — reakcja w 1 godzinę przez całą dobę wyceniana jest inaczej niż 8 godzin w dni robocze.
• Stare wersje PHP i CMS bez wsparcia producenta. To już nie utrzymanie, a łatanie.

Co obniża koszt:

• Uporządkowany hosting z aktualnym PHP i wspieranym MySQL.
• Brak długu technicznego — 8 sensownych modułów zamiast 40 wtyczek, które się nadpisują.
• Moduły dedykowane zamiast zestawu wtyczek robiących to samo.
• Gotowe dostępy, dokumentacja i staging po stronie klienta.

Czego nie robić: nie bierz najtańszego pakietu 2 godzin do sklepu z integracją ERP — jedna aktualizacja z testem zjada cały miesiąc. Sposób liczenia opisujemy w tekstach ile kosztuje utrzymanie sklepu w regionie oraz cennik i zakres opieki.

Jak działa SLA i komunikacja z deweloperem?

SLA (Service Level Agreement) to zapis w umowie, który odpowiada na jedno pytanie: jak szybko ktoś zareaguje, gdy coś się zepsuje. Trzeba rozróżnić dwie rzeczy. Czas reakcji to moment, w którym deweloper potwierdza przyjęcie zgłoszenia i zaczyna diagnozę. Czas rozwiązania to przywrócenie sprzedaży. Mieszanie tych pojęć to najczęstsze źródło konfliktów między firmą a wykonawcą.

Kanały zgłoszeń powinny być trzy i każdy do czego innego. Telefon — wyłącznie awarie krytyczne, na numer, który naprawdę ktoś odbiera. Helpdesk lub system ticketowy — błędy i zadania, bo zostaje historia: kto, kiedy i co zmienił. E-mail — ustalenia i pytania. Jeśli cała komunikacja idzie przez telefon albo Messengera, po dwóch miesiącach nikt nie odtworzy, dlaczego cena na karcie produktu różni się od tej w koszyku.

Raport miesięczny powinien mieć trzy części: wykonane prace (z numerami zgłoszeń i datami), ryzyka (np. hosting kończy wsparcie dla używanej wersji PHP, certyfikat SSL wygasa za 45 dni, moduł płatności nie był testowany po ostatniej aktualizacji) oraz rekomendacje na kolejny miesiąc. Raport bez numerów, dat i konkretów nic nie wnosi — to lista ogólników.

Model bezpośredniej pracy z deweloperem, bez pośredników, skraca ścieżkę zgłoszenia. Jest jedna osoba, która pisze kod, i ona odbiera telefon — nie account manager przekazujący ticket dalej. Ustal też po swojej stronie jedną osobę decyzyjną, bo zgłoszenia od pięciu pracowników bez priorytetów rozjeżdżają się w dwa dni. Cennik i zakres opieki technicznej warto porównać przed podpisaniem umowy, żeby wiedzieć, co dokładnie wchodzi w abonament, a co jest płatne osobno.

Checklista: czy Twój sklep jest dobrze utrzymany?

Poniższa lista to szybki test. Przejdź przez 14 punktów i policz te, na które odpowiadasz „tak”. Jeden punkt to jeden punkt w wyniku.

• Zewnętrzny monitoring dostępności z alertem SMS lub e-mail, sprawdzający sklep co 1–5 minut.
• Automatyczne kopie bazy i plików wykonywane co najmniej raz dziennie.
• Backup trzymany poza serwerem produkcyjnym — na innym hostingu lub w chmurze.
• Test odtworzenia kopii wykonany w ciągu ostatnich 6 miesięcy.
• Środowisko staging do testowania zmian przed wdrożeniem na produkcję.
• Aktualizacje PrestaShop lub WooCommerce wchodzące najpierw na staging.
• Aktualizowane są też moduły, wtyczki i wersja PHP — nie tylko sam sklep.
• Certyfikat SSL z automatycznym odnawianiem i alertem przed wygaśnięciem.
• Po każdej aktualizacji test płatności, e-maili transakcyjnych i ścieżki zakupu.
• Dostępy do hostingu, domeny i panelu sklepu zarejestrowane na Twoją firmę.
• Rejestr zmian i dokumentacja modyfikacji prowadzone na bieżąco.
• Czasy reakcji na awarię krytyczną zapisane w umowie.
• Wiesz, kto konkretnie odbiera telefon, gdy sklep przestaje sprzedawać.
• Miesięczny raport z prac, ryzyk i rekomendacji trafia do Ciebie.

Wynik 0–4 to sytuacja krytyczna — zacznij od punktów 1, 2 i 4, bo bez monitoringu i sprawdzonego backupu każda awaria oznacza przestój liczony w zamówieniach. Przy 5–8 jesteś w połowie drogi: kolej na staging i testy po aktualizacjach. Wynik 9–14 oznacza, że sklep jest stabilnie utrzymany, a rozmowę można przesunąć na rozwój i wydajność.

W PrestaShop najpierw sprawdź Zaawansowane > Baza danych (ręczny eksport bazy to kopia częściowa — bez katalogów /img i /modules nie odtworzysz sklepu), zgodność modułów przy aktualizacji oraz logi błędów PHP. W WooCommerce zajrzyj do WooCommerce > Status > Logi, przetestuj wysyłkę e-maili przez SMTP i sprawdź, czy wtyczka backupu eksportuje dane poza serwer. Szczegóły techniczne aktualizacji opisuje dokumentacja deweloperska PrestaShop, z której korzystamy przy wdrożeniach. Jeśli chcesz porównać swój wynik z tym, jak wygląda utrzymanie i opieka techniczna sklepów Zamość w praktyce, tam rozpisaliśmy standardowy zakres miesięczny.

Najczęstsze pułapki w utrzymaniu sklepu i jak je wykryć

Cztery sytuacje wracają w rozmowach najczęściej. Każda ma prosty sposób sprawdzenia — nie trzeba do tego audytu za kilka tysięcy złotych.

• Brak testu odtworzenia backupu. Wykryjesz to dopiero wtedy, gdy kopia będzie potrzebna i nie wstanie. Metoda: raz na kwartał odtwórz kopię na subdomenie testowej. Sprawdź, czy baza importuje się bez błędów, czy w katalogu /img są zdjęcia produktów, czy moduły płatności i wysyłki działają. Kopia, której nigdy nie odtworzono, to nie backup, a plik.
• Aktualizacje bez stagingu. Objaw: po aktualizacji przestaje działać koszyk, płatność albo rozjeżdża się szablon, bo moduł nie wspiera nowej wersji. Test: zapytaj wykonawcę, co się stanie, jeśli aktualizacja pójdzie źle, i poproś o punkt przywrócenia. Odpowiedź „przywrócimy z backupu z wczoraj” oznacza, że w razie problemu tracisz dzień zamówień.
• Brak monitoringu. Objaw: o awarii dowiadujesz się z telefonu od klienta. Metoda: przejrzyj skrzynkę — jeśli nie ma historii alertów, masz nadzieję, a nie monitoring. Sprawdzaj nie tylko stronę główną, ale też koszyk, formularz zamówienia i moduł płatności.
• Domena, hosting i dostępy przypisane do agencji. Objaw: nie możesz się zalogować i nie kontrolujesz odnowienia. Metoda: WHOIS domeny .pl pokazuje registranta i kontakt techniczny; w panelu hostingu sprawdź, czy masz własne konto administratora, czy jesteś tylko użytkownikiem dodanym; ustal, na czyj e-mail przychodzą przypomnienia o odnowieniu domeny i SSL. Przeniesienie domeny po konflikcie trwa dni, a sklep stoi.

Zanim podpiszesz umowę, sprawdź też, co składa się na koszt utrzymania i opieki technicznej sklepu — najtańszy abonament, który nie obejmuje testu odtworzenia kopii, kosztuje więcej niż pełna opieka w momencie pierwszej dłuższej awarii.

Integracje, które wymagają stałej opieki: płatności, kurierzy, ERP

Serwer działa, certyfikat ważny, a sklep i tak nie sprzedaje — bo padł webhook z bramki płatniczej albo moduł kuriera przestał pobierać statusy. W utrzymaniu sklepu najwięcej awarii nie dzieje się na poziomie hostingu, tylko na styku z systemami zewnętrznymi.

• Kurierzy: InPost, DPD, DHL. Każdy ma własne API, własny limit zapytań (osobno na minutę i na dobę) i webhooki, które informują sklep o zmianie statusu przesyłki. Typowe awarie: wygasły token, zmiana wersji API po stronie przewoźnika, przekroczony limit przy wysyłce fali zamówień po weekendzie. Efekt: klient widzi „przesyłka przygotowana”, a paczka jedzie od dwóch dni i nikt nie dzwoni z pytaniem, co się stało.
• Płatności online. PSD2 i 3DS wymuszają uwierzytelnianie silnym klientem. Po zmianach po stronie operatora płatności trzeba przekonfigurować moduł i przejść pełną ścieżkę: koszyk, 3DS, potwierdzenie, zwrot. Praktyka, która oszczędza weekendy: po każdej aktualizacji modułu płatności wykonaj transakcję testową i zwrot. To pięć minut pracy.
• ERP. Synchronizacja stanów magazynowych, zamówień i faktur działa na kolejkach. Kolejka potrafi się zatrzymać: brak wpisu cron, błąd 500 z API ERP, duplikat faktury przy podwójnym kliknięciu. Bez monitoringu dowiesz się o tym od klienta, któremu anulowano zamówienie na produkt, którego „nie ma”, choć leży na półce.

Alternatywą dla dokładania kolejnych płatnych wtyczek jest własny moduł pisany pod konkretny proces — płacisz raz za wdrożenie, a nie za roczną licencję. Komunikację modułu z PrestaShop realizuje się przez hooki, opisane w [dokumentacji dla deweloperów PrestaShop](https://devdocs.prestashop-project.org/). Takie podejście realnie obniża miesięczny koszt — zobacz, [ile kosztuje utrzymanie sklepu](https://dropdigital.pl/utrzymanie-opieka-techniczna-sklepow-zamosc-koszt).

Jak wybrać wykonawcę opieki technicznej w Zwierzyńcu i na Lubelszczyźnie?

Kryteria wyboru dostawcy opieki są sprawdzalne i nie potrzebujesz do nich wielkiej analizy. Cztery pytania zadane przez telefon odsieją większość słabych ofert:

• Kto realnie pracuje na moim sklepie? Chcesz usłyszeć role i godziny dostępności, nie „mamy zespół specjalistów”. Jeśli w ofercie jest tylko ogólny adres, poproś o kontakt do osoby prowadzącej projekt.
• Jaki jest SLA i co dokładnie obejmuje? Potrzebujesz dwóch liczb: czas reakcji i czas przywrócenia działania dla awarii krytycznej (sklep nie przyjmuje zamówień) oraz osobno dla zgłoszeń zwykłych. Muszą być w umowie, nie w prezentacji.
• Czy dostępy zostają u mnie? Panel hostingu, SFTP, baza, konto administratora sklepu — wszystko na konto firmy, z możliwością nadania i odebrania dostępu. Jeśli dostawca „trzyma” loginy, zostajesz z nim na zawsze.
• Kto robi backup i czy jest test odtworzenia? Kopia na tym samym serwerze to nie backup. Poproś o potwierdzenie, że kopia leży poza serwerem produkcyjnym i raz na kwartał jest odtwarzana na środowisku testowym.

Lokalność bywa przeceniana, ale nie jest bez znaczenia. W Polsce strefa czasowa jest jedna — problem pojawia się wtedy, gdy wykonawca pracuje z innego kontynentu i jego „reakcja w godzinę” wypada w środku naszej nocy. Lokalnie liczy się coś innego: kontakt telefoniczny w godzinach pracy, możliwość dojazdu i zrozumienie specyfiki regionu, np. sezonowości ruchu turystycznego na Roztoczu i wysyłek przed weekendem. Zanim podpiszesz umowę, porównaj [cennik i zakres opieki technicznej](https://dropdigital.pl/utrzymanie-i-opieka-techniczna-sklepow-zamosc-cennik) — zakres bywa ważniejszy od samej kwoty.

Czerwone flagi, które powinny zatrzymać rozmowę: brak miesięcznego raportu, brak testu backupu, brak jasnych godzin reakcji, aktualizacje wdrażane od razu na produkcji, brak środowiska testowego.

Od czego zacząć: pierwsze 30 dni opieki nad sklepem

Jeśli zaczynasz opiekę od zera, pierwsze 30 dni rozłóż na trzy etapy. Nie chodzi o wielkie wdrożenie, ale o uporządkowanie tego, co już masz.

Tydzień 1 — audyt i zabezpieczenie tyłów. Zbierz dostępy: panel hostingu, SFTP/SSH, baza danych, konto administratora sklepu, Cloudflare, Google Search Console. Spisz wersję PrestaShop lub WooCommerce, wersję PHP i listę modułów z datami ostatnich aktualizacji. Zrób pełną kopię plików i bazy, a potem odtwórz ją na środowisku testowym — bez tego nie wiesz, czy backup działa. Włącz monitoring dostępności z próbą co 1 minutę i alertem na e-mail oraz SMS. Przejrzyj logi błędów PHP i serwera z ostatnich 30 dni.

Tydzień 2–3 — aktualizacje, bezpieczeństwo, wydajność. Aktualizacje testuj najpierw na kopii testowej: rdzeń, moduły, szablon. Na produkcji wdrażaj pojedynczo, z kopią przed każdą zmianą. Włącz 2FA do panelu hostingu i konta administratora, ogranicz dostęp do katalogu /admin po IP lub hasłem serwera, wyłącz katalogowanie plików. Wydajność: cache, PHP-FPM, kompresja obrazów, poprawa LCP i CLS — te wskaźniki Google opisuje w dokumentacji [Core Web Vitals](https://web.dev/articles/vitals).

Tydzień 4 — raport, plan i SLA. Raport ma być krótki: co znaleziono, co naprawiono, co zostało na później. Do tego plan rozwoju na kwartał i ustalenie zasad zgłoszeń — jeden kanał, jasne godziny, zapisane czasy reakcji.

Chcesz zacząć od konkretów? DropDigital robi bezpłatną wstępną weryfikację sklepu: sprawdzamy wersje, backup, monitoring i integracje, a wynik dostajesz w formie krótkiej listy z priorytetami. Zakres i sposób pracy opisujemy na stronie [utrzymanie i opieka techniczna sklepów Zwierzyniec](https://dropdigital.pl/utrzymanie-i-opieka-techniczna-sklepow-zwierzyniec).

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

Lista kontrolna do odklikania

• Codzienny backup bazy i plików — Sprawdź w panelu lub u wykonawcy, czy kopia powstaje codziennie i obejmuje zarówno bazę, jak i pliki sklepu, w tym katalog uploadów.
• Retencja kopii minimum 30 dni — Zapytaj, ile dni wstecz sięgasz po kopię. Jeśli odpowiedź brzmi „tydzień”, wykrycie cichej awarii po dwóch tygodniach będzie kosztowne.
• Test odtworzenia w ostatnich 3 miesiącach — Poproś o datę ostatniego testu odtworzenia. Brak takiej daty oznacza, że nikt nie wie, czy backup w ogóle działa.
• Kopie trzymane poza serwerem produkcyjnym — Backup na tym samym serwerze, na którym stoi sklep, nie chroni przed awarią hostingu ani przed usunięciem danych.
• Środowisko testowe (staging) — Sprawdź, czy istnieje kopia sklepu do testów. Bez stagingu każda aktualizacja modułu jest testem na żywym organizmie.
• Aktualizacje bezpieczeństwa w ciągu 7 dni — Ustal, w jakim czasie od publikacji poprawki bezpieczeństwa jest ona wdrażana. Dłużej niż tydzień to realne okno dla atakujących.
• Monitoring dostępności co 1–5 minut — Sprawdź interwał i to, gdzie trafiają alerty. Monitor raz na godzinę nie wychwyci awarii w szczycie sprzedaży.
• Monitoring błędów i logów — Zapytaj, czy ktoś przegląda logi błędów PHP i ostrzeżenia. Błędy, których nikt nie widzi, zbierają się tygodniami.
• Certyfikat SSL z automatycznym odnawianiem — Sprawdź datę ważności i to, czy odnowienie jest automatyczne. Wygasły certyfikat blokuje zakupy i straszy klientów ostrzeżeniem w przeglądarce.
• Dostępy do domeny, DNS i hostingu po Twojej stronie — Zaloguj się do panelu rejestratora domeny i hostingu. Jeśli nie masz danych dostępowych, zacznij od ich odzyskania.
• Monitoring integracji płatności i kurierów — Sprawdź, czy błędy webhooków są rejestrowane i czy ktoś reaguje na ich wzrost. Powtarzające się błędy oznaczają zamówienia bez statusu.
• Synchronizacja z ERP z obsługą błędów — Ustal, co się dzieje, gdy ERP nie odpowiada. Bez kolejki i ponownych prób zamówienia po prostu nie trafią do systemu.
• Dokumentacja modułów, integracji i niestandardowych zmian — Sprawdź, czy istnieje lista modułów z wersjami i opis własnych modyfikacji. Bez tego każda migracja zaczyna się od archeologii.
• Miesięczny raport z wykonanych prac — Poproś o jeden przykładowy raport: co zrobiono, jakie ryzyka wykryto, co rekomendujecie na następny miesiąc.

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