Biały ekran. Pięć cyfr: 500. Ani panelu administracyjnego, ani strony, ani śladu przyczyny. Znajomy widok?

Wewnętrzny błąd serwera WordPress 500, najbardziej niemy ze wszystkich błędów. Nie mówi, co dokładnie się zepsuło, przez co panika jest tylko większa. Ale rzeczywistość jest prozaiczna: w 9 na 10 przypadków winna jest wtyczka, motyw lub jeden błędny wiersz w .htaccess. Serwer nie oszalał, po prostu natknął się na kod, którego nie może wykonać.

Teraz przeanalizujemy trzy główne scenariusze i krok po kroku naprawimy każdy z nich. Bez paniki, bez telefonu do dostawcy hostingu o trzeciej w nocy. Własnymi rękami, w 15 minut.

💡 Szybki przegląd:

• Proszę wyłączyć wszystkie wtyczki naraz, zmienić nazwę folderu plugins przez FTP, błąd zniknął? Winowajca jest wśród nich
• Proszę zresetować .htaccess do standardowego WordPress: błędna dyrektywa buforowania lub przekierowania natychmiast psuje stronę
• Proszę włączyć WP_DEBUG w wp-config.php, zobaczą Państwo konkretny plik i wiersz z błędem krytycznym
• Jeśli strona właśnie została przeniesiona na nowy hosting, proszę sprawdzić wersję PHP: WordPress od 2026 roku wymaga PHP 8.3 lub nowszego, a stare wtyczki często są niekompatybilne

Kody odpowiedzi HTTP: co serwer próbuje Państwu powiedzieć

Zanim zagłębią się Państwo w debugowanie, warto zrozumieć alfabet odpowiedzi HTTP. Serwer zawsze odpowiada przeglądarce trzycyfrowym kodem, a po pierwszej cyfrze już widać, gdzie szukać problemu.

• 1xx, informacyjne: „połączenie jest nawiązywane, proszę czekać". Nie mają związku z błędami.
• 2xx, sukces. Słynne 200 OK oznacza, że serwer bez zastrzeżeń dostarczył stronę.
• 3xx, przekierowania. Na przykład 301 (stałe przekierowanie) lub 307 (tymczasowe). Przeglądarka przechodzi pod nowy adres po cichu, to polecenie, a nie błąd.
• 4xx, błąd po stronie klienta. 404 Not Found, strona została usunięta lub adres URL został wpisany z błędem. Serwer działa, po prostu nie ma treści.
• 5xx, błąd po stronie serwera. Tutaj zaczyna się nasze terytorium.

Wśród 5xx są trzej główni „pacjenci": 503 Service Unavailable (serwer przeciążony, leczy się buforowaniem lub przejściem na mocniejszy plan taryfowy), 502 Bad Gateway (PHP-FPM padł lub stracił połączenie z serwerem WWW, problem z konfiguracją) i wreszcie **500 **Internal Server Error, najbardziej ogólny i przez to najbardziej podstępny. O nim porozmawiamy.

Trzy główne przyczyny błędu 500 i naprawa krok po kroku

Błąd 500 nie jest tajemniczy, jest po prostu ogólny. Serwer mówi: „nie mogłem wykonać kodu, ale nie powiem którego". Diagnostyka to metodyczne sprawdzanie trzech standardowych winowajców.

1. Niekompatybilność wersji PHP podczas przenoszenia strony

Klasyka gatunku: przenieśli Państwo stronę ze starego hostingu, gdzie działało PHP 7.4, na nowy, z PHP 8.3 lub 8.4. I natychmiast zobaczyli biały ekran.

Przyczyna jest banalna: stara wtyczka lub motyw używają funkcji, które w nowych wersjach PHP są uznane za przestarzałe (deprecated) lub całkowicie usunięte. Interpreter odmawia ich wykonania i strona pada.

Jak naprawić. Proszę zrobić pełną kopię zapasową folderów wp-content/plugins/ i wp-content/themes/. Następnie proszę zmienić nazwę folderu plugins na plugins_old przez FTP lub menedżer plików hostingu, to natychmiast wyłączy wszystkie wtyczki razem. Błąd zniknął? Winowajca jest wśród wtyczek. Proszę przywracać je pojedynczo, za każdym razem sprawdzając stronę. Ta, po której wrócił błąd 500, jest problemem.

