Obsługa strony internetowej — co naprawdę kupujecie, podpisując umowę

Obsługę strony internetowej sprzedaje się jako listę czynności: aktualizacje, kopie zapasowe, monitoring, „drobne zmiany w ramach pakietu". Kupujecie jednak coś innego — umowę. A w umowie liczą się trzy rzeczy, o których oferty zwykle milczą: co dostajecie, kiedy obietnica nie zostanie dotrzymana, czyje jest to, co wykonawca zrobił, i kto ma klucze, kiedy się rozstaniecie.

Żeby zobaczyć, jak duża jest różnica między „ktoś się stroną zajmuje" a „ktoś za nią odpowiada", wystarczy jedna liczba z publicznych statystyk WordPressa.

Według statystyk WordPress.org 38% instalacji działa dziś na wersji PHP, która nie dostaje już poprawek bezpieczeństwa. Kolejne 25% stoi na PHP 8.2, dla którego harmonogram php.net kończy wsparcie 31 grudnia 2026 roku. Od 1 stycznia będzie to 63%.

Wersji PHP nie widać w panelu WordPressa i nie przypomina o niej żadne powiadomienie. Zmienia się ją na serwerze, nie przyciskiem „aktualizuj". Dlatego jest dobrym testem: przy wielu z tych stron ktoś co miesiąc klika aktualizacje wtyczek i wystawia za to fakturę — i nikt nie zapisał w umowie, że środowisko, na którym strona stoi, też jest jego zadaniem.

Ten tekst jest o umowie, nie o czynnościach. Każdą z czynności rozkładamy osobno i odsyłamy do niej w miejscu, w którym się pojawia.

Obsługa, opieka, administracja — jedna usługa, cztery rodzaje pracy

Obsługa strony internetowej, opieka nad stroną, administracja stroną www, wsparcie techniczne — w ofertach te nazwy są wymienne i żadna nie ma ustalonego znaczenia. Dwie firmy sprzedające „opiekę" mogą mieć w pakiecie zupełnie co innego, a dwie sprzedające „obsługę" i „administrację" — dokładnie to samo. Porównywanie ofert po nazwie usługi nie ma więc sensu. Porównuje się je po tym, które z czterech rodzajów pracy są w środku:

• Praca stała — to, co dzieje się bez Waszego zgłoszenia: aktualizacje, kopie zapasowe, monitoring dostępności, odnowienia domeny i certyfikatu. Da się ją opisać z góry i wycenić ryczałtem.
• Reakcja — to, co dzieje się, gdy coś się zepsuło: strona nie działa, formularz nie wysyła, sklep nie przyjmuje płatności. Nie da się jej przewidzieć, da się tylko ustalić, jak szybko i w jakich godzinach ma nastąpić.
• Zmiany — to, o co prosicie: nowa podstrona, poprawka w układzie, podmiana zdjęć, nowe pole w formularzu. To praca rozwojowa, nie utrzymaniowa, nawet jeśli jest drobna.
• Doradztwo — odpowiedź na pytanie „czy powinniśmy", zanim ktoś coś zrobi: zmiana hostingu, wtyczka do rezerwacji, przejście na nowszą wersję systemu.

Większość ofert opisuje szczegółowo pierwszy rodzaj — bo jest najłatwiejszy do spisania — a pozostałe trzy jednym zdaniem. Spory rodzą się w tych trzech.

Gdzie kończy się zakres

Najczęstszy spór w obsłudze strony nie dotyczy awarii, tylko zdania „to było w pakiecie". Zaczyna się od sformułowania, które jest w prawie każdej ofercie: „drobne zmiany w ramach abonamentu". Dla Was drobną zmianą jest dodanie pola „NIP" do formularza. Dla wykonawcy to może być zmiana w formularzu, w walidacji, w szablonie maila z potwierdzeniem i w eksporcie do systemu sprzedaży — cztery miejsca, dwie godziny.

Są dwa uczciwe sposoby, żeby to rozstrzygnąć zawczasu:

Pula godzin. Pakiet zawiera określoną liczbę godzin miesięcznie na zmiany, a wykonawca raportuje, ile zużył. Zaleta: nie ma sporu o to, czy coś jest „drobne". Warunek: raport z rozbiciem na zadania, a nie jedna liczba na fakturze, i jasna zasada, co się dzieje z niewykorzystanymi godzinami — przechodzą na kolejny miesiąc czy przepadają.

