Opieka techniczna WordPress: utrzymanie strony i sklepu

WPPoland (Mariusz Szatkowski) to opieka techniczna i utrzymanie WordPress: codzienne kopie zapasowe, aktualizacje najpierw na stagingu, monitoring dostępności co 1 do 5 minut, całą dobę. WordPress od 2006, z Gdyni. Pisemna wycena po krótkim briefie.

#Opieka techniczna WordPress: na czym polega utrzymanie strony

Opieka techniczna nad stroną opartą o WordPress to stała praca, od której zależy, czy strona działa, ładuje się szybko i nie rozsyła malware. Strona bez aktualizacji zbiera luki we wtyczkach, a strona bez sprawdzonej kopii zapasowej może stracić zamówienia i faktury przy pierwszej awarii hostingu.

Przy przejęciach i przenosinach stacku przed pierwszym miesiącem utrzymania zacznij od oceny migracji WordPress. Po przeniesieniu trzymaj sklep na planie niezawodności, żeby monitoring i aktualizacje były jawne. Jeśli koszyk już nie działa, zacznij od sprintu naprawy WooCommerce przed abonamentem.

Opiekę prowadzę zdalnie, więc ten sam zakres dostają firmy z Warszawy, Krakowa, Wrocławia, Gdańska, Poznania i każdego innego miasta. Gdy strona już nie działa, zamiast abonamentu potrzebna jest naprawa i pomoc techniczna WordPress.

#Co obejmuje opieka nad stroną WordPress

Opieka składa się z kilku stałych prac. Każda z nich ma osobną stronę z dokładnym opisem.

Rdzeń, wtyczki i motywy aktualizuję co tydzień, najpierw na stagingu, po pełnej kopii zapasowej, a po aktualizacji porównuję zrzuty ekranu sprzed zmiany i po niej. Przejście na nowszą wersję PHP też jest w opiece. Duże wersje wtyczek przeglądam co miesiąc, listę wtyczek co kwartał. Harmonogram, przebieg jednej rundy i to, co robię, gdy aktualizacja coś zepsuje, opisuję na stronie aktualizacje WordPress.

Monitoring skanuje pliki pod kątem malware i pilnuje ich integralności. Gdy dojdzie do włamania, pracuję według stałej kolejności: dowody, diagnoza, czyszczenie na kopii, nowe hasła, prośba o przegląd w Google. Szczegóły i obowiązki z RODO są na stronie usuwanie wirusów WordPress. Jednorazową, dogłębną ocenę zabezpieczeń daje audyt bezpieczeństwa WordPress.

Widełki dla strony firmowej i sklepu, to, co wchodzi w abonament, i to, co rozliczam osobno, zebrałem na stronie opieka WordPress cena.

W opiece mierzę Core Web Vitals co miesiąc i pilnuję, żeby wynik nie spadał. Jednorazową, skupioną poprawę szybkości robię w ramach optymalizacji szybkości WordPress.

Zmierzone liczby dla jednego adresu, jeszcze przed rozmową o zakresie, pokazuje sprawdzenie strony WordPress.

#Jak zaczyna się opieka

#Harmonogram prac w opiece

Codziennie, niezależnie od harmonogramu, powstaje kopia zapasowa, a monitoring sprawdza dostępność co 1 do 5 minut i pilnuje plików.

#Na czym polega pielęgnacja WordPress?

WordPress to najpopularniejszy system zarządzania treścią na świecie, napędzający około 40% wszystkich stron internetowych (W3Techs). Ta sama otwartość, która daje mu tysiące wtyczek i motywów, sprawia, że każda instalacja składa się z kodu wielu autorów, wydawanego w różnym tempie. Pielęgnacja WordPress to zestaw regularnych czynności technicznych, które utrzymują ten zestaw w działającym, bezpiecznym i szybkim stanie. Strona po uruchomieniu wymaga stałej uwagi przez cały okres działania.

