Naprawa WordPress

WordPress nie działa po aktualizacji: co robić?

WordPress nie działa po aktualizacji? Zabezpiecz stan, sprawdź Recovery Mode, ustal zakres awarii i zdecyduj, czy cofnąć zmianę, czy ją naprawić.

Opublikowano 31 lipca 2026 · 13 min czytania · Opracowanie: PanWWW

Jeśli WordPress przestał działać po aktualizacji, nie uruchamiaj od razu kolejnych aktualizacji i nie usuwaj przypadkowych plików. Najpierw zapisz godzinę zmiany, objawy i ostatnie wykonane działania. Następnie zabezpiecz bieżący stan, sprawdź pocztę administratora pod kątem Recovery Mode i ustal, czy problem dotyczy całej strony, panelu czy jednej funkcji. Cofnięcie zmiany ma sens tylko wtedy, gdy znasz poprzednią wersję i masz pewne źródło plików lub kopię.

Najważniejsze wnioski

Aktualizacja może ujawnić konflikt, który wcześniej pozostawał niewidoczny. Nie zawsze oznacza to błąd samego WordPressa.
Pierwsza decyzja to ograniczenie szkody, a nie szukanie najszybszej wtyczki naprawczej.
Bieżący stan warto zachować nawet wtedy, gdy strona jest uszkodzona. Może zawierać dane potrzebne do diagnozy.
Recovery Mode pomaga wejść do panelu po określonych błędach PHP, ale nie zastępuje kopii ani analizy.
Rollback jest bezpieczniejszy, gdy dotyczy jednej znanej zmiany i jest poprzedzony kopią.
Po przywróceniu widoku trzeba sprawdzić formularz, płatności, logowanie i źródło problemu, nie tylko stronę główną.

Pierwsze 15 minut po awarii

Zacznij od zebrania faktów. Nie próbuj jeszcze kilku rozwiązań naraz.

Zapisz dokładną godzinę aktualizacji i moment zauważenia problemu.
Wymień aktualizowane elementy: rdzeń, wtyczka, motyw, tłumaczenie albo środowisko serwera.
Zrób zrzut komunikatu i skopiuj jego treść.
Sprawdź stronę w zwykłym oknie i trybie prywatnym.
Sprawdź panel logowania oraz najważniejszą podstronę.
Otwórz pocztę przypisaną do konta administratora.
Ustal, czy działa hosting, domena i certyfikat.
Powstrzymaj kolejne osoby przed równoległym wprowadzaniem zmian.

Ta lista tworzy punkt odniesienia. Jeśli po pięciu kolejnych próbach nie wiadomo już, co było pierwszą zmianą, naprawa staje się dłuższa i mniej przewidywalna.

Jakiego rodzaju problem widzisz

Hasło „strona nie działa” może oznaczać kilka różnych sytuacji. Rozpoznanie objawu pomaga wybrać bezpieczny pierwszy test.

Objaw	Możliwy obszar	Pierwsza kontrola
Biały ekran lub błąd krytyczny	PHP, wtyczka, motyw lub pamięć	Recovery Mode, wiadomość administratora i log błędu
Błąd 500	Serwer, PHP, reguły lub kod	Log serwera i zakres ostatniej zmiany
Strona działa, panel nie	Logowanie, uprawnienia, wtyczka lub sesja	Inne konto, tryb prywatny i stan hostingu
Rozsypany wygląd	Motyw, cache, CSS lub zasoby	Wyczyść bezpiecznie cache i sprawdź błędy zasobów
Formularz przestał wysyłać	Wtyczka formularza, poczta lub integracja	Test wysyłki i log dostarczenia
Sklep nie kończy zamówienia	WooCommerce, płatność, sesja lub JavaScript	Próbne zamówienie w kontrolowanych warunkach
Jedna podstrona zwraca błąd	Szablon, blok, dane lub konkretny moduł	Porównanie z inną podstroną tego samego typu
Strona jest bardzo wolna	Zadanie w tle, cache, baza lub nowy kod	Obciążenie serwera i ostatnio zmieniony komponent

