Czym jest utrzymanie i opieka techniczna sklepu – zakres bez marketingowej mgły

Utrzymanie i opieka techniczna to nie jedna usługa, a powtarzalny zestaw czynności. W umowie warto rozbić go na siedem obszarów, każdy z osobnym zakresem odpowiedzialności. Bez tego po dwóch miesiącach pojawia się spór: czy opieka obejmuje konfigurację nowej metody płatności, czy to już osobny projekt.

1. Hosting lub VPS. Kto odpowiada za serwer, jaki jest limit memory_limit i max_execution_time, jaka wersja PHP i MariaDB. Sklep na PrestaShop 8 wymaga PHP 8.1+, a na hostingu z PHP 7.4 aktualizacje rdzenia są ryzykowne.
2. Aktualizacje. Rdzeń sklepu, moduły, motyw, biblioteki JS. Nie „raz na rok”, a w cyklu: krytyczne podatności łatane szybciej, zmiany funkcjonalne w oknie serwisowym. Punktem odniesienia dla zgodności modułów jest dokumentacja deweloperska PrestaShop.
3. Bezpieczeństwo. 2FA do panelu, WAF przed sklepem, skanowanie plików pod kątem webshelli, blokada nieudanych logowań.
4. Kopie zapasowe. Pliki plus baza, retencja minimum 30 dni, kopia poza serwerem sklepu, test odtworzenia na stagingu.
5. Monitoring. Dostępność, ważność certyfikatu SSL, błędy PHP w logach, czas odpowiedzi.
6. Wydajność. Cache, kompresja obrazów, indeksy w bazie. Mierzalne wskaźniki LCP, INP i CLS opisuje web.dev.
7. Wsparcie użytkowników. Kanał zgłoszeń (mail albo panel ticketowy) i czas reakcji — zarówno dla zespołu klienta, jak i dla zgłoszeń od kupujących.

Kluczowe rozróżnienie: utrzymanie chroni stan obecny, rozwój zmienia sklep tak, że kupujący widzi nową funkcję. Jedno i drugie jest potrzebne, ale rozliczane inaczej. Szerszy opis samego zakresu znajdziesz w tekście o utrzymaniu stron internetowych.

Ile kosztuje utrzymanie i opieka techniczna sklepu w Toruniu? Widełki 2025

Dla sklepu prowadzonego przez małą lub średnią firmę ceny w 2025 roku mieszczą się w trzech pasmach. Kwoty podaję netto miesięcznie, przy umowie na 12 miesięcy i stałej opłacie.

Drugi model to rozliczenie godzinowe. Realne stawki: 120–160 zł/h przy stałej współpracy miesięcznej, 180–250 zł/h przy pracach doraźnych. Za interwencję poza godzinami pracy — na przykład w niedzielę w trakcie promocji — dolicza się 50–100%.

Co podnosi cenę:

• Liczba modułów. 12 wtyczek to inny zakres testów po aktualizacji niż 60.
• Integracje z ERP (Subiekt, WF-Mag, Comarch) i systemami magazynowymi — każda aktualizacja wymaga sprawdzenia wymiany danych.
• Ruch. 10 tys. wizyt miesięcznie i 300 tys. to inne wymagania sprzętowe i inny koszt VPS.
• SLA. Reakcja w godzinę kosztuje więcej niż reakcja w jeden dzień roboczy.
• Wiek sklepu. PrestaShop 1.6 po zakończeniu wsparcia oznacza pracę na kodzie bez łatek bezpieczeństwa.

Przykład: sklep na PrestaShop 8, 25 modułów, integracja z Subiektem GT, 40 tys. wizyt miesięcznie, jedna osoba obsługująca zgłoszenia — realnie 1200–1600 zł netto miesięcznie. Podobne zestawienie stawek znajdziesz w materiale o cenniku utrzymania i opieki technicznej sklepów.

SLA, czas reakcji i dostępy – co musi znaleźć się w umowie

W umowie muszą być trzy rzeczy: priorytety zgłoszeń, czas reakcji oraz lista dostępów. Bez tego SLA jest deklaracją, nie zobowiązaniem.