Lista zadań. Pakiet wymienia, co obejmuje — z nazwy — a wszystko inne jest wyceniane osobno przed wykonaniem. Zaleta: przewidywalny rachunek. Warunek: lista musi być konkretna. „Bieżące wsparcie" nie jest pozycją listy, „podmiana treści na istniejących podstronach, do 10 zmian miesięcznie" — jest.

Niezależnie od modelu w umowie powinna być lista wyłączeń, czyli rzeczy, które na pewno nie są w pakiecie. Typowo: nowe funkcje, zmiany w wyglądzie wykraczające poza podmianę treści, integracje z nowymi systemami, naprawa skutków zmian wprowadzonych przez kogoś innego, przeniesienie strony na inny serwer. Wyłączenia nie są złą wiadomością — są informacją, za którą płacicie osobno i o której wiecie przed podpisaniem, a nie przy pierwszej fakturze dodatkowej.

Ile to wszystko kosztuje, rozkładamy w osobnym tekście o kosztach utrzymania strony, a policzyć dla własnej strony można w kalkulatorze kosztu utrzymania. Tutaj interesuje nas, co za tę kwotę dostajecie.

Czas reakcji to nie czas naprawy

„Odpowiadamy w ciągu godziny" to najczęściej spotykana obietnica w ofertach obsługi stron i najczęściej źle rozumiana. Czas reakcji mierzy, kiedy ktoś potwierdzi, że przyjął zgłoszenie. Czas naprawy mierzy, kiedy strona znowu działa. Umowa może gwarantować pierwsze i milczeć o drugim — wtedy w ciągu godziny dostaniecie maila „przyjęliśmy, sprawdzamy", a strona może nie działać do następnego dnia, zgodnie z umową.

Nie znaczy to, że czas naprawy da się zagwarantować. Nie da się, bo przyczyna awarii może leżeć poza wykonawcą — u dostawcy hostingu, operatora płatności, w zewnętrznej usłudze. Da się za to zapisać trzy rzeczy, które mają realną wartość:

• Czas reakcji osobno dla każdego priorytetu. Priorytet ustala się według skutku dla firmy, nie według tego, co jest zepsute technicznie: „strona nie działa albo nie da się złożyć zamówienia" to co innego niż „na jednej podstronie rozjechało się zdjęcie", nawet jeśli oba wymagają podobnej pracy.
• Godziny, w których obowiązuje. „W ciągu godziny" w dni robocze od 9 do 17 oznacza, że awaria zgłoszona w piątek o 18 czeka do poniedziałku. To może być w porządku dla strony firmowej i nie do przyjęcia dla sklepu, ale powinno być napisane.
• Czas do obejścia albo informacji o przyczynie. Zamiast gwarancji naprawy — zobowiązanie, że w określonym czasie dostaniecie diagnozę i plan albo tymczasowe rozwiązanie. Tego się nie da obiecać bez wiedzy, więc to dobry sprawdzian, czy wykonawca ją ma.

Umowa SLA: co dopuszcza 99,9% i co dostajecie, gdy nie zostanie dotrzymana

SLA (ang. service level agreement) to część umowy, w której dostępność usługi wyraża się w procentach. Brzmi to jak gwarancja, ale warto policzyć, co procent oznacza w godzinach, bo intuicja podpowiada coś innego niż arytmetyka.

Dostępność 99,9% dopuszcza 44 minuty przestoju w każdym miesiącu — i przez te 44 minuty nic Wam się nie należy, bo umowa jest dotrzymana. 99% to już ponad siedem godzin miesięcznie. Jeśli oferta podaje procent bez słowa o tym, jak jest liczony, brakuje w niej trzech rzeczy, które decydują o tym, ile ten procent jest wart:

• Okres rozliczenia. 99,9% liczone w skali roku pozwala na prawie dziewięć godzin przestoju jednego dnia, byle reszta roku była czysta. W skali miesiąca — nie.
• Kto mierzy i czym. Pomiar wykonawcy z jego własnego serwera może nie zauważyć, że strona nie odpowiada z zewnątrz. Najprostsze rozwiązanie to niezależny monitoring, do którego wgląd macie Wy.
• Co jest wyłączone. Prace zaplanowane i zapowiedziane zwykle nie liczą się do przestoju. To rozsądne — pod warunkiem, że umowa określa, jak wcześnie trzeba je zapowiedzieć i w jakich godzinach wolno je robić.

