Aktualizacja WordPress bez awarii: kopia i kolejność

Wielu właścicieli firm boi się kliknąć „aktualizuj”. Mają powód: kiedyś po aktualizacji coś się rozjechało i od tamtej pory nikt tego przycisku nie rusza.

U nas też zdarza się, że aktualizacja coś psuje. Najczęstszy scenariusz to wtyczka, po której rozjeżdża się koszyk i nie da się kupić. Dlatego nie aktualizujemy na żywo: każdą aktualizację wgrywamy najpierw na kopię strony i na produkcję idzie tylko to, co działa. Widzimy też drugą stronę: strony, których nikt nie ruszał od pół roku, są wolniejsze, zaniedbane, a czasem zhakowane.

Strach jest zrozumiały, ale ma cenę. Według raportu Patchstack State of WordPress Security in 2026 mediana czasu od ujawnienia luki do masowych ataków wynosi 5 godzin, licząc luki, które w ogóle są masowo atakowane. Strona, która czeka z aktualizacją tydzień, jest przez ten czas łatwym celem.

Nie chodzi o to, żeby klikać na ślepo ani żeby nie ruszać niczego. Chodzi o kolejność, w której awaria trafia na kopię strony, a nie na stronę, którą widzą klienci. Opisuję ją niżej, razem z miejscami, w których sam WordPress Cię nie uratuje. Stan na 28 października 2026, aktualna wersja WordPressa to 7.1.4.

Czy trzeba aktualizować WordPressa, skoro strona działa?

Tak. Zaległa aktualizacja to otwarta furtka. Patchstack naliczył w 2025 roku 11 334 nowe podatności w ekosystemie WordPressa, o 42% więcej niż rok wcześniej. Z tego 91% dotyczyło wtyczek, 9% motywów, a rdzenia tylko sześć.

Atakowane są też stare dziury. Patchstack pisze, że napastnicy sięgają po starsze luki, licząc na strony, które nie są aktualizowane. W zestawieniu 10 najczęściej atakowanych podatności tylko cztery pochodziły z 2025 roku. Do tego około połowa podatności o wysokim wpływie jest atakowana w ciągu 24 godzin od ujawnienia.

Wynika z tego jedno: największe ryzyko siedzi we wtyczkach, nie w samym WordPressie. Więcej o tym, jak je zabezpieczać, jest w tekście jak chronić WordPress przed atakami brute force, w części o konserwacji.

Pogadajmy

Zrobić to razem?

Wdrażam takie rzeczy w firmach na co dzień. Umów 30 minut, pogadamy konkretnie o Twoim przypadku. Bez prezentacji sprzedażowej.

Umów bezpłatną rozmowę →

Łukasz ŚlusarskiTwórca important.is

Co zrobić przed aktualizacją WordPressa?

Zrób kopię bazy i plików, najlepiej poza serwerem strony. Potem wykonaj aktualizację najpierw na kopii roboczej (stagingu), a dopiero gdy tam działa, na stronie, którą widzą klienci.

Oficjalna instrukcja aktualizacji WordPressa też zaczyna od kopii zapasowej i radzi sprawdzić, czy da się z niej odtworzyć stronę. Kopia, której nigdy nie próbowano przywrócić, to na razie tylko nadzieja.

Kopia bazy i plików z dzisiaj, poza serwerem strony.
Staging, czyli kopia strony pod osobnym adresem, na której możesz psuć bez skutków.
Lista tego, co zaktualizujesz, z numerami wersji. Gdy coś padnie, wiesz, do czego wracać.
Notatki do wydania przy większych skokach wersji, na przykład z 5.x na 6.x wtyczki. Szukaj słów „breaking change” i „wymaga PHP”.
Wersja PHP. Według wymagań WordPressa zalecane jest PHP 8.3 lub nowsze, a z PHP 7.4 jeszcze działa, choć to wersja bez wsparcia. Według php.net PHP 8.2 dostaje już tylko poprawki bezpieczeństwa, do 31 grudnia 2026.
Lista rzeczy do sprawdzenia po aktualizacji: formularz kontaktowy, koszyk i płatność, logowanie, najważniejsza podstrona.

Ostatni punkt ludzie pomijają najczęściej. Strona wygląda dobrze, a formularz od miesiąca nie wysyła maili. Taka awaria jest najdroższa, bo nic jej nie pokazuje.

W jakiej kolejności aktualizować rdzeń, wtyczki i motyw?

Poradniki nie są tu zgodne. My trzymamy się kolejności z oficjalnej instrukcji: najpierw rdzeń, potem wtyczki, na końcu motyw. Każdą zmianę rób osobno, żeby wiedzieć, co ją spowodowało.

Kopia i staging.
Rdzeń WordPressa.
Wtyczki, po jednej albo w małych grupach. Najpierw te z poprawkami bezpieczeństwa.
Motyw. Przy motywie potomnym sprawdź, czy nadrzędny nie zmienił struktury plików.
Test rzeczy z Twojej listy.
Dopiero potem to samo na żywej stronie.

