WordPress po aktualizacji nie działa. Jak wrócić do działającej strony

Kliknąłeś „Aktualizuj”, a strona przestała działać. Albo nikt niczego nie klikał, a rano strona pokazuje błąd, bo w nocy zadziałała automatyczna aktualizacja. W obu przypadkach Twoje treści są na miejscu: aktualizacja zmienia kod, a wpisy, strony i zdjęcia leżą w bazie danych i folderze z mediami. Zadanie polega na ustaleniu, która zmiana zepsuła stronę, i cofnięciu tylko jej. Poniżej opisujemy kolejność działań od najprostszych, bez dostępu do plików, do przywracania kopii.

WordPress po aktualizacji nie działa: rozpoznaj objaw

Najczęstsze przyczyny

Kolejność według częstości to nasza ocena na podstawie dokumentacji WordPressa i zgłoszeń na forach wsparcia. Na konkretnej stronie może być inaczej.

1. Niezgodność wtyczki lub motywu (bardzo często). Nowa wersja wymaga nowszego PHP, nowszego WordPressa albo gryzie się z inną wtyczką.
2. Cache (często). Przeglądarka, wtyczka cache, hosting albo Cloudflare podają stare pliki stylów do nowego kodu. Strona wygląda na zepsutą, choć nie jest.
3. Wtyczka główna i jej dodatek w różnych wersjach (często przy kreatorach stron i sklepach). Główną wtyczkę zaktualizowano, a płatny dodatek nie, bo wygasła licencja.
4. Przerwana aktualizacja (czasem). Zabrakło czasu wykonania, pamięci albo miejsca na dysku i część plików jest niekompletna.
5. Nadpisane zmiany w motywie (czasem). Ktoś edytował pliki motywu bezpośrednio, bez motywu potomnego, a aktualizacja przywróciła oryginał.
6. Zmiana wersji PHP przez hosting (rzadziej, ale wygląda tak samo). Objaw pojawia się bez żadnej aktualizacji po Twojej stronie.

Zanim zaczniesz

• Zrób kopię obecnego stanu, także zepsutego. Brzmi dziwnie, ale jeśli przywracanie się nie uda, będziesz mieć do czego wrócić. A w sklepie kopia zawiera zamówienia złożone po aktualizacji.
• Sprawdź, czy masz kopię sprzed aktualizacji i z której jest godziny. Zapisz to, zanim zaczniesz. Wiele hostingów trzyma automatyczne kopie z kilku ostatnich dni.
• Nie klikaj ponownie „Aktualizuj wszystko”. Kolejne zmiany utrudniają ustalenie, która była winna.
• Przygotuj dostęp do panelu hostingu (menedżer plików lub FTP). Bez niego wykonasz tylko kroki 1 i 2.

Diagnoza i powrót krok po kroku

Krok 1. Ustal, co się zmieniło

• E-mail administratora. Po automatycznej aktualizacji wtyczek, motywów lub rdzenia WordPress wysyła wiadomość z listą zmian. Sprawdź skrzynkę i folder spam z dnia awarii.
• Kokpit → Aktualizacje, jeśli panel działa. Zobaczysz aktualną wersję WordPressa i to, co czeka na aktualizację.
• Daty folderów. W menedżerze plików hostingu otwórz wp-content/plugins i posortuj według daty modyfikacji. Foldery zmienione w momencie awarii to podejrzani.
• Panel hostingu. Sprawdź, czy hosting nie zmienił w tym czasie wersji PHP. Informację znajdziesz w ustawieniach PHP domeny albo w komunikatach hostingu.

Co powinieneś mieć po tym kroku: listę jednej lub kilku zmian z godziną. Jeśli zmieniło się tylko jedno, dalsza diagnoza jest prosta.

Krok 2. Wyczyść cache, zanim cokolwiek cofniesz

Po aktualizacji wtyczka może używać nowych plików stylów, a cache wciąż podaje stare. Wyczyść kolejno:

1. Cache wtyczki (np. „Wyczyść cache” w pasku administratora).
2. Cache hostingu, jeśli hosting ma własny (szukaj w panelu opcji cache lub LiteSpeed Cache).
3. Cloudflare: Caching → Configuration → Purge Everything.
4. Pliki kreatora stron, jeśli go używasz. Np. w Elementorze w ustawieniach narzędzi jest opcja regenerowania plików CSS i danych (nazwa zależy od wersji).

Potem otwórz stronę w oknie prywatnym przeglądarki. Co powinieneś zobaczyć: poprawny wygląd. Jeśli strona nadal jest rozjechana, zanotuj, które elementy, i przejdź do kroku 4.

