Profesjonalna opieka nad stroną WordPress — co obejmuje i kiedy ma sens

„Opieka nad WordPressem” brzmi jak marketing abonamentu, w którym ktoś raz w miesiącu klika „Update all”. W praktyce to regularny cykl konkretnych zadań technicznych — i większość z nich wykonuje się w ciszy, żeby klient nigdy nie zauważył, że coś było nie tak.

Poniżej opisuję jak to wygląda od środka u nas w Devance: co dzieje się w tygodniowym cyklu, co w miesięcznym, co w kwartalnym. Jakie decyzje podejmujemy i na podstawie czego. Kiedy opieka ma sens, a kiedy — szczerze — nie ma.

Co realnie robi agencja co tydzień

Stały klient = 2–15 godzin pracy miesięcznie rozłożonych na cztery cykle:

Poniedziałek, 9:00 — audit weekly. Automatyczny skrypt (własny worker albo ManageWP/MainWP) sprawdza:

• dostępne aktualizacje WP / motywu / wtyczek,
• status SSL (wygasa w najbliższych 30 dniach?),
• uptime z poprzedniego tygodnia (reżim SLA),
• rozmiar bazy / autoloadu / plików (trendy),
• logi błędów PHP (nowe fatale w ostatnich 7 dniach),
• wynik skanu malware (Wordfence / Sucuri).

Wynik trafia na panel agencji. Operator w ciągu dnia przegląda zgłoszenia: co pilne, co może poczekać, co wymaga konsultacji z klientem.

Środa — aktualizacje. W okienku w godzinach najmniejszego ruchu (dane z GA4) uruchamiamy proces: backup → staging → update → szybki test dymny → produkcja → weryfikacja.

Piątek — raport. Krótkie podsumowanie dla klienta: co zrobiono, ile godzin zeszło, co na przyszły tydzień.

Miesięcznie: przegląd bazy danych, cleanup transientów, analiza Core Web Vitals w Search Console, inwentaryzacja wtyczek (czy żadna nie została porzucona przez autora), test restore backupu z poprzedniego miesiąca.

Kwartalnie: audyt bezpieczeństwa (sprawdzenie nagłówków HTTP, konfiguracji firewall, siły haseł adminów), przegląd strategiczny z klientem (co zmienia się w biznesie, jakie nowe funkcjonalności).

To jest punkt odniesienia. Faktyczny zakres zależy od pakietu — ale ten rytm powtarza się u każdego klienta.

Aktualizacje — dlaczego „klik update” to zły pomysł

Aktualizacja wtyczki rzadko coś psuje. Ale gdy psuje, psuje na czarną godzinę. 5% updatów kończy się regresją: konflikt z inną wtyczką, deprecation w PHP, zmiana zachowania shortcodu używanego w 50 postach, zmiana nazwy meta keya.

Nasz proces (nieco uproszczony):

1. Snapshot — backup pełny (pliki + DB) przed czymkolwiek.
2. Staging — kopia serwisu na subdomenie (staging.domain.pl) indexowana noindex, nofollow. Aktualizacja idzie tam pierwsza.
3. Smoke test — 20-punktowy checklist: home, 3 losowe posty, sklep (PDP + koszyk + checkout z test kartą Stripe), formularz kontaktowy, WP-admin, uploader plików. 15 minut ręcznie, albo Playwright jeśli klient ma scenariusze dla e2e.
4. Wdrożenie na produkcję w oknie 2:00–6:00 w nocy (minimum ruchu). Maintenance mode przez wtyczkę WP-Rocket albo prostym .maintenance w root.
5. Weryfikacja — ponowny szybki test dymny na produkcji.
6. Rollback plan — jeśli coś odkryje się przez 48 h, mamy snapshot z kroku 1.

Dla pakietu 2h/mies aktualizacje kluczowych wtyczek robimy raz w tygodniu, pełny cykl (z rdzeniem + motywem) raz w miesiącu. Dla większych pakietów — częściej i bardziej automatycznie.

