Jak naprawić błąd 500 w WordPress

Komunikat wewnętrzny błąd serwera potrafi sparaliżować stronę i nerwy. Gdy strona WordPress nagle wyświetla błąd 500, najczęściej winne są błędne reguły, brak zasobów lub konflikt rozszerzeń. Ten poradnik prowadzi krok po kroku: od zebrania informacji i włączenia diagnostyki, przez izolację przyczyny, po trwałe naprawy i profilaktykę. Znajdziesz tu precyzyjne instrukcje, wskazówki dla różnych paneli hostingowych oraz praktyczne checklisty, które skracają czas przestoju do minimum.

Zrozumienie błędu 500 i bezpieczny plan działania

Co naprawdę oznacza kod 500

Kod 500 Internal Server Error informuje, że serwer napotkał problem, którego nie potrafi opisać bardziej szczegółowo w odpowiedzi HTTP. Nie mówi, czy problem leży w PHP, konfiguracji serwera, bazie danych, czy w plikach aplikacji. Dlatego kluczowe jest zebranie szczegółów: komunikatów błędów, śladów stosu, fragmentów konfiguracji i informacji o ostatnich zmianach. Dopiero na ich podstawie podejmujemy decyzję o naprawie.

Najpierw bezpieczeństwo: kopia i środowisko

Zanim cokolwiek zmienisz, wykonaj kopię plików i bazy danych. Jeśli masz dostęp do panelu hostingu, skorzystaj z wbudowanego narzędzia backupów. W przeciwnym razie pobierz pliki przez SFTP oraz zrzut bazy z phpMyAdmin lub CLI. Idealnie, pracuj na stagingu: klonie witryny utrzymywanym na subdomenie lub osobnym kontenerze. Minimalizujesz ryzyko pogorszenia sytuacji i możesz testować naprawy bez wpływu na odwiedzających.

Mapa działań: od diagnozy do przywrócenia

Skuteczna naprawa 500 składa się z czterech etapów: zbieranie symptomów, izolacja źródła, zastosowanie właściwej poprawki i testy regresji. Ten schemat pozwala szybko skrócić listę podejrzanych i uniknąć zmian na oślep. W praktyce często już po pierwszej godzinie da się wskazać winowajcę, jeśli tylko poprawnie ustawisz diagnostykę i nauczysz się czytać kluczowe komunikaty.

Dlaczego 500 pojawia się nagle

Najczęstsze przyczyny to automatyczna aktualizacja wtyczki lub motywu, zmiana wersji PHP po stronie hostingu, wyczerpanie pamięci po wzroście ruchu, nowa reguła w pliku .htaccess, błędna migracja serwisu, ewentualnie nietypowe reguły WAF/ModSecurity. Rzadziej źródłem będzie uszkodzony dysk lub awaria bazy danych, choć i takie przypadki się zdarzają.

Jak minimalizować przestój

Ustaw stronę zastępczą 503 lub tryb konserwacji, jeśli musisz działać na produkcji. Zadbaj o cache na warstwie CDN, aby część treści pozostała dostępna. Ustal priorytety: najpierw przywrócenie odpowiedzi 200, potem dopiero kosmetyka. Dokumentuj kroki, które wykonujesz, by w razie potrzeby łatwo było się cofnąć.

Kiedy od razu kontaktować hosting

Jeżeli błąd 500 pojawia się przed uruchomieniem PHP (np. brak połączenia z PHP-FPM), gdy blokują Cię uprawnienia lub limity konta albo widzisz komunikaty o błędach modułów serwera, zgłoś się do wsparcia. Dostęp do dzienników na poziomie systemu znacznie przyspiesza diagnozę.

Diagnoza: jak znaleźć źródło problemu

Włącz tryb debugowania w WordPress