Pielęgnacja obejmuje aktualizacje rdzenia, motywów i wtyczek, monitoring bezpieczeństwa, kopie zapasowe, wydajność i reakcję na awarie. Te obszary zależą od siebie: aktualizacja bez kopii zapasowej jest ryzykiem, a kopia, której nikt nie odtworzył na próbę, może zawieść w dniu awarii.

Stała opieka różni się od doraźnych poprawek powtarzalnością. Te same kroki idą w tej samej kolejności przy każdej aktualizacji, a każda zmiana trafia do raportu. Dzięki temu po awarii wiadomo, co i kiedy zmieniło się na stronie.

#Dlaczego pielęgnacja jest ważna?

Pierwszy powód to bezpieczeństwo. WordPress jest najczęściej atakowanym CMS-em, bo jest najczęściej używany, a krążące w sieci liczby ataków nie mają możliwego do sprawdzenia źródła, więc ich nie powtarzam. Każda nieaktualna wtyczka czy motyw z opublikowaną luką to potencjalny wektor ataku. Regularne aktualizacje zamykają znane luki, zanim ktoś z nich skorzysta.

Drugi powód to wydajność. Badanie Google i SOASTA z 2016 roku pokazało, że 53% wizyt mobilnych kończy się porzuceniem, jeśli ładowanie trwa dłużej niż 3 sekundy. Zaniedbana strona WordPress gromadzi zbędne dane w bazie i ładuje zasoby, których nie potrzebuje. Regularny pomiar pokazuje spadek, zanim odczują go klienci.

Trzeci powód to obowiązki prawne. Gdy przez włamanie wyciekną dane osobowe klientów, właściciel strony jako administrator danych ma obowiązki z RODO, w tym zgłoszenie naruszenia Prezesowi UODO, co do zasady w ciągu 72 godzin. Jeśli strona zacznie rozsyłać malware, Google oznaczy ją ostrzeżeniem, a przegląd po sprzątaniu trwa według Google od kilku dni do kilku tygodni. Opisuję to dokładniej na stronie usuwanie wirusów WordPress.

Czwarty powód to koszt. Naprawa po włamaniu albo odtwarzanie danych po awarii hostingu zwykle kosztuje więcej niż regularna opieka i spada na najgorszy możliwy moment.

#Czym różni się utrzymanie proaktywne od naprawy awarii?

Najczęstszy błąd właścicieli stron to traktowanie utrzymania jako wydatku, który można ciąć: “zadzwonię do programisty, kiedy coś się zepsuje”. W WordPressie awaria rzadko jest pojedynczym zdarzeniem. Częściej to skutek zaniedbań, które kumulowały się miesiącami. Model reaktywny wygląda tanio w arkuszu, dopóki nie policzy się kosztu jednego dnia przestoju sklepu WooCommerce w piątek przed długim weekendem.

Dwa scenariusze, które obsługiwałem, pokazują różnicę. Pierwszy: nieaktualna wtyczka formularza kontaktowego z opublikowanym CVE, której nikt nie zaktualizował przez cztery miesiące, stała się wektorem wstrzyknięcia skryptu. Strona trafiła na listę ostrzeżeń Google, a przywrócenie czystej wersji i zdjęcie ostrzeżenia zajęły więcej czasu niż rok proaktywnego utrzymania. Drugi: właściciel wykonywał kopię “od czasu do czasu”, ręcznie, kiedy pamiętał. Po awarii hostingu okazało się, że ostatni backup miał siedem tygodni i nie obejmował 200 zamówień oraz faktur VAT wystawionych w tym okresie. Tych danych nie dało się odtworzyć.

Różnicę między dwoma podejściami widać najlepiej w zestawieniu zakresu i ryzyka.

Stała opieka nie usuwa wszystkich awarii. Skraca czas od awarii do reakcji, bo monitoring zgłasza przestój, zanim zauważy go klient, a kopia zapasowa i staging są gotowe przed incydentem. Koszt rozkłada się na stałą miesięczną kwotę zamiast jednorazowej naprawy w dniu awarii.