Wyjątek: CVE o krytycznej severity (np. SSRF w LiteSpeed Cache z lipca 2024, atakował w ciągu 48 h od publikacji patcha). Wtedy update idzie od razu, bez cyklu — klient dostaje informację „zrobiliśmy, oto co się działo”.

Backup — 3-2-1, z testem restore

Najczęstszy problem, z którym przyjmujemy nowych klientów: „mamy backup przez plugin, ale nigdy nie sprawdzaliśmy czy działa”. Zwykle nie działa. Z badania Unitrends (2023) 37% firm, które ufały backupom, nie umiało ich odtworzyć.

Strategia 3-2-1 w praktyce:

• 3 kopie: plików + bazy.
• 2 różne nośniki: serwer + chmura (S3 / Backblaze B2 / Wasabi).
• 1 offsite: nie na tym samym hostingu, nie u tego samego vendora.

Częstotliwość:

Retencja: minimum 30 dni wstecz. Dla sklepów z abonamentami — 90+ dni (bo czasem wycieki odkrywa się po 60 dniach).

Test restore raz w kwartale. Bierzemy backup z wczoraj, przywracamy na staging, sprawdzamy czy baza się zgadza z produkcją. Zajmuje 30 minut, kosztuje nic, ale odpowiada na najważniejsze pytanie: „czy to w ogóle działa”.

Monitoring — 24/7, ale co konkretnie

„Monitoring 24/7” to marketing. Technicznie składa się z:

Uptime checks (UptimeRobot / Better Uptime / własny endpoint) — ping co 1 minutę. Alert na Slacka / SMS jeśli 2 kolejne sprawdzenia = fail. Reakcja: operator dyżurny (w Devance rotacja tygodniowa) dostaje powiadomienie, ma 15 minut na first response.

Log monitoring — tail logów PHP i nginx przez centralny collector. Sentry dla fataliów, custom alerts na wzorce błędów („Out of memory” w MySQL, „Too many connections”). Wczesne ostrzeganie — często widzimy problem zanim klient zauważy.

Certificate monitoring — skrypt sprawdzający datę ważności SSL na wszystkich domenach klientów raz dziennie. Alert 14 dni przed wygaśnięciem.

Database health — trendy rozmiaru bazy, autoloadu, wp_options size, liczba rewizji. Jeśli któraś metryka zaczyna rosnąć nienormalnie — investigate.

Malware scanning — Wordfence Premium (lub Sucuri) z real-time skanowaniem. Alert na każdą zmianę w plikach rdzenia albo nowy plik niestandardowy w wp-content/uploads/.

Nie mamy kogoś, kto patrzy w ekran 24/7 — ale mamy operatorów dyżurnych z telefonami, do których alerty trafiają bezpośrednio. Reakcja poza godzinami pracy (19:00–8:00) kosztuje więcej, dlatego krytyczne aktualizacje staramy się pushować przed wieczorem.

Sklepy WooCommerce — dodatkowe wymagania

Opieka nad sklepem różni się od opieki nad blogiem/stroną firmową w czterech obszarach:

1. Płatności — monitoring bramki (Przelewy24, PayU, Stripe). Każdy webhook fail = potencjalne zamówienie bez statusu „paid” = klient zły. Sprawdzamy logi webhook’ów co 24 h.
2. Stan magazynowy — synchronizacja z BaseLinkerem / ERP. Bo jeśli rano status „na magazynie: 3”, a wieczorem 15 sprzedanych — zaraz będzie afera z klientem.
3. Pozamówieniowe — faktury (ifirma.pl / wfirma / WooCommerce PDF Invoices), mailingi transakcyjne (potwierdzenia, status wysyłki), monitoring wystawiania paragonów.
4. Compliance — RODO (consent mode, eksport danych), EAA (dostępność), cookie consent działający poprawnie.

Dla sklepów dodajemy też cykliczny „cleanup wygasłych sesji koszyka” (wp wc tool run clear_expired_sessions) — inaczej tabela wp_woocommerce_sessions potrafi urosnąć do setek MB.

Więcej szczegółów w artykule o opiece nad WooCommerce.

