Błąd 500 Internal Server Error w WordPressie. Kolejność sprawdzania: logi serwera, .htaccess, wtyczki, wersja PHP

Wchodzisz na stronę, a zamiast niej widzisz suchy komunikat „500 Internal Server Error”. Bez wskazówki, co się stało, bez przycisku „napraw”. Albo jeszcze gorzej: strona działa, ale panel nie. Albo wszystko jest w porządku do chwili, w której klient klika „Kupuję i płacę”.

Błąd 500 to jeden z najczęstszych problemów, z jakimi zgłaszają się do mnie właściciele stron i sklepów na WordPressie. I jednocześnie jeden z najbardziej frustrujących, bo sam komunikat nie mówi nic poza tym, że serwer „coś” zepsuł. Dobra wiadomość jest taka, że w zdecydowanej większości przypadków przyczyna siedzi w jednym z czterech miejsc, a sprawdzenie ich we właściwej kolejności zajmuje kilkanaście minut, a nie kilka dni.

W tym wpisie pokażę Ci dokładnie tę kolejność, którą sam stosuję przy każdej takiej awarii: logi, .htaccess, wtyczki i motyw, wersja PHP. Do tego to, co zrobić, gdy żaden z tych kroków nie pomógł, i jak sprawić, żeby ten błąd nie wracał.

Czym właściwie jest błąd 500

Kod 500 to ogólny sygnał od serwera: „próbowałem obsłużyć Twoje żądanie, ale po drodze coś poszło nie tak i nie powiem Ci co”. Serwer celowo nie pokazuje szczegółów w przeglądarce, bo treść błędów mogłaby zdradzić osobom z zewnątrz informacje o konfiguracji strony.

W praktyce, w WordPressie błąd 500 oznacza najczęściej jedną z dwóch rzeczy. Albo kod PHP (wtyczki, motywu lub samego WordPressa) zakończył się błędem krytycznym, albo serwer WWW nie poradził sobie z własną konfiguracją, zanim w ogóle doszedł do uruchomienia PHP. To rozróżnienie jest ważne, bo każdą z tych przyczyn szuka się w innym miejscu.

Błąd 500 a inne awarie WordPressa

Różne awarie wyglądają podobnie, a prowadzą do zupełnie innych przyczyn. Zanim zaczniesz, upewnij się, z czym masz do czynienia:

Co widzisz	Co to zwykle znaczy	Gdzie szukać
„500 Internal Server Error” na szarej stronie serwera	Błąd konfiguracji serwera albo błąd PHP, zanim WordPress się załadował	Logi serwera, .htaccess
„Wystąpił błąd krytyczny na tej stronie”	Błąd PHP, który WordPress przechwycił; serwer i tak zwraca kod 500	Błąd krytyczny w WordPressie
Biała, pusta strona	Błąd PHP przy wyłączonym wyświetlaniu błędów	Biała strona (WSOD)
„Błąd nawiązywania połączenia z bazą danych”	Problem z bazą danych, a nie z kodem	Błąd połączenia z bazą
502 lub 504	Serwer pośredniczący nie doczekał się odpowiedzi (przeciążenie, zbyt długi czas działania skryptu)	Hosting, limity zasobów
503 lub komunikat o konserwacji	Strona chwilowo wyłączona, np. przez przerwaną aktualizację albo limit zasobów	Komunikat o konserwacji nie znika

Warto wiedzieć, że „błąd krytyczny” i biała strona to pod spodem bardzo często dokładnie ten sam błąd 500, tylko inaczej podany. Dlatego ścieżka z tego wpisu przyda Ci się także w tamtych sytuacjach.

Zanim cokolwiek ruszysz: trzy rzeczy

Wiem, że przy niedziałającej stronie chce się działać od razu. Poświęć jednak dwie minuty na przygotowanie, bo oszczędzi Ci to kłopotów, jeśli coś pójdzie nie tak.