#Aktualizacje i bezpieczeństwo

Zespół bezpieczeństwa WordPressa wydaje poprawki, które naprawiają wykryte luki, ale poprawka działa dopiero wtedy, gdy trafi na twoją stronę. Według strony zespołu oficjalnie wspierana jest tylko najnowsza wersja WordPressa. Strona zatrzymana kilka wersji wstecz może zostać bez poprawki.

Proces aktualizacji w opiece wygląda zawsze tak samo. Najpierw pełna kopia zapasowa bazy i plików, potem aktualizacja na stagingu, czyli kopii twojej strony, i testy najważniejszych funkcji. Po aktualizacji porównuję zrzuty ekranu wybranych podstron sprzed zmiany i po niej, bo test funkcjonalny nie zauważy rozjechanego układu. Dopiero po pozytywnym teście zmiana trafia na produkcję, a przez kolejne 24 godziny prowadzę wzmożony monitoring. Gdy coś pójdzie źle, wracam do poprzedniej wersji z kopii. Staging najpierw, dlatego WP Rocket 3.23.2.2 poszedł na klon przed WordPressem 7.1: WP Rocket, fatal WordPress 7.1 i Cloudflare.php.

Krytyczne poprawki bezpieczeństwa nie czekają na cotygodniowy cykl. Idą pierwsze, tą samą drogą przez staging, a dokładne okno na nie zapisuję w wycenie. O lukach dowiaduję się z baz podatności, między innymi WPScan i Patchstack. Pełny opis harmonogramu jest na stronie aktualizacje WordPress. Jeśli potrzebujesz jednorazowej, dogłębnej oceny przed rozpoczęciem stałego utrzymania, zacznij od audytu bezpieczeństwa WordPress.

#Kopie zapasowe i odtwarzanie

Kopie zapasowe chronią przed awarią sprzętu, błędem człowieka, włamaniem i nieudaną aktualizacją. W opiece powstają codziennie, przyrostowo, trafiają do chmury, poza serwer strony, i są przechowywane co najmniej 30 dni. Kopia przyrostowa zapisuje tylko zmiany od poprzedniej, więc nie obciąża serwera, a pozwala wrócić do kilku punktów w czasie. To ważne, gdy problem wychodzi na jaw po kilku dniach.

Stosuję zasadę 3-2-1 z jedną kopią poza serwerem. Kopia poza serwerem oznacza innego dostawcę niż hosting, nigdy to samo konto. Bazę danych odtwarzam osobno od plików z katalogu uploads.

Kopia sprawdza się dopiero przy odtworzeniu, dlatego regularnie robię próbne odtworzenie, a w raporcie stoi stan kopii i data ostatniej próby. Po włamaniu przywracam kopię dopiero po sprawdzeniu daty infekcji: kopia sprzed tygodnia nie pomoże, jeśli złośliwy kod siedzi na stronie od miesiąca.

#Optymalizacja wydajności

Szybkość strony wpływa na doświadczenie użytkowników i na pozycje w wyszukiwarce, bo Google bierze pod uwagę metryki Core Web Vitals. W opiece mierzę je co miesiąc. Gdy wynik spada, szukam przyczyny: nowej wtyczki, większych obrazów, rosnącej bazy.

Stan bazy oceniam na podstawie jej rozmiaru, czasu zapytań i struktury tabel. Sprawdzam między innymi transienty, wersje robocze, osierocone metadane i brakujące indeksy. Dane usuwam dopiero po potwierdzeniu, że nie są potrzebne aplikacji.

Warstwy cache dobieram do architektury strony: cache strony, obiektów i przeglądarki nie zawsze są potrzebne jednocześnie. W razie potrzeby konfiguruję CDN oraz optymalizację obrazów. Efekt każdej zmiany porównuję z pomiarem bazowym. Duże zmiany w motywie lub architekturze strony są poza opieką; przy nich zaczynam od optymalizacji szybkości WordPress.

