W skrócie
- WordPress od wersji 3.7 sam instaluje drobne aktualizacje bezpieczeństwa rdzenia. Wtyczki, motywy i duże wersje rdzenia trzeba włączyć albo aktualizować ręcznie.
- Największe ryzyko jest we wtyczkach, nie w samym WordPressie. Każda nieużywana wtyczka to kod, którego nikt nie pilnuje.
- Bezpieczny rytm dla małej firmy: przegląd raz w tygodniu, poprawki bezpieczeństwa od razu, kopia zapasowa przed każdą większą zmianą.
- Po aktualizacji sprawdź pięć rzeczy: stronę główną, formularz, menu, stronę usługi i wersję na telefonie.
Strona działa, więc „nie ma co ruszać”. To zdanie słyszę najczęściej od właścicieli stron, które potem trafiają do nas po włamaniu. WordPress jest najpopularniejszym systemem stron na świecie, dlatego automaty skanujące internet szukają w nim znanych dziur bez przerwy. Nie trzeba być ważnym celem. Wystarczy mieć starą wersję wtyczki, w której luka jest już opisana publicznie.
Co aktualizuje się samo?
WordPress od wersji 3.7 (2013 rok) instaluje w tle drobne wydania rdzenia, czyli poprawki bezpieczeństwa i błędów, na przykład z 6.9.1 do 6.9.2. Robi to domyślnie, jeśli serwer na to pozwala.
Od wersji 5.5 (2020 rok) w panelu przy każdej wtyczce i motywie jest link „Włącz automatyczne aktualizacje”. Domyślnie jest wyłączony. Od wersji 5.6 można też włączyć automatyczne aktualizacje do nowych dużych wersji rdzenia.
Część firm hostingowych ma własne mechanizmy aktualizacji, a niektóre wtyczki bezpieczeństwa potrafią zablokować aktualizacje w tle. Sprawdź więc w kokpicie, w menu „Kokpit → Aktualizacje”, jaką wersję masz i kiedy była ostatnia aktualizacja. Jeśli różnica do najnowszej wersji jest duża, coś blokuje mechanizm.
Dlaczego wtyczki są najważniejsze?
Rdzeń WordPressa ma zespół bezpieczeństwa i szybko wydaje poprawki. Wtyczki tworzą tysiące niezależnych autorów: od dużych firm po jedną osobę po godzinach. Raporty firm zajmujących się bezpieczeństwem WordPressa, takich jak Patchstack czy Wordfence, od lat pokazują, że zdecydowana większość nowo zgłaszanych luk dotyczy wtyczek i motywów, a nie rdzenia.
Wnioski dla małej firmy:
- Mniej wtyczek, mniej ryzyka. Usuń te, których nie używasz. Wyłączona wtyczka nadal leży na serwerze i może być wykorzystana. Usuń ją całkiem.
- Sprawdzaj, czy wtyczka żyje. W katalogu WordPress.org widać datę ostatniej aktualizacji i informację, z którą wersją WordPressa była testowana. Wtyczka nieaktualizowana od dwóch lat to sygnał, żeby poszukać zamiennika.
- Uważaj na wtyczki z nieoficjalnych źródeł. Płatna wtyczka pobrana za darmo z przypadkowej strony to częsty sposób na wpuszczenie złośliwego kodu. Do tego nie dostaje aktualizacji.
- Licencje płatnych wtyczek muszą być aktywne. Bez licencji często nie ma aktualizacji, także bezpieczeństwa.
Jak często aktualizować?
Rytm, który stosujemy w Opiece i który sprawdzi się też, gdy robisz to sam:
- Poprawki bezpieczeństwa: od razu, najpóźniej w ciągu jednego, dwóch dni. Gdy autor wtyczki pisze w opisie zmian „security fix”, nie czekaj do końca miesiąca.
- Zwykłe aktualizacje wtyczek: raz w tygodniu, wszystkie naraz, z kopią przed.
- Duże wersje rdzenia (na przykład z 6.9 do 7.0): po kilku dniach od wydania. W tym czasie autorzy wtyczek łatają ewentualne niezgodności, a pierwsze poprawki rdzenia wychodzą zwykle szybko.
- Wersja PHP na serwerze: co najmniej raz w roku sprawdź, czy wersja jest wspierana. Stare wersje PHP przestają dostawać poprawki bezpieczeństwa. Zmianę robi się w panelu hostingu, ale najpierw na kopii strony.
Automatyczne aktualizacje wtyczek: włączać?
To zależy od strony. Na prostej wizytówce z kilkoma popularnymi wtyczkami automatyczne aktualizacje zwykle dają więcej, niż ryzykują. Strona jest wtedy łatana także wtedy, gdy nikt o niej nie myśli.
Na stronie z rezerwacjami, sklepem albo rozbudowanym kreatorem stron wolę aktualizacje ręczne albo przynajmniej z kopią i szybką kontrolą po. Jedna nieudana aktualizacja może wyłączyć formularz zamówień na kilka dni, zanim ktoś to zauważy. Jak sprawdzać, czy formularz działa, piszę w tekście o formularzu kontaktowym.
Rozsądny kompromis: automatyczne aktualizacje dla wtyczek prostych i popularnych, ręczne dla tych, od których zależy sprzedaż lub kontakt z klientem.
Jak zaktualizować bez awarii?
- Zrób kopię zapasową plików i bazy danych. Sprawdź, czy kopia się skończyła i gdzie leży. Jak ustawić kopie, opisałem w tekście o zasadzie 3-2-1.
- Przeczytaj opis zmian przy dużych aktualizacjach. Autorzy uprzedzają, gdy coś wymaga uwagi.
- Aktualizuj po kolei, nie wszystko jednym kliknięciem, jeśli to duże zmiany. Łatwiej wtedy wskazać, która wtyczka zepsuła stronę.
- Sprawdź stronę w oknie przeglądarki, w którym nie jesteś zalogowany: stronę główną, menu, jedną stronę usługi, formularz kontaktowy (wyślij próbną wiadomość) i widok na telefonie.
- Wyczyść cache, jeśli strona korzysta z wtyczki cache albo z Cloudflare. Inaczej możesz oglądać starą wersję.
Większe strony warto najpierw aktualizować na kopii testowej. Wiele firm hostingowych ma w panelu funkcję tworzenia kopii testowej jednym kliknięciem. Jak ułożyć aktualizacje i środowisko testowe w portalu, piszę w tekście o WordPressie dla dużych serwisów i portali.
Co zrobić, gdy po aktualizacji strona nie działa?
Od wersji 5.2 WordPress ma tryb odzyskiwania. Gdy wtyczka lub motyw powoduje błąd krytyczny, administrator dostaje mail z linkiem, który pozwala wejść do panelu i wyłączyć winowajcę. Jeśli po aktualizacji pojawi się błąd krytyczny, całą diagnozę krok po kroku opisujemy w poradniku Błąd krytyczny na stronie WordPress. Jeśli mail nie przychodzi, często winna jest poczta wysyłana z serwera bez konfiguracji, o czym pisałem w tekście o SPF, DKIM i DMARC.
Jeżeli panel jest niedostępny, a kopia jest świeża, najszybciej jest przywrócić kopię sprzed aktualizacji i spokojnie szukać przyczyny. Jeśli po aktualizacji widzisz na stronie dziwne przekierowania lub obce treści, to nie jest problem z aktualizacją, tylko możliwe włamanie. Wtedy pomoże tekst WordPress po włamaniu: pierwsze 24 godziny.
Nie chcesz o tym pamiętać?
W Opiece aktualizujemy WordPressa i wtyczki z kopią przed każdą zmianą i sprawdzamy stronę po. Gdy strona już nie działa, pomoże naprawa WordPressa. Ceny w cenniku.
Źródła
- WordPress.org: Configuring Automatic Background Updates (dostęp: 3.11.2026)
- WordPress.org: Plugins & Themes Auto-Updates (dostęp: 3.11.2026)
- Make WordPress Core: Fatal Error Recovery Mode in 5.2 (dostęp: 3.11.2026)
- PHP.net: Supported Versions (dostęp: 3.11.2026)
- Patchstack: raporty o stanie bezpieczeństwa WordPressa (dostęp: 3.11.2026)