Zrób kopię zapasową. Tak, także uszkodzonej strony. Pliki i baza danych. Sprawdź też w panelu hostingu, z którego dnia jest ostatnia automatyczna kopia, żebyś wiedział, na czym stoisz.
Przygotuj dostępy. Będziesz potrzebować dostępu do plików (FTP, SFTP albo menedżer plików w panelu hostingu) oraz do samego panelu hostingu, bo tam są logi i ustawienia PHP. Przyda się też dostęp do phpMyAdmin.
Przypomnij sobie, co się ostatnio zmieniło. Aktualizacja, nowa wtyczka, kod wklejony z poradnika, przeniesienie strony na inny serwer, zmiana wersji PHP. Błąd 500 bardzo rzadko pojawia się „z niczego”. Pamiętaj też, że część zmian robi za Ciebie hosting albo automatyczne aktualizacje.

Krok 0: ustal, gdzie dokładnie pojawia się błąd

To pytanie zadaję zawsze jako pierwsze, bo samo miejsce występowania błędu bardzo zawęża listę podejrzanych:

Cała strona i panel administracyjny. Problem jest globalny: .htaccess, wersja PHP albo wtyczka ładowana na każdej podstronie.
Tylko panel wp-admin, a strona działa. Najczęściej wtyczka lub motyw działający w panelu albo limit pamięci PHP.
Tylko przy jednej czynności, np. zapisie wpisu, wgrywaniu zdjęcia, płatności w sklepie albo w edytorze strony. Wtedy winna jest zwykle konkretna wtyczka lub limit serwera. Przy zapisywaniu w edytorze błąd 500 często widzisz nie wprost, tylko jako komunikat „Updating failed. The response is not a valid JSON response”.
Sporadycznie, w różnych miejscach. To sygnał, że strona dobija do limitów zasobów na hostingu.

Jest też prosty trik, który pokazuje, który dokładnie adres zwraca błąd. W przeglądarce naciśnij F12, przejdź do zakładki „Sieć” (Network) i odśwież stronę albo powtórz czynność, która wywołuje błąd. Żądanie z kodem 500 będzie oznaczone na czerwono. Często okazuje się, że strona ładuje się poprawnie, a błąd zwraca tylko admin-ajax.php albo jakiś adres /wp-json/, czyli konkretna funkcja konkretnej wtyczki.

Krok 1: logi, czyli zamiast zgadywać, przeczytaj

To krok, który większość poradników w internecie pomija albo wrzuca na sam koniec, po „wyłącz wszystkie wtyczki”. Ja zaczynam od niego zawsze. Log bardzo często podaje przyczynę wprost, razem ze ścieżką do pliku, który zawiódł, i numerem linii. Pięć minut z logiem oszczędza godzinę wyłączania wtyczek na ślepo.

Gdzie znaleźć logi

W panelu hostingu. Szukaj sekcji „Logi”, „Error log” albo „Dziennik błędów”. Uważaj, żeby otworzyć log błędów (error log), a nie log odwiedzin (access log). Log odwiedzin powie Ci tylko, że błąd wystąpił, ale nie dlaczego.
W plikach strony. Niektóre hostingi zapisują błędy PHP do pliku error_log w katalogu głównym strony albo w katalogu wp-admin.
W logu WordPressa, czyli w pliku debug.log, który możesz włączyć samodzielnie.

Jak włączyć debug.log w WordPressie

Otwórz plik wp-config.php w głównym katalogu strony i znajdź linię define( 'WP_DEBUG', false );. Zamień ją na poniższy fragment. Jeśli takiej linii nie ma, wklej go powyżej komentarza „To wszystko, zakończ edycję!” (w angielskiej wersji: „That’s all, stop editing!”).

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

Dzięki temu błędy będą zapisywane do pliku wp-content/debug.log, ale nie będą wyświetlane odwiedzającym. Teraz odśwież stronę z błędem, otwórz ten plik i przewiń na sam koniec. Najświeższe wpisy są na dole.

Ważne: po zakończeniu diagnozy przywróć WP_DEBUG na false i usuń plik debug.log. Domyślnie da się go otworzyć z przeglądarki, więc każdy, kto zna jego adres, może przeczytać ścieżki do plików i fragmenty konfiguracji Twojej strony. Poza tym potrafi urosnąć do setek megabajtów.

