Błędy WordPress - jak rozpoznać błąd po objawie i go naprawić

Większość błędów WordPressa ma kilka tych samych źródeł: wtyczka albo motyw, które się ze sobą gryzą, za mało zasobów na serwerze, uszkodzony plik konfiguracyjny, baza danych albo coś po stronie hostingu. Dlatego naprawa prawie zawsze zaczyna się tak samo. Zapisujesz, co dokładnie widzisz, robisz kopię i dopiero wtedy szukasz przyczyny, od najprostszej do najbardziej kosztownej.

Ten tekst to mapa. Nie znasz nazwy błędu? Nie szkodzi. Szukasz po tym, co widzisz na ekranie: biały ekran, komunikat o błędzie krytycznym, strona nie istnieje, zamówienia nie zmieniają statusu. Przy każdym objawie masz najczęstszą przyczynę, pierwszy bezpieczny ruch i odnośnik do szczegółowego poradnika.

Piszę z perspektywy kogoś, kto takie zgłoszenia dostaje od klientów: od wizytówek po sklepy WooCommerce z ruchem. Procedury z dokumentacji WordPressa sprawdziłem 22.10.2026, a przykłady z praktyki są opisane bez nazw klientów.

Zanim cokolwiek zmienisz - pięć minut, które oszczędzają godziny

Bez tych informacji naprawa zamienia się w zgadywanie. Zanim klikniesz cokolwiek, zrób te pięć rzeczy:

1. Zapisz objaw dokładnie. Treść komunikatu (najlepiej zrzut ekranu), adres strony, na której błąd występuje, godzina. „Strona nie działa” to za mało. „Po kliknięciu Zamów pojawia się biały ekran” to już trop.
2. Sprawdź, kogo to dotyczy. Otwórz stronę jako zalogowany administrator, jako niezalogowany gość i w oknie incognito. Różnica między tymi trzema widokami to najczęstsze miejsce, w którym chowa się awaria.
3. Przypomnij sobie ostatnią zmianę. Aktualizacja, nowa wtyczka, wklejony fragment kodu, zmiana hostingu albo ustawień Cloudflare. Błąd, który pojawił się zaraz po zmianie, prawie zawsze ma z nią związek.
4. Zajrzyj na skrzynkę administratora. Przy błędzie krytycznym WordPress sam wysyła maila z opisem problemu i linkiem do trybu odzyskiwania (więcej niżej).
5. Zrób kopię zapasową, zanim zaczniesz coś zmieniać. Jak ją zrobić i gdzie trzymać, opisałem w poradniku o kopiach zapasowych WordPress.

Mapa błędów WordPress - objaw, przyczyna i pierwszy ruch

Co widzisz	Co to zwykle oznacza	Pierwszy bezpieczny ruch	Szczegóły
„W witrynie wystąpił błąd krytyczny.”	błąd PHP we wtyczce, motywie albo wklejonym kodzie	mail od WordPressa i tryb odzyskiwania	sekcja niżej i poradnik o błędzie krytycznym
biały ekran bez żadnego komunikatu	błąd PHP przy wyłączonym wyświetlaniu błędów, często brak pamięci	debug.log, potem wtyczki i motyw	sekcja niżej
błąd 500 (Internal Server Error)	uszkodzony .htaccess, wtyczka, limit pamięci	log serwera; na Apache albo LiteSpeed kopia i zmiana nazwy .htaccess	poradnik o błędzie 500 i 503
błąd 503 albo „Briefly unavailable for scheduled maintenance”	przeciążenie, limity hostingu albo przerwana aktualizacja	sprawdź plik .maintenance i obciążenie serwera	jw.
„Error establishing a database connection”	błędne dane w wp-config.php albo niedziałający serwer bazy	sprawdź dane dostępu, potem hosting	sekcja niżej
błąd 403 (Forbidden)	uprawnienia plików, reguła zabezpieczeń, wtyczka bezpieczeństwa	sprawdź, co blokuje: serwer, WAF czy WordPress	poradnik o błędzie 403
błąd 404 na stronach, które istnieją	odnośniki bezpośrednie (permalinki) albo zmiana adresów	zapisz ponownie ustawienia bezpośrednich odnośników	poradnik o błędzie 404
strona się zapętla albo nie ładuje kłódki	konflikt HTTPS, przekierowań i ustawień Cloudflare	sprawdź adres witryny i tryb SSL	sekcja niżej
po aktualizacji coś przestało działać	niezgodność wersji wtyczki, motywu albo PHP	wycofaj jedną zmianę, nie całą stronę	poradnik o aktualizacjach
strona działa, ale nie dochodzą maile, statusy zamówień, płatności	ciche błędy: SMTP, zablokowane powiadomienia	logi wtyczki SMTP i access log serwera	sekcja o cichych błędach
dziwne przekierowania, nowe konta administratorów, ostrzeżenie Google	infekcja	nie kasuj plików na szybko, zabezpiecz dostęp	sekcja o infekcji
strona jest po prostu wolna	to zwykle nie błąd, tylko wydajność	pomiar zamiast debug.log	poradnik o cache

