Aktualizacja strony internetowej — co, jak często i czego nie ruszać samemu

Nie aktualizujecie „strony". Aktualizujecie to, co ktoś do niej dołożył — i tam też siedzi praktycznie całe ryzyko. To jedno zdanie zmienia listę zadań bardziej niż wszystkie porady o systematyczności.

Ten tekst jest o rutynie: co, jak często, w jakiej kolejności i czego nie ruszać bez wykonawcy. Terminy zewnętrzne, które zapadają niezależnie od Waszych planów — koniec wsparcia dla wersji oprogramowania, wymagania przeglądarek — to osobna rozmowa o modernizacji.

Gdzie naprawdę siedzą podatności

W 2025 roku w ekosystemie WordPressa znaleziono 11 334 nowe podatności — o 42% więcej niż rok wcześniej. Tak wynika z raportu Patchstack. Ale liczba nie jest tu najciekawsza; ciekawy jest rozkład, bo obala najczęstszy zarzut wobec tego systemu:

91% podatności dotyczyło wtyczek, 9% motywów, a w samym rdzeniu znaleziono sześć — wszystkie o niskim priorytecie.

Rdzeń WordPressa nie jest problemem. Problemem jest to, co się do niego dokłada. Ma to bezpośredni skutek praktyczny: strona z trzema wtyczkami i strona z trzydziestoma to dwa różne poziomy ryzyka, niezależnie od tego, jak sumiennie obie są aktualizowane.

Warto przy tym pamiętać, czego ta liczba nie mówi. Nie mówi, ile stron zostało zaatakowanych — mówi, ile luk opisano. Podatność opisana to nie to samo co podatność wykorzystana, a większość z tych jedenastu tysięcy dotyczy wtyczek, których na Waszej stronie nie ma. Użyteczne jest tu nie samo jedenaście tysięcy, tylko proporcja: cokolwiek się dzieje, dzieje się w warstwie, którą sami dołożyliście — i tę warstwę sami kontrolujecie.

Dlatego pierwsze zadanie w tym artykule nie polega na aktualizowaniu czegokolwiek, tylko na wypisaniu, co właściwie macie zainstalowane. Lista wtyczek z datą ostatniej aktualizacji każdej z nich, na jednej kartce. Przy typowej stronie firmowej zajmuje to dziesięć minut i zwykle kończy się dwoma odkryciami: że wtyczek jest więcej, niż ktokolwiek pamiętał, i że kilku z nich nikt nie rozwija od lat.

Liczba, która zmienia sens słowa „regularnie"

Z tego samego raportu: 46% podatności nie doczekało się poprawki od autora na czas publicznego ujawnienia.

To znaczy, że przy niemal połowie luk sumienne aktualizowanie nie pomoże — nie ma czego zainstalować. Podatność jest opisana publicznie, a poprawki nie ma i nie wiadomo, kiedy będzie.

Przesuwa to punkt ciężkości i warto to powiedzieć wprost, bo cała branża opieki technicznej sprzedaje samą dyscyplinę:

• Dyscyplina aktualizacji chroni przed połową problemu. To dużo i jest bezpłatna, więc nie ma powodu z niej rezygnować.
• Druga połowa wymaga czegoś innego: wiedzy, że luka istnieje, i decyzji, co z tym zrobić. Wyłączyć wtyczkę, zablokować podatną ścieżkę na serwerze, podmienić komponent na inny.

Z tego wynika najtańsza rzecz, jaką można zrobić poza samym klikaniem „aktualizuj": mieć mniej wtyczek. Każda usunięta to jedna mniej, przy której trzeba będzie kiedyś podjąć tę decyzję.

Ile wtyczek to za dużo

Nie ma progu, po przekroczeniu którego dzieje się coś złego — jest za to pytanie, które porządkuje listę w kwadrans. Przy każdej wtyczce: co się stanie, jeśli ją wyłączę?

Odpowiedzi są zwykle trzy i każda znaczy co innego.