Jeśli po odświeżeniu debug.log w ogóle się nie pojawił albo jest pusty, to też jest informacja. Oznacza, że błąd występuje, zanim WordPress zdążył się uruchomić. Wtedy przyczyny szukaj w logu serwera i w kroku 2.

Jak czytać log

Typowy wpis wygląda mniej więcej tak:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/uzytkownik/public_html/wp-content/plugins/stara-wtyczka/includes/functions.php:42

Na co patrzę w takim wpisie:

Rodzaj błędu. Liczą się wpisy Fatal error i Parse error. Komunikaty Warning, Notice i Deprecated zwykle nie są przyczyną błędu 500, choć potrafią zalać log setkami linii. Nie daj się im rozproszyć.
Ścieżkę do pliku. Jeśli zawiera /wp-content/plugins/nazwa/, winna jest ta wtyczka. Jeśli /wp-content/themes/nazwa/, motyw. Jeśli /wp-includes/ lub /wp-admin/, błąd wystąpił w rdzeniu WordPressa, ale bardzo często wywołała go wtyczka. Wtedy czytaj dalsze linie (tzw. stack trace), aż trafisz na katalog wtyczki lub motywu.
Godzinę. Upewnij się, że wpis pochodzi z chwili, w której odświeżałeś stronę, a nie sprzed trzech tygodni.

Najczęstsze komunikaty i co oznaczają

Fragment komunikatu	Przyczyna	Co zrobić
`Allowed memory size of … bytes exhausted`	Skończył się limit pamięci PHP	Zwiększ limit pamięci i sprawdź, czy to coś da
`Maximum execution time of 30 seconds exceeded`	Skrypt działał za długo: import, ciężka wtyczka, wolne zapytania do bazy	Zwiększ `max_execution_time` w panelu hostingu i znajdź proces, który trwa tak długo
`Call to undefined function`, `syntax error, unexpected`	Kod niezgodny z wersją PHP albo uszkodzony plik	Krok 3 i krok 4
`Cannot redeclare`	Ta sama funkcja zdefiniowana dwa razy, np. dwie kopie wtyczki albo kod wklejony do functions.php	Usuń duplikat
`Invalid command`, `not allowed here` (log serwera)	Niedozwolona dyrektywa w pliku .htaccess	Krok 2
`Permission denied`	Złe uprawnienia plików lub katalogów	Krok 5
`End of script output before headers`	Proces PHP został przerwany, często przez limit hostingu albo złe uprawnienia	Krok 5

Krok 2: plik .htaccess

Jeśli log WordPressa jest pusty albo w logu serwera widzisz błąd konfiguracji, następny w kolejce jest plik .htaccess. To plik konfiguracyjny serwera Apache oraz LiteSpeed, na którym działa wiele polskich hostingów. Wystarczy w nim jedna literówka i serwer odmawia obsłużenia czegokolwiek, zanim WordPress w ogóle się uruchomi.

Plik zaczyna się od kropki, więc jest ukryty. W kliencie FTP albo w menedżerze plików włącz pokazywanie plików ukrytych. Jeśli Twój serwer działa wyłącznie na Nginx, plik .htaccess nie jest w ogóle używany i ten krok możesz pominąć.

Test, który zajmuje minutę

Zmień nazwę pliku .htaccess na .htaccess_stary. Nie usuwaj go, bo będziesz go jeszcze potrzebować.
Odśwież stronę główną.
Jeśli strona główna się wczytała, winny jest .htaccess. Podstrony mogą teraz zwracać błąd 404, to normalne na tym etapie.
Zaloguj się do panelu, wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany”, niczego nie zmieniając. WordPress utworzy nowy, czysty plik .htaccess.
Porównaj nowy plik ze starym i przenoś z powrotem tylko te reguły, których naprawdę potrzebujesz i które rozumiesz. Po jednej, testując stronę po każdej.

Tak wygląda domyślna zawartość pliku .htaccess dla WordPressa zainstalowanego w głównym katalogu domeny:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Co najczęściej psuje .htaccess