Drugie pytanie jest ważniejsze od pierwszego: co się dzieje, gdy SLA nie zostanie dotrzymane. Standardem rynkowym jest zwrot części opłaty za usługę. Dobrze to widać w jednym z najczęściej cytowanych publicznych SLA — umowie Amazon EC2. Amazon zobowiązuje się do 99,99% dostępności w regionie. Gdy jej nie dotrzyma, klient dostaje zwrot 10% opłaty; poniżej 99% — 30%; poniżej 95% — 100%. A umowa zastrzega, że to jej „sole and exclusive remedies" — jedyny środek, jaki klientowi przysługuje.

To nie jest zarzut wobec Amazona — tak wygląda mechanizm. Ale przeniesiony na stronę firmową daje rachunek, który warto zrobić przed podpisaniem: cały dzień bez strony to dostępność w miesiącu około 96,7%, czyli przy takiej skali zwrotów 30% opłaty. Przy abonamencie za kilkaset złotych miesięcznie cała rekompensata za dzień bez sprzedaży to sto, dwieście złotych. Wasza utracona sprzedaż nie wchodzi do rachunku. SLA jest więc przede wszystkim informacją — mierzalnym zobowiązaniem, które pozwala stwierdzić, że usługa jest zła — a nie ubezpieczeniem.

Jeśli potrzebujecie czegoś więcej niż informacji, polskie prawo daje narzędzie, które działa inaczej: karę umowną. Kodeks cywilny pozwala w art. 483 zastrzec, że naprawienie szkody z niewykonania zobowiązania niepieniężnego nastąpi przez zapłatę określonej sumy, a art. 484 stanowi, że kara należy się „bez względu na wysokość poniesionej szkody". Kara umowna działa w obie strony — wykonawca wyceni ją w cenie usługi — więc ma sens tam, gdzie przestój realnie kosztuje, a nie jako punkt negocjacji dla zasady.

Kto trzyma klucze

Najdroższy problem w obsłudze strony nie wydarza się w trakcie współpracy, tylko przy jej końcu — kiedy okazuje się, że domena jest zarejestrowana na wykonawcę, konto hostingowe założył jego pracownik, a hasło do panelu zna jedna osoba, która już tam nie pracuje. Każda z tych rzeczy jest do odzyskania, ale każda kosztuje czas, a niektóre — dobrą wolę strony, z którą właśnie się rozstajecie.

Zasada jest jedna: wszystko, co jest „stroną", powinno być zarejestrowane na firmę, a wykonawca powinien mieć do tego dostęp nadany — nie własny. Różnica jest taka, że dostęp nadany można odebrać jednym kliknięciem.

Domena jest z tej listy najpoważniejsza, bo jako jedyna może przejść na kogoś zupełnie obcego — co dzieje się z nią po przeoczonym odnowieniu, opisujemy przy kosztach utrzymania. Reszta tabeli nie wymaga żadnej wiedzy technicznej: wystarczy przy podpisaniu umowy zapytać o każdy wiersz, na kogo jest dziś zarejestrowany, i zapisać odpowiedź.

Czyje jest to, co napisał wykonawca — i czyje są dane

Druga część tego samego problemu dotyczy nie dostępów, tylko praw. Zapłaciliście za stronę, więc intuicja podpowiada, że jest Wasza. Ustawa mówi co innego — i warto znać trzy przepisy, zanim podpisze się umowę na wykonanie albo na obsługę. Przytaczamy ich treść; to nie jest porada prawna, a przy umowie o dużej wartości warto pokazać ją prawnikowi.

Faktura nie przenosi praw autorskich. Według art. 53 ustawy o prawie autorskim umowa o przeniesienie autorskich praw majątkowych „wymaga zachowania formy pisemnej pod rygorem nieważności". Jeśli takiej umowy nie ma, macie stronę, za którą zapłaciliście, ale prawa do kodu, grafik i tekstów mogą nadal należeć do tego, kto je stworzył.

Liczy się to, co wymienione. Art. 41 ust. 2 tej samej ustawy: umowa o przeniesienie praw lub licencja obejmują „pola eksploatacji wyraźnie w nich wymienione". Zapis „przenosimy wszelkie prawa" bez wyliczenia, co wolno z utworem robić — zwielokrotniać, wprowadzać do sieci, modyfikować — może znaczyć mniej, niż się wydaje. Dla strony internetowej szczególnie ważne jest prawo do modyfikacji, bo bez niego inny wykonawca formalnie nie powinien tego kodu zmieniać.