W pliku wp-config.php w katalogu instalacji ustaw stałe: WP_DEBUG na true, WP_DEBUG_LOG na true, WP_DEBUG_DISPLAY na false. Dzięki temu błędy trafią do wp-content/debug.log, a odwiedzający ich nie zobaczą. To pierwszy, najważniejszy krok: umożliwia wychwycenie fatal error, brakujących klas, funkcji i konfliktów wersji. W razie problemu przy autoloadzie sprawdź posiadane loader-y Composer.

Sprawdź dzienniki serwera i PHP

Jeżeli masz SSH lub panel, zajrzyj do plików dzienników. W Apache typowo: /var/log/apache2/error.log, w Nginx: /var/log/nginx/error.log, a w PHP-FPM: /var/log/php*-fpm.log. W cPanel często znajdziesz plik error_log w głównym katalogu domeny, w Plesk w katalogu logs witryny. Słowo klucz to error_log. Wpisy z dokładnym czasem i ścieżką pliku wskażą linijkę, od której zaczął się problem.

Wyizoluj konflikt wtyczek

Najbezpieczniej zmień nazwę katalogu wp-content/plugins na plugins.offline przez SFTP. Jeśli strona wstanie, masz potwierdzenie konfliktu. Przywróć nazwę i wyłącz wszystkie rozszerzenia w bazie (tabela wp_options, wpis active_plugins) lub w panelu, a następnie włączaj po kolei, testując działanie. Zwróć uwagę na wtyczki buforujące, bezpieczeństwa, SEO, integracje płatności – to częste źródła problemów. Słowo klucz: wtyczki.

Sprawdź aktywny motyw

Przełącz tymczasowo na Twenty Twenty-Three lub nowszy motyw domyślny. Zrobisz to w bazie, zmieniając szablon i stylesheet w wp_options, lub po prostu zmieniając nazwę katalogu aktywnego motywu, by WordPress przełączył się awaryjnie. Jeśli błąd znika, winny jest motyw potomny, przestarzały framework lub niestandardowe funkcje w functions.php. Słowo klucz: motyw.

Zresetuj i zweryfikuj .htaccess

Błędne reguły przepisów URL często powodują 500. Zmień nazwę .htaccess na .htaccess.bak i spróbuj wejść na stronę. Jeśli działa, wejdź do Ustawienia → Bezpośrednie odnośniki i zapisz ponownie. Jeśli korzystasz z Nginx, sprawdź bloki location i przepisy przekazujące żądania do index.php. Słowo klucz: .htaccess.

Zweryfikuj limity i wersję PHP

Błąd 500 potrafi wynikać z przekroczenia pamięci, czasu wykonania lub niekompatybilności z nową wersją PHP. W panelu hostingu sprawdź memory_limit, max_execution_time i post_max_size. Jeśli niedawno zmieniono wersję PHP, porównaj wymagania wtyczek i motywu. Często powrót z PHP 8.2 do 8.1 na czas aktualizacji łagodzi problem, a docelowo wykonujesz aktualizacje kodu.

Uprawnienia i właściciel plików

Nieprawidłowe prawa (np. 777) lub właściciel inny niż proces PHP mogą skutkować 500. Standardowo katalogi 755, pliki 644, właściciel zgodny z użytkownikiem webservera lub mechanizmem FPM. Po migracjach na nowe serwery to częsty błąd. Upewnij się, że nie blokuje Cię reguła open_basedir lub SELinux.

Odłącz cache i warstwy pośrednie

Wyłącz tymczasowo Redis, Memcached, opcache preloading oraz wtyczki cache. Usuń plik wp-content/object-cache.php. 500 bywa efektem nieaktualnego cache opcode po aktualizacji PHP. W panelu hostingu często znajdziesz przycisk do restartu PHP-FPM, który odświeża opcache.

Sprawdź zewnętrzne usługi

Niektóre wtyczki czekają na odpowiedź API i przekraczają limit czasu, zwłaszcza przy płatnościach lub analizie. Zajrzyj do dzienników, by zobaczyć, czy wątek blokuje się na curl_exec lub gniazdach. Tymczasowe odłączenie integracji pozwala szybko zweryfikować hipotezę.