Strona nie działa wcale

Komunikat o błędzie krytycznym i tryb odzyskiwania

Komunikat „W witrynie wystąpił błąd krytyczny.” oznacza, że PHP natrafił na błąd, którego nie da się obejść, a WordPress przechwycił go, zamiast pokazać pusty ekran. Od wersji 5.2 WordPress wysyła wtedy na adres administratora maila z informacją, która wtyczka albo motyw spowodowały błąd, i z tajnym linkiem do trybu odzyskiwania (ogłoszenie zespołu WordPressa, 16.04.2019).

Tryb odzyskiwania działa przez ciasteczko w Twojej przeglądarce. Wadliwa wtyczka albo motyw są wstrzymane tylko dla Ciebie, a reszta odwiedzających nadal widzi stronę tak jak przed kliknięciem. Logujesz się, widzisz w panelu, co zostało wstrzymane, i możesz to wyłączyć albo zaktualizować. To bezpieczniejszy pierwszy krok niż wyłączanie wszystkich wtyczek wszystkim klientom.

Maila nie ma? Sprawdź spam i to, czy strona w ogóle wysyła wiadomości (o tym niżej). Krok po kroku, także bez dostępu do panelu, opisałem w poradniku o tym, jak rozwiązać błąd krytyczny i konflikt wtyczek.

Biały ekran bez żadnego komunikatu

Biały ekran to zwykle ten sam błąd PHP, tylko bez komunikatu: wyświetlanie błędów jest wyłączone, a mechanizm z WordPressa 5.2 nie zadziałał albo został wyłączony. Częstą przyczyną jest brak pamięci dla PHP. Domyślnie WordPress próbuje ustawić 40 MB (w sieci multisite 64 MB), ale wiele hostingów i tak narzuca własny limit (dokumentacja wp-config.php).

Kolejność: najpierw włącz zapis błędów do pliku (sekcja o szukaniu przyczyny), a dopiero gdy log milczy, wyłącz wtyczki przez zmianę nazwy folderu wp-content/plugins przez FTP albo menedżer plików hostingu. Szczegóły i warianty w poradniku o tym, jak naprawić biały ekran śmierci WordPress.

Błąd 500 i błąd 503

Te dwa kody wyglądają podobnie, ale mówią co innego. 500 oznacza, że serwer nie potrafił obsłużyć żądania, bo coś po drodze się wysypało. Dokumentacja WordPressa wskazuje jako najczęstszą przyczynę uszkodzony plik .htaccess, a dalej wtyczki, motyw i limit pamięci (Common WordPress Errors). 503 oznacza, że serwer jest chwilowo niedostępny: przeciążony, przyblokowany przez limity hostingu albo zatrzymany w trybie konserwacji.

Pełną procedurę dla obu kodów, z limitem pamięci, plikiem .htaccess i limitami hostingu, masz w poradniku o błędzie 503 i 500 na WordPressie. Czym jest sam plik .htaccess w WordPressie, wyjaśniam osobno.

Błąd połączenia z bazą danych

Komunikat „Error establishing a database connection” znaczy, że WordPress nie może połączyć się z bazą danych, w której trzyma wszystkie treści, ustawienia i zamówienia. Według dokumentacji WordPressa najczęściej winny jest plik wp-config.php (Common WordPress Errors). Sprawdzaj w tej kolejności:

1. Dane dostępu w wp-config.php. Nazwa bazy, użytkownik, hasło i host muszą być identyczne z tym, co widzisz w panelu hostingu. Po przeniesieniu strony albo zmianie hasła bazy to najczęstszy winowajca. Co jeszcze siedzi w tym pliku, opisałem w tekście o pliku wp-config.php.
2. Serwer bazy u hostingu. Jeśli dane się zgadzają, baza mogła przekroczyć limit pakietu albo serwer bazy po prostu nie działa. To sprawdza tylko hosting, więc napisz do supportu z godziną wystąpienia błędu.
3. Naprawa tabel. Gdy komunikat mówi o uszkodzonej bazie, WordPress ma wbudowane narzędzie naprawy. Włączasz je jedną linią w wp-config.php, wchodzisz na /wp-admin/maint/repair.php, uruchamiasz naprawę i od razu usuwasz linię.

<?php
// Tylko na czas naprawy. Narzędzie działa bez logowania, więc po użyciu usuń tę linię.
define( 'WP_ALLOW_REPAIR', true );

Zostawienie tej linii na stałe to błąd: dokumentacja zaznacza, że z narzędzia można korzystać bez logowania (wp-config.php, WP_ALLOW_REPAIR). Przed naprawą zrób kopię bazy.

1. Infekcja. Jeśli wszystko wygląda poprawnie, a błąd wraca, dokumentacja radzi sprawdzić, czy strona nie została zaatakowana. Wtedy przejdź do sekcji o infekcji niżej.

Strona utknęła w trybie konserwacji

Komunikat „Briefly unavailable for scheduled maintenance. Check back in a minute.” po aktualizacji oznacza, że WordPress nie usunął pliku .maintenance z głównego katalogu strony. Zwykle przerwała się aktualizacja. Usuwasz plik przez FTP albo menedżer plików (Common WordPress Errors). Potem sprawdź, czy aktualizacja, która się przerwała, faktycznie doszła do końca.

Strona działa, ale nie wszędzie

Błąd 403 i błąd 404

403 to „dostęp zabroniony”: serwer wie, o co prosisz, ale nie chce tego wydać. Winne bywają uprawnienia plików, reguła zapory na hostingu albo w Cloudflare i wtyczka bezpieczeństwa. Zanim zaczniesz zmieniać uprawnienia, ustal, kto blokuje. Szczegóły w poradniku o błędzie 403 na WordPressie.

404 to „nie ma takiej strony”. Jeśli dotyczy wszystkich wpisów naraz, najczęściej wystarczy zapisać ponownie ustawienia bezpośrednich odnośników (Ustawienia > Bezpośrednie odnośniki). Jeśli dotyczy pojedynczych adresów po zmianie struktury albo przeprowadzce, potrzebne są przekierowania. Pełna procedura, także raport z Search Console i własna strona 404, jest w poradniku o błędzie 404 w WordPressie.

Pętla przekierowań i błędy po przeniesieniu strony

Strona, która przekierowuje się sama na siebie, albo strona bez kłódki w przeglądarce mimo certyfikatu to zwykle konflikt ustawień HTTPS. Przy przenosinach strony, która stoi za Cloudflare, pilnujemy jednego ustawienia: certyfikat na serwerze przed przepięciem i tryb SSL „Full (strict)”. Tryb „Flexible” daje pętle przekierowań i mieszaną zawartość (część plików ładowana przez http).

Druga typowa pułapka po przeniesieniu: przy imporcie strefy DNS łatwo pominąć rekordy poczty (MX, SPF, DKIM, DMARC). Strona działa, a poczta przestaje dochodzić, więc po przeniesieniu porównaj te rekordy ze starą strefą. O tym, co sprawdzić przed przeprowadzką i po niej, piszę w poradniku o migracji strony WordPress i sklepu WooCommerce, a o samych przekierowaniach w tekście o przekierowaniu 301 w WordPressie.

Błąd po aktualizacji