Najczęstsza pułapka: czas reakcji to nie czas naprawy. „Reagujemy w godzinę” znaczy, że ktoś odbierze zgłoszenie i zacznie diagnozę — nie że sklep wróci do pracy po 60 minutach. Oba parametry zapisz osobno, podobnie jak okno serwisowe (np. aktualizacje w godz. 2:00–5:00).

Dostępy — zasada: agencja dostaje własne konto z uprawnieniami, klient pozostaje właścicielem. Konkretnie:

• DNS i domena — konto rejestratora na firmę klienta, agencja z dostępem technicznym.
• Hosting lub VPS — panel u klienta, agencja na podkoncie z ograniczonymi prawami.
• Panel sklepu — osobne konto administratora dla agencji, nie współdzielone hasło.
• Repozytorium kodu (Git) — właściciel: klient, agencja jako współpracownik.
• Płatności, Search Console, Analytics — dostęp przez zaproszenie, nigdy jako jedyny użytkownik.

Klauzula wyjścia. Zapisz okres wypowiedzenia (1–3 miesiące) i obowiązek przekazania dokumentacji: inwentaryzacji modułów, wersji, zadań cron, konfiguracji oraz dostępów w menedżerze haseł. Bez tego zmiana wykonawcy oznacza tygodnie odtwarzania wiedzy.

Własność kopii. Ustal, gdzie leżą (serwer agencji, chmura, macierz klienta), jak długo (np. 30 dni) i czy klient dostaje własną kopię poza infrastrukturą wykonawcy. Test odtworzenia raz na kwartał — bez testu kopia to tylko plik.

Checklista opieki technicznej sklepu w Toruniu – co sprawdzać co miesiąc

Poniższa lista zakłada jeden przegląd miesięczny, ale rozbity na zadania wykonywane w różnych dniach. Nie robi się wszystkiego w jednym oknie serwisowym — aktualizację modułu płatności sprawdza się po wdrożeniu na staging, a etykietę kurierską generuje się osobno, bo to inne API.

Obszar	Co dokładnie sprawdzić	Czym / gdzie	Dowód
Aktualizacje rdzenia	PrestaShop 1.7/8 lub WordPress + WooCommerce, changelog pod kątem zmian w API modułów	zaplecze, staging	lista wersji przed i po
PHP i baza	wersja PHP zgodna z wymaganiami sklepu, MySQL/MariaDB, zapytania dłuższe niż 1 s	phpinfo, logi serwera, slow query log	zrzut wersji i logów
Wtyczki i moduły	moduły płatności oraz InPost, DPD, DHL — data ostatniej aktualizacji i zgodność z wersją rdzenia	panel, changelog dostawcy	tabela wersji
Dostępność	kody 5xx, czas odpowiedzi TTFB dla strony głównej i karty produktu	UptimeRobot, Better Uptime, Pingdom	raport miesięczny
SSL	data wygaśnięcia, łańcuch certyfikatu, wymuszenie HTTPS, mixed content	SSL Labs, curl -I	wynik testu
Kopie zapasowe	pełna kopia plików i bazy, retencja 30 dni, kopia poza serwerem sklepu	panel hostingu lub skrypt	log kopii z rozmiarem
Test odtworzenia	przywrócenie kopii na staging i przejście ścieżki zakupowej	subdomena staging	notatka z datą testu
Płatności i kurierzy	transakcja testowa 1 zł i wygenerowanie etykiety InPost, DPD, DHL	sandbox bramki, panel przewoźnika	zrzut zamówienia testowego
SEO techniczne	liczba zaindeksowanych adresów, nowe 404, sitemap, dane strukturalne produktu	Search Console, Screaming Frog	lista błędów z datą
Core Web Vitals	LCP, INP, CLS dla mobile na trzech najważniejszych URL	PageSpeed Insights, Search Console	wartości liczbowe
Bezpieczeństwo	2FA dla kont administracyjnych, WAF, lista ról i uprawnień, logi logowań	panel, Cloudflare, logi	lista kont i zdarzeń