#Monitoring, SEO techniczne i raport

Wiele czynników technicznych, które Google bierze pod uwagę, zależy od stanu strony: szybkość, HTTPS, poprawne adresy kanoniczne, mapa strony XML, plik robots.txt. W opiece sprawdzam, czy nowe treści są indeksowane i czy w Search Console nie pojawiły się błędy indeksacji albo ślady spamu po włamaniu.

Zainfekowana witryna może otrzymać ostrzeżenie w wynikach Google. Dlatego sprawdzam alerty bezpieczeństwa, HTTPS i ważność certyfikatu. Jeśli odnowienie certyfikatu obsługuje hosting, weryfikuję także działanie tej automatyzacji.

Raport techniczny pokazuje stan aktualizacji, dostępność, wydajność i wykryte błędy indeksacji. Zawiera listę działań, ale nie zastępuje strategii treści ani osobnej usługi SEO.

#Wsparcie techniczne WordPress

W opiece odpowiadam na pytania, doradzam w konfiguracji, diagnozuję i naprawiam błędy w ramach miesięcznego limitu godzin. Opiekę prowadzę sam, więc znam specyfikę twojej strony i nie trzeba za każdym razem tłumaczyć kontekstu od nowa.

Zgłoszenia przyjmuję mailem lub w systemie zgłoszeń. Każde zgłoszenie jest rejestrowane, więc w raporcie widać, co i kiedy zostało zrobione. Monitoring sprawdza stronę co 1 do 5 minut, całą dobę, i wysyła mi alert, więc wiele problemów widzę, zanim je zauważysz. Reaguję w godzinach roboczych CET, w oknie zapisanym w umowie.

#Opieka nad stroną, która nie stoi na WordPressie

Część firm ma obok WordPressa serwis na innym systemie albo całą stronę poza WordPressem. Utrzymuję też takie serwisy, według tej samej zasady: kopia, staging, testy, publikacja w oknie, plan powrotu.

• Drupal: aktualizacje bezpieczeństwa w procesie opartym na Composerze i Drushu, migracje między wersjami, własne moduły. Drupal 10 traci wsparcie bezpieczeństwa 9 grudnia 2026, co opisuję we wpisie Drupal 10 koniec wsparcia.
• TYPO3: aktualizacje bezpieczeństwa, przejścia na nowe wersje LTS, rozszerzenia w Extbase i Fluid.
• Laravel: wersje poprawkowe na produkcji w ciągu kilku dni, razem z aktualizacją zależności Composera, zawsze najpierw na serwerze testowym.
• Symfony: aktualizacje ze starszych wersji, warstwy integracji między WordPressem lub WooCommerce a ERP, CRM albo PIM.

Opiekę nad takim systemem wyceniam po audycie, bo zakres zależy od wersji, liczby modułów i tego, kto zarządza serwerem. Gdy utrzymanie starego systemu przestaje się opłacać, rozważam przejście na WordPressa. Przebieg takiego przejścia pokazuje anonimowe studium przypadku migracji TYPO3 do WordPressa, a kiedy migracja ma sens, opisuję we wpisach o migracji z TYPO3 i z Joomli.

#Opieka obok migracji, integracji i audytów

Opieka utrzymuje to, co już działa. Gdy strona potrzebuje większej zmiany, robię ją jako osobny projekt z osobną wyceną, a potem strona wraca do zwykłego abonamentu.

Przeniesienie WordPressa na inny serwer obejmuje kopię, przeniesienie bazy i plików, zmianę DNS i kontrolę po wdrożeniu. Gdy strona potrzebuje innej architektury, robię migrację do Next.js lub Astro.

Integracje sklepu i strony z innymi systemami (ERP, CRM, płatności, faktury w KSeF) opisuję w przewodnikach integracja WooCommerce z ERP, WordPress API-first i KSeF w WooCommerce. W opiece pilnuję, żeby istniejące integracje działały po aktualizacjach; budowa nowej to osobny projekt.

