Biały ekran. Pięć cyfr: 500 Internal Server Error. Strona nie działa, klient pisze w komunikatorze, a Pan/Pani nie wie, za co się zabrać.

Pięćsetka, najbardziej nieprzyjemny ze statusów HTTP. W przeciwieństwie do 404 („nie znaleziono strony") lub 403 („dostęp zabroniony"), nie wskazuje winowajcy. Po prostu „coś poszło nie tak na serwerze". A dalej już samodzielnie: wtyczka, motyw, wadliwy PHP, hosting, uszkodzony .htaccess, dziesiątki wariantów, a każdy wymaga innego leczenia.

Dobra wiadomość: błąd 500 zawsze da się naprawić. Bez paniki, bez ponownej instalacji WordPressa od zera i w większości przypadków bez programisty. W 7 krokach, od 30-sekundowej diagnostyki po chirurgiczną wymianę plików systemowych, znajdzie Pan/Pani przyczynę i postawi stronę. Każda metoda z konkretnymi plikami, linijkami kodu i zrzutami ekranu.

💡 Szybki przegląd:

• Krok 1: włączamy WP_DEBUG i czytamy logi, od razu widzimy, który plik zawinił
• Krok 2: wykluczamy problemy z hostingiem, zanim zacznie Pan/Pani grzebać w kodzie
• Krok 3: naprawiamy .htaccess, przyczyna numer jeden według statystyk wsparcia
• Krok 4: podnosimy limit pamięci PHP, częsty winowajca podczas przesyłania plików multimedialnych i logowania do panelu administracyjnego
• Krok 5: ponownie wgrywamy rdzeń WordPressa, gdy pliki są uszkodzone przez błąd automatycznej aktualizacji
• Krok 6: wyłączamy wtyczki przez FTP, metoda, która zamyka ponad połowę przypadków
• Krok 7: resetujemy motyw do domyślnego, krok, który często jest pomijany

Czym jest błąd 500 i skąd się bierze

HTTP 500, to odpowiedź serwera oznaczająca „błąd wewnętrzny". Żądanie z przeglądarki dotarło, Apache lub Nginx je przyjęły, PHP zaczął się wykonywać i potknął się. W przeciwieństwie do 404 lub 403, gdzie serwer świadomie odpowiada „nie", piątka na początku kodu mówi: coś zepsuło się wewnątrz skryptu i serwer nie wie, co dokładnie.

W WordPressie błąd 500 występuje w czterech typowych scenariuszach:

• Zainstalowano lub zaktualizowano wtyczkę, a ona wchodzi w konflikt z innym kodem w systemie.
• Zmieniono .htaccess i błąd składniowy wywrócił Apache.
• Skrypt PHP wyczerpał przydzieloną pamięć (biały ekran z Allowed memory size of X bytes exhausted w logach).
• Pliki rdzenia są uszkodzone, awaria podczas automatycznej aktualizacji, uszkodzone pobranie przez FTP, wadliwa wtyczka, która weszła do folderów systemowych.

Rzadziej: motyw z błędem krytycznym w functions.php, problemy po stronie hostingu (przeciążenie, wyłączenie modułu PHP) lub uszkodzony shortcode usuniętej wtyczki wewnątrz treści strony.

Zanim Pan/Pani zacznie: proszę wykonać pełną kopię zapasową strony. Bez backupu każde działanie na plikach serwera to ryzyko. Większość hostingodawców udostępnia przycisk backupu w panelu sterowania (cPanel, ISPmanager, aaPanel) na dwa kliknięcia.

1. Proszę włączyć WP_DEBUG i przeczytać logi