Trzy pozycje z tej listy robi się inaczej niż resztę. Kopia zapasowa bez testu odtworzenia to tylko pliki — dopiero przywrócenie na staging pokazuje, czy sklep wstaje w 20 minut, czy w 4 godziny. Test płatności sprawdza pełną ścieżkę: koszyk, wybór metody, powrót z bramki, mail potwierdzający i status zamówienia. Etykieta kurierska generowana raz w miesiącu wyłapuje zmiany w API przewoźnika, zanim zrobi to klient w listopadzie.

SEO techniczne rozdziel od treści. Sprawdzasz tylko rzeczy mierzalne: indeksację, nowe 404 (przekierowanie 301), poprawność danych strukturalnych i wyniki Core Web Vitals dla mobile. Progi LCP poniżej 2,5 s, INP poniżej 200 ms i CLS poniżej 0,1 to wartości podane w dokumentacji Web Vitals. Jeśli opiekun nie podaje tych liczb w raporcie, nie ma czego porównywać miesiąc do miesiąca. Sam zakres prac i ich podstawy opisujemy szerzej w materiale o utrzymaniu stron internetowych.

Monitoring sklepu: co robić codziennie, tygodniowo i miesięcznie

Rytm pracy ustala się raz i potem się go pilnuje. Bez tego opieka staje się reaktywna: ktoś dzwoni, że sklep nie działa, i dopiero wtedy zaczyna się szukanie. Podział na trzy częstotliwości działa, bo rozdziela tanie sprawdzenia od prac wymagających okna serwisowego. Sposób ułożenia całej współpracy opisujemy w tekście utrzymanie i opieka techniczna sklepów – jak to poukładać.

Częstotliwość	Zadanie	Kto wykonuje	Dowód / sygnał
Codziennie	dostępność strony głównej i karty produktu, kody 5xx, czas odpowiedzi	monitoring automatyczny	alert SMS przy braku odpowiedzi dłuższym niż 1 minuta
Codziennie	status transakcji w panelu bramki płatności	opiekun lub zespół sklepu	lista nieudanych transakcji
Tygodniowo	kopia plików i bazy poza serwer, kontrola rozmiaru i czasu wykonania	opiekun techniczny	log kopii w raporcie
Tygodniowo	przegląd logów błędów PHP i logów serwera	opiekun techniczny	wpis w raporcie tygodniowym
Tygodniowo	test ścieżki koszyka do potwierdzenia zamówienia	opiekun techniczny	zamówienie testowe z datą
Tygodniowo	aktualizacje modułów i wtyczek na staging	opiekun techniczny	lista wersji
Tygodniowo	bezpieczeństwo: nowe konta, nieudane logowania, blokady WAF	opiekun techniczny	lista zdarzeń
Miesięcznie	Core Web Vitals dla mobile	SEO lub opiekun	wartości dla trzech URL
Miesięcznie	raport incydentów i czas reakcji w odniesieniu do SLA	opiekun techniczny	zestawienie czasów
Miesięcznie	przegląd kosztów wtyczek i plan aktualizacji rdzenia	opiekun i właściciel sklepu	arkusz kosztów, harmonogram

Codzienny monitoring ustawia się na żądanie z losowym parametrem, żeby nie trafiać w cache. Alert idzie SMS-em, nie mailem — maila o 3:00 nikt nie czyta. Osobno sprawdzasz, czy liczba zamówień nie odbiega od średniej z siedmiu dni; spadek o połowę przy działającej stronie oznacza zwykle problem z bramką płatności, nie z hostingiem.

Tydzień to kopie, logi, wtyczki, bezpieczeństwo i test koszyka. Miesiąc to pomiary i decyzje: Core Web Vitals, raport incydentów z czasami reakcji, przegląd rocznych kosztów licencji i plan aktualizacji rdzenia na kolejny okres.

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

Te sytuacje rzadko wynikają ze złej woli — najczęściej z braku ustaleń na starcie. Każdą można sprawdzić w jeden dzień, jeszcze przed podpisaniem umowy albo przed przedłużeniem obecnej.