Z motywami ta sama logika: proszę przełączyć się na standardowy motyw WordPress (Twenty Twenty-Five lub nowszy). Strona ożyła? Problem tkwi w Państwa motywie, proszę go zaktualizować lub wymienić.

Ten scenariusz najczęściej ujawnia się podczas przenoszenia strony między hostingami z różnymi wersjami PHP. Większość dostawców hostingu nie oferuje już PHP 7.x w panelu sterowania, minimalne wymagania WordPress od 2026 roku zaczynają się od PHP 8.3. Stary kod bez aktualizacji w takim środowisku jest skazany na porażkę.

2. Uszkodzony.htaccess, niewidzialny zabójca

Skonfigurowali Państwo wtyczkę buforowania, włączyli przekierowania lub dodali własne reguły w .htaccess i strona padła. Natychmiast i bez ostrzeżenia.

Plik .htaccess (Apache) steruje serwerem WWW w locie: dyrektywa zapisana, dyrektywa wykonana. Jeden błąd składniowy, nieprawidłowa flaga lub konflikt reguł i cała strona odpowiada błędem 500.

Jak naprawić. Proszę połączyć się ze stroną przez FTP lub menedżer plików hostingu. Proszę znaleźć .htaccess w folderze głównym (public_html, www lub htdocs). Proszę skopiować jego zawartość do pliku tekstowego jako kopię zapasową. Następnie proszę zastąpić całą zawartość standardowym szablonem WordPress:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

Ten kod przywraca standardowe reguły przepisywania adresów URL (bezpośrednie odnośniki) i usuwa wszystko, co zbędne. Strona powinna natychmiast ożyć. Następnie można ponownie skonfigurować wtyczkę, ale teraz wiedzą już Państwo, gdzie szukać, jeśli coś pójdzie nie tak.

Nie pomogło? Proszę przywrócić stary .htaccess z kopii zapasowej i przejść do następnego kroku. Na Nginx .htaccess nie działa, proszę sprawdzić logi /var/log/nginx/error.log, problem leży w konfiguracji bloku serwera.

3. Błąd krytyczny w kodzie PHP

Wtyczka lub motyw wywołują funkcję, która nie istnieje, przekazują nieprawidłowy typ argumentu lub odwołują się do nieistniejącej klasy. PHP przerywa wykonywanie i widzą Państwo ten sam błąd 500.

Bez informacji debugowania wróżą Państwo z fusów. Na szczęście WordPress potrafi pokazywać błędy, wystarczy tylko włączyć tryb debugowania.

Włączamy WP_DEBUG

Proszę otworzyć plik wp-config.php w katalogu głównym strony. Proszę znaleźć wiersz:

1
define( 'WP_DEBUG', false );

Proszę zamienić false na true. Jeśli takiego wiersza nie ma, proszę dodać go przed /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Po zapisaniu proszę odświeżyć stronę. Zamiast białego ekranu zobaczą Państwo komunikat podobny do:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

W błędzie wskazano: typ problemu (undefined function), plik winowajcę (wp-cache.php) i wiersz (342). To bezpośrednie wskazanie wtyczki, która spowodowała awarię. Proszę ją wyłączyć, zmienić nazwę folderu wtyczki, strona zacznie działać. Następnie proszę zaktualizować wtyczkę, znaleźć zamiennik lub skontaktować się z deweloperem.

Koniecznie proszę przywrócić WP_DEBUG na false po diagnostyce. Na działającej stronie wyświetlanie błędów odwiedzającym nie jest potrzebne i może ujawnić wewnętrzne ścieżki serwera. Jeśli chcą Państwo zbierać logi bez pokazywania ich na ekranie, proszę dodać w wp-config.php wiersze define( 'WP_DEBUG_LOG', true ); i define( 'WP_DEBUG_DISPLAY', false );. Błędy będą zapisywane w wp-content/debug.log.

⁉️🤔 Często zadawane pytania

Czy można po prostu zrestartować serwer, aby usunąć błąd 500?

