Błąd 500 (Internal Server Error) to ogólnikowy komunikat serwera „coś poszło nie tak, ale nie wiem co”. W przeciwieństwie do 503 (Service Unavailable, czyli „jestem przeciążony”) 500 oznacza, że serwer napotkał nieoczekiwany warunek uniemożliwiający wykonanie żądania. Crash PHP, zepsute .htaccess, brak pamięci, błąd w kodzie wtyczki. Najczęstszy błąd serwerowy na stronach WordPress.
Najczęstsze przyczyny 500 na WordPressie
1. Zepsuty .htaccess. Plik steruje przepisywaniem URL-i, przekierowaniami, zabezpieczeniami i cache. Jeden błąd składniowy (literówka, brakujący tag zamykający, niepoprawna dyrektywa) i cały serwer zwraca 500 na każde żądanie.
Naprawa:
- FTP do katalogu głównego WordPressa.
- Zmieniasz nazwę
.htaccessna.htaccess-backup. - Refresh strony. Działa? Problem był w .htaccess.
- wp-admin, Ustawienia, Bezpośrednie odnośniki, „Zapisz zmiany”. WordPress wygeneruje czysty .htaccess.
- Niestandardowe reguły dorzucasz po jednej, testujesz po każdej.
2. Wyczerpany limit pamięci PHP. WordPress i wtyczki potrzebują RAM. Domyślny limit na wielu hostingach to 64-128 MB. Przy ciężkich wtyczkach (Elementor, WooCommerce, WPML) potrafi nie wystarczyć i PHP się wysypuje na 500.
Naprawa: w wp-config.php dodajesz define('WP_MEMORY_LIMIT', '256M');. Albo w php.ini: memory_limit = 256M. Albo w panelu hostingu, sekcja PHP, memory_limit, 256M.
3. Wtyczka albo motyw z błędem. Aktualizacja wtyczki wprowadziła konflikt albo fatal error w PHP. Serwer nie może wygenerować strony. To najczęstsza przyczyna 500 na WP, zwłaszcza po aktualizacjach.
Naprawa:
- FTP,
wp-content/, zmień nazwę folderupluginsnaplugins-off. - Refresh. Działa? Winowajca to wtyczka.
- Przywracasz
plugins, wyłączasz wtyczki po jednej (zmiana nazwy folderu pojedynczej wtyczki), refresh po każdej. - Wyłączenie wtyczek nie pomaga? Zmień motyw: FTP,
wp-content/themes/, zmiana nazwy aktywnego motywu, WordPress przełączy się na domyślny (Twenty Twenty-Five).
4. Zepsuty wp-config.php. Edytowałeś plik (zmiana danych bazy, dodawanie stałych) i wjechał błąd składniowy: brakujący średnik, niezamknięty cudzysłów, podwójny <?php. PHP nie sparsuje pliku.
Naprawa: FTP, otwierasz wp-config.php, znajdujesz błąd (najczęściej w ostatniej edycji). Porównanie z wp-config-sample.php pomaga. Zwykłe pułapki: brak średnika na końcu linii, literówka w nazwie stałej, nieparzyste cudzysłowy.
5. Błędne uprawnienia plików. Pliki WordPress powinny mieć 644, foldery 755. Złe wartości (000, 777 na pliku PHP) i serwer nie może odczytać/wykonać pliku.
Naprawa: FTP, zaznaczasz pliki, prawym, Uprawnienia: 644 dla plików, 755 dla folderów. W SSH: find /var/www/html -type f -exec chmod 644 {} \; i find /var/www/html -type d -exec chmod 755 {} \;.
6. Niekompatybilna wersja PHP. Zmiana z 7.4 na 8.2 i stara wtyczka albo motyw używa funkcji usuniętej w nowszym PHP. Fatal error, 500.
Naprawa: w panelu hostingu wracasz do poprzedniej wersji PHP. Aktualizujesz wtyczki i motyw do wersji kompatybilnych z PHP 8.x i wtedy ponawiasz upgrade.
7. Uszkodzone pliki core WordPressa. Rzadkie, ale się zdarza: wp-admin/ albo wp-includes/ zostały uszkodzone (nieudana aktualizacja, malware, awaria dysku).
Naprawa: pobierasz świeżego WordPressa z wordpress.org, rozpakowujesz, wgrywasz przez FTP foldery wp-admin/ i wp-includes/ (nadpisujesz). Nie wgrywasz wp-content/ (twoje wtyczki i media) ani wp-config.php (twoja konfiguracja).
Znajdowanie konkretnej przyczyny: debug.log
Włączasz tryb debugowania WordPressa, który zapisuje błędy do pliku zamiast wyświetlać 500. W wp-config.php przed linią /* That's all */:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Refresh strony (nadal 500, ale teraz WordPress zapisał szczegóły). Otwierasz wp-content/debug.log, patrzysz na ostatni wpis. Zobaczysz dokładny plik i linię z błędem (np. Fatal error: Call to undefined function xyz() in /wp-content/plugins/bad-plugin/main.php on line 42). Mówi ci precyzyjnie co naprawić. Sam zawsze zaczynam od debug.log, oszczędza godziny zgadywania.
Po naprawie wyłączasz debug (WP_DEBUG na false). Nie zostawiaj na produkcji, bo logi rosną i mogą ujawnić wrażliwe informacje.
Logi serwera, kiedy debug.log nie pomaga
Czasem WordPress nie zdąży się załadować na tyle, żeby zapisać debug.log (bo błąd jest w wp-config.php albo .htaccess). Wtedy logi serwera:
| Serwer | Lokalizacja logów |
|---|---|
| Apache | /var/log/apache2/error.log albo ~/logs/error.log |
| Nginx | /var/log/nginx/error.log |
| LiteSpeed | /usr/local/lsws/logs/error.log |
| cPanel | Metrics, Errors, error_log |
| PHP-FPM | /var/log/php-fpm/error.log |
Błąd 500 a SEO
Krótkotrwały 500 (minuty): bez wpływu, Googlebot ponowi próbę. Długotrwały 500 (godziny, dni): Google może tymczasowo usunąć strony z indeksu. 500 jest gorszy od 503, bo 503 mówi „wrócę” (z nagłówkiem Retry-After), a 500 mówi „coś się zepsuło, nie wiem kiedy wrócę”. Naprawiasz jak najszybciej.
Po naprawie: Search Console, Stan indeksowania, sprawdzasz, czy strony wróciły. Jeśli nie, Inspekcja URL, Poproś o indeksowanie (per strona).
Szybka checklista
- .htaccess: zmiana nazwy na .htaccess-backup, refresh. Działa? Znaleziony.
- Wtyczki: FTP, plugins, plugins-off, refresh. Działa? Wyłączaj po jednej.
- Motyw: zmiana nazwy aktywnego motywu. WordPress wjedzie na domyślny.
- PHP memory:
define('WP_MEMORY_LIMIT', '256M');. - Wersja PHP: powrót do poprzedniej w panelu hostingu.
- wp-config.php: porównanie z sample, sprawdzenie ostatniej edycji.
- Uprawnienia: pliki 644, foldery 755.
- debug.log: włączasz WP_DEBUG, refresh, czytasz log.
- Core WP: wgranie świeżych wp-admin/ i wp-includes/ z wordpress.org.
- Hosting: kontakt, jeśli nic nie pomaga, problem może być po ich stronie.
Najczęściej zadawane pytania
Błąd 500 widzę tylko ja czy wszyscy
Zwykle wszyscy. 500 to błąd serwera, nie przeglądarki. Sprawdzasz na telefonie (z danych mobilnych, nie WiFi) albo prosisz znajomego. Też widzi 500? Problem serwerowy. Tylko ty? Sprawdź cache przeglądarki, VPN, ewentualne rozszerzenia.
500 tylko na jednej podstronie
Najczęściej problem z konkretną wtyczką na tej stronie (shortcode, blok Gutenberga, custom field) albo uszkodzonym wpisem w bazie. Włącz WP_DEBUG, refresh tej podstrony, debug.log pokaże konkretny plik, linię i wtyczkę.
500 tylko w wp-admin, frontend działa
Częste po aktualizacji wtyczki modyfikującej panel admina (Elementor, WooCommerce, WPML, ACF). FTP, wyłącz wtyczki, sprawdź, czy wp-admin wstaje, włączaj po jednej.
500 po wgraniu .htaccess z internetu
Reguły z poradników nie zawsze pasują do twojego serwera (np. reguły Apache na LiteSpeed/Nginx, moduł mod_rewrite wyłączony). Usuwasz wgrane reguły, przywracasz domyślny .htaccess WordPressa (Ustawienia, Bezpośrednie odnośniki, Zapisz).
Czy mogę zobaczyć szczegóły błędu zamiast białej strony
Domyślnie serwer ich nie wyświetla (bezpieczeństwo). Włączasz WP_DEBUG z WP_DEBUG_DISPLAY = true tymczasowo, na czas diagnozy. WordPress wyświetli szczegóły zamiast 500. Wyłączasz po naprawie, na produkcji nie zostawiasz, bo to ujawnia ścieżki i strukturę plików.