Sklepy WooCommerce, w których liczy się każdy dzień sprzedaży, prowadzę w Store Reliability Plan, a sklep z niedziałającym koszykiem najpierw w sprincie naprawy WooCommerce. Jak wygląda odzyskanie wydajności sklepu bez przebudowy, pokazuje anonimowe studium przypadku sklepu WooCommerce.

Strony, które muszą wykazać zgodność z przepisami UE, zaczynają od audytu: dostępności WCAG pod Europejski Akt o Dostępności, Core Web Vitals albo gotowości NIS2 i DORA. Opieka podtrzymuje potem wynik audytu.

#Jak wygląda opieka nad wieloma stronami WordPress jednego właściciela?

Masz od 5 do 10 stron i chcesz jednego opiekuna zamiast kilku umów? Tak to ustawiam.

• Przed startem zbieram w jednej tabeli: gdzie stoi każda strona, kto ma dostęp do hostingu i domeny, które serwisy są sklepami.
• Zakres spisuję osobno dla każdej strony, bo sklep WooCommerce i wizytówka firmy wymagają innej uwagi.
• Limit godzin i czas reakcji trafiają do pisemnej wyceny jako konkretne liczby, nie jako “zależy”.
• Sieć Multisite wyceniam indywidualnie, tak samo jak resztę portfela.
• Widełki opieki technicznej są na stronie opieka WordPress cena i w cenniku. Cenę portfela podaję w wycenie po krótkim briefie.

#Co obejmuje, a czego nie obejmuje opieka nad stroną WordPress?

#Jak działają limit godzin i czas reakcji?

Godziny programistyczne mają miesięczny limit ustalany w wycenie, razem ze stawką za godziny ponad limit. Liczby nie ma na tej stronie, bo zależy od liczby i rodzaju serwisów. Niewykorzystane godziny nie przechodzą na kolejny miesiąc. Praca spoza zakresu dostaje osobną wycenę i rusza po jej potwierdzeniu.

Monitoring działa całą dobę. Odpowiadam w dni robocze (CET), bez gwarantowanego czasu reakcji. Czas reakcji obowiązuje w dni robocze CET i oznacza diagnozę oraz plan, bez gwarancji czasu naprawy. Opieka zmniejsza ryzyko włamania, ale nie daje gwarancji, że strona nigdy nie zostanie zhakowana. Odpowiedzialność stron określa umowa.

#Jak pracuję z kodem

Każdy kod, którego dotykam w opiece, trzymam w systemie kontroli wersji: poprawki w motywie, we wtyczkach napisanych dla firmy, w konfiguracji. Kod WordPressa sprawdzam pod kątem WordPress Coding Standards narzędziem PHP_CodeSniffer z regułami WPCS, a kod PHP spoza WordPressa (Laravel, Symfony, moduły Drupala) według standardu PSR-12. Analiza statyczna PHPStan wyłapuje błędy, zanim zmiana trafi do testów na stagingu. Przed publikacją przeglądam własną zmianę jeszcze raz, osobno od pisania. Dzięki temu po roku opieki twoja strona ma historię zmian, którą może przejąć każdy inny programista.

#Kto prowadzi opiekę

WPPoland to Mariusz Szatkowski, senior WordPress developer, z WordPressem od 2006 roku. Opiekę prowadzę osobiście: aktualizacje, kopie, monitoring i raporty robi ta sama osoba, z którą ustalasz zakres. Wycenę piszę po krótkim briefie, a pierwszy miesiąc opieki zaczyna się od audytu startowego, wliczonego w opłatę za ten miesiąc.

Zanim ustalę zakres opieki, sprawdź stan strony samodzielnie: sprawdzenie strony WordPress pobiera publiczną wersję jednego adresu i pokazuje zmierzone liczby, w tym żądania blokujące pierwsze malowanie i ich wagę. Wynik jest natychmiastowy i nie wymaga podawania adresu e-mail.