Jak naprawić stronę na WordPressie? Sprawdzone sposoby

Data publikacji: 17 sierpnia 2026

Awaria strony na WordPressie potrafi wyglądać groźnie: zamiast witryny pojawia się biały ekran, komunikat o błędzie krytycznym, kod 500 albo informacja o problemie z połączeniem z bazą danych. Czasem strona działa, ale nie można wejść do panelu administracyjnego. Innym razem wszystko psuje się tuż po aktualizacji wtyczki, motywu lub samego WordPressa.

Najważniejsze jest, aby nie wykonywać wielu przypadkowych zmian naraz. Dobra naprawa polega na zabezpieczeniu danych, ustaleniu objawu, sprawdzeniu ostatnich zmian i testowaniu jednej hipotezy po drugiej. Dzięki temu łatwiej przywrócisz stronę i nie zatrzesz śladów potrzebnych do znalezienia przyczyny.

Kluczowe wnioski

• Przed naprawą wykonaj kopię plików i bazy danych, nawet jeśli strona już nie działa.
• Zacznij od sprawdzenia zasięgu awarii i zapisania dokładnego komunikatu oraz kodu błędu.
• Jeśli problem pojawił się po aktualizacji, najpierw podejrzewaj ostatnio zmienioną wtyczkę, motyw lub wersję PHP.
• Logi serwera i plik debug.log zwykle mówią więcej niż sam komunikat o błędzie krytycznym.
• Po przywróceniu strony sprawdź formularze, logowanie, koszyk, płatności i zadania cykliczne, a nie tylko stronę główną.

Najpierw zabezpiecz stronę i zbierz informacje

Zanim zaczniesz wyłączać wtyczki albo podmieniać pliki, zrób kopię obecnego stanu. Potrzebujesz kopii wszystkich plików WordPressa oraz eksportu bazy danych. Możesz wykonać je w panelu hostingu, przez SFTP lub SSH oraz w narzędziu do obsługi bazy udostępnionym przez dostawcę hostingu.

Kopia uszkodzonej strony również jest cenna. Zawiera logi, konfigurację i pliki, które mogą pomóc ustalić przyczynę. Pozwala też wycofać nieudaną próbę naprawy. Nie nadpisuj jedynego działającego backupu nową kopią i przed przywróceniem upewnij się, że obejmuje on zarówno pliki, jak i bazę danych z właściwego dnia.

Zapisz też podstawowe informacje:

• dokładny komunikat widoczny w przeglądarce,
• adres podstrony, na której występuje problem,
• godzinę pierwszego wystąpienia awarii,
• ostatnie aktualizacje i zmiany konfiguracji,
• informację, czy działa panel /wp-admin,
• wersję PHP oraz WordPressa,
• kod odpowiedzi HTTP, jeśli jest dostępny.

Sprawdź stronę w innej przeglądarce, w trybie prywatnym i przez inną sieć. Możesz też skontrolować jej dostępność z zewnątrz za pomocą ping.pl. Jeśli witryna działa z innych lokalizacji, przyczyną może być lokalny cache, DNS, rozszerzenie przeglądarki lub blokada adresu IP, a nie sam WordPress.

Sprawdź, co zmieniło się przed awarią

Awaria występująca bezpośrednio po konkretnej zmianie jest ważną wskazówką. Przypomnij sobie, czy tuż wcześniej została zaktualizowana wtyczka, motyw, WordPress albo PHP. Problem może też pojawić się po instalacji nowego dodatku, zmianie ustawień cache, migracji strony, wgraniu własnego kodu lub automatycznej aktualizacji wykonanej w nocy.

Jeżeli masz środowisko testowe, odtwórz na nim tę samą zmianę. Przy stronie produkcyjnej wycofuj tylko jeden element naraz i po każdym kroku sprawdzaj rezultat. Masowe aktualizowanie, usuwanie oraz przywracanie wielu składników jednocześnie może przywrócić witrynę przypadkiem, ale nie pokaże, co faktycznie ją zepsuło.

Skorzystaj z trybu odzyskiwania WordPressa