Gdy coś przestało działać zaraz po aktualizacji, nie przywracaj od razu całej strony z kopii. Ustal, która aktualizacja to zrobiła, i cofnij tylko ją. Pełne przywrócenie kopii na sklepie oznacza utratę zamówień złożonych od chwili jej wykonania. Kolejność aktualizacji, listę testów po niej i sposób na wycofanie jednej wtyczki opisałem w poradniku, jak bezpiecznie zaktualizować WordPress.

Ciche błędy - strona działa, a coś nie dochodzi

Tych błędów nie widać na ekranie, więc wychodzą późno, zwykle wtedy, gdy klient dzwoni, że nie dostał potwierdzenia.

Maile. Brak maila to typowy niewidoczny błąd. Formularz pokazuje „Wysłano”, a wiadomość nigdy nie wychodzi. Dlatego przy każdym uruchomieniu sklepu zaglądamy do logów wtyczki SMTP i sprawdzamy, czy maile faktycznie wyszły. Jeden przykład z życia: w jednym z naszych wdrożeń FluentSMTP w połączeniu z wtyczkami do faktur od WP Desk sprawiał, że maile z fakturami nie wychodziły, a support WP Desk zaproponował przejście na WP Mail SMTP. Nie znaczy to, że te wtyczki zawsze się gryzą, ale po takiej zmianie warto wysłać fakturę testową. Jak ustawić wysyłkę, opisałem w tekstach o tym, co zrobić, gdy formularz kontaktowy nie wysyła wiadomości, i o wtyczkach SMTP dla WordPressa.

Statusy zamówień i płatności. Zamówienie powstaje, klient zapłacił, a status w sklepie stoi w miejscu. Najczęściej problemem nie jest sama płatność, tylko powiadomienie od bramki, które blokuje Cloudflare albo zabezpieczenia hostingu. Rozwiązaniem bywa dodanie adresów IP pośrednika płatności do białej listy, ale nie każdy hosting na to pozwala. Warto to sprawdzić przed wyborem hostingu, a nie po awarii. Po każdej przeprowadzce strony powiadomienia bramek i kurierów testujemy od nowa, bo zmienia się adres serwera.

Jak szukać przyczyny, gdy komunikat nic nie mówi

Kiedy objaw nie pasuje do żadnego wiersza w tabeli, przechodzę przez cztery kroki. Każdy jest tańszy i bezpieczniejszy od następnego.

1. Stan witryny. W panelu wejdź w Narzędzia > Stan witryny. Zakładka Status pokazuje problemy krytyczne, na przykład nieaktualne PHP, wyświetlanie błędów odwiedzającym, zapis logu do pliku, który może być publiczny, albo aktywną sesję PHP, która przeszkadza REST API i zadaniom w tle (dokumentacja Site Health). Zakładka Informacje zbiera wersje, wtyczki i ustawienia serwera w jednym miejscu. Przyda się, gdy będziesz pisać do hostingu albo do kogoś, kto ma pomóc.

2. Logi. Są trzy różne i każdy odpowiada na inne pytanie:

• debug.log WordPressa mówi, który plik i która linia kodu się wysypały. To pierwszy wybór przy błędach krytycznych, których front w ogóle nie pokazuje.
• error log serwera pokazuje błędy PHP i serwera, także te sprzed załadowania WordPressa.
• access log serwera mówi, czy dane żądanie w ogóle dotarło do strony. Przy problemach z płatnościami i integracjami to często ważniejsze pytanie niż „co się wysypało”.

Zapis błędów do pliku włączasz w wp-config.php. Błędy idą do pliku, nie na ekran odwiedzających:

<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', '0' );

Domyślnie log trafia do wp-content/debug.log, czyli do katalogu, który może być dostępny z przeglądarki. Włączaj go na czas szukania błędu i wyłączaj po wszystkim. Jak zapisać log poza katalogiem publicznym i jak go czytać, opisałem w poradniku WordPress debug - jak włączyć i czytać logi błędów.

3. Wykluczanie. Gdy log nie wskazuje winnego, wyłączasz kolejne elementy: wtyczki, potem motyw (przełączenie na domyślny). Na stronie firmowej możesz to zrobić od ręki. Na działającym sklepie wyłączenie wszystkich wtyczek wyłącza też koszyk i płatności dla klientów, więc lepiej sprawdzać na kopii testowej albo przez tryb odzyskiwania, który wstrzymuje wtyczkę tylko w Twojej przeglądarce.