Naprawa najczęstszych przyczyn

Konflikt wtyczek: plan naprawy

Po zidentyfikowaniu winnej wtyczki, sprawdź changelog i wymagania. Zaktualizuj ją do najnowszej wersji kompatybilnej z Twoim PHP. Jeśli to błąd w aktualnym wydaniu, wróć do poprzedniej wersji z repozytorium lub kopii. Na stałe ogranicz ładowanie wtyczki tylko do potrzebnych obszarów (np. wyłącz w REST, jeśli nie wymaga). Zgłoś błąd autorowi, dołączając stack trace i wersje środowiska.

Motyw: bezpieczne poprawki

Jeśli problem tkwi w motywie potomnym, przenieś niestabilne fragmenty do oddzielnych plików i testuj na motywie rodzicu. Stosuj dobry wzorzec child theme, unikaj kopiowania całych plików szablonów, jeśli zmieniasz tylko pojedyncze funkcje. Nieużywane hooki usuń, a nadpisywane funkcje zabezpiecz sprawdzeniem function_exists. Dla większych refaktorów rozważ przejście na motyw blokowy.

Reset reguł przepisywania

Gdy .htaccess był winny, usuń duplikaty bloków # BEGIN WordPress i # END WordPress. Upewnij się, że nie ma niestandardowych dyrektyw, jak php_flag czy Options, których hosting nie pozwala ustawić w katalogach użytkownika. W Nginx dopilnuj, by przekierowania nie tworzyły pętli (status 500 po 301/302 może oznaczać cichą pętlę przekierowań maskowaną przez serwer).

Braki w zasobach: pamięć i czas

Jeśli w dziennikach widzisz Allowed memory size exhausted, podnieś limit pamięci. W wp-config.php możesz dodać define(’WP_MEMORY_LIMIT’, '256M’); oraz define(’WP_MAX_MEMORY_LIMIT’, '512M’); dla panelu administracyjnego. Na hostingu często ustawisz limity w .user.ini, php.ini lub panelu. Przy długich procesach (importy, generowanie miniatur) zwiększ max_execution_time i rozważ uruchamianie z CLI.

Uszkodzone pliki rdzenia

Po przerwanych aktualizacjach zdarzają się niekompletne pliki. Prześlij ponownie katalog wp-admin i wp-includes z czystego pakietu tej samej wersji. Nie nadpisuj wp-content. Sprawdź, czy w katalogu głównym nie pozostał plik .maintenance – jego obecność wymusza tryb konserwacji i może ujawniać się jako 500 przy specyficznych konfiguracjach.

PHP i autoloadery

Jeśli widzisz błędy nieznanych klas lub funkcji, sprawdź autoloading. W projektach korzystających z Composera uruchom composer install –no-dev na środowisku zgodnym z docelową wersją PHP, a następnie prześlij vendor. Usuń przestarzałe pliki autoloadera dostarczane przez wtyczki, jeśli duplikują przestrzenie nazw. Upewnij się, że ext-intl, ext-gd czy ext-mysqli są zainstalowane.

ModSecurity i WAF

Niektóre reguły bezpieczeństwa blokują żądania do endpointów REST lub admin-ajax, zwracając 500. W dziennikach serwera odszukaj wzmianki o mod_security. Zgłoś do hostingu prośbę o wyłączenie konkretnej reguły dla Twojej domeny lub wykluczenie ścieżki, zamiast wyłączania WAF globalnie.

Object cache i opcache

Po aktualizacjach usuń pamięci podręczne: w Redis FLUSHDB na przestrzeni kluczy strony, w Memcached invalidate, a w opcache wymuś restart FPM. Jeżeli masz persistent object cache w pliku object-cache.php, sprawdź kompatybilność wersji biblioteki z rdzeniem WP i Twoimi wtyczkami.