Gdy WordPress wykryje krytyczny błąd PHP, może wysłać na adres administratora wiadomość z linkiem do trybu odzyskiwania. Specjalny link pozwala zalogować się do panelu, mimo że zwykli użytkownicy nadal widzą komunikat o awarii. W panelu można sprawdzić, który motyw lub wtyczka wywołuje problem, a następnie tymczasowo go wyłączyć.

Jeśli wiadomość nie dotarła, sprawdź spam oraz adres administracyjny zapisany w WordPressie. Brak e-maila nie oznacza, że naprawa jest niemożliwa. Wtyczkę można wyłączyć także przez zmianę nazwy jej katalogu, a błędy odczytać z logów hostingu.

Wyłącz wadliwą wtyczkę

Konflikt lub błąd wtyczki to jedna z najczęstszych przyczyn awarii WordPressa. Jeżeli panel administracyjny działa, wyłącz dodatek zainstalowany albo zaktualizowany tuż przed wystąpieniem problemu. Następnie sprawdź stronę w nowej karcie.

Gdy nie możesz wejść do panelu, połącz się z plikami strony i przejdź do katalogu wp-content/plugins. Zmień nazwę katalogu podejrzanej wtyczki, na przykład z nazwa-wtyczki na nazwa-wtyczki-disabled. WordPress przestanie ją ładować, ale pliki pozostaną na serwerze. Jeśli nie wiesz, który dodatek jest winny, możesz tymczasowo zmienić nazwę całego katalogu plugins, sprawdzić stronę, a potem przywracać dodatki pojedynczo.

Po znalezieniu sprawcy nie włączaj od razu tej samej wersji. Sprawdź, czy dostępna jest poprawka, czy wtyczka obsługuje używaną wersję WordPressa i PHP oraz czy jej funkcję można tymczasowo zastąpić innym rozwiązaniem. Przed usunięciem dodatku sprawdź też, czy nie przechowuje własnych danych lub ustawień potrzebnych stronie.

Przełącz stronę na domyślny motyw

Motyw może powodować awarię po aktualizacji, zmianie PHP lub edycji pliku functions.php. Aby go wykluczyć, przełącz stronę na jeden z zainstalowanych, domyślnych motywów WordPressa. Jeżeli panel nie działa, możesz tymczasowo zmienić nazwę katalogu aktywnego motywu w wp-content/themes.

Na serwerze powinien znajdować się sprawny motyw zastępczy. Jeśli po przełączeniu strona zaczyna odpowiadać, problem leży najpewniej w motywie nadrzędnym, motywie potomnym lub dodanym do niego kodzie. Porównaj zmienione pliki z czystą wersją, sprawdź ostatnie modyfikacje i komunikaty w logach. Nie naprawiaj motywu bezpośrednio na produkcji, jeśli możesz skopiować stronę do środowiska testowego.

Włącz logowanie błędów na czas diagnozy

Komunikat „Wystąpił błąd krytyczny” informuje o skutku, ale nie wskazuje konkretnej linii kodu. Szczegóły można znaleźć w logach PHP i serwera WWW dostępnych w panelu hostingu. Na czas diagnozy można też włączyć logowanie WordPressa w pliku wp-config.php:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Po ponownym wywołaniu błędu wpisy powinny pojawić się w wp-content/debug.log. Szukaj komunikatów Fatal error, Uncaught Error, Allowed memory size exhausted oraz ścieżek prowadzących do konkretnej wtyczki lub motywu. Ostrzeżenie czy informacja o przestarzałej funkcji nie zawsze jest bezpośrednią przyczyną awarii, dlatego zwracaj uwagę na czas wpisu i kolejność zdarzeń.

Po zakończeniu diagnozy wyłącz debugowanie. Log może zawierać ścieżki serwera i inne dane techniczne, a pozostawiony bez kontroli potrafi szybko urosnąć. Nie ustawiaj WP_DEBUG_DISPLAY na true w działającej witrynie publicznej, ponieważ szczegóły błędów mogłyby zostać pokazane odwiedzającym.

Sprawdź wersję PHP, limity i zasoby hostingu