4. Odtworzenie. Bez powtarzalnego scenariusza żaden log nie pomoże. Ustal, w jakich warunkach błąd występuje: jaka podstrona, jaki krok, zalogowany czy nie, telefon czy komputer. Dopiero wtedy włączasz logowanie i powtarzasz ten scenariusz.

Jedna rzecz, której ten proces nie rozwiąże: wolna strona. Jeśli nic się nie wywala, a strona po prostu zwolniła, debug.log jest złym narzędziem. Tu potrzebny jest pomiar (na przykład Query Monitor pokaże wolne zapytania do bazy) i praca nad wydajnością, którą opisałem w poradniku o cache w WordPressie.

Alarm to nie zawsze awaria

Część „błędów”, które trafiają do skrzynki, nie wymaga żadnej naprawy. Trzy przykłady z naszych zgłoszeń z ostatnich miesięcy, które opisywałem w newsletterze:

• Ostrzeżenie PHP „deprecated” w raporcie monitoringu. Klient dostał dwa takie ostrzeżenia z motywu i zapytał, czy strona jest zagrożona. Nie była. „Deprecated” znaczy, że kod używa przestarzałej funkcji albo konstrukcji, która może wymagać zmiany przed aktualizacją PHP. Strona działa, a to informacja dla autora motywu. Do listy zadań: „sprawdzić przy następnej zmianie wersji PHP”.
• Błędy 5xx i 403 w Search Console. W raporcie sklepu z filtrami produktów było osiem kategorii komunikatów, a do zrobienia jedna rzecz. Dziesięć adresów z błędem 5xx to były rozbudowane kombinacje filtrów i każdy z nich już działał. Jednorazowe 5xx w Search Console to zwykle chwilowy problem do obserwacji. Gdyby wracało co tydzień, byłby to sygnał o serwerze.
• 1,8 miliona odpowiedzi 504 w statystykach Cloudflare. W szczytowej dobie u jednego klienta 49% wszystkich żądań miało kod 504. To nie byli ludzie ani atak, tylko wewnętrzny mechanizm Cloudflare (Early Hints), który przy braku zapisanych wskazówek odnotowuje 504. Dokumentacja Cloudflare opisuje te wpisy jako spodziewane i nieszkodliwe (Early Hints).

Zasada, którą z tego wyciągam: tytuł alertu mówi, co narzędzie zobaczyło, a nie co jest zepsute. Zanim zaczniesz naprawiać, sprawdź, czy klient albo Google widzą problem na stronie, która zarabia.

Infekcja - kiedy błąd nie jest błędem

Dziwne przekierowania na obce strony, nowe konta administratorów, których nikt nie zakładał, nagły wzrost spamu albo ostrzeżenie Google o złośliwym oprogramowaniu to nie błędy WordPressa, tylko objawy włamania. Tu nie działa zasada „usuń jeden podejrzany plik”. Takie infekcje mają kilka dróg powrotu.

Przy infekcji na sklepie na czas szukania przyczyny wyłączamy niemal wszystkie krytyczne funkcje strony, żeby zainfekowany kod się nie powielał. W logach szukamy powtarzalnych, charakterystycznych ruchów: dodawania komentarza albo odpytywania jednego, bardzo konkretnego pliku PHP. Jak się zabezpieczyć na przyszłość, opisałem w poradniku o tym, jak zabezpieczyć WordPressa przed atakami i infekcjami. Jeśli strona już jest zainfekowana, a nie masz doświadczenia w czyszczeniu, zobacz, jak wygląda odwirusowanie WordPressa.

Czego nie robić przy naprawie

• Nie nadawaj plikom uprawnień 777 ani 666 „na chwilę”. Takie rady krążą w poradnikach, a otwierają plik do zapisu dla każdego procesu na serwerze. Problem z uprawnieniami rozwiązuje się zmianą właściciela pliku albo przez menedżer plików hostingu.
• Nie zostawiaj włączonych narzędzi naprawczych. WP_ALLOW_REPAIR i wyświetlanie błędów (WP_DEBUG_DISPLAY) wyłączasz zaraz po użyciu.
• Nie wyłączaj wszystkich aktualizacji automatycznych, bo raz coś się zepsuło. Tracisz w ten sposób także poprawki bezpieczeństwa. Lepiej kontrolować aktualizacje wtyczek, a poprawki bezpieczeństwa rdzenia zostawić włączone.
• Nie przywracaj całej kopii sklepu, gdy winna jest jedna wtyczka. Kopia cofa też zamówienia i klientów.
• Nie naprawiaj w ciemno na żywej stronie. Najpierw kopia, najlepiej kopia testowa, potem zmiana.

Jak my z tym pracujemy

Debug log włączamy, gdy przychodzi zgłoszenie o błędzie albo o tym, że coś działa nie tak, zwłaszcza przy błędach krytycznych, których front w ogóle nie pokazuje. Wtedy log najczęściej wskazuje konkretną ścieżkę z problemem.

Przykład z praktyki: sklep, w którym zamówienia powstają, ale statusy się nie aktualizują. Kolejność była taka:

1. Access log serwera. Najpierw sprawdzamy, czy zapytania od bramki płatności w ogóle docierają na stronę. Jeśli nie docierają, problem jest po stronie bramki albo sieci i szukanie w logach WordPressa to strata czasu.
2. Transakcja testowa. Jeśli docierają, robimy zakup testowy i patrzymy w error log w trakcie i zaraz po nim.
3. Błędy tuż po zamówieniu. Przeglądamy logi pod kątem błędów, które pojawiają się bezpośrednio po utworzeniu zamówienia.

Sklep i wizytówka różnią się tu bardziej, niż się wydaje. Na sklepie z ruchem nie wyłączamy wtyczek na produkcji, tylko raczej odtwarzamy problem na kopii. Logi na produkcji włączamy na chwilę, tylko żeby zebrać minimum danych. Przy dużych logach szukanie wzorców konsultujemy z asystentem AI, bo ręczne przeglądanie tysięcy linii nie ma sensu. Wizytówka i blog są paradoksalnie trudniejsze: ruchu prawie nie ma, więc log milczy. Wtedy dopytujemy klienta, w jakich warunkach błąd wystąpił, i odtwarzamy go u siebie z włączonym logowaniem.

Przy przeglądach strony w ramach opieki sięgamy najczęściej po Query Monitor, bo pokazuje wolne zapytania do bazy i błędy PHP na konkretnej podstronie.

Kiedy to podejście nie jest dla Ciebie: jeśli strona po prostu zwolniła, a nic się nie wywala, debug log to złe narzędzie. Jeśli nie da się opisać, kiedy błąd występuje, log też nie pomoże. Najpierw powtarzalny scenariusz, potem logowanie.

Kiedy naprawiać samemu, a kiedy oddać stronę

Samemu spokojnie poradzisz sobie, gdy:

• błąd pojawił się zaraz po Twojej zmianie i wiesz, którą zmianę cofnąć,
• masz aktualną kopię i dostęp do plików (FTP albo menedżer plików hostingu),
• chodzi o stronę firmową lub bloga, na której godzina niedostępności niczego nie kosztuje.

Oddaj stronę komuś, kto robi to na co dzień, gdy:

• to sklep z ruchem i każda godzina awarii to utracone zamówienia,
• błąd dotyczy płatności, statusów zamówień albo faktur,
• widzisz objawy infekcji,
• błąd wraca po naprawie albo nie umiesz ustalić, w jakich warunkach występuje,
• nie masz kopii albo nie wiesz, czy kopia działa.

Ostatni punkt jest najbardziej bolesny. Błędu nie da się cofnąć, jeśli nie ma do czego wracać.

FAQ

Podsumowanie

Błędy WordPress łatwiej naprawić, gdy szukasz ich po objawie i w stałej kolejności: zapis objawu, kopia, mail od WordPressa i Stan witryny, logi, wykluczanie, a na końcu hosting. Najgroźniejsze są te ciche, bo strona wygląda dobrze, a maile i zamówienia nie dochodzą. Część alarmów nie wymaga żadnej naprawy.

Jeśli nie chcesz za każdym razem przechodzić tej listy sam, zobacz, jak wygląda stała opieka nad stroną WordPress: aktualizacje, kopie i reakcja, gdy coś się zepsuje.