Krok 3. Strona „chwilowo niedostępna”: usuń plik .maintenance

Na czas aktualizacji WordPress tworzy w głównym folderze strony plik .maintenance i pokazuje odwiedzającym komunikat o pracach konserwacyjnych. Po udanej aktualizacji usuwa plik sam. Jeśli aktualizacja się przerwała (zamknięta karta, przekroczony czas na serwerze), plik zostaje.

WordPress ignoruje ten plik, jeśli zapisany w nim czas jest starszy niż 10 minut. Dlatego najpierw odczekaj 10 minut i odśwież stronę. Jeśli komunikat nadal jest widoczny:

1. W menedżerze plików hostingu otwórz główny folder strony (ten, w którym jest wp-config.php).
2. Włącz pokazywanie plików ukrytych. Nazwa zaczynająca się od kropki oznacza plik ukryty.
3. Usuń plik .maintenance.
4. Wejdź do panelu i zaktualizuj ponownie tylko tę jedną wtyczkę lub motyw, których aktualizacja się przerwała. Niekompletne pliki to częsta przyczyna błędów w kolejnych krokach.

Jeśli komunikat wraca po każdym odświeżeniu, sprawdź, czy nie pochodzi z wtyczki trybu konserwacji (wygląda wtedy inaczej, często z logo) albo czy na serwerze nie trwa automatyczna aktualizacja. Odczekaj kilkanaście minut.

Krok 4. Błąd krytyczny: wyłącz winną wtyczkę lub motyw

Jeśli strona pokazuje komunikat o błędzie krytycznym, sprawdź e-mail administratora: WordPress wysyła tam nazwę winnej wtyczki i link do trybu odzyskiwania. Gdy e-maila nie ma, włącz dziennik błędów albo wyłącz wtyczkę, zmieniając nazwę jej folderu w wp-content/plugins (np. dopisz -wylaczona). Całą procedurę opisujemy w poradniku Błąd krytyczny na stronie WordPress.

Co powinieneś zobaczyć: strona działa, ale bez funkcji winnej wtyczki. Na tym etapie masz pewność, która zmiana zepsuła stronę. Nie zostawiaj jednak wtyczki wyłączonej na stałe, jeśli od niej zależy formularz, sklep albo bezpieczeństwo. Przejdź do kroku 5.

Krok 5. Wróć do poprzedniej wersji wtyczki lub motywu

Wtyczka z katalogu WordPress.org:

1. Otwórz stronę wtyczki na wordpress.org/plugins i przejdź do zakładki Zaawansowane (Advanced).
2. Na dole, w sekcji poprzednich wersji, wybierz wersję, która działała (zwykle tę o jeden numer niższą) i pobierz plik ZIP.
3. W panelu WordPressa wejdź w Wtyczki → Dodaj nową → Wyślij wtyczkę na serwer i wskaż pobrany plik.
4. WordPress pokaże porównanie wersji i zapyta, czy zastąpić obecną. Potwierdź.
5. W liście wtyczek wyłącz na razie automatyczne aktualizacje tej wtyczki i zapisz, dlaczego.

Jeśli masz dostęp do WP-CLI (wiele hostingów udostępnia go przez SSH), to samo zrobisz jednym poleceniem:

wp plugin install nazwa-wtyczki --version=2.4.1 --force
# nazwa-wtyczki – nazwa folderu wtyczki w wp-content/plugins
# --version     – wersja, do której wracasz
# --force       – nadpisz wersję, która jest zainstalowana teraz

Wtyczka lub motyw płatny: poprzednie wersje są zwykle do pobrania na koncie u producenta. Jeśli problemem jest niezgodność wtyczki głównej z płatnym dodatkiem, często wystarczy zaktualizować dodatek, co wymaga aktywnej licencji.

Ważne przy sklepach i dużych wtyczkach: nowa wersja mogła już zmienić strukturę bazy danych (WooCommerce prosi wtedy o „aktualizację bazy danych”). Powrót do starszej wersji samych plików może w takiej sytuacji zepsuć więcej, niż naprawi. Tu zatrzymaj się i przeczytaj sekcję „Kiedy przestać”.

Krok 6. Cofnięcie wersji WordPressa (rdzenia)

Rzadko potrzebne. Problem prawie zawsze leży we wtyczce, która nie nadąża za nową wersją, a nie w samym WordPressie. Jeśli jednak wiele wtyczek przestało działać naraz po dużej aktualizacji, a nie możesz czekać na ich poprawki:

wp core update --version=7.1.3 --force
# --version – numer wersji, która działała (sprawdź w e-mailu lub kopii)
# --force   – pozwala zainstalować wersję starszą niż obecna