„Jedna zmiana naraz” brzmi jak strata czasu, a oszczędza go. Po kliknięciu „aktualizuj wszystko” szukasz winnego wśród kilkunastu wtyczek. Po jednej zmianie winny jest ten, którego ruszyłeś ostatni. W sklepie na WooCommerce to jeszcze ważniejsze, bo aktualizacja może dotknąć płatności, dostaw i integracji.

Wolisz to zlecić? 30 minut, bez zobowiązań. Sprawdzimy czy to ma sens.

Zarezerwuj termin →

Czy włączyć automatyczne aktualizacje WordPressa i wtyczek?

Dla drobnych wydań rdzenia tak, to ustawienie domyślne. Dla wtyczek i motywu zależy od strony. Gdy awaria kosztuje niewiele, włącz. Gdy strona zarabia, aktualizuj przez staging.

Automatyczne aktualizacje w tle działają od WordPressa 3.7. Do wersji 5.6 domyślnie dotyczyły tylko drobnych wydań rdzenia i tłumaczeń. Od 5.6 nowe instalacje aktualizują też wydania główne, a starsze instalacje zachowują dawne ustawienie. Aktualizacje wtyczek i motywów dołożył WordPress 5.5, ale są domyślnie wyłączone, włączasz je przełącznikiem przy każdej wtyczce.

Od WordPressa 6.6 działa jeszcze rollback automatycznych aktualizacji wtyczek. WordPress sprawdza zapytaniem do strony głównej, czy po aktualizacji nie pojawił się błąd krytyczny PHP. Jeśli tak, wraca do poprzedniej wersji wtyczki i wysyła mail do administratora.

To przydatne zabezpieczenie, ale ma granicę. Złapie błąd krytyczny. Nie zauważy formularza, który przestał wysyłać maile, ani przycisku „kup”, który nic nie robi. Dotyczy też tylko wtyczek, nie rdzenia i nie motywu.

Co aktualizujesz	Automatycznie, gdy	Przez staging, gdy
Rdzeń, drobne wydania	prawie zawsze	bardzo rozbudowana strona
Rdzeń, wydania główne	wizytówka, jest kopia	sklep, własne wtyczki, własny motyw
Popularne wtyczki (SEO, formularze)	mała strona, tania awaria	strona zarabia albo zależy od integracji
WooCommerce, płatności, rezerwacje	prawie nigdy	zawsze, z testowym zamówieniem
Motyw z własnymi zmianami	nie	zawsze

Patchstack dopisuje zastrzeżenie. W raporcie za 2024 rok stwierdza, że korzystanie tylko z niezbędnych wtyczek i auto-aktualizacje mogą na jakiś czas ochronić, ale dane pokazują, że to za mało. Powód: 33% podatności z 2024 roku i 46% z 2025 roku nie miało poprawki w chwili ujawnienia. Nie zaktualizujesz czegoś, czego nie ma.

Co zrobić, gdy aktualizacja rozjechała stronę?

Cofnij ostatnią zmianę. Przyczyny szukaj potem, na kopii i na spokojnie. Od najłatwiejszego:

Sprawdź skrzynkę administratora. Od WordPressa 5.2 działa tryb odzyskiwania: przy błędzie krytycznym WordPress wysyła mail z tajnym linkiem, po którym wejdziesz do panelu z wstrzymaną wadliwą wtyczką.
Wyłącz ostatnio aktualizowaną wtyczkę. Bez dostępu do panelu zmień przez FTP nazwę jej katalogu w wp-content/plugins. Jeśli nie wiesz której, zmień nazwę całego katalogu plugins na plugins_old. Poradnik WordPressa o częstych błędach opisuje to jako sposób na biały ekran. Potem wróć do starej nazwy i włączaj wtyczki po jednej.
Strona wisi na komunikacie o przerwie technicznej? Aktualizacja mogła się przerwać i zostawić w głównym katalogu plik .maintenance. Usunięcie go przez FTP to oficjalne rozwiązanie.
Po aktualizacji motywu przełącz się na motyw domyślny i sprawdź, czy to on.
Jeśli nic nie pomaga albo to sklep, przywróć kopię sprzed aktualizacji. Dlatego ma być z dziś, a nie z zeszłego miesiąca.

Jeśli pracujesz z wiersza poleceń, WP-CLI pokaże, co czeka na aktualizację: wp plugin list --update=available. Polecenie wp plugin update aktualizuje jedną wtyczkę albo wszystkie (--all). Z opcją --version ustawisz konkretną wersję, więc cofnięcie wtyczki to jedno polecenie. Najpierw na stagingu.

Czym jest administracja WordPress i czy aktualizacje do niej należą?

Administracja WordPress to codzienne utrzymanie strony: aktualizacje, kopie, monitoring, bezpieczeństwo i reakcja na awarie. Aktualizacje to jej najbardziej regularna część.

W małej firmie zwykle nie robi tego nikt, bo nikt nie ma na to czasu. U nas jest to zwykła praca. Z zespołem pilnujemy dziesiątek stron na WordPressie. W pakietach opieki nad stroną każdą aktualizację wgrywamy najpierw na kopię, którą utrzymujemy na naszym serwerze w Europie. Na produkcję idzie to, co działa. Kopie zapasowe robimy codziennie, poza serwerem strony, a formularze testujemy cyklicznie.

Nie obiecujemy, że nic się nie zepsuje. Zmniejszamy ryzyko, nie usuwamy go. Dlatego jest kopia, do której można wrócić. Pakiet Start kosztuje 399 zł netto miesięcznie, w pakietach Standard i Pro dochodzą godziny pracy i administratora. Ile to wszystko kosztuje i co obejmuje, opisaliśmy w tekście opieka nad stroną WordPress.

Kiedy aktualizacja to zły pomysł i czego nie rozwiąże?

Gdy robisz ją bez kopii, na żywej stronie, w środku sezonu sprzedażowego, albo gdy wtyczka jest porzucona. Aktualizacja nie naprawi też kodu, którego autor przestał pilnować.

Bez kopii i stagingu to rzut monetą. Czasem wychodzi, ale nie wiesz kiedy przestanie.
Sklep w godzinach największego ruchu albo tuż przed kampanią. Awaria kosztuje wtedy najwięcej. Wybierz okno z małym ruchem i zostaw czas na naprawę.
Porzucona wtyczka nie dostanie poprawki. W 2025 roku 46% podatności nie miało łatki w chwili ujawnienia. Wtedy rozwiązaniem jest wymiana wtyczki, nie klikanie.
Skok wersji PHP albo rdzenia może zepsuć starą wtyczkę i własny kod. Lepiej to zobaczyć na stagingu niż w wiadomości od klienta.
Rollback chroni przed błędem krytycznym, nie przed błędem logicznym: źle liczonym koszykiem, zepsutym formularzem, układem rozjechanym na telefonie.
Aktualizacja nie zastąpi firewalla, kopii poza serwerem i monitoringu. To osobne rzeczy.

Jeśli masz własną wtyczkę albo mocno zmieniony motyw, każdą aktualizację rdzenia trzeba sprawdzić pod kątem zgodności. Zmiany rób w motywie potomnym, bo ten pozwala aktualizować motyw nadrzędny bez utraty modyfikacji.

Co możesz zrobić dziś?

Zajrzyj do kokpitu i zobacz, ile aktualizacji czeka. Sprawdź, czy kopia zapasowa leży poza serwerem strony i czy ktoś kiedyś próbował ją odtworzyć. Usuń wtyczki, których nie używasz, bo każda to dodatkowa powierzchnia ataku. Włącz powiadomienia o aktualizacjach na mail administratora.

Potem wybierz jedną małą aktualizację, na przykład drobną wtyczkę, i zrób ją według powyższej kolejności. Chodzi o to, żeby wypróbować proces, zanim będzie potrzebny w nerwach.

Jeśli wolisz, żeby robił to ktoś inny, w important.is zrobimy to za Ciebie. Na stronie opieki jest też bezpłatny audyt: sprawdzamy m.in. stan aktualizacji i kopie zapasowe, a raport zostaje u Ciebie, nawet jeśli nie zaczniemy współpracy.

Najczęściej zadawane pytania

Jak często aktualizować WordPressa i wtyczki?

Poprawki bezpieczeństwa jak najszybciej, w praktyce w ciągu kilku dni. Patchstack pisze, że około połowa podatności o wysokim wpływie jest atakowana w ciągu 24 godzin od ujawnienia. Pozostałych aktualizacji nie trzeba robić jednego dnia, ale nie powinny leżeć miesiącami.

Czy aktualizacja wtyczek WordPress może zepsuć stronę?

Może. Zdarza się błąd krytyczny, konflikt z inną wtyczką albo zmiana, która psuje jedną funkcję, a reszta działa. Dlatego aktualizujesz najpierw na kopii i masz świeży backup.

Czy aktualizacja WordPressa usuwa moje treści?

Aktualizacja rdzenia podmienia pliki WordPressa. Oficjalna instrukcja ręcznej aktualizacji każe zostawić katalog wp-content, a w nim są wtyczki, motywy i wgrane pliki, oraz wp-config.php. Własne zmiany w plikach rdzenia albo motywu nadrzędnego możesz jednak stracić, dlatego robi się je w motywie potomnym.

Co zrobić, gdy po aktualizacji pojawił się biały ekran?

Sprawdź mail administratora, bo WordPress mógł wysłać link do trybu odzyskiwania. Jeśli go nie ma, zmień przez FTP nazwę katalogu wtyczki, którą ostatnio aktualizowałeś. Gdy to nie pomoże, przywróć kopię zapasową.

Czy mogę aktualizować WordPressa sam, czy potrzebuję administratora?

Możesz, jeśli masz kopię, miejsce do testów i czas, żeby sprawdzić stronę po zmianie. Administrator przydaje się, gdy strona zarabia, jest sklepem albo ma kilkanaście wtyczek. Wtedy każda aktualizacja to też sprawdzenie, czy płatności i formularze nadal działają.

raz na jakiś czas

Zostań w pętli

Nowe artykuły, narzędzia i case study prosto na maila. Bez spamu, bez sprzedaży.