Dyrektywy php_value i php_flag, np. php_value memory_limit 256M wklejone z jakiegoś poradnika. Na serwerach, gdzie PHP działa w trybie FPM lub CGI (czyli na większości współczesnych hostingów), są niedozwolone i dają błąd 500 natychmiast. Limity PHP ustawiasz wtedy w panelu hostingu albo w pliku .user.ini.
Reguły pozostawione przez wtyczki cache, bezpieczeństwa i przekierowań. Wtyczka została usunięta, a jej reguły zostały w pliku i odwołują się do czegoś, czego już nie ma. Albo dwie wtyczki dopisały reguły, które się wykluczają.
Ręcznie dopisane przekierowania, np. wymuszanie HTTPS albo wersji z www, z błędem w składni.
Kod wstrzyknięty po włamaniu. Długie reguły z obcymi domenami, przekierowania tylko dla telefonów albo tylko dla odwiedzających z Google. Jeśli coś takiego widzisz, sama naprawa .htaccess nie wystarczy, bo złośliwy kod siedzi też gdzie indziej. Opisałem to w poradniku jak odwirusować stronę na WordPressie.

Krok 3: wtyczki i motyw

Z mojego doświadczenia wynika, że to właśnie tutaj najczęściej kończy się poszukiwanie przyczyny. Jeśli log z kroku 1 wskazał konkretną wtyczkę, sprawa jest prosta: przez FTP zmień nazwę jej katalogu, np. wp-content/plugins/nazwa-wtyczki na nazwa-wtyczki_off. WordPress nie znajdzie jej plików i automatycznie ją dezaktywuje. Odśwież stronę i gotowe.

Gdy log nie wskazał winnego

W katalogu wp-content zmień nazwę katalogu plugins na plugins_off. Wszystkie wtyczki zostaną dezaktywowane.
Odśwież stronę. Jeśli działa, winna jest jedna z wtyczek.
Przywróć katalogowi nazwę plugins. Wtyczki pozostaną nieaktywne.
Zaloguj się do panelu i aktywuj wtyczki po jednej, odświeżając stronę po każdej. Zacznij od tych, które były ostatnio aktualizowane lub dodane. Ta, po której wraca błąd 500, jest winowajcą.

Jeśli masz kilkadziesiąt wtyczek, możesz przyspieszyć sprawę metodą połówkową: aktywuj połowę naraz. Jeśli błąd wraca, szukasz w tej połowie, jeśli nie, w drugiej. Kilka takich podziałów i masz winowajcę.

Dezaktywacja wtyczki nie usuwa jej ustawień ani danych, więc nie musisz się tego obawiać. W sklepie pamiętaj jednak, że wyłączenie wszystkich wtyczek oznacza też wyłączenie WooCommerce, czyli sklep na czas testu nie działa. Jeśli możesz, rób to na kopii strony (stagingu), a jeśli nie, rób to sprawnie i poza godzinami największego ruchu.

Nie zapomnij o mu-plugins i drop-inach

To miejsca, o których zapomina większość osób, a ja trafiam w nie zaskakująco często:

Katalog wp-content/mu-plugins. Tak zwane wtyczki „must use” ładują się zawsze, nie widać ich na zwykłej liście wtyczek i zmiana nazwy katalogu plugins ich nie wyłącza. Często umieszczają tam coś hostingi oraz wtyczki cache i bezpieczeństwa.
Drop-iny bezpośrednio w wp-content: pliki object-cache.php, advanced-cache.php i db.php. Typowy scenariusz: ktoś usunął wtyczkę cache albo przeniósł stronę na inny serwer, a w wp-content został object-cache.php, który próbuje połączyć się z Redisem, którego już nie ma. Efekt to błąd 500 na całej stronie. Test jest prosty: tymczasowo zmień nazwę pliku i odśwież stronę.

Motyw

Jeśli wtyczki są czyste, sprawdź motyw. Zmień nazwę katalogu aktywnego motywu w wp-content/themes. WordPress przełączy się wtedy na motyw domyślny (np. Twenty Twenty-Five), o ile jest zainstalowany. Jeśli nie ma żadnego, wgraj go przez FTP.