Problemy z CRON

Jeśli 500 dotyczy tylko żądań do wp-cron.php, sprawdź, czy DISABLE_WP_CRON nie koliduje z zadaniem crontab. Przy dużym ruchu rozważ zewnętrzny CRON wywołujący cron w stałych odstępach. Zbyt wiele zadań jednocześnie potrafi wyczerpać pamięć i wywołać 500.

Baza danych i migracje

Przy migracjach upewnij się, że prefiks tabel odpowiada temu w wp-config.php, a kolacja i zestaw znaków są zgodne (utf8mb4). Błędy 500 mogą wynikać z zapytań generujących fatal error przy nieistniejących kolumnach po częściowej aktualizacji wtyczki. Uruchom skrypty instalacyjne wtyczek, jeśli wymagają migracji schematu.

Zaawansowane scenariusze i środowiska hostingowe

Nginx i PHP-FPM

Zweryfikuj, czy fastcgi_param SCRIPT_FILENAME wskazuje na właściwy index.php i czy blok location ~ .php$ nie gryzie się z innymi regułami. Monitoruj dzienniki FPM pod kątem pm.max_children reached oraz slowlog. Zbyt niski pm.max_children przy pikach ruchu potrafi generować sporadyczne 500 bez jasnych śladów w aplikacji.

Apache: moduły i dyrektywy

Na hostingu współdzielonym część dyrektyw php_flag i php_value jest zabroniona w .htaccess. Ich użycie kończy się 500. Zamień je na ustawienia w .user.ini lub panelu. Upewnij się, że mod_rewrite jest aktywny i że nie powielasz reguł przepisywania między katalogami, co może tworzyć pętle.

Proxy, CDN i Cloudflare

Rozróżnij błędy pochodzące z CDN od błędów origin. 5xx na Cloudflare z kodem 520/522 nie zawsze oznacza 500 w aplikacji – to może być timeout lub reset połączenia. Sprawdź logi po stronie origin, wyłącz chwilowo proxy (tryb DNS only), skróć łańcuchy redirectów i zwiększ timeouty połączeń do upstream.

Kontenery, Docker, orkiestracja

Sprawdź logi kontenerów: docker logs dla PHP i Nginx, upewnij się, że wolumeny z kodem są montowane z odpowiednimi uprawnieniami. W środowiskach z read-only root filesystem przenieś katalogi na dane zapisywalne (np. wp-content/uploads). Spójność wersji rozszerzeń PHP w obrazie ma krytyczne znaczenie.

Multisite i mapowanie domen

W instalacjach multisite błędne mapowanie domen oraz reguły cookie mogą generować 500 tylko dla części podsieci. Sprawdź sunrise.php, konfigurację domen w bazie i pliki .htaccess/konfigurację Nginx specyficzną dla sieci. Testuj na subdomenie głównej i porównuj nagłówki odpowiedzi.

Bedrock i niestandardowe struktury

Jeżeli używasz Bedrocka lub kompozytowej struktury katalogów, pamiętaj o poprawnych ścieżkach do wp, web i config. Nieprawidłowe ścieżki autoload lub brak environment variables (.env) powodują 500 bez wyraźnego komunikatu. Porównaj wersje zależności i upewnij się, że composer dump-autoload został wykonany na właściwej platformie.

Integracje headless i REST

W projektach headless 500 często wynika z błędów w endpointach WP REST API. Włącz logowanie żądań, sprawdź nonces, uprawnienia użytkowników i metody HTTP. Jeżeli używasz GraphQL dla WP, zweryfikuj schemat i rozdziel duże zapytania na mniejsze, aby uniknąć limitów pamięci.

Ograniczenia bezpieczeństwa na serwerze

open_basedir, disable_functions i brak niektórych rozszerzeń systemowych potrafią wywołać 500 podczas działań takich jak generowanie miniatur, kompresja ZIP czy połączenia sieciowe. Sprawdź konfigurację phpinfo w środowisku testowym i porównaj z wymaganiami wtyczek.