Model rozliczenia — godzinowy vs retainer vs unlimited

Są trzy sposoby liczenia opieki:

Godzinowy (nasz model). Klient kupuje pakiet X godzin / miesiąc. Zużyte → raportowane. Niewykorzystane → przepadają (tak jak karnet na siłownię, nie kumulują się). Plus: przewidywalność budżetu, elastyczność zakresu. Minus: miesiące rozrachunkowe, trzeba mierzyć czas.

Retainer — flat fee za umówiony scope (np. „wszystko co trzeba do opieki”). Plus: prosta faktura. Minus: agencja staje się niechętna do większych zadań, bo nie jest dodatkowo płacona.

Unlimited — marketingowe hasło, w praktyce zawsze ograniczone umową (np. „bez nowych funkcjonalności, tylko maintenance”). Plus: prosty dla klienta. Minus: albo agencja traci pieniądze na klientach z dużymi potrzebami, albo miesza limity, które w końcu wychodzą.

W polskim rynku WordPress większość agencji (w tym my) pracuje godzinowo. Ważne: model sam w sobie nie jest dobry ani zły — ważne, żeby był jasno opisany w umowie i zgodny z potrzebami klienta.

Kiedy opieka NIE ma sensu

Wbrew oczekiwaniom marketingowym — są przypadki, gdzie opieka WP to strata pieniędzy:

• Strona-wizytówka bez ruchu, bez formularzy, statyczna treść — jeśli publikujesz raz w roku, prosty hosting WordPress z auto-updates w pakiecie wystarczy. 500 zł/mies. na utrzymanie strony, która robi Ci 2 leady na rok = ekonomicznie bez sensu.
• Plan migracji na inny stack — jeśli za 3 miesiące rebuildujesz na Next.js / Webflow / Framer, nie ma powodu wydawać na WP.
• Strona bez wartości biznesowej — bo nikt jej nie odwiedza, nie generuje leadów, nie wspiera sprzedaży. Lepiej dogadać z hostingiem auto-updates i sprawdzać raz na kwartał.

Zdarza się że rozmawiamy z potencjalnym klientem i rekomendujemy „nie kupuj naszego pakietu, zainstaluj Cloudflare + auto-updates + zrób backup raz na miesiąc”. Tracimy klienta, ale nie chcemy sprzedawać czegoś co nie jest potrzebne.

Jak wygląda handoff nowego klienta

Pierwsze 2 tygodnie współpracy to najwięcej pracy:

Dzień 1–2: Otrzymujemy dostępy (wp-admin, hosting, DNS, repozytorium jeśli jest). Ustawiamy 2FA, zmieniamy hasła. Instalujemy nasz narzędziowy bundle (ManageWP / WP-CLI / Query Monitor jako mu-plugin).

Dzień 3–5: Pełny audyt. Inwentaryzacja wtyczek (aktywne vs nieaktywne, daty aktualizacji, CVE), motywu (classic vs block, czy ma child theme), konfiguracji PHP, stanu bazy (autoload, rewizje, transientów), SSL, nagłówków bezpieczeństwa, Core Web Vitals. Wynik = dokument „stan zastany + rekomendacje”.

Dzień 5–7: Cleanup „low-hanging fruit” — wyłączenie nieużywanych wtyczek, update zaległych (po wcześniejszej migracji na staging), konfiguracja backupu, aktywacja monitoring, ustawienie kanału komunikacji (Slack / dedicated email).

Dzień 8+: Normalny cykl tygodniowy. Pierwszy raport na koniec tygodnia.

Handoff dobrze zrobiony = klient od początku widzi, gdzie idą godziny i co konkretnie robimy.

Jeśli rozważasz opiekę nad swoim WordPressem, ale nie wiesz od czego zacząć — zacznij od darmowego audytu. Dostaniesz raport „co jest ok, co wymaga poprawy, co jest ryzykowne” bez zobowiązań. Jeśli po audycie dojdziesz do wniosku że sam ogarniasz — też OK. Artykuły linkowane powyżej są pisane tak, żeby dało się dużo zrobić samemu.