„Strona przestanie działać." To jest wtyczka niezbędna — formularz, sklep, system rezerwacji. Zostaje, ale trafia na krótką listę rzeczy, które trzeba sprawdzać po każdej większej aktualizacji.

„Zniknie jakiś element." Karuzela, galeria, ikony społecznościowe, mapa. Zostaje, jeśli ten element ma cel. Bardzo często okazuje się, że nie ma — bo pochodzi z projektu sprzed trzech lat.

„Nie wiem." To jest odpowiedź najczęstsza i najbardziej wymowna. Wtyczka, przy której nikt nie umie powiedzieć, po co jest, prawie zawsze została po testach, po dawnym wykonawcy albo po funkcji, której nigdy nie uruchomiono. Wyłączcie ją na tydzień i zobaczcie, czy ktokolwiek zauważy.

Dwie zasady, które wynikają z tego samego rozkładu podatności:

Usuwajcie, nie dezaktywujcie. Wtyczka wyłączona nadal leży na serwerze, nadal ma swój kod i nadal bywa podatna. Dezaktywacja jest wygodna dla Was, nie dla bezpieczeństwa.

Nie instalujcie „na próbę" na stronie produkcyjnej. To jest najczęstsze źródło pozycji z kategorii „nie wiem" — ktoś sprawdzał trzy rozwiązania, wybrał jedno, a dwa zostały.

Płatne nie znaczy bezpieczniejsze

Przekonanie, że wtyczka premium jest z definicji pewniejsza, też nie broni się w tych danych. Komponenty płatne i freemium odpowiadały za 1 983 zgłoszenia, czyli 29% wszystkich — ale 76% podatności znalezionych w komponentach premium było możliwych do wykorzystania, czyli wyższy odsetek niż w darmowych.

Cena licencji nie jest miarą jakości kodu. Jest za to całkiem dobrą miarą czegoś innego i to warto kupować świadomie: płacicie za to, że ktoś tę wtyczkę nadal utrzymuje. Pytanie przed zakupem nie brzmi „czy płatna", tylko „kiedy była ostatnia aktualizacja i ile wersji wyszło w zeszłym roku".

Skalę zagrożenia warto przy okazji czytać ostrożnie. Z tych 11 334 podatności 1 966 (17%) miało wysoką ocenę istotności, a 4 124 (36%) uznano za realne zagrożenie wymagające reguły ochronnej. Reszta to znaleziska o ograniczonym znaczeniu praktycznym — podawanie samej liczby 11 334 bez tego podziału byłoby straszeniem, a nie informowaniem.

Cztery warstwy, nie jedna

„Zaktualizuj stronę" to w rzeczywistości cztery różne czynności o różnym ryzyku.

Poprawki bezpieczeństwa rdzenia — automatycznie. Są wąskie, testowane u wydawcy i wychodzą rzadko. To jest jedyna warstwa, przy której automat jest bezpieczniejszy od Waszej pamięci — bo luka w rdzeniu, choć rzadka, dotyczy naraz wszystkich stron na świecie i jest wykorzystywana masowo w ciągu godzin od ujawnienia. Warto rozróżnić: automatyczne są zwykle wydania bezpieczeństwa, nie duże wydania funkcjonalne. Te drugie warto przepuścić przez ten sam proces co wtyczki.

Wtyczki — ręcznie i po jednej. Tu siedzi 91% podatności i tu psuje się układ strony. Aktualizowanie ośmiu naraz oznacza, że przy awarii nie wiadomo, która ją spowodowała — a to jest różnica między piętnastoma minutami a pół dniem. Wyjątek, który warto znać: jeśli wtyczka ma w opisie aktualizacji słowo „security" albo numer CVE, nie czekajcie na wygodny moment. Reszta może poczekać do zaplanowanego kwadransa.