Twarde resetowanie i profilaktyka na przyszłość

Szybkie przywrócenie działania

Jeśli diagnoza się przeciąga, a serwis stoi, rozważ przywrócenie ostatniego stabilnego backupu, by wznowić ruch. Następnie odtwórz środowisko problematyczne na stagingu i tam kontynuuj analizę. W komunikacji z interesariuszami podaj szacowany czas oraz kroki mitigacji, by ograniczyć presję.

Testy po naprawie

Po każdej poprawce wykonaj pełny smoke test: strona główna, logowanie do wp-admin, dodanie wpisu, wyszukiwanie, formularze, płatności, Webhooks. Sprawdź konsolę przeglądarki i sieć, by upewnić się, że nie ma błędów JS, które mogłyby maskować kolejne problemy.

Monitorowanie i alerty

Skonfiguruj monitoring uptime i alerty 5xx. Połącz je z prostym heartbeat, który weryfikuje krytyczne endpointy (np. REST i admin-ajax). Logi aplikacyjne wysyłaj do centralnego systemu (np. ELK, Loki) z korelacją żądań. To skraca czas wykrycia i diagnozy przyszłych awarii.

Higiena aktualizacji

Włącz aktualizacje automatyczne tylko dla zaufanych komponentów. Duże aktualizacje wykonuj etapami na stagingu, z pomiarem wydajności i testami regresji. Utrzymuj listę kompatybilnych wersji PHP i MySQL dla Twojego stosu. Zawsze przygotowuj plan cofnięcia zmian.

Kontrola jakości kodu

Wprowadź CI/CD z testami jednostkowymi i integracyjnymi. Lintery PHPStan i PHPCS wykrywają problemy kompatybilności jeszcze przed wdrożeniem. Wtyczki custom utrzymuj w repozytorium, wersjonuj i taguj wydania. Dokumentuj wymagania zależności i proces buildowania.

Bezpieczeństwo i czystość środowiska

Regularnie skanuj witrynę pod kątem malware. Nieznany kod w uploads lub mu-plugins potrafi generować 500 i wycieki danych. Zadbaj o właściwe uprawnienia, oddziel konta SFTP, klucze SSH, oraz rotację haseł. Upewnij się, że tylko potrzebne procesy mają dostęp do plików i bazy.

Optymalizacja zasobów

Dopasuj plan hostingowy do ruchu i obciążenia. Skaluj procesy FPM, przydziel pamięć i CPU zgodnie z pikiem ruchu. Konfiguruj cache po stronie serwera i CDN tak, aby dynamiczne części były odciążone. To nie tylko zapobiega 500, ale też obniża TTFB i poprawia UX.

Dokumentacja i wiedza zespołu

Spisz procedury: jak włączyć WP_DEBUG, gdzie są logi, jak działa przełączanie serwera, procedury awaryjne i kontakty do wsparcia hostingu. Dzięki temu przy następnej awarii każdy w zespole wie, co robić, a czas reakcji drastycznie maleje.

Rewizja konfiguracji i zależności

Co kwartał przeprowadź przegląd wersji PHP, baz danych, wtyczek i motywów. Usuń to, czego nie używasz. Przejrzyj reguły w .htaccess, harmonogram CRON i automatyzacje. Regularna konserwacja eliminuje całą klasę potencjalnych awarii nim się pojawią.

Checklisty na trudne przypadki

Przygotuj krótkie listy kontrolne: izolacja wtyczki, test alternatywnego motywu, reset przepisywania, sprawdzenie błędów pamięci, restart FPM, weryfikacja error_log, test endpointów REST, zestaw minimalny wtyczek, weryfikacja wersji PHP i rozszerzeń, kontrola uprawnień. Dzięki temu nawet w stresie wykonasz poprawne kroki we właściwej kolejności.