Po zmianie wersji PHP stara wtyczka albo motyw może zacząć zgłaszać błąd składni lub wywoływać usuniętą funkcję. Z kolei zbyt stara wersja PHP może nie spełniać wymagań nowej wersji dodatku. Porównaj wymagania wszystkich kluczowych składników i wybierz wersję obsługiwaną przez cały zestaw.

Jeśli awaria pojawiła się natychmiast po zmianie PHP, tymczasowy powrót do poprzedniej, bezpiecznej wersji może przywrócić dostęp. Jest to jednak rozwiązanie przejściowe. Docelowo zaktualizuj lub zastąp niezgodny składnik, ponieważ utrzymywanie niewspieranej wersji PHP zwiększa ryzyko bezpieczeństwa.

W logach mogą pojawić się także informacje o wyczerpaniu pamięci, przekroczeniu czasu wykonywania albo limitu procesów. Sprawdź użycie CPU, RAM, operacji dyskowych, liczbę procesów i wolne miejsce na koncie hostingowym. Samo zwiększenie limitu pamięci może ukryć źle działającą wtyczkę, dlatego po przywróceniu strony nadal trzeba znaleźć proces zużywający zasoby.

Napraw błąd połączenia z bazą danych

Komunikat o błędzie nawiązywania połączenia z bazą danych oznacza, że WordPress nie może odczytać treści i ustawień. Otwórz wp-config.php i sprawdź wartości DB_NAME, DB_USER, DB_PASSWORD oraz DB_HOST. Po migracji lub zmianie hasła dane w pliku mogą nie zgadzać się z konfiguracją konta hostingowego.

Jeśli dane są poprawne, sprawdź w panelu hostingu, czy serwer bazy działa, czy konto nie osiągnęło limitu i czy baza nie została uszkodzona. Zwróć uwagę na wolne miejsce na dysku. Pełny dysk może uniemożliwić zapis danych, tworzenie plików tymczasowych i prawidłowe działanie wielu usług naraz.

Nie wykonuj przypadkowych poleceń SQL na produkcji. Przed naprawą tabel zrób eksport bazy, a jeśli nie masz doświadczenia, skorzystaj z narzędzia udostępnionego przez hosting lub poproś jego obsługę o weryfikację usługi.

Odbuduj plik .htaccess i reguły adresów

Uszkodzony .htaccess może powodować błąd 500, pętlę przekierowań albo niedziałające podstrony, mimo że strona główna się otwiera. W katalogu głównym WordPressa zmień nazwę pliku na przykład na .htaccess-old, a następnie sprawdź witrynę.

Jeśli panel administracyjny działa, przejdź do ustawień bezpośrednich odnośników i zapisz je ponownie bez zmiany wybranej struktury. WordPress spróbuje utworzyć poprawne reguły. Pamiętaj jednak, że .htaccess może zawierać również ustawienia bezpieczeństwa, cache, przekierowania lub konfigurację dodaną przez hosting. Nie usuwaj starego pliku, dopóki nie porównasz jego zawartości i nie odtworzysz potrzebnych reguł.

Wyczyść cache na wszystkich poziomach

Po naprawie możesz nadal widzieć starą wersję strony albo ten sam błąd. Cache bywa przechowywany w przeglądarce, wtyczce WordPressa, na serwerze, w CDN i u operatora reverse proxy. Wyczyść pamięć podręczną w używanych warstwach, a potem sprawdź stronę w trybie prywatnym.

Nie zakładaj jednak, że cache jest przyczyną każdej awarii. Jeśli serwer zwraca błąd 500 lub log zawiera krytyczny błąd PHP, czyszczenie pamięci podręcznej nie zastąpi naprawy kodu. Cache warto czyścić po usunięciu właściwej przyczyny lub wtedy, gdy różni użytkownicy widzą niespójne wersje witryny.

Przywróć kopię zapasową, gdy naprawa trwa zbyt długo

Przywrócenie sprawdzonego backupu jest często najszybszą metodą odzyskania dostępności. Ma to szczególne znaczenie w sklepie lub serwisie obsługującym klientów. Zanim rozpoczniesz, ustal, z której godziny pochodzi kopia oraz jakie dane powstały później. Przywrócenie starej bazy może usunąć nowe zamówienia, konta, komentarze i zmiany treści.