Jeżeli widzisz pusty ekran, skorzystaj równolegle z bardziej szczegółowej procedury biały ekran WordPress: bezpieczna diagnoza. Ten poradnik obejmuje szerszą sytuację, w której aktualizacja pogorszyła dowolną ważną funkcję.

Co mogło zostać zaktualizowane

WordPress to nie jeden program. Strona składa się z kilku współpracujących warstw, co wyjaśniamy w materiale WordPress: co to jest i kiedy ma sens.

Po awarii ustal, czy zmienił się:

rdzeń WordPressa,
jedna lub kilka wtyczek,
motyw albo motyw potomny,
tłumaczenie,
wersja PHP,
konfiguracja hostingu,
reguły cache,
ustawienia bezpieczeństwa,
plik konfiguracyjny,
integracja z usługą zewnętrzną.

Aktualizacja jednego elementu może ujawnić problem w innym. Na przykład nowa wersja PHP może przestać tolerować stary kod w motywie. Aktualizacja wtyczki może zacząć korzystać z funkcji, której nie obsługuje środowisko. Zmiana motywu może nadpisać dostosowanie wykonane bez motywu potomnego.

Nie zakładaj więc, że ostatni zaktualizowany komponent jest automatycznie winny. Jest pierwszym kandydatem do testu, nie gotową diagnozą.

Recovery Mode: kiedy pomaga

WordPress może wysłać na adres administratora wiadomość z linkiem do trybu odzyskiwania, gdy wykryje określony błąd krytyczny PHP. Oficjalna dokumentacja opisuje to jako Recovery Mode.

Po wejściu przez bezpieczny link panel może wskazać komponent powodujący błąd i pozwolić na kontrolowane działanie. Sprawdź:

czy wiadomość rzeczywiście pochodzi z Twojej domeny,
jakiego elementu dotyczy,
kiedy link został wygenerowany,
czy po wejściu widzisz komunikat trybu odzyskiwania,
czy można wykonać kopię przed wyłączeniem elementu.

Brak wiadomości nie oznacza, że problem nie istnieje. Poczta może trafiać do spamu, adres administratora może być nieaktualny, a rodzaj awarii może nie uruchamiać Recovery Mode.

Nie wysyłaj publicznie linku odzyskiwania. Traktuj go jak czasowy dostęp administracyjny.

Zabezpiecz bieżący stan przed naprawą

Uszkodzona instalacja nadal jest materiałem dowodowym. Może zawierać bieżące zamówienia, wiadomości, logi i dokładny stan plików po aktualizacji.

Przed rollbackiem lub ręczną zmianą wykonaj, jeśli jest to bezpieczne:

kopię plików,
eksport bazy danych,
kopię logów serwera i aplikacji,
listę aktywnych wtyczek i ich wersji,
zrzut informacji o środowisku,
zapis aktualnej konfiguracji DNS i hostingu, jeśli problem może być szerszy.

Nazwij kopię datą oraz dopiskiem „stan po awarii”. Nie nadpisuj ostatniej zdrowej kopii.

Jeżeli podejrzewasz przejęcie strony, standardowa procedura aktualizacji może być niewystarczająca. Użyj planu z poradnika bezpieczeństwo WordPressa dla firmy i zabezpiecz także hosting, domenę oraz pocztę.

Kopia zapasowa czy rollback komponentu

To dwie różne operacje.

Przywrócenie pełnej kopii cofa pliki i bazę do określonego momentu. Może usunąć zamówienia, formularze lub zmiany treści wykonane po tej dacie.

Rollback komponentu przywraca poprzednią wersję jednej wtyczki, motywu lub rdzenia. Ogranicza zakres, ale wymaga zgodności z bazą i innymi elementami.

Przed decyzją odpowiedz:

Kiedy powstała ostatnia zdrowa kopia?
Jakie dane pojawiły się od tego czasu?
Czy aktualizacja zmieniła strukturę bazy?
Czy znasz dokładną poprzednią wersję?
Czy pliki pochodzą z zaufanego źródła?
Czy można najpierw odtworzyć problem w środowisku testowym?
Czy cofana wersja nie zawiera znanej luki bezpieczeństwa?