• Brak testu odtworzenia backupu. Poproś, żeby wykonawca przywrócił kopię z konkretnej daty — na przykład z 3. dnia poprzedniego miesiąca — na środowisko staging i pokazał, że strona oraz panel administracyjny działają. Jeśli odpowiedź brzmi „backup jest, na pewno działa”, to znaczy, że nikt go nie odtwarzał. To pytanie zadaj raz w roku, nie raz na zawsze.
• Aktualizacje od razu na produkcji. Wymagaj stagingu ze skopiowaną bazą i wyłączoną produkcyjną wysyłką maili, żeby testowe zamówienia nie trafiały do klientów ani do działu księgowości. Bez tego każda aktualizacja modułu to zakład: działa albo nie działa, a Ty dowiadujesz się o tym od klienta.
• Ukryte limity godzin w pakiecie. Czytaj regulamin i żądaj przykładowego raportu czasowego z poprzedniego miesiąca, z pozycjami po 15–30 minut. Zapytaj wprost, co się dzieje po przekroczeniu limitu: jaka jest stawka za godzinę i czy zadania są kolejkowane.
• Uzależnienie od jednej osoby. Pytaj o zastępstwo na czas urlopu i o dokumentację: dostępy w menedżerze haseł, opis konfiguracji serwera, lista modułów krytycznych. Jeśli wszystko zna jedna osoba i nie ma tego spisanego, ryzyko przenosi się na Ciebie.
• Płatne wtyczki tam, gdzie wystarczy moduł. Policz koszt trzech lat: licencja roczna × 3 plus czas na konfigurację i aktualizacje przemnożony przez Twoją stawkę godzinową. Porównaj wynik z jednorazową licencją modułu dedykowanego i jego rocznym wsparciem.

Przy każdym punkcie miej z tyłu głowy jedno: pytasz o dowód, nie o zapewnienie. Odtworzona kopia, lista wersji, raport czasowy i zrzut zamówienia testowego to dokumenty, które można obejrzeć. Widełki i sposób wyceny tych prac opisujemy w materiale o cenniku utrzymania i opieki technicznej sklepów.

Własne utrzymanie, freelancer czy agencja? Porównanie dla MŚP

Wybór modelu sprowadza się do trzech liczb: ile sklep ma zamówień miesięcznie, ile jest integracji poza sklepem i czy w firmie jest ktoś, kto realnie może wejść na serwer, bazę i moduły. Widełki poniżej to orientacyjne stawki rynkowe z 2025 roku dla PrestaShop i WooCommerce. Traktuj je jako punkt odniesienia do rozmowy, nie jako cennik.

Kiedy własne utrzymanie ma sens. Sklep do 500 zamówień/mies., prosty stack (PrestaShop lub WooCommerce, kilka modułów, brak ERP), brak kampanii sezonowych generujących skoki ruchu i osoba wewnątrz firmy, która ma czas i kompetencje. Policz to uczciwie: 6–10 godzin miesięcznie przy stawce wewnętrznej ok. 48 zł/h to 290–480 zł kosztu pracy plus narzędzia. Jeśli ta osoba robi jednocześnie faktury i obsługę klienta, w praktyce nie będzie robić aktualizacji w piątek o 22:00 przed weekendem promocyjnym.

Kiedy agencja. Gdy wchodzą integracje z ERP (Subiekt, Comarch, WF-Mag), gdy ruch przekracza 5000 zamówień/mies., gdy płatności i kurierzy mają API z limitami albo gdy potrzebujesz SLA z karami umownymi, bo przestój kosztuje więcej niż abonament. Przy kilku tysiącach zamówień miesięcznie każda godzina przestoju w poniedziałek rano to realna strata.

Pułapki. Freelancer bywa tańszy i szybszy, ale nie ma zastępstwa — choroba i urlop w szczycie sezonu to Twój problem. Własne utrzymanie zwykle nie zawiera testu odtworzenia backupu, bo nikt tego nie lubi robić. Agencja bywa wolniejsza w drobiazgach, dlatego w umowie musi być zapisany czas reakcji dla zgłoszeń drobnych, nie tylko dla awarii krytycznej.