Najczęstsze przyczyny po stronie motywu to kod dopisany do pliku functions.php z błędem składni oraz aktualizacja motywu, która nie dogaduje się z resztą strony. Ten drugi scenariusz opisałem szerzej we wpisie strona rozsypała się po aktualizacji wtyczki lub motywu. Jeśli korzystasz z Elementora i błąd pojawia się głównie w edytorze, zajrzyj też do wpisu Elementor nie działa: szybka diagnoza.

Jedna rada, którą powtarzam każdemu klientowi: nigdy nie edytuj functions.php przez wbudowany edytor plików w panelu WordPressa. Jeden brakujący średnik i tracisz dostęp do całej strony, łącznie z edytorem, którym mógłbyś ten błąd poprawić.

Krok 4: wersja PHP

Ostatni z czterech głównych podejrzanych, a w ostatnich latach coraz częstszy. Hostingi regularnie wycofują stare wersje PHP i przenoszą klientów na nowsze. Czasem informują o tym mailem, który ląduje w spamie, czasem wcale. Efekt: strona działała wczoraj, dziś zwraca błąd 500, a nikt niczego nie aktualizował.

Problem z wersją PHP występuje w dwóch odmianach:

PHP jest za nowe dla kodu strony. Stara wtyczka lub motyw używa funkcji, które w PHP 8 zostały usunięte, np. create_function() albo each(). W logu zobaczysz Call to undefined function, Uncaught TypeError albo ArgumentCountError.
PHP jest za stare dla kodu strony. Zaktualizowana wtyczka wymaga nowszej wersji PHP, niż masz na serwerze, i używa składni, której stare PHP nie rozumie. W logu zobaczysz syntax error, unexpected.

Wersję PHP sprawdzisz i zmienisz w panelu hostingu, zwykle w sekcji „PHP”, „Wersja PHP” albo „Konfiguracja PHP”. Zwróć uwagę, czy ustawienie dotyczy całego konta, czy konkretnej domeny, bo na wielu hostingach można to ustawić osobno.

Jak to przetestować:

Zanotuj obecną wersję PHP.
Tymczasowo przełącz na wersję, na której strona ostatnio działała.
Odśwież stronę. Jeśli wróciła, znalazłeś przyczynę.

Pamiętaj, że to rozwiązanie doraźne, a nie docelowe. Stara wersja PHP nie dostaje już poprawek bezpieczeństwa. Docelowo trzeba zaktualizować albo wymienić wtyczkę lub motyw, który się sypie, i wrócić na wspieraną wersję PHP.

Przy zmianie wersji zdarza się też, że brakuje włączonych rozszerzeń PHP, np. mysqli, intl, gd albo imagick. Każda wersja PHP ma na wielu hostingach osobną listę rozszerzeń, więc po przełączeniu warto sprawdzić, czy wszystkie potrzebne są zaznaczone. Przy okazji zajrzyj do limitu pamięci, bo on również bywa ustawiany osobno dla każdej wersji.

Krok 5: gdy cztery główne kroki nie pomogły

Jeśli logi, .htaccess, wtyczki, motyw i PHP są w porządku, a błąd dalej jest, sprawdzam kolejno poniższe rzeczy.

Uprawnienia plików

Standardowe uprawnienia dla WordPressa to 755 dla katalogów, 644 dla plików i 640 lub 600 dla wp-config.php (zależnie od hostingu). Uprawnienia zbyt restrykcyjne blokują dostęp, ale zbyt liberalne też bywają problemem. Na części serwerów PHP odmawia uruchomienia skryptu, który ma uprawnienia 777, i zwraca właśnie błąd 500. Taki stan często zostaje po migracji albo po „naprawie”, w której ktoś ustawił 777 na wszystkie pliki, „żeby działało”.

Uszkodzone pliki WordPressa

Przerwana aktualizacja, nieudana migracja albo problem z dyskiem na serwerze mogą zostawić niekompletne pliki rdzenia. Często idzie to w parze z tym, że komunikat o konserwacji nie znika. Rozwiązanie: pobierz z pl.wordpress.org dokładnie tę samą wersję WordPressa, której używasz, i wgraj na serwer katalogi wp-admin i wp-includes, nadpisując istniejące. Nie ruszaj katalogu wp-content ani pliku wp-config.php, bo tam są Twoje treści i ustawienia.