Nie. W przeciwieństwie do 503, który często znika po restarcie (zdejmowane jest szczytowe obciążenie), błąd 500 jest spowodowany problemem w kodzie. Restart serwera go nie naprawi: po uruchomieniu strona ponownie natknie się na ten sam uszkodzony kod i padnie.

Jak ustalić, czy winna jest wtyczka czy motyw, jeśli panel administracyjny jest niedostępny?

Proszę połączyć się przez FTP lub menedżer plików hostingu. Proszę zmienić nazwę folderu wp-content/plugins, to natychmiast wyłączy wszystkie wtyczki. Strona ożyła? Problem tkwi we wtyczkach. Nie? Proszę zmienić nazwę folderu aktywnego motywu w wp-content/themes. WordPress automatycznie przełączy się na standardowy motyw. Ożyła? Problem tkwi w motywie.

Czy koniecznie trzeba włączać WP_DEBUG na działającej stronie?

Nie, na działającej stronie WP_DEBUG powinno być wyłączone (false). Proszę włączać je tylko na czas diagnostyki i natychmiast wyłączać. Do stałego zbierania błędów bez pokazywania ich odwiedzającym proszę używać połączenia WP_DEBUG_LOG (zapisuje do wp-content/debug.log) i WP_DEBUG_DISPLAY (wyłącza wyświetlanie na ekranie).

Co robić, jeśli żaden z trzech sposobów nie pomógł?

Proszę sprawdzić limit pamięci PHP, memory_limit w php.ini. Czasami skryptom brakuje przydzielonych megabajtów i padają z błędem 500. Proszę zwiększyć do 256M lub 512M. Jeśli to nie pomogło, proszę skontaktować się z pomocą techniczną hostingu: poprosić o sprawdzenie logów błędów serwera (error_log Apache/Nginx). Będzie tam dokładna przyczyna, której nie widać od strony WordPress.

Strona jest na Nginx, co robić z.htaccess?

Nginx nie używa .htaccess. Reguły przepisywania są zapisywane w konfiguracji bloku serwera (nginx.conf lub sites-available/your-site). Jeśli są Państwo na Nginx i otrzymali błąd 500, proszę sprawdzić logi /var/log/nginx/error.log. Nieprawidłowy .htaccess na serwerze Nginx nie powoduje problemów, jest po prostu ignorowany.

Jak zapobiec błędowi 500 w przyszłości?

Trzy zasady profilaktyki. Po pierwsze: proszę aktualizować wtyczki, motywy i rdzeń WordPress na czas, co miesiąc, a nie raz w roku. Po drugie: proszę nie trzymać się rozszerzeń porzuconych przez deweloperów; jeśli wtyczka nie była aktualizowana od ponad roku, proszę szukać aktywnie rozwijanego zamiennika. Po trzecie: przed zainstalowaniem jakiejkolwiek wtyczki proszę sprawdzić datę ostatniej aktualizacji i kompatybilność z Państwa wersją PHP na stronie wtyczki w katalogu WordPress. Dziesięć minut profilaktyki miesięcznie oszczędza godziny awaryjnego debugowania.

Co zrobić teraz, jeśli strona leży z błędem 500

Błąd 500 to zagadka z przewidywalnym rozwiązaniem. W zdecydowanej większości przypadków naprawią Państwo stronę w kwadrans, przechodząc trzy kroki we właściwej kolejności: wyłączyć wtyczki, zresetować .htaccess, włączyć WP_DEBUG. Kolejność jest ważna, od najbardziej prawdopodobnego i najszybszego do najbardziej szczegółowego.

Jeśli przenosili Państwo stronę na nowy hosting, proszę zacząć od sprawdzenia PHP. Jeśli konfigurowali Państwo buforowanie lub przekierowania, od .htaccess. Jeśli aktualizowali Państwo wtyczki i strona padła, od WP_DEBUG. A jeśli nic Państwo nie robili, a błąd 500 pojawił się sam, proszę przejść wszystkie trzy kroki po kolei, jeden z nich prawie na pewno zadziała.

Proszę nie odkładać diagnostyki: każda minuta przestoju strony to utrata odwiedzających i pozycji w wyszukiwarkach. Proszę otworzyć FTP, zrobić kopię zapasową i do dzieła.