Motyw i jego dodatki — ręcznie, po zrobieniu kopii. Aktualizacja motywu potrafi nadpisać zmiany wprowadzone bezpośrednio w szablonie. Jeśli ktoś kiedyś „poprawił coś w kodzie", to właśnie tutaj to zniknie — bez ostrzeżenia i bez śladu, a odtworzenie wymaga pamiętania, co to było. Rozwiązaniem przewidzianym na to jest motyw potomny, w którym własne zmiany leżą osobno i przeżywają aktualizację. Jeśli nie wiecie, czy go macie, to jest jedno pytanie do wykonawcy i warto je zadać przed pierwszą aktualizacją motywu, a nie po.

Wersja PHP — nie bez wykonawcy. To nie jest aktualizacja, tylko zmiana środowiska, w którym strona działa. Może położyć wszystko naraz, a odkręcenie wymaga dostępu do hostingu. Kiedy trzeba to zrobić niezależnie od Waszych planów, rozstrzyga tekst o modernizacji.

Jest jeszcze warstwa piąta, o której się nie myśli jak o aktualizacji, a która potrafi zepsuć stronę tak samo: skrypty wklejone bezpośrednio w szablon. Piksel, czat, widżet opinii, licznik. Nie pojawiają się na liście wtyczek, nie mają numeru wersji i nikt ich nie aktualizuje — ale gdy dostawca zmieni sposób osadzania, przestają działać albo zaczynają blokować ładowanie strony. Warto je przejrzeć przy tej samej okazji co wtyczki.

Kto to robi i ile to trwa

Uczciwa odpowiedź na pytanie o czas: przy typowej stronie firmowej to kwadrans raz w miesiącu, jeśli nic nie zaskoczy, plus godzina raz na kwartał na przegląd listy wtyczek. To jest zakres, który spokojnie robi osoba nietechniczna, o ile ma dostęp do panelu i kopię zapasową.

Sensowne jest zlecenie tego na zewnątrz w trzech przypadkach:

Nikt w firmie nie wchodzi do panelu. Jeśli jedyną osobą, która kiedykolwiek się logowała, był wykonawca, to nie ma kto zauważyć, że coś czeka na aktualizację.

Strona zarabia. Przy sklepie albo systemie rezerwacji różnica między awarią wykrytą w godzinę a wykrytą po weekendzie jest policzalna — i to ona, a nie sama aktualizacja, jest tym, za co się płaci.

Macie wtyczki, których nie da się bezpiecznie ruszyć samemu. Zwykle są to rozwiązania mocno zmodyfikowane pod Was albo integracje z systemem zewnętrznym.

Czego nie warto kupować: pakietów opieki, w których „aktualizacje" są jedyną pozycją. To jest kwadrans pracy miesięcznie — jeśli cena wygląda na więcej niż kwadrans, to znaczy, że płacicie za coś innego i warto zapytać, za co dokładnie.

Kolejność, która nie psuje strony

Sześć kroków. Przy stronie firmowej to kwadrans raz w miesiącu, jeśli nic nie zaskoczy.

1. Kopia zapasowa — przed, nie po. Nie „mamy kopie", tylko świeża, z dzisiaj. O tym, dlaczego to dwie różne rzeczy, piszemy osobno.
2. Jeśli macie środowisko testowe — tam najpierw. Jeśli nie macie, przejdźcie do punktu trzeciego i nadrabiajcie ostrożnością.
3. Najpierw rdzeń, potem reszta. Odwrotna kolejność bywa przyczyną konfliktów, bo wtyczki wydaje się pod nową wersję systemu, nie pod starą.
4. Wtyczki po jednej, ze sprawdzeniem po każdej. Sprawdzenie to trzydzieści sekund: strona główna, jedna podstrona usługowa, formularz kontaktowy.
5. Na końcu przejrzyjcie stronę na telefonie. Najczęstsza usterka po aktualizacji nie jest błędem serwera, tylko rozjechanym układem — a ten widać dopiero na wąskim ekranie.
6. Zanotujcie datę i co poszło. Jedno zdanie w tym samym dokumencie, w którym trzymacie dostępy. Przy następnej awarii to jest pierwsza rzecz, której się szuka.