Limity zasobów hostingu

Hosting współdzielony ma limity procesora, pamięci, liczby jednoczesnych procesów, a nawet liczby plików na koncie. Po ich przekroczeniu serwer zaczyna odrzucać żądania kodem 500, 503 albo 508. Charakterystyczne jest to, że błąd pojawia się sporadycznie: w godzinach szczytu, przy imporcie produktów, przy wzmożonym ruchu botów. Statystyki zużycia zasobów znajdziesz w panelu hostingu. Jeśli wykres dobija do sufitu, przyczyną nie jest błąd w kodzie, tylko strona, która potrzebuje więcej, niż dostaje. Więcej o tym pisałem w artykule dlaczego mój sklep WooCommerce działa wolno oraz w zestawieniu najczęstszych przyczyn awarii strony.

Firewall hostingu (mod_security)

Wiele hostingów ma zaporę aplikacyjną, która blokuje żądania wyglądające na atak. Czasem blokuje też zupełnie niewinne rzeczy, np. zapis wpisu zawierającego fragment kodu albo wysłanie konkretnego formularza. Objaw: błąd 500 (lub 403) tylko przy tej jednej czynności, a w logu serwera wpis z „ModSecurity” i numerem reguły. Rozwiązanie: wyślij hostingowi numer reguły i poproś o jej wyłączenie dla Twojej domeny. Nie wyłączaj całej zapory, bo ona naprawdę chroni Twoją stronę.

Baza danych

Uszkodzone tabele w bazie potrafią dać błąd 500 zamiast klasycznego komunikatu o problemie z bazą danych. Jak to sprawdzić i naprawić, opisałem w ścieżce diagnostycznej dla błędu nawiązywania połączenia z bazą danych.

Złośliwy kod

Jeśli podczas szukania przyczyny trafisz na nieznany kod w plikach rdzenia, pliki o dziwnych nazwach albo pliki PHP w katalogu wp-content/uploads (tam nie powinno być żadnego pliku PHP), błąd 500 jest najmniejszym z Twoich problemów. Wtedy trzeba stronę porządnie wyczyścić i zabezpieczyć: jak odwirusować stronę WordPress.

Błąd 500 tylko w jednym miejscu: szybka ściąga

Gdzie występuje błąd	Najczęstsza przyczyna	Od czego zaczynam
Tylko w panelu wp-admin	Wtyczka działająca w panelu, limit pamięci	Log, limit pamięci PHP
Przy zapisie wpisu lub strony	Wtyczka podpięta pod zapis, firewall hostingu, REST API	Błąd „not a valid JSON response”
W edytorze Elementora	Limit pamięci, konflikt dodatków do Elementora	Diagnoza Elementora
W koszyku lub przy płatności	Wtyczka bramki płatności lub dostawy, konflikt z motywem	Log z chwili składania zamówienia, konfiguracja płatności
Przy wgrywaniu plików	Limity uploadu, brak rozszerzenia GD lub Imagick, uprawnienia katalogu uploads	Log, uprawnienia, rozszerzenia PHP
Przy logowaniu	Wtyczka bezpieczeństwa, uszkodzone ciasteczka lub sesje	Problemy z logowaniem do wp-admin
Sporadycznie, w różnych miejscach	Limity zasobów hostingu, ruch botów, ciężkie zadania cron	Statystyki zasobów w panelu hostingu

Jak sprawić, żeby błąd 500 nie wracał

Większość błędów 500, które naprawiam, dało się uniknąć kilkoma prostymi nawykami:

Aktualizuj na kopii strony albo przynajmniej z kopią zapasową zrobioną chwilę wcześniej. Wtedy powrót do działającej wersji to kwestia minut, co opisałem w poradniku jak wrócić do działającej wersji po aktualizacji.
Aktualizuj partiami, a nie wszystko jednym kliknięciem. Jeśli coś się zepsuje, od razu wiesz, co.
Pilnuj wersji PHP. Czytaj komunikaty od hostingu i testuj zmianę wersji na kopii, zanim hosting zrobi ją za Ciebie.
Wyłącz edytor plików w panelu WordPressa, dopisując do wp-config.php linię define( 'DISALLOW_FILE_EDIT', true );. To chroni zarówno przed przypadkowym błędem, jak i przed atakującym, który zdobył dostęp do panelu.
Usuwaj nieużywane wtyczki, zamiast je tylko dezaktywować. Każda wtyczka leżąca na serwerze to kod, który może się kiedyś zepsuć albo zostać wykorzystany do ataku.
Włącz monitoring dostępności. Darmowe narzędzia sprawdzają stronę co kilka minut i wysyłają powiadomienie, gdy przestanie działać. Lepiej dowiedzieć się o awarii po pięciu minutach od maila niż po dwóch dniach od klienta.
Zaglądaj czasem do logów, nie tylko w kryzysie. Ostrzeżenia typu Deprecated to zapowiedź błędu krytycznego, który pojawi się przy następnej zmianie wersji PHP.

Ściąga: kolejność diagnozy w pigułce

Ustal, gdzie występuje błąd: cała strona, sam panel czy jedna czynność.
Przeczytaj log serwera i debug.log.
Sprawdź .htaccess: zmień nazwę i wygeneruj nowy plik.
Wyłącz wtyczki, sprawdź mu-plugins i drop-iny, potem motyw.
Sprawdź wersję PHP i włączone rozszerzenia.
Uprawnienia, pliki rdzenia, limity hostingu, firewall, baza danych.

Najczęściej zadawane pytania

Czy błąd 500 oznacza, że straciłem dane?

Nie. W ogromnej większości przypadków treści, zamówienia, konta klientów i ustawienia są w bazie danych nienaruszone. Problem dotyczy tego, jak serwer wykonuje kod, a nie samych danych. Dlatego nie warto w panice przywracać kopii sprzed tygodnia.

Czy mogę po prostu przywrócić kopię zapasową?

Możesz i czasem to najszybsza droga. Ale bez znajomości przyczyny błąd często wraca przy następnej aktualizacji. W sklepie dochodzi jeszcze jedna rzecz: przywrócenie kopii sprzed kilku dni oznacza utratę zamówień i kont klientów założonych w tym czasie. Najpierw diagnoza, potem decyzja.

Czy błąd 500 szkodzi pozycjom w Google?

Krótka awaria nie. Jeśli jednak strona zwraca błąd 500 przez dłuższy czas, Google zaczyna ją rzadziej odwiedzać, a po kilku dniach może zacząć usuwać podstrony z wyników wyszukiwania. Do tego dochodzą utraceni klienci, którzy w tym czasie trafili na niedziałającą stronę. Im szybciej to naprawisz, tym lepiej.

Hosting twierdzi, że u nich wszystko działa. Co dalej?

Często to formalnie prawda: serwer działa, a problem jest w kodzie strony. Zamiast ogólnego „strona nie działa” zadaj supportowi konkretne pytania: poproś o fragment logu błędów z określonej godziny i adresu, zapytaj, czy ostatnio zmieniana była wersja PHP lub konfiguracja serwera, i czy Twoje konto nie przekracza limitów zasobów. Na takie pytania support odpowiada szybko i rzeczowo.

Kiedy warto oddać to w ręce specjalisty

Ścieżka opisana w tym wpisie pozwala samodzielnie rozwiązać większość przypadków błędu 500. Są jednak sytuacje, w których lepiej nie eksperymentować: log wskazuje na coś, czego nie rozumiesz, w plikach widzisz podejrzany kod albo chodzi o sklep, w którym każda godzina przestoju to utracone zamówienia.

Wtedy po prostu napisz do mnie. Diagnozuję i naprawiam takie awarie na co dzień, zaczynając od dokładnie tych samych logów, które opisałem wyżej, tylko szybciej, bo wiem, czego szukać. Ustalę przyczynę, naprawię ją i powiem Ci, co zrobić, żeby problem nie wrócił.