Najbezpieczniej odtworzyć backup najpierw w środowisku testowym i potwierdzić, że działa. Jeżeli musisz przywrócić stronę produkcyjną, zachowaj kopię obecnych plików i bazy. Po odtworzeniu nie kończ pracy: ustal przyczynę awarii, zanim ponownie wykonasz tę samą aktualizację.

Co zrobić, gdy podejrzewasz włamanie

Nietypowe przekierowania, nowe konta administratorów, zmienione pliki, wysyłka spamu i ostrzeżenia przeglądarki mogą oznaczać infekcję, a nie zwykły konflikt wtyczek. Samo usunięcie widocznego pliku albo przywrócenie strony głównej nie daje pewności, że napastnik stracił dostęp.

W takiej sytuacji:

1. Ogranicz publiczny dostęp do zainfekowanej witryny.
2. Zabezpiecz kopię plików, bazy oraz logów do analizy.
3. Zmień hasła do hostingu, SFTP, bazy, WordPressa i skrzynek administratorów.
4. Sprawdź konta użytkowników, klucze w wp-config.php i zadania cykliczne.
5. Podmień pliki systemowe, motywy i wtyczki na czyste kopie z zaufanych źródeł.
6. Usuń nieużywane dodatki i zaktualizuj wszystkie wspierane składniki.
7. Sprawdź inne strony działające na tym samym koncie hostingowym.

Jeśli strona przechowuje dane klientów albo obsługuje płatności, warto zaangażować specjalistę od reagowania na incydenty. Trzeba nie tylko przywrócić działanie, lecz także określić zakres naruszenia i zamknąć drogę ponownego wejścia.

Lista kontrolna po naprawie WordPressa

Otwierająca się strona główna to dopiero początek testów. Po naprawie sprawdź:

• logowanie i wylogowanie użytkownika,
• panel administracyjny oraz edycję treści,
• formularze kontaktowe i dostarczanie wiadomości,
• wyszukiwarkę, menu i najważniejsze podstrony,
• koszyk, płatność i wiadomości transakcyjne w sklepie,
• wyświetlanie strony na telefonie,
• zadania zaplanowane i automatyczne kopie,
• certyfikat SSL oraz przekierowanie z HTTP na HTTPS,
• logi pod kątem nowych błędów,
• szybkość odpowiedzi i użycie zasobów hostingu.

Warto też zapisać przyczynę, wykonane kroki i wersję wadliwego składnika. Taka krótka dokumentacja przyspieszy reakcję, jeśli podobna awaria wystąpi ponownie.

Jak zapobiegać kolejnym awariom

Regularnie aktualizuj WordPressa, motywy i wtyczki, ale większe zmiany najpierw sprawdzaj w środowisku testowym. Utrzymuj automatyczne kopie plików i bazy w lokalizacji niezależnej od głównego serwera oraz okresowo testuj ich odtwarzanie. Nieużywane dodatki usuwaj, a nie tylko wyłączaj.

Włącz monitoring dostępności, certyfikatu SSL i kluczowych procesów. Sam kod 200 na stronie głównej nie wystarczy, jeśli formularz nie wysyła wiadomości albo sklep nie przyjmuje płatności. Przed aktualizacją zapisz listę wersji, a po wdrożeniu wyczyść cache, wykonaj testy i obserwuj logi.

Podsumowanie

Naprawę WordPressa zacznij od kopii zapasowej i dokładnego rozpoznania objawu. Potem sprawdź ostatnie zmiany, tryb odzyskiwania, wtyczki, motyw, logi, wersję PHP, zasoby hostingu, bazę danych oraz reguły .htaccess. Zmieniaj tylko jeden element naraz i po każdym kroku kontroluj rezultat.

Jeśli szybka diagnoza nie przynosi efektu, przywróć zweryfikowany backup, aby ograniczyć czas niedostępności, a przyczynę badaj na kopii testowej. Po naprawie wykonaj pełne testy funkcjonalne i usuń źródło problemu. Dzięki temu witryna nie tylko zacznie się otwierać, ale rzeczywiście wróci do bezpiecznego, stabilnego działania.