Poprawianie błędów jest wyjątkiem. Art. 75 ust. 1 pozwala osobie, która legalnie weszła w posiadanie programu komputerowego, wykonywać czynności niezbędne do korzystania z niego zgodnie z przeznaczeniem, „w tym do poprawiania błędów" — bez zgody uprawnionego, „jeżeli umowa nie stanowi inaczej". To zabezpiecza bieżące naprawy po zmianie wykonawcy, ale nie rozbudowę. I umowa może ten wyjątek wyłączyć, więc warto sprawdzić, czy tego nie robi.

W praktyce oznacza to jedno zdanie do sprawdzenia w umowie na wykonanie strony: czy jest w niej pisemne przeniesienie praw z wyliczonymi polami eksploatacji, w tym modyfikacją. Przy obsłudze to samo dotyczy wszystkiego, co wykonawca dopisze w trakcie — nowych podstron, funkcji, grafik.

Dane to osobna umowa. Jeśli wykonawca ma dostęp do panelu, w którym leżą zgłoszenia z formularzy, konta klientów albo zamówienia, przetwarza dane osobowe w Waszym imieniu. RODO wymaga na to umowy powierzenia (art. 28), co opisujemy przy przepisach o prywatności na stronie. Przy obsłudze najważniejszy jest jeden jej punkt — art. 28 ust. 3 lit. g: po zakończeniu świadczenia usług wykonawca, zależnie od Waszej decyzji, usuwa albo zwraca wszystkie dane i usuwa ich kopie. To jest zapis o wyjściu ze współpracy, zanim ta się zaczęła.

Zmiana firmy obsługującej stronę

Jeśli poprzednie dwie sekcje są uporządkowane, zmiana wykonawcy jest procedurą, a nie kryzysem. Pięć kroków, w tej kolejności:

1. Inwentarz. Lista z tabeli wyżej, z odpowiedzią przy każdym wierszu: na kogo, kto ma dostęp, gdzie leży. Plus lista wtyczek, integracji i zewnętrznych usług, za które płaci się osobno — to one najczęściej wychodzą na jaw dopiero po przekazaniu, kiedy przestają działać.
2. Eksport. Kod (repozytorium albo pełna kopia plików), baza danych, pliki wgrane przez użytkowników, konfiguracja serwera, dokumentacja — jeśli istnieje. Do tego umowa o przeniesieniu praw, jeśli jej dotąd nie było.
3. Test odtworzenia. Nowy wykonawca stawia kopię strony u siebie z tego, co dostał. Dopiero działająca kopia dowodzi, że eksport jest kompletny — sama paczka plików niczego nie dowodzi, co rozkładamy przy kopiach zapasowych.
4. Okres równoległy. Tydzień albo dwa, w których stary wykonawca jeszcze odpowiada na pytania. Najtańsze w tej pracy są odpowiedzi na pytanie „dlaczego to jest zrobione w ten sposób".
5. Zamknięcie dostępów. Zmiana haseł do wszystkiego z inwentarza, usunięcie kont poprzedniego wykonawcy, odebranie uprawnień w Search Console i menedżerze tagów. I pisemne potwierdzenie usunięcia danych, o którym mowa w art. 28 RODO.

Przy dobrze prowadzonej obsłudze krok pierwszy zajmuje godzinę, bo inwentarz już istnieje. Przy źle prowadzonej — to on trwa najdłużej, i to jest najlepsza miara tego, co przez lata faktycznie kupowaliście.

Opieka nad stroną WordPress — co jest inne

Opieka nad stroną WordPress to w praktyce dwie rzeczy, i żadna z nich nie jest „utrzymywaniem WordPressa".

Pierwsza to wtyczki. Według raportu, który rozkładamy przy aktualizacjach, 91% podatności znalezionych w 2025 roku w ekosystemie WordPressa dotyczyło wtyczek, a w samym rdzeniu — sześć, wszystkie niskiego priorytetu. Opieka nad WordPressem to więc głównie dyscyplina wtyczek: ile ich jest, które są jeszcze rozwijane, w jakiej kolejności je aktualizować i co zrobić, gdy któraś ma lukę bez poprawki. WordPress od wersji 5.5 potrafi aktualizować wtyczki automatycznie, ale automat nie zastępuje tej decyzji — przy awarii nie wiadomo, która z aktualizacji ją spowodowała.

