Ten case study opisuje wzorzec projektu, który powtarzamy przy przejmowaniu opieki nad zaniedbaną stroną WordPress — taką, która działa, ale nikt nie wie dokładnie jak i nikt nie chce jej dotykać. Metryki pochodzą z anonimizowanych wdrożeń z obszaru usług profesjonalnych, publikowanych również w naszych case studies.
- Wynik: 12 miesięcy bez krytycznych awarii, wdrożenia szybsze o połowę, koniec ręcznej pracy przy aktualizacjach.
Najważniejsze: Strona nie była zepsuta — była nieprzewidywalna. Każda aktualizacja wtyczki groziła białym ekranem, kopie zapasowe istniały tylko teoretycznie, a nikt nie potrafił powiedzieć, które wtyczki są potrzebne. Naprawa nie polegała na przepisaniu strony od zera, ale na wprowadzeniu procesu: środowiska testowego, kontroli aktualizacji, kopii z testem odtworzenia i monitoringu. Efekt: 12 miesięcy bez awarii krytycznej.
Punkt wyjścia
Strona firmowa na WordPressie, rozwijana przez lata przez różnych wykonawców. Objawy, które widzimy w większości takich przypadków:
- 38 aktywnych wtyczek, z czego część zainstalowana „na próbę" i nigdy nieusunięta. Nikt nie potrafił powiedzieć, która odpowiada za co.
- Aktualizacje odkładane miesiącami, bo po każdej poprzedniej strona się wysypywała. Zespół bał się klikać „aktualizuj".
- Kopie zapasowe robione, ale nigdy nie testowane. Backup, którego nie próbowano odtworzyć, nie jest kopią zapasową — jest nadzieją.
- Brak środowiska testowego. Zmiany szły bezpośrednio na produkcję.
- Konto administratora wspólne dla kilku osób, bez rozdzielenia uprawnień i bez historii zmian.
- Wersje PHP i WordPressa starsze o kilka wydań, co samo w sobie jest ryzykiem bezpieczeństwa.
To nie jest zaniedbanie po stronie klienta — to naturalny efekt strony, którą przez lata dotykało kilka osób bez wspólnego procesu.
Co zrobiliśmy
1. Inwentaryzacja i cięcie wtyczek. Dla każdej wtyczki sprawdziliśmy: czy jest aktywna, co generuje w kodzie strony, kiedy była aktualizowana i czy istnieje alternatywa w rdzeniu WordPressa. Z 38 zostało 12. Mniej wtyczek to mniejsza powierzchnia ataku, szybsza strona i mniej rzeczy, które mogą się zepsuć przy aktualizacji.
2. Środowisko testowe. Staging z kopią danych produkcyjnych, na którym każda aktualizacja jest najpierw sprawdzana. To pojedyncza zmiana, która zmienia najwięcej — bo usuwa strach przed aktualizacją.
3. Kontrola wersji plików motywu i własnych modyfikacji. Modyfikacje, które wcześniej żyły tylko na serwerze produkcyjnym, trafiły do repozytorium. Od tego momentu każda zmiana jest cofnialna.
4. Kopie zapasowe z testem odtworzenia. Kopia dzienna i tygodniowa, ale co ważniejsze: raz w miesiącu odtwarzamy kopię na stagingu, żeby sprawdzić, czy backup faktycznie działa. Bez tego testu kopia jest tylko plikiem.
5. Proces aktualizacji. Ustalony cykl: wtyczki i motyw raz w miesiącu, rdzeń WordPressa i PHP według polityki wsparcia wersji, aktualizacje bezpieczeństwa natychmiast. Każda aktualizacja przechodzi przez staging, z listą kontrolną tego, co trzeba sprawdzić po wdrożeniu.
6. Monitoring i rozdzielenie dostępu. Monitoring dostępności i błędów PHP z alertami, konta indywidualne zamiast wspólnego administratora, uwierzytelnianie dwuskładnikowe i zasada minimalnych uprawnień.
Efekt
| Wskaźnik | Przed | Po |
|---|---|---|
| Krytyczne awarie | kilka w roku | 0 przez 12 miesięcy |
| Czas wdrożenia zmiany | dni (ręcznie, na produkcji) | o połowę krócej |
| Aktywne wtyczki | 38 | 12 |
| Kopie zapasowe | nietestowane | test odtworzenia co miesiąc |
| Wykrycie awarii | od użytkownika | z monitoringu |
| Aktualizacje | odkładane | cykl miesięczny + bezpieczeństwo natychmiast |
Metryka „zero krytycznych awarii przez 12 miesięcy" pochodzi z anonimizowanego wdrożenia publikowanego w naszych case studies.
Co z tego wynika dla Twojej strony
Strach przed aktualizacją jest objawem, nie przyczyną. Przyczyną jest brak środowiska testowego i brak kontroli wersji. Gdy je wprowadzisz, aktualizacje przestają być ryzykiem.
Liczba wtyczek to dług techniczny. Każda wtyczka to zależność, którą ktoś musi utrzymywać i którą ktoś może porzucić. Regularny przegląd i cięcie to nie optymalizacja — to higiena.
Backup bez testu odtworzenia nie liczy się jako backup. To najczęstsze odkrycie przy przejmowaniu opieki nad stroną: kopie są, ale nikt nigdy nie sprawdził, czy da się z nich wrócić.
Najczęściej zadawane pytania
Czy trzeba przebudować stronę od zera?
Prawie nigdy. W opisanych projektach strona została, zmienił się sposób jej utrzymania. Przebudowa od zera ma sens tylko wtedy, gdy fundament jest błędny — np. strona opiera się na porzuconym motywie z nieznanymi modyfikacjami, których nie da się odtworzyć.
Ile kosztuje przejęcie opieki nad stroną WordPress?
Audyt i uporządkowanie to jednorazowy koszt 1 500–5 000 zł netto, zależnie od liczby wtyczek i jakości istniejącego kodu. Miesięczna opieka to 200–800 zł netto w zależności od zakresu — aktualizacje, kopie, monitoring i czas na drobne zmiany. Widełki znajdziesz w cenniku.
Czy aktualizacja WordPressa zawsze psuje stronę?
Nie, ale bez środowiska testowego nie masz jak tego sprawdzić przed wdrożeniem. Ryzyko wynika nie z samej aktualizacji, tylko z aktualizowania na produkcji bez testu.
Jak często aktualizować WordPressa?
- Wtyczki i motyw: raz w miesiącu, w ustalonym oknie. Aktualizacje bezpieczeństwa: natychmiast. Rdzeń WordPressa: po sprawdzeniu zgodności z wtyczkami na stagingu. PHP: zgodnie z polityką wsparcia — wersje bez wsparcia bezpieczeństwa nie powinny działać na produkcji.
Czy monitoring naprawdę jest potrzebny przy małej stronie?
Przy stronie wizytówkowej — wystarczy monitoring dostępności. Przy stronie, która generuje zapytania lub sprzedaż — potrzebny jest też monitoring błędów PHP, bo cichy błąd potrafi blokować formularz kontaktowy tygodniami, zanim ktoś to zauważy.
Co jeśli nie mam dostępu do serwera ani kodu?
To pierwszy problem do rozwiązania. Bez dostępu do plików, bazy i DNS nie da się prowadzić bezpiecznej opieki. W praktyce najczęściej oznacza to odzyskanie dostępu od poprzedniego wykonawcy — i warto to zrobić przed podpisaniem umowy na opiekę.
Źródła i narzędzia
- WordPress — dokumentacja wsparcia wersji
- WordPress — hardening (bezpieczeństwo)
- PHP — wspierane wersje
- W3C — dostępność WCAG 2.1
👉 Masz stronę WordPress, którą boisz się aktualizować? Zobacz usługę WordPress — wdrożenia i opieka i utrzymanie oraz modernizację kodu. Napisz przez formularz kontaktowy lub na kontakt@informatix.com.pl.
📖 Zobacz również: Opieka nad stroną WordPress — pakiety i SLA, aktualizacja WordPress — bezpieczny proces oraz usuwanie wirusów WordPress. Usługa: Opieka techniczna z SLA.