Jak wybrać wykonawcę utrzymania sklepu w Toruniu – 7 pytań na pierwszą rozmowę

Pierwsza rozmowa nie służy do poznania ceny, tylko do sprawdzenia, czy wykonawca ma procedury. Zadaj te pytania po kolei i notuj odpowiedzi — po rozmowie wyślij mailem podsumowanie ustaleń, to najprostszy sposób, żeby później nie było sporów.

1. Jakie macie gwarantowane czasy reakcji i naprawy? Potrzebujesz dwóch różnych liczb: czas reakcji (potwierdzenie przyjęcia zgłoszenia) i czas usunięcia awarii, osobno dla P1 (sklep nie działa, płatności nie przechodzą), P2 (błąd w koszyku, część zamówień nie trafia do systemu) i P3 (kosmetyka). „Zajmiemy się szybko” to nie SLA.
2. Jak robicie kopie zapasowe i kiedy ostatnio odtwarzaliście je z testem? Konkret: baza co godzinę lub raz dziennie, pliki raz dziennie, kopia poza serwerem produkcyjnym, retencja min. 30 dni, test odtworzenia na staging raz na kwartał. Brak testu odtworzenia oznacza brak backupu.
3. Kto i jak przechowuje dostępy? Menedżer haseł (Bitwarden, 1Password), nie arkusz na dysku. Zapytaj, czy dostaniesz pełną listę dostępów i czy wrócą do Ciebie w 24 h po zakończeniu umowy. Nie oddawaj na wyłączność konta hostingu i zarządzania DNS.
4. Co dokładnie znajdę w raporcie miesięcznym? Lista aktualizacji z numerami wersji, incydenty z godzinami, wynik testu backupu, czasy ładowania, rekomendacje. Poproś o przykładowy raport dla innego klienta z zamazanymi danymi.
5. Ile sklepów PrestaShop i WooCommerce prowadzicie i w jakich wersjach? Sprawdź, czy wiedzą, że aktualizacja modułu może nadpisać zmiany w motywie, i czy pracują na PHP 8.1+ oraz MariaDB. Dokumentacja techniczna PrestaShop pomaga zweryfikować, czy rozmawiasz z kimś, kto czyta release notes.
6. Opowiedzcie o ostatniej awarii: co się stało, jak ją wykryliście, ile trwało usunięcie? Dobra odpowiedź zawiera datę, liczbę godzin i zmianę procesu po zdarzeniu.
7. Kto fizycznie wykonuje prace? Czy masz kontakt z deweloperem, czy z pośrednikiem, i kto odbiera telefon w sobotę przed kampanią.

Czerwona flaga: umowa na 12 miesięcy bez miesięcznego okresu wypowiedzenia i bez kar za niedotrzymanie SLA. Zanim podpiszesz, zobacz, jak poukładać zakres utrzymania i opieki technicznej sklepów — to dobra lista kontrolna do porównania ofert.

Wdrożenie opieki krok po kroku: od audytu do pierwszego raportu

Dobry start opieki zamyka się w 30 dniach. Poniżej rozkład prac, który można wpisać do umowy jako etap wdrożenia.

Dni 1–3: audyt i inwentaryzacja.

• Spis modułów i wtyczek z wersjami (PrestaShop: zakładka Moduły; WooCommerce: Wtyczki) — również tych wyłączonych, bo to częste źródło podatności.
• Wersje PHP, MySQL/MariaDB, motywu oraz lista plików nadpisanych w katalogu motywu.
• Inwentaryzacja dostępów: panel hostingu, DNS, poczta, FTP/SFTP lub SSH, konto administratora sklepu, Google Search Console, Analytics, API płatności i kurierów.
• Arkusz z kolumnami: komponent, wersja, kto odpowiada, data ostatniej zmiany, do kiedy wsparcie/licencja.

Dni 4–7: zabezpieczenie podstaw.