Bez WP-CLI: pobierz archiwum właściwej wersji ze strony wydań WordPressa i podmień tylko foldery wp-admin i wp-includes oraz pliki w głównym folderze. Nie ruszaj folderu wp-content ani pliku wp-config.php. Traktuj to jako rozwiązanie na kilka dni, do czasu poprawek wtyczek. Starsze wersje WordPressa przestają dostawać poprawki bezpieczeństwa.

Krok 7. Przywróć kopię sprzed aktualizacji

To najpewniejsza droga, gdy zmian było dużo i nie da się wskazać jednej winnej. Przywróć pliki i bazę danych z tej samej chwili, najlepiej narzędziem hostingu albo wtyczki, którą kopia została zrobiona. Szczegóły opisujemy w artykule Kopie zapasowe: zasada 3-2-1.

Uwaga: przywrócenie bazy cofa wszystko, co zmieniło się po kopii. Na stronie firmowej to zwykle kilka wpisów lub wiadomości. W sklepie to zamówienia, konta klientów i stany magazynowe. W takiej sytuacji przywróć kopię na osobnej kopii testowej, a dane z okresu po kopii przenieś ręcznie albo poproś o pomoc.

Co WordPress robi sam, a czego nie

• Od wersji 6.3: jeśli instalacja aktualizacji wtyczki lub motywu nie powiedzie się (np. zabraknie miejsca), WordPress przywraca poprzednią wersję z kopii tymczasowej.
• Od wersji 6.6: po automatycznej aktualizacji wtyczki WordPress sprawdza stronę główną zapytaniem do samego siebie. Jeśli wykryje błąd krytyczny, cofa aktualizację i wysyła e-mail do administratora. Przy kolejnym sprawdzeniu aktualizacji spróbuje ponownie.
• Czego to nie obejmuje: aktualizacji klikniętych ręcznie, błędów widocznych tylko na podstronach, w koszyku lub w panelu, zepsutego wyglądu i funkcji, które przestały działać bez błędu krytycznego. Dlatego kontrola strony po aktualizacji nadal jest potrzebna.

Kiedy przestać i poprosić o pomoc

• Sklep z zamówieniami po kopii albo przerwana aktualizacja bazy danych WooCommerce lub innej dużej wtyczki.
• Nie masz kopii sprzed aktualizacji, a cofnięcie wtyczki nie pomaga.
• Po aktualizacji widzisz obce treści, przekierowania lub nieznane konta administratorów. To nie jest skutek aktualizacji, tylko możliwe włamanie. Zobacz WordPress po włamaniu: pierwsze 24 godziny.
• Nie możesz zalogować się do panelu mimo działającej strony. Zobacz Nie mogę zalogować się do WordPressa.
• Problem wraca przy każdej próbie aktualizacji, a autor wtyczki nie odpowiada. Wtedy trzeba zdecydować o zamienniku.

Jak zapobiegać

• Kopia przed każdą większą aktualizacją, ze sprawdzeniem, że się zakończyła.
• Aktualizacje po kolei, nie wszystkie naraz, jeśli to duże wersje. Łatwiej wskazać winowajcę.
• Duże wersje WordPressa po kilku dniach od wydania, gdy autorzy wtyczek zdążą wydać poprawki.
• Kopia testowa (staging) dla stron z rezerwacjami, sklepem lub kreatorem stron. Wiele hostingów tworzy ją jednym kliknięciem.
• Kontrola po aktualizacji: strona główna, menu, strona usługi, formularz (wyślij próbną wiadomość, zobacz WordPress nie wysyła maili) i widok na telefonie.
• Aktywne licencje płatnych wtyczek i zmiany w motywie tylko w motywie potomnym.

Rytm aktualizacji i to, co warto włączyć automatycznie, opisujemy w artykule Aktualizacje WordPressa i wtyczek.

Źródła

• WordPress Developer Resources: wp_is_maintenance_mode() (plik .maintenance i reguła 10 minut) (dostęp: 10.11.2026)
• Make WordPress Core: Merge Proposal: Rollback Auto-Update (cofanie automatycznych aktualizacji wtyczek) (dostęp: 10.11.2026)
• Make WordPress Core: wpisy z tagiem Rollback (przywracanie po nieudanej aktualizacji, WordPress 6.3) (dostęp: 10.11.2026)
• WordPress.org Documentation: Plugins & Themes Auto-Updates (dostęp: 10.11.2026)
• WP-CLI: wp plugin install i wp core update (dostęp: 10.11.2026)
• WordPress.org: Releases (archiwum wersji) (dostęp: 10.11.2026)