Najszybszy sposób, by poznać przyczynę, to zmusić WordPressa, by ją pokazał. Domyślnie rdzeń ukrywa błędy PHP za białym ekranem (to tryb „nie straszyć odwiedzających"). Ale WordPress ma wbudowany mechanizm debugowania, stałe WP_DEBUG.

Włączenie trybu debugowania

Proszę otworzyć wp-config.php w katalogu głównym strony przez FTP lub menedżera plików hostingu. Proszę znaleźć linię:

1
/* That's all, stop editing! Happy blogging. */

Przed nią proszę wstawić blok:

1
// Включаем режим отладки
2
define( 'WP_DEBUG', true );
3
 
4
// Пишем ошибки в файл /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Не показываем ошибки посетителям на экране
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Co tu się dzieje:

• WP_DEBUG, główny włącznik; bez true pozostałe stałe nie działają.
• WP_DEBUG_LOG, kieruje wszystkie błędy do wp-content/debug.log, a nie na ekran. Odwiedzający nie widzą niepokojących komunikatów.
• WP_DEBUG_DISPLAY + @ini_set, wymusza ukrycie błędów z wyjścia strony.

Proszę zapisać plik, odświeżyć problematyczną stronę serwisu i pobrać wp-content/debug.log przez FTP. W logu zobaczy Pan/Pani konkretny plik i linię: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Proszę wyłączyć debugowanie po diagnostyce. Proszę zakomentować lub usunąć dodane linie. WP_DEBUG na produkcyjnej stronie spowalnia działanie, a debug.log z czasem rozrasta się do gigabajtów.

2. Proszę skontaktować się z dostawcą hostingu

Logi są puste lub nie zostały zapisane, błąd może leżeć po stronie serwera, a nie w kodzie WordPressa. Szczególnie często na tanich planach hostingu współdzielonego z twardymi limitami na procesy.

Proszę otworzyć zgłoszenie do wsparcia i dodać trzy rzeczy:

• Dokładny czas wystąpienia błędu ze strefą czasową serwera.
• URL strony, na której błąd się pojawia.
• Zrzut ekranu błędu, jeśli jest dostępny.

Wsparcie techniczne sprawdzi logi serwera Apache lub Nginx, obciążenie procesora i pamięci, dostępne moduły PHP. Na tym etapie problem często jest rozwiązywany: administrator hosta restartuje PHP-FPM lub poprawia limit na liczbę procesów.

Jak ustalić, po czyjej stronie leży problem

Proszę utworzyć plik info.php z jedną linią:

1
<?php phpinfo(); ?>

Proszę wgrać go do katalogu głównego strony przez FTP i otworzyć ваш-сайт.com/info.php. Jeśli zobaczy Pan/Pani tabelę z parametrami PHP, serwer działa, błąd tkwi w kodzie WordPressa. Jeśli zobaczy Pan/Pani błąd 500, problem leży na poziomie serwera, proszę przekazać ten URL do wsparcia.

Po sprawdzeniu **proszę usunąć **info.php. phpinfo() ujawnia wersje, ścieżki i moduły serwera, to dziura w bezpieczeństwie.

3. Proszę naprawić plik.htaccess

.htaccess, plik konfiguracyjny Apache w katalogu głównym witryny. WordPress używa go do przyjaznych adresów URL, przekierowań i podstawowych reguł bezpieczeństwa. Jeden zbędny nawias, konflikt reguł z dwóch wtyczek i cała witryna pada z błędem 500. Według statystyk zgłoszeń do wsparcia to właśnie .htaccess okazuje się przyczyną numer jeden.

Szybkie sprawdzenie: proszę zmienić nazwę .htaccess na .htaccess_old przez FTP i odświeżyć witrynę. Jeśli zadziała, problem na pewno leży w tym pliku.

Teraz proszę przywrócić .htaccess: proszę wejść do panelu administracyjnego WordPress, Ustawienia → Bezpośrednie odnośniki i kliknąć „Zapisz zmiany", nie zmieniając struktury. WordPress wygeneruje nowy, czysty .htaccess ze standardowymi regułami:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Jeśli wprowadzali Państwo do .htaccess niestandardowe reguły (przekierowania, cache, bezpieczeństwo), proszę dodawać je z powrotem pojedynczo i sprawdzać witrynę po każdej z nich. W ten sposób zidentyfikują Państwo zabójczy wiersz.

4. Zwiększenie limitu pamięci PHP

Skrypty PHP WordPressa potrzebują pamięci RAM. Gdy wtyczka lub motyw zażądają więcej, niż przydzielono, skrypt pada. Rezultat: błąd 500 lub biała strona z komunikatem Allowed memory size of X bytes exhausted.

Standardowy limit u wielu hostingodawców wciąż wynosi 64 MB. Dla nowoczesnej witryny na WordPressie z kilkunastoma wtyczkami to katastrofalnie mało. Zalecane minimum to 256 MB.

Sposób 1: przez wp-config.php (zalecany)

Proszę dodać w wp-config.php przed /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Ta stała nadpisuje limit PHP dla frontowej części witryny. Dla panelu administracyjnego WordPress automatycznie podnosi poprzeczkę do WP_MAX_MEMORY_LIMIT (domyślnie 256 MB).

Sposób 2: przez php.ini (jeśli hosting nie pozwala edytować wp-config)

Proszę utworzyć plik php.ini z zawartością:

1
memory_limit = 256M

Proszę wgrać go do katalogu głównego witryny i do folderu wp-admin/. Jeśli to nie pomoże, proszę utworzyć lub wyedytować .user.ini w katalogu głównym witryny z tym samym wierszem.

Jeśli żaden sposób nie zadziałał, taryfa hostingu fizycznie ogranicza pamięć. Czas zaktualizować taryfę lub zmienić hostingodawcę.

5. Ponowne wgranie plików rdzenia WordPress

Uszkodzony plik rdzenia to niezbyt częsta, ale podstępna przyczyna. Awaria podczas automatycznej aktualizacji, uszkodzony transfer FTP, wtyczka, która zmieniła pliki systemowe, i wp-admin lub wp-includes zawierają śmieci.

Kolejność działań:

• Proszę pobrać świeże archiwum ZIP WordPressa z wordpress.org.
• Proszę rozpakować archiwum na komputerze.
• Przez FTP proszę wejść do katalogu głównego witryny i usunąć foldery wp-admin i wp-includes (tylko je, proszę nie ruszać wp-content!).
• Proszę wgrać foldery wp-admin i wp-includes ze świeżego archiwum.
• Proszę nie nadpisywać wp-content, tam są Państwa motywy, wtyczki i przesłane pliki.

Pliki w katalogu głównym (wp-settings.php, index.php i inne) również można zastąpić świeżymi z archiwum. **Z wyjątkiem **wp-config.php, tego pliku proszę nie ruszać, zawiera dane dostępowe do bazy danych. Po zastąpieniu proszę odświeżyć witrynę, błąd zniknie, jeśli przyczyną były uszkodzone pliki systemowe.

6. Wyłącz wtyczki

Wtyczka-zabójca, najbardziej prawdopodobna przyczyna błędu 500. Zaktualizowali Państwo kilka wtyczek jednocześnie i jedna weszła w konflikt z drugą, witamy biały ekran.

Jeśli panel administracyjny działa

Proszę wejść w Wtyczki → zaznaczyć wszystkie → akcja grupowa „Dezaktywuj" → „Zastosuj". Błąd zniknął, proszę włączać wtyczki pojedynczo, odświeżając stronę po każdej. Znaleźli Państwo winowajcę, proszę go usunąć lub powiadomić dewelopera.

Jeśli panel administracyjny jest niedostępny

Proszę wejść na serwer przez FTP i zmienić nazwę folderu wp-content/plugins na plugins_off. WordPress przestanie ładować wszystkie wtyczki i strona ożyje. Proszę przywrócić folderowi pierwotną nazwę i zmieniać nazwy podfolderów wtyczek pojedynczo, w ten sposób znajdą Państwo problematyczną bez wchodzenia do panelu administracyjnego.

Na co zwrócić uwagę: wtyczki cache (W3 Total Cache, WP Rocket) czasami zapisują swoje reguły w .htaccess i wp-config.php. Po dezaktywacji takiej wtyczki błąd może pozostać, proszę sprawdzić te pliki i usunąć linie między znacznikami # BEGIN W3TC i # END W3TC lub analogicznymi.

7. Przełącz się na domyślny motyw

Aktywny motyw, niedoceniane, ale realne źródło błędu 500. Szczególnie jeśli w functions.php dodano snippet z błędem krytycznym.

Sprawdzenie jest proste: przez FTP proszę zmienić nazwę folderu aktywnego motywu w wp-content/themes/ (na przykład mytheme → _mytheme). WordPress wykryje, że aktywny motyw zniknął i automatycznie przełączy się na standardowy, Twenty Twenty-Five lub inny domyślny motyw zainstalowany w systemie.

Strona zadziałała na domyślnym motywie, problem jest w Państwa motywie. Proszę przywrócić motywowi pierwotną nazwę, otworzyć functions.php i szukać błędów w niestandardowym kodzie. Jeśli to nie Państwo dodawali kod, proszę skontaktować się z deweloperem motywu.

⁉️🤔 Często zadawane pytania

Co zrobić, jeśli błąd 500 pojawia się tylko podczas logowania do panelu administracyjnego?

Najprawdopodobniej limitu pamięci PHP nie wystarcza właśnie dla panelu administracyjnego, ładuje on wszystkie wtyczki jednocześnie i jest cięższy niż front-end. Proszę dodać w wp-config.php linię define( 'WP_MAX_MEMORY_LIMIT', '512M' );, to osobny limit dla panelu administracyjnego, wyższy niż front-endowy WP_MEMORY_LIMIT. Proszę sprawdzić również folder wtyczek: z naszej praktyki najczęściej winna jest wtyczka bezpieczeństwa typu Wordfence lub wtyczka do backupu, która zużywa pamięć podczas ładowania paska administracyjnego. Proszę je wyłączyć przez FTP (folder plugins_off z kroku 6) i sprawdzić.

Czy można naprawić błąd 500 bez dostępu FTP?

Tak. Większość hostingodawców udostępnia menedżer plików w panelu sterowania: cPanel → File Manager, ISPmanager → Pliki. Za jego pomocą zmienia się nazwy .htaccess, folderów wtyczek i motywów, edytuje wp-config.php, wszystkie kroki są takie same. Zupełnie bez dostępu do plików, tylko przez support hostingu. Lifehack: jeśli zainstalowano wtyczkę do snippetów (Code Snippets, WPCode) i ostatnią czynnością było dodanie snippetu, proszę spróbować otworzyć ваш-сайт.com/?code_snippets_safe_mode=1 lub analogiczny safe-mode URL Państwa wtyczki. To wyłącza wszystkie snippety bez FTP.

Błąd 500 pojawia się tylko na jednej stronie, jaka jest przyczyna?

Uszkodzona funkcja lub shortcode wewnątrz treści tej konkretnej strony. Proszę otworzyć stronę w edytorze WordPress (jeśli panel administracyjny działa) i tymczasowo usunąć wszystkie shortcody, bloki Gutenberga i wstawki kodu. Jeśli panel administracyjny jest niedostępny, proszę znaleźć wpis w bazie danych przez phpMyAdmin (tabela wp_posts), skopiować zawartość do edytora tekstowego i usunąć podejrzane shortcody. Najczęstsi winowajcy: shortcody usuniętych wtyczek ([dead_plugin] pozostał, a wtyczki nie ma), uszkodzony PHP w blokach treści, nieprawidłowo zagnieżdżone bloki Gutenberga.

Po przywróceniu błąd 500 wraca po kilku godzinach, jak znaleźć przyczynę?

Cykliczny błąd z interwałem, prawie zawsze jeden z trzech scenariuszy: zadanie cron WordPress uruchamia uszkodzony proces zgodnie z harmonogramem, wtyczka cache generuje uszkodzony cache lub hosting okresowo wpada w limit procesów (szczególnie na tanich hostingach współdzielonych). Proszę zainstalować WP Crontrol i sprawdzić listę zadań cron, znaleźć to, które pokrywa się czasowo z awarią. Proszę wyczyścić cache wtyczki cache. Proszę zapytać hostingodawcę o limit Entry Processes lub PHP Workers, na hostingach współdzielonych często są one ograniczane do 5-10 i skok ruchu kładzie stronę.

Czy trzeba przechodzić wszystkie 7 kroków, czy można część pominąć?

Pierwsze dwa kroki (WP_DEBUG i hosting) są diagnostyczne: nie psują strony i dostarczają informacji. Z doświadczenia wsparcia stron WordPress, krok 3 (.htaccess) i krok 6 (wtyczki) rozwiązują zdecydowaną większość przypadków. Pozostałe przypadają na pamięć PHP, uszkodzony rdzeń i motyw. W typowej sytuacji rozwiążą Państwo problem już na krokach 3 i 6, bez przechodzenia całego łańcucha.

Od czego zacząć teraz

Proszę nie powtarzać typowego scenariusza: panika → usuwanie wszystkiego po kolei → pogorszenie. Proszę postępować po kolei, od diagnostyki do naprawy:

Główna zasada naprawy WordPressa: jedna czynność, jedno sprawdzenie. Nigdy nie robią Państwo dwóch poprawek naraz, nie zrozumieją Państwo, co zadziałało. I proszę zapisać, która konkretnie wtyczka lub poprawka wywołała błąd. Następnym razem naprawią Państwo wszystko w 30 sekund.