• Pełny backup plików i bazy, a następnie test odtworzenia na subdomenie staging — sprawdzasz, czy po odtworzeniu zgadzają się zamówienia, stany magazynowe i ceny.
• Monitoring z zewnątrz, np. sprawdzenie co minutę z dwóch lokalizacji, z alertem SMS do konkretnej osoby, nie na ogólną skrzynkę.
• Aktualizacje krytyczne: łaty bezpieczeństwa wgrane od razu, pozostałe moduły testowane najpierw na staging.
• Dokumentacja w pięciu krokach: jak przywrócić sklep z backupu, do kogo dzwonić, kto decyduje o wyłączeniu sklepu w tryb serwisowy.

Dni 8–30: rytm tygodniowy i pierwszy raport. Tydzień w tydzień: przegląd logów pod kątem błędów 500 i nieudanych płatności, aktualizacje w oknie niskiego ruchu (np. wtorek 6:00–8:00), jedno zamówienie testowe z prawdziwą płatnością. W dniu 30 dostajesz raport miesięczny: liczba aktualizacji, czasy reakcji, wynik testu backupu, czas ładowania sklepu i plan rozwoju na kolejny kwartał — np. aktualizacja PHP albo wymiana modułu, którego autor przestał go rozwijać. Zgodność wersji modułów z rdzeniem najłatwiej sprawdzić w dokumentacji deweloperskiej PrestaShop, zanim zaplanujesz aktualizację.

Pułapka: jeśli po 30 dniach nie masz raportu i dokumentacji przywracania, nie kupiłeś opieki, tylko spokój na papierze. Podobny proces opisujemy przy utrzymaniu i opiece technicznej sklepów dla firmy.

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

Lista kontrolna do odklikania

• Aktualizacje PrestaShop / WooCommerce i wtyczek — Raz w miesiącu, po wcześniejszym teście na stagingu. Zapisuj wersje przed i po aktualizacji, żeby móc cofnąć zmianę.
• Wersja PHP i bazy danych — Sprawdź raz w miesiącu, czy PHP jest w wersji wspieranej przez dostawcę i czy sklep nie działa na wersji wycofanej ze wsparcia.
• Monitoring dostępności sklepu — Codziennie. Sprawdzaj nie tylko stronę główną, ale też kartę produktu, koszyk i stronę płatności – awarie najczęściej dotyczą właśnie tych kroków.
• Certyfikat SSL — Sprawdź datę wygaśnięcia raz w miesiącu i ustaw alert na 30 dni przed. Wygasły certyfikat blokuje zakupy i psuje zaufanie w przeglądarce.
• Kopie zapasowe – obecność i retencja — Sprawdź raz w tygodniu, czy kopie faktycznie powstały i ile dni wstecz możesz się cofnąć. Minimum to 30 dni retencji dla sklepu z zamówieniami.
• Test odtworzenia kopii na staging — Raz na kwartał. Nie wystarczy, że plik istnieje – trzeba pokazać działający sklep odtworzony z tej kopii.
• Testy płatności — Raz w miesiącu wykonaj transakcję testową (lub zwrotową) i sprawdź, czy statusy zamówień wracają poprawnie do sklepu. Sprawdź też powiadomienia e-mail.
• Integracje kurierskie: InPost, DPD, DHL — Raz w miesiącu wygeneruj etykietę testową i sprawdź aktualizację statusu przesyłki. Po każdej aktualizacji modułu sprawdzaj to ponownie.
• Indeksacja i błędy 404 — Raz w miesiącu przejrzyj raport błędów w Google Search Console i listę 404 w logach serwera. Wyłapiesz wtedy produkty usunięte bez przekierowania.
• Core Web Vitals — Raz w miesiącu porównaj wyniki z poprzednim odczytem. Punkt odniesienia i definicje metryk opisuje dokumentacja web.dev oraz Google Search Central.
• Bezpieczeństwo: 2FA, WAF, uprawnienia, logi — Raz w miesiącu sprawdź, kto ma konto administracyjne, czy 2FA jest włączone wszędzie i czy w logach nie ma serii nieudanych logowań.
• Przegląd kosztów wtyczek i modułów — Raz na kwartał zrób listę aktywnych subskrypcji i sprawdź, czy nadal zarabiają na siebie. Zbędne wyłączaj świadomie, nie „na potem”.

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