Rollback nie powinien polegać na pobraniu przypadkowego archiwum z forum. Użyj kopii lub oficjalnego źródła producenta.

Drzewo decyzji po aktualizacji

Strona działa, ale jedna funkcja nie

Nie przywracaj od razu całej instalacji. Zabezpiecz stan i odtwórz problem na konkretnej ścieżce. Sprawdź konsolę przeglądarki, żądania sieciowe, logi i zależność od aktualizowanego komponentu.

Przykład: jeśli nie działa formularz, przetestuj samo wysłanie, dostarczenie wiadomości, walidację i zgodę. Zielona strona główna nie mówi nic o tej funkcji.

Panel działa w Recovery Mode

Zapisz wskazany komponent. Wykonaj kopię, a następnie wyłącz tylko element powiązany z błędem, jeśli znasz skutek. Sprawdź stronę publiczną oraz funkcje zależne.

Nie usuwaj od razu danych wtyczki. Wyłączenie jest odwracalne, usunięcie ustawień może nie być.

Nie działa panel, ale działa dostęp do hostingu

Zbierz logi i kopię. Doświadczona osoba może czasowo wyłączyć konkretny komponent na poziomie plików, ale taka operacja powinna być zapisana i wykonana na właściwej instalacji. Przy kilku podobnych katalogach łatwo zmienić środowisko testowe zamiast produkcyjnego albo odwrotnie.

Nie działa także hosting lub domena

To może nie być problem WordPressa. Sprawdź status dostawcy, DNS, wygaśnięcie domeny, certyfikat i komunikaty konta. Aktualizacja mogła zbiec się czasowo z niezależną awarią.

Sklep lub system rezerwacji przyjmuje dane

Ogranicz publiczne transakcje, jeśli nie masz pewności, że proces jest spójny. Zachowaj zamówienia i nie przywracaj starszej bazy bez planu przeniesienia nowych danych. Taka strona wymaga ostrożniejszej procedury niż witryna informacyjna.

Jak diagnozować bez ujawniania błędów klientom

WordPress ma mechanizmy debugowania opisane w oficjalnym przewodniku Debugging in WordPress. Na stronie publicznej błędy nie powinny być wyświetlane wszystkim odwiedzającym, bo mogą ujawniać ścieżki, nazwy plików lub szczegóły środowiska.

Bezpieczniejszy proces to:

zapis błędów do kontrolowanego logu,
odtworzenie problemu w określonym czasie,
powiązanie wpisu z konkretnym działaniem,
test jednej hipotezy,
zapis wyniku,
wyłączenie diagnostyki po zakończeniu.

Log z tysiącami starych ostrzeżeń może być mylący. Zacznij od czasu awarii i pierwszego powtarzalnego błędu, który zatrzymuje działanie.

Cache po aktualizacji

Po zmianie kodu przeglądarka, wtyczka cache, serwer lub CDN mogą nadal podawać starszą wersję zasobów. Objawem bywa rozsypany wygląd mimo poprawnego panelu.

Cache czyść warstwami i po każdej zmianie sprawdzaj rezultat:

tryb prywatny lub inna przeglądarka,
cache konkretnej strony w WordPressie,
cache serwera,
CDN,
service worker, jeśli jest używany.

Nie używaj czyszczenia jako uniwersalnej naprawy. Jeśli formularz zwraca błąd serwera, problem najpewniej wymaga innej diagnozy. Zapisz też, który cache został wyczyszczony, aby nie powtarzać tej samej próby.

Kiedy cofnąć zmianę

Rollback jest rozsądny, gdy:

problem pojawił się bezpośrednio po jednej znanej aktualizacji,
dostępna jest poprzednia, zaufana wersja,
bieżący stan został zabezpieczony,
znasz wpływ na bazę danych,
przywrócenie funkcji jest ważniejsze niż natychmiastowa analiza,
można później odtworzyć problem w środowisku testowym.

Nie cofaj bez dodatkowej oceny, gdy:

aktualizacja zamykała krytyczną lukę,
od kopii powstały ważne dane,
kilka elementów zmieniło się jednocześnie,
nie wiadomo, która wersja była wcześniej,
instalacja może być zainfekowana,
producent nie wspiera starej wersji,
cofnięcie wymaga mieszania plików z różnych źródeł.

Czasem bezpieczniejsze jest szybkie wyłączenie jednej funkcji i przygotowanie poprawki niż pełne cofnięcie strony.

Co sprawdzić po przywróceniu widoku

Nie kończ naprawy, gdy otworzy się strona główna. Przejdź przez listę:

logowanie i wylogowanie,
menu na telefonie,
najważniejsze podstrony,
formularz wraz z dostarczeniem wiadomości,
płatność lub rezerwację w kontrolowanym teście,
konto klienta, jeśli występuje,
wyszukiwanie i filtry,
wersje językowe,
obrazy oraz pliki,
przekierowania,
błędy w logach,
wydajność najważniejszej ścieżki,
kopię po naprawie.

Jeżeli strona zaczęła działać, ale wyraźnie zwolniła, użyj metody z poradnika PageSpeed: co mierzy i co poprawić najpierw. Nie optymalizuj jednak wydajności przed przywróceniem stabilności.

Zamknij przyczynę, nie tylko objaw

Po awarii zapisz krótką notatkę:

Pytanie	Przykład odpowiedzi
Co się zmieniło?	Aktualizacja konkretnej wtyczki z wersji A do B
Jaki był objaw?	Błąd przy wysyłaniu formularza
Co potwierdziło przyczynę?	Odtworzenie w środowisku testowym i wpis w logu
Jak przywrócono działanie?	Kontrolowany rollback jednej wtyczki
Co zapobiegnie powtórce?	Test aktualizacji na stagingu i kontrola formularza
Co nadal wymaga działania?	Aktualizacja po wydaniu poprawionej wersji

Taka notatka oszczędza czas przy kolejnej zmianie i pokazuje, czy awarie mają wspólne źródło.

Procedura aktualizacji na przyszłość

Oficjalna instrukcja Updating WordPress zaleca wykonanie kopii przed aktualizacją. Dla strony firmowej dodaj do tego test najważniejszej ścieżki.

Praktyczny cykl:

przejrzyj zakres aktualizacji,
sprawdź zgodność środowiska,
wykonaj i oznacz kopię,
przetestuj na stagingu, jeśli zmiana jest istotna,
aktualizuj możliwie mały zestaw,
sprawdź stronę publiczną oraz panel,
wykonaj realny test formularza lub zakupu,
przejrzyj świeże błędy,
zapisz wersje i wynik,
monitoruj stronę po zmianie.

Strona nie musi mieć rozbudowanego działu technicznego, ale procedura powinna mieć właściciela. Jeśli aktualizacje wykonują różne osoby bez wspólnego rejestru, trudno ustalić, co naprawdę się zmieniło.

Stała opieka nad stroną internetową ma sens wtedy, gdy obejmuje kopie, kontrolowane zmiany, monitoring i odpowiedzialność za reakcję, a nie tylko automatyczne kliknięcie „aktualizuj”.

Jakie informacje przekazać osobie naprawiającej

Przygotuj jedną wiadomość zawierającą:

adres strony,
dokładny objaw,
godzinę wystąpienia,
miejsce, w którym problem jest widoczny,
ostatnie aktualizowane elementy,
pełny komunikat błędu,
dostępność panelu i Recovery Mode,
informację o kopii,
dane o hostingu i wersji PHP,
zmiany wykonane już po awarii,
priorytet biznesowy, na przykład niedziałające zamówienia.

Nie wysyłaj haseła w zwykłej wiadomości. Utwórz czasowe konto lub użyj bezpiecznego sposobu przekazania dostępu. Po zakończeniu usuń niepotrzebne konto.

Jeżeli nie masz pewności, czy kolejne działanie jest odwracalne, opisz objawy i skontaktuj się z PanWWW. Najpierw można ustalić zakres diagnozy, zanim cokolwiek zostanie zmienione na stronie.