Aktualizacja WordPressa krok po kroku — bez awarii

Przycisk „Zaktualizuj teraz” budzi w ludziach dwa skrajne odruchy. Jedni klikają wszystko od razu na żywej stronie, drudzy nie klikają nic od dwóch lat, bo „działa, to nie ruszam”. Obie strategie kończą się tak samo — awarią. Różnica jest tylko w dacie.

Ten poradnik pokazuje trzecią drogę: procedurę, którą sami stosujemy przy aktualizacjach na zlecenie. Nie wymaga wiedzy programistycznej, wymaga kolejności.

Dlaczego „działa, to nie ruszam” nie działa

Zdecydowana większość włamań na strony WordPress nie ma nic wspólnego z „hakowaniem”. To automaty skanujące internet w poszukiwaniu stron ze starą wersją wtyczki, w której ktoś opublikował znaną lukę. Publikacja luki i aktualizacja łatająca wychodzą zwykle tego samego dnia — kto aktualizuje, jest bezpieczny; kto czeka pół roku, jest na liście celów.

Drugi koszt czekania jest mniej oczywisty: im większy skok wersji, tym boleśniejsza aktualizacja. Przeskok wtyczki o trzy wydania w górę to zwykle nic. Przeskok o trzy lata to często zmiana struktury danych, porzucone API i konflikt z nowym PHP — wszystko naraz.

Krok 0: kopia zapasowa, którą umiesz przywrócić

Bez tego kroku reszta nie ma sensu. Potrzebujesz kopii plików i bazy danych — samo jedno z dwóch to nie backup, to połowa backupu. Jak wygląda kopia, która naprawdę ratuje, opisaliśmy osobno.

Najprościej: wtyczka typu UpdraftPlus albo Duplicator, z zapisem kopii poza serwerem (Dysk Google, Dropbox). Wielu hostingów robi też własne kopie — sprawdź w panelu, czy Twój je ma i jak daleko wstecz sięgają.

Jedna rzecz, którą pomija prawie każdy: sprawdź raz, że kopię faktycznie da się przywrócić. Backup, którego nikt nigdy nie testował, to przesąd, nie zabezpieczenie.

Krok 1: przejrzyj, co czeka w kolejce

W panelu: Kokpit → Aktualizacje. Zanim klikniesz cokolwiek:

• Wtyczki nieaktualizowane od ponad roku potraktuj jako sygnał ostrzegawczy. Wejdź na stronę wtyczki w katalogu wordpress.org — jeśli autor porzucił projekt, szukaj zamiennika, bo to tykająca bomba niezależnie od aktualizacji.
• Przy dużych skokach wersji (WooCommerce, Elementor, wtyczki SEO) otwórz changelog i poszukaj słów „breaking change” albo „migration”. Duzi wydawcy ostrzegają wprost.
• Zmiana wersji PHP to osobna aktualizacja, nie „przy okazji”. Rób ją na końcu, gdy wszystko inne już działa na bieżących wersjach.

Krok 2: kolejność — wtyczki, motyw, rdzeń

Aktualizuj od góry zależności: najpierw wtyczki, potem motyw, na końcu rdzeń WordPressa. Autorzy wtyczek dostosowują je do nadchodzącej wersji rdzenia wcześniej — odwrotna kolejność (najpierw rdzeń) zostawia Cię ze starymi wtyczkami na nowym rdzeniu, czyli w konfiguracji, której nikt nie testował.

Dwie zasady, które ratują przed długim szukaniem winnego:

1. Nie klikaj „zaznacz wszystkie”. Aktualizuj partiami po kilka wtyczek i po każdej partii przeklikaj stronę. Gdy coś się wysypie, wiesz, w której partii szukać.
2. Po każdej partii otwórz stronę w trybie incognito — nie tylko panel. Część błędów widać wyłącznie od frontu.

Masz sklep albo stronę, na której zarabiasz? Zrób to samo, tylko najpierw na kopii (staging). Większość hostingów z panelem DirectAdmin czy cPanel pozwala sklonować stronę na subdomenę w kilka minut. Na sklonowanej wersji możesz psuć do woli.

Krok 3: co sprawdzić po aktualizacji

Krótka lista zamiast „chyba działa”:

• strona główna i 2–3 najważniejsze podstrony (od frontu, w trybie incognito),
• formularz kontaktowy — wyślij testowe zgłoszenie i sprawdź, że mail dotarł,
• w sklepie: dodanie do koszyka i przejście do płatności,
• wygląd na telefonie, nie tylko na monitorze.

Gdy po aktualizacji strona leży

Bez paniki — to naprawialne i zwykle szybkie:

• Biały ekran albo „krytyczny błąd” — najczęściej konflikt jednej wtyczki. Jak ją znaleźć i wyłączyć bez dostępu do panelu: krytyczny błąd na witrynie i biała strona WordPressa. A jak wrócić do poprzedniej wersji wtyczki — osobny poradnik.
• Strona wisi na komunikacie o konserwacji — aktualizację coś przerwało i został plik .maintenance: jak zdjąć tryb konserwacji. Jeśli WordPress twierdzi, że „trwa już inna aktualizacja”, w bazie została blokada.
• Błąd 500 — zajrzyj do logu serwera, tam jest prawdziwa przyczyna: jak znaleźć przyczynę błędu 500 w 15 minut.
• Nic z tego nie pomaga — przywróć kopię z kroku 0 i masz stronę sprzed aktualizacji. Właśnie po to była.

Ile czasu na to liczyć

Zadbana strona aktualizowana co miesiąc: 15–30 minut. Strona nieruszana od dwóch lat: potrafi zjeść całe popołudnie, właśnie przez skoki wersji. To dobry argument, żeby aktualizować często i małymi porcjami, a nie raz na wielkie święto.

---

Wolisz mieć to z głowy? Jednorazową aktualizację robimy od 120 zł netto/h — z kopią, testami na stagingu i sprawdzeniem strony po wszystkim. A w stałej opiece aktualizacje dzieją się co miesiąc same z siebie, razem z kopiami i monitoringiem — i to jest ta wersja, w której o tym artykule możesz zapomnieć.