Bezpieczna aktualizacja WordPressa to pięć kroków: kopia zapasowa, test na kopii strony, aktualizacja w ustalonej kolejności, sprawdzenie najważniejszych funkcji i obserwacja przez dobę. Sama aktualizacja rzadko psuje stronę. Psuje ją aktualizacja zrobiona bez kopii, bez testu albo po roku zaległości.

Dlaczego aktualizacje psują strony

Strona na WordPressie to rdzeń, motyw i kilkanaście lub kilkadziesiąt wtyczek od różnych autorów. Każdy z tych elementów ma własny cykl wydań. Awaria pojawia się zwykle na styku dwóch z nich.

Najczęstsze przyczyny awarii po aktualizacji:

  • Zaległości. Wtyczka aktualizowana po dwóch latach przeskakuje kilka wersji naraz, razem ze wszystkimi zmianami, które autor wprowadzał stopniowo.
  • Zmiany wpisane w pliki motywu. Ktoś poprawił kod bezpośrednio w motywie. Aktualizacja nadpisuje plik i poprawka znika.
  • Nadpisane szablony WooCommerce. Motyw ma własne kopie szablonów sklepu, a nowa wersja WooCommerce oczekuje innych.
  • Zależności między wtyczkami. Dodatek do WooCommerce albo do page buildera wymaga konkretnej wersji wtyczki głównej.
  • Wygasłe licencje. Płatna wtyczka bez aktywnej licencji przestaje dostawać aktualizacje i zostaje w tyle za resztą.
  • Stara wersja PHP. Nowe wydania wtyczek przestają działać na wersjach PHP, których nikt już nie wspiera.

Każdą z tych przyczyn wykryjesz przed aktualizacją na produkcji. Do tego służą kopia i test.

Kopia zapasowa przed każdą aktualizacją

Kopia musi obejmować bazę danych i katalog wp-content z plikami, motywami i wtyczkami. Sama baza nie wystarczy, bo bez plików nie odtworzysz wtyczek w starej wersji. Same pliki też nie, bo treści, zamówienia i ustawienia są w bazie.

Dobra kopia spełnia trzy warunki:

  • Jest przechowywana poza serwerem strony. Awaria serwera nie zabiera jej razem ze stroną.
  • Powstała tuż przed aktualizacją. Nocna kopia sprzed dwóch dni nie zawiera zamówień z tych dwóch dni.
  • Ktoś sprawdził, że da się ją odtworzyć. Kopia, której nikt nigdy nie przywracał, to hipoteza.

Przy dostępie do serwera przez SSH szybką kopię bazy zrobisz narzędziem WP-CLI: wp db export przed-aktualizacja.sql. Pliki spakujesz poleceniem tar -czf wp-content.tar.gz wp-content. Obie paczki przenieś poza serwer.

Sklep ma jeszcze jedną pułapkę. Przywrócenie kopii sprzed godziny kasuje zamówienia z tej godziny. Aktualizuj więc sklep w porze najmniejszego ruchu. Po ewentualnym przywróceniu kopii porównaj listę zamówień z panelem bramki płatności.

Test na kopii strony, czyli staging

Staging to kopia strony pod osobnym adresem, na tym samym typie serwera i tej samej wersji PHP. Aktualizacje robisz najpierw tam. Jeśli coś się zepsuje, psuje się kopia, a klienci niczego nie widzą.

Wiele hostingów tworzy staging jednym kliknięciem w panelu. Bez takiej funkcji stawiasz kopię ręcznie: przenosisz bazę i pliki, a adres zmieniasz poleceniem wp search-replace.

Staging sklepu wymaga trzech zabezpieczeń przed testami:

  1. Przełącz bramki płatności w tryb testowy albo je wyłącz.
  2. Zablokuj wysyłkę maili do klientów, na przykład wtyczką przechwytującą pocztę.
  3. Wyłącz zadania cykliczne połączone z zewnętrznymi systemami: hurtownią, ERP, integracją z kurierem.

Zasłoń też kopię hasłem na poziomie serwera. Opcja „Proś wyszukiwarki o nieindeksowanie witryny” to tylko prośba. Druga, identyczna strona w wynikach Google nie jest Ci do niczego potrzebna.

Kolejność aktualizacji

Kolejność ma znaczenie, bo wtyczki deklarują minimalne wersje rdzenia i wtyczek, od których zależą. Dodatki do WooCommerce podają na przykład wymaganą wersję WooCommerce w nagłówku swojego pliku.

  1. Otwórz Narzędzia → Stan witryny i usuń krytyczne problemy, zanim cokolwiek zaktualizujesz.
  2. Zaktualizuj rdzeń WordPressa. Jeśli po aktualizacji WordPress poprosi o aktualizację bazy danych, zrób ją od razu.
  3. Zaktualizuj wtyczki główne: WooCommerce, page builder, wtyczkę SEO. Każdą osobno i po każdej sprawdź stronę.
  4. Zaktualizuj dodatki do nich: bramki płatności, moduły wysyłki, rozszerzenia buildera.
  5. Zaktualizuj pozostałe wtyczki. Proste wtyczki możesz aktualizować grupowo.
  6. Na końcu zaktualizuj motyw i tłumaczenia.

Po aktualizacji WooCommerce otwórz WooCommerce → Status i przewiń do listy szablonów. Nieaktualne kopie szablonów w motywie są tam oznaczone ostrzeżeniem. Dokumentacja WooCommerce opisuje, jak je poprawić.

W WP-CLI zaczynasz od wp core update i wp core update-db. Potem aktualizujesz wtyczki po nazwie, na przykład wp plugin update woocommerce. Listę zaległych aktualizacji pokaże wp plugin list --update=available.

Co sprawdzić po aktualizacji

Działająca strona główna niczego nie dowodzi. Sprawdź ścieżki, na których zarabiasz:

  • formularz kontaktowy: wyślij wiadomość i sprawdź, czy dotarła,
  • w sklepie: koszyk, kupon rabatowy, wybór dostawy, płatność testowa i mail z potwierdzeniem,
  • logowanie do konta klienta i do panelu,
  • wyszukiwarkę, filtry produktów i menu na telefonie,
  • podstronę produktu lub usługi z największym ruchem,
  • integracje: czy testowe zamówienie trafiło do systemu magazynowego lub księgowego.

Część błędów nie pokazuje się na ekranie. Włącz zapis błędów PHP do pliku. W wp-config.php dopisz trzy linie: define( 'WP_DEBUG', true );, define( 'WP_DEBUG_LOG', true ); i define( 'WP_DEBUG_DISPLAY', false );. Błędy trafią do pliku wp-content/debug.log, a odwiedzający ich nie zobaczą. Po testach wyłącz zapis. Na wielu serwerach ten plik da się otworzyć z przeglądarki.

Na koniec wyczyść cache strony i CDN. Bez tego część odwiedzających dostanie nowy HTML ze starymi plikami CSS i JavaScript.

Przez następną dobę obserwuj monitoring dostępności, skrzynkę z formularza i liczbę zamówień. Zero zamówień w godzinach, w których zwykle są, to sygnał do sprawdzenia koszyka.

Automatyczne aktualizacje: tak czy nie

WordPress od wersji 3.7 sam instaluje drobne wydania rdzenia, czyli poprawki błędów i bezpieczeństwa. Zostaw to włączone. Te wydania łatają luki i nie zmieniają funkcji.

Automatyczne aktualizacje wtyczek i motywów działają od WordPressa 5.5. Włączasz je osobno dla każdej wtyczki, a WordPress uruchamia je dwa razy dziennie i wysyła administratorowi mail z wynikiem.

Od wersji 6.6 WordPress ma dodatkowe zabezpieczenie. Jeśli automatyczna aktualizacja aktywnej wtyczki wywoła błąd krytyczny PHP, wtyczka wraca do poprzedniej wersji. Mechanizm opisuje propozycja zespołu rozwijającego WordPress. Sprawdza on tylko, czy strona główna odpowiada bez błędu krytycznego. Rozjechanego układu, błędu JavaScript ani zepsutego koszyka nie wykryje.

Rekomendacja zależy od typu strony:

  • Prosta strona firmowa z kilkoma popularnymi wtyczkami: automatyczne aktualizacje wtyczek mogą działać, jeśli masz codzienną kopię i monitoring dostępności.
  • Sklep WooCommerce: wtyczki aktualizuj ręcznie, po teście na stagingu. Automat nie sprawdzi płatności.
  • Strona z modyfikacjami w kodzie lub na page builderze: tylko ręcznie. Tu po aktualizacji najczęściej psuje się układ, a tego automat nie widzi.

Wyjątek to łatki na luki, które atakujący już wykorzystują. Instaluj je w ciągu doby, nawet kosztem skróconego testu. Priorytety bezpieczeństwa zebraliśmy w checkliście zabezpieczenia WordPressa.

Wersja PHP to też aktualizacja

PHP to język, w którym działa WordPress. Każda wersja PHP ma dwa lata pełnego wsparcia i dwa lata samych poprawek bezpieczeństwa. Stan na wrzesień 2026 r. według php.net:

  • PHP 8.1 i starsze: bez wsparcia i bez łatek bezpieczeństwa,
  • PHP 8.2: łatki bezpieczeństwa do 31 grudnia 2026 r.,
  • PHP 8.3: łatki bezpieczeństwa do 31 grudnia 2027 r.,
  • PHP 8.4: wsparcie do 31 grudnia 2028 r.,
  • PHP 8.5: wsparcie do 31 grudnia 2029 r.

WordPress zaleca PHP 8.3 lub nowsze. Od wersji 7.0 minimalną wersją jest PHP 7.4. Minimalna nie znaczy bezpieczna. PHP 7.4 od lat nie dostaje poprawek.

Jeśli Twoja strona działa na PHP 8.2, masz trzy miesiące na przejście. Zmień wersję najpierw na stagingu i przejrzyj debug.log. Komunikaty „Deprecated” wskazują kod, który przestanie działać w kolejnych wersjach PHP. „Fatal error” wskazuje wtyczkę lub fragment motywu do wymiany przed zmianą na produkcji.

Jeśli hosting nie pozwala wybrać wersji PHP, to poważny argument za przeprowadzką. Na co patrzeć przy wyborze, opisujemy w tekście o hostingu dla WordPress i WooCommerce.

Jak często aktualizować

Rytm, który sprawdza się na stronach firmowych i w sklepach:

  • łatki bezpieczeństwa: w ciągu doby od publikacji, jeśli luka dotyczy wtyczki, którą masz,
  • rutynowe aktualizacje wtyczek: co tydzień lub co dwa tygodnie, partiami, z testem,
  • duże wydania WordPressa: na stagingu od razu, na produkcji po kilku dniach.

Skąd te kilka dni? WordPress 7.1 wyszedł 19 sierpnia 2026 r. Do 22 września dostał dwie wersje poprawkowe: 7.1.1 i 7.1.2. W pierwszych tygodniach po dużym wydaniu autorzy wtyczek też publikują poprawki zgodności.

Odstęp dłuższy niż miesiąc zwiększa ryzyko. Każdy tydzień przerwy dokłada zmian, które potem testujesz naraz.

Najczęstsze pytania

Czy aktualizacja WordPressa może usunąć treści strony?

Aktualizacja rdzenia i wtyczek nie usuwa wpisów, stron ani zamówień, bo są zapisane w bazie danych. Znikają za to zmiany wpisane bezpośrednio w pliki motywu lub wtyczki. Własny kod trzymaj więc w motywie potomnym albo we własnej wtyczce.

Co zrobić, gdy po aktualizacji pojawia się błąd krytyczny?

WordPress wysyła wtedy administratorowi mail z linkiem do trybu odzyskiwania. Po zalogowaniu w tym trybie wyłączysz winną wtyczkę. Bez maila zmień przez FTP nazwę katalogu wtyczki w wp-content/plugins, co ją dezaktywuje. Jeśli to nie pomaga, przywróć kopię sprzed aktualizacji.

Jak często aktualizować wtyczki WordPress?

Łatki bezpieczeństwa instaluj w ciągu doby od publikacji. Pozostałe aktualizacje rób co tydzień lub co dwa tygodnie, partiami, po teście na kopii strony. Odstęp dłuższy niż miesiąc zwiększa liczbę zmian testowanych naraz i ryzyko awarii.

Czy mogę nie aktualizować strony, która działa?

Możesz, ale z każdym miesiącem przybywa znanych luk w wersjach, które masz zainstalowane. Po roku zaległości aktualizacja wymaga zwykle przeglądu całej strony. Stan takiej strony najlepiej ocenić audytem technicznym WordPressa, zanim ruszysz cokolwiek na produkcji.

W stałej opiece nad WordPress aktualizacje testujemy najpierw na kopii strony. Kopie zapasowe trzymamy w trzech lokalizacjach geograficznych, a monitoring dostępności działa 24/7. Zakres i cenę opisaliśmy na stronie opieki nad stroną WordPress.