Druga to PHP, czyli wykres z początku tego tekstu. Wersja PHP to warstwa, której właściciel strony nie widzi, a która decyduje, czy serwer dostaje poprawki bezpieczeństwa. Przy 38% instalacji już ich nie dostaje. Zmiana wersji PHP nie jest aktualizacją, tylko zmianą środowiska: potrafi położyć starszą wtyczkę albo motyw, więc wymaga kopii, testu i kogoś, kto wie, co sprawdzić. Termin dla PHP 8.2 i to, co z niego wynika dla całej strony, opisujemy w tekście o tym, kiedy strona wymaga modernizacji.

Z tego wynika prosty test oferty na opiekę nad WordPressem. Zapytajcie wykonawcę o dwie rzeczy: na jakiej wersji PHP stoi dziś Wasza strona i kiedy traci ona wsparcie oraz ile wtyczek jest zainstalowanych i które z nich nie miały aktualizacji od roku. Wykonawca, który opiekuje się stroną, odpowie w kilka minut z pamięci albo z raportu. Wykonawca, który klika aktualizacje, musi sprawdzić — a to też jest odpowiedź.

Administracja WordPressem dotyczy też kont w panelu. Po kilku latach lista użytkowników z uprawnieniami administratora wygląda zwykle inaczej, niż ktokolwiek pamięta — to zabezpieczenia, ale sprawdzenie tej listy powinno być pozycją w każdym pakiecie opieki.

Własny administrator czy firma zewnętrzna

Pytanie „zatrudnić czy zlecić" ma w obsłudze strony jedną właściwość, która zwykle rozstrzyga je szybciej niż rachunek: jedna osoba na etacie nie zapewni dyżuru. Choruje, ma urlop, śpi. Umowa SLA na 99,9% dostępności, czyli 44 minuty przestoju w miesiącu, jest z jedną osobą niewykonalna niezależnie od jej kompetencji — awaria, która w tygodniu urlopu poczeka na jego powrót choćby jeden dzień, przekracza miesięczny limit ponad trzydziestokrotnie.

Rachunek też warto zrobić na danych, a nie na obiegowych kwotach. GUS podaje w badaniu struktury wynagrodzeń za październik 2024 roku:

• technicy wsparcia informatycznego (grupa zawodów, do której należy administrator stron): mediana 8 238 zł brutto miesięcznie, średnia 9 588 zł, a w zakładach do 19 osób średnio 6 810 zł;
• programiści i analitycy systemów: mediana 13 900 zł brutto.

Dwa zastrzeżenia do tych liczb. Badanie obejmuje podmioty zatrudniające więcej niż 9 osób, więc najmniejsze firmy nie są w nim widoczne. I są to kwoty brutto pracownika — koszt pracodawcy jest wyższy o składki, a do tego dochodzą sprzęt, licencje i szkolenia.

Z tego wynika granica, a nie werdykt. Etat ma sens, gdy strona jest częścią codziennej pracy firmy — sklep z codziennymi zmianami w ofercie, portal, system, w którym pracują klienci — i gdy zajęcia wystarczy na pełny etat, a dyżur poza godzinami pracy zapewnia ktoś inny. Firma zewnętrzna ma sens, gdy pracy jest kilka godzin w miesiącu, co dotyczy większości stron firmowych — płacicie wtedy za dostępność zespołu, a nie za czas jednej osoby. Model mieszany, w którym osoba w firmie zbiera zgłoszenia i zarządza treścią, a wykonawca odpowiada za technikę i dyżur, łączy obie zalety — pod warunkiem, że podział jest zapisany.

Czego w tym tekście świadomie nie ma

• Cen i widełek — to koszty utrzymania strony, rozłożone na cztery warstwy rachunku, i kalkulator do policzenia własnego przypadku.
• Jak aktualizować — aktualizacje strony, z kolejnością, która nie psuje strony.
• Jak robić kopie i je sprawdzać — kopia zapasowa strony.
• Jak ustawić monitoring — osobno.
• Szybkości strony — to Core Web Vitals, czyli metryki, których Google naprawdę używa.

Najkrótsze podsumowanie: przed podpisaniem umowy na obsługę strony internetowej sprawdźcie nie listę czynności, tylko trzy zapisy — co dostajecie, gdy wykonawca nie dotrzyma obietnicy, czyje jest to, co napisze, i na kogo są zarejestrowane domena, hosting i konta. Czynności wykona każda firma. Te trzy zapisy odróżniają usługę, za którą ktoś odpowiada, od usługi, którą ktoś wykonuje.