Co dokładnie sprawdzać w punkcie czwartym, żeby to miało sens: stronę główną, jedną podstronę usługową, formularz kontaktowy i koszyk, jeśli jest. Cztery miejsca, trzydzieści sekund. Pokusa, żeby sprawdzać „czy strona się otwiera", jest duża i bezużyteczna — strona otwiera się prawie zawsze, a psuje się zwykle to, co ma stan: formularz, który przestał wysyłać, albo płatność, która przestała przechodzić.

Kiedy to robić: nie w piątek po południu i nie przed urlopem. Brzmi banalnie i jest najczęściej łamaną zasadą z całej listy — awaria wykryta w poniedziałek rano miała trzy dni na zebranie konsekwencji.

Gdy aktualizacja położy stronę

Trzy objawy pokrywają większość przypadków i każdy ma inną pierwszą reakcję.

Biała strona, bez żadnego komunikatu. Zwykle konflikt wtyczki z nową wersją rdzenia albo z wersją PHP. Pierwszy krok: wyłączyć ostatnio aktualizowaną wtyczkę. Jeśli nie macie dostępu do panelu, robi się to przez zmianę nazwy jej katalogu z poziomu hostingu.

Błąd 500 albo komunikat o krytycznym błędzie. To samo źródło, ale WordPress zwykle wysyła wtedy wiadomość na adres administratora z linkiem do trybu awaryjnego. Warto wiedzieć, na jaki adres — bo bywa to skrzynka sprzed dwóch wykonawców.

Strona działa, ale wygląda inaczej. Najczęściej nadpisany motyw albo wtyczka od układu, która zmieniła sposób działania. To jest przypadek, w którym odtworzenie kopii bywa szybsze niż szukanie przyczyny.

Reguła wspólna dla wszystkich trzech: odkręcajcie ostatnią zmianę, nie wszystkie naraz. Jeśli aktualizowaliście po jednej rzeczy, wiecie którą — i po to właśnie się aktualizuje po jednej.

Co zrobić, gdy odkręcenie nie pomaga: odtworzyć kopię i zostawić problem na później. To nie jest porażka, tylko właściwa decyzja — strona, która działa w starej wersji, jest w lepszym stanie niż strona, która nie działa w nowej. Przyczynę można znaleźć następnego dnia, na spokojnie, najlepiej na kopii środowiska, a nie na żywej stronie.

I jedna rzecz, o której się zapomina w panice: sprawdźcie, czy problem widzą też inni. Zdarza się, że strona „nie działa" wyłącznie w Waszej przeglądarce, bo trzyma starą wersję plików w pamięci podręcznej. Otwarcie jej w trybie prywatnym albo na telefonie zajmuje dziesięć sekund i bywa całym rozwiązaniem.

Trzy zdania, które słyszymy najczęściej

„Nie aktualizujemy, bo działa." Działa do momentu, w którym przestaje — a przy 46% luk bez poprawki „działa" nie oznacza „jest bezpieczne". Ważniejsze jest jednak coś innego: im dłużej się nie aktualizuje, tym trudniejsza staje się pierwsza aktualizacja. Przeskok o dwa lata to nie jest ta sama czynność co przeskok o miesiąc.

„Mamy automatyczne aktualizacje, więc temat jest załatwiony." Automat zamyka warstwę rdzenia. Nie zamyka wtyczek porzuconych przez autorów, nie zauważy, że coś przestało działać po aktualizacji, i nie podejmie decyzji o komponencie z luką bez łatki.

„To zadanie dla informatyka." W zakresie z tego artykułu — nie. Kopia, kliknięcie „aktualizuj" po jednej pozycji i sprawdzenie trzech podstron to czynności administracyjne, nie programistyczne. Wykonawca jest potrzebny przy wersji PHP i przy wtyczkach zmodyfikowanych pod Was, czyli w dwóch przypadkach z kilkunastu.

Sklep to inna kategoria

Wszystko powyżej dotyczy strony firmowej. Przy sklepie trzy rzeczy zmieniają się na tyle, że warto je wymienić osobno.

Środowisko testowe przestaje być luksusem. Przy stronie wizytówkowej awaria kosztuje wizerunek; przy sklepie kosztuje zamówienia w czasie rzeczywistym, więc aktualizowanie „na żywo" przestaje być do obronienia.

Integracje płatności i wysyłki trzeba sprawdzać osobno. Są to zwykle wtyczki od podmiotów trzecich, które zmieniają się niezależnie od Waszego sklepu — i to one najczęściej przestają działać cicho, bez żadnego komunikatu. Sprawdzenie polega na wykonaniu zamówienia testowego, nie na obejrzeniu strony.

Moment ma znaczenie liczbowe, nie tylko organizacyjne. Godzina przestoju w piątkowe popołudnie i godzina przestoju we wtorek rano to dwie różne kwoty, a przy sklepie da się je policzyć z własnych danych sprzedażowych.

Co sprawdzić raz w roku

Rutyna miesięczna zamyka bieżące ryzyko. Raz na rok warto zajrzeć w rzeczy, które nie zgłaszają się same, bo nie pojawiają się jako czerwona kropka w panelu.

• Wersja oprogramowania serwera. Jedno pytanie do hostingu albo jeden ekran w panelu. To jest ta warstwa, która nie aktualizuje się sama i o której przypomina dopiero awaria.
• Wtyczki bez aktualizacji od ponad roku. Nie są stabilne, tylko porzucone — i to właśnie przy nich pojawia się luka bez łatki.
• Czy motyw ma wersję potomną, jeśli ktokolwiek kiedykolwiek zmieniał coś w kodzie.
• Czy kopia zapasowa daje się odtworzyć. Nie czy jest — czy ktoś ją odtworzył i ile to trwało. To jest osobny temat i najczęściej pomijany.
• Kto ma dostęp do panelu. Lista kont po roku wygląda inaczej, niż pamiętacie; rozkładamy to przy zabezpieczeniach.

Cały przegląd to godzina raz na rok. Jest to jedyna pozycja z tego artykułu, która wymaga zapisania w kalendarzu — miesięczna rutyna przypomina się sama, bo panel pokazuje liczbę oczekujących aktualizacji. Roczny przegląd nie przypomni się nigdy.

Czego w tym tekście świadomie nie ma

• Terminów zewnętrznych i końca wsparcia dla wersji oprogramowania — to modernizacja, osobna decyzja i osobny kalendarz.
• Kopii zapasowych — osobno, z pytaniem, kto ostatnio odtwarzał.
• Kontroli dostępu i kont w panelu — jak zabezpieczyć stronę, gdzie jest też rozkład incydentów w Polsce.
• Kosztów opieki technicznej — to dział o utrzymaniu, nie o bezpieczeństwie.

Najkrótsze podsumowanie: aktualizujcie po jednej rzeczy, róbcie kopię przed, a resztę ryzyka zdejmijcie usuwaniem wtyczek, których nie używacie. Dyscyplina zamyka połowę problemu — drugiej połowy nie zamknie żadna, bo przy 46% luk nie ma czego instalować.

Jeśli mielibyśmy zostawić jedno zdanie z całego tekstu, brzmiałoby ono tak: najskuteczniejszą aktualizacją jest usunięcie czegoś, czego nie używacie. Nie wymaga kopii, nie psuje układu, nie ma wersji i nie pojawi się w żadnym raporcie o podatnościach — bo komponentu, którego nie ma, nikt nie zaatakuje. Przy typowej stronie firmowej pierwsze takie porządki zdejmują z listy od kilku do kilkunastu pozycji, i jest to jedyna czynność z tego artykułu, po której ryzyko spada trwale, a nie do następnego wydania.