Błąd 500 w WordPressie. Jak ustalić przyczynę, gdy ekran nic nie podpowiada?

Błąd 500 to jeden z najbardziej niewdzięcznych komunikatów, jakie może wyświetlić strona na WordPressie. Zamiast witryny pojawia się krótki napis w rodzaju „Internal Server Error” albo „HTTP ERROR 500”, czasem zupełnie pusta karta. Ekran nie mówi, co się zepsuło, gdzie i dlaczego. Mówi tylko tyle, że serwer próbował przygotować stronę i mu się to nie udało.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się swoją stroną. Nie wymaga znajomości programowania. Wymaga dostępu do panelu hostingu oraz cierpliwości, bo przyczynę ustala się metodą kolejnych wykluczeń, a nie zgadywaniem.

Po lekturze czytelnik będzie umiał odczytać dziennik błędów, w którym serwer zapisuje to, czego nie pokazuje na ekranie, sprawdzić po kolei cztery najczęstsze przyczyny, naprawić każdą z nich i upewnić się, że strona wróciła do pełnej sprawności. Opisuję też, co przygotować dla pomocy technicznej hostingu, gdy samodzielne kroki nie wystarczą.

Po czym rozpoznać błąd 500 i czym różni się od podobnych awarii?

Liczba 500 to kod odpowiedzi serwera. Oznacza błąd wewnętrzny: serwer otrzymał prośbę o stronę, zaczął ją przygotowywać i w trakcie natrafił na przeszkodę, której nie potrafił obejść. Wygląd komunikatu zależy od serwera i przeglądarki. Raz jest to angielski napis „Internal Server Error”, innym razem „Ta strona nie działa” z dopiskiem „HTTP ERROR 500”, a czasem biała karta bez żadnej treści.

Dla diagnozy ważne jest, aby nie pomylić tego błędu z innymi, bo każdy z nich ma inne źródło. Komunikat „Błąd podczas nawiązywania połączenia z bazą danych” wskazuje na bazę danych, a nie na pliki strony. Błędy 502, 503 i 504 mówią zwykle o przeciążeniu albo niedostępności serwera i najczęściej leżą po stronie hostingu. Błąd 404 oznacza brak konkretnej podstrony, a nie awarię całej witryny.

WordPress ma też własny mechanizm ochronny. Gdy wykryje poważny błąd w kodzie wtyczki lub motywu, pokazuje napis „W witrynie wystąpił błąd krytyczny” i wysyła wiadomość na adres administratora. Ten przypadek omawiam osobno we wpisie o tym, jak znaleźć wtyczkę, która wywołała błąd krytyczny. Jeżeli natomiast ekran jest całkowicie pusty i nie ma na nim nawet kodu błędu, pomocny będzie tekst o tym, jak przywrócić stronę, gdy wyświetla się biały ekran.

Przed rozpoczęciem pracy trzeba ustalić zasięg awarii, ponieważ już on zawęża listę podejrzanych. Należy otworzyć stronę główną, dowolną podstronę oraz adres logowania do panelu, najlepiej w oknie prywatnym przeglądarki i na drugim urządzeniu, na przykład na telefonie korzystającym z sieci komórkowej.

• Błąd na wszystkich adresach, łącznie z panelem, wskazuje zwykle na plik .htaccess, brak pamięci, wersję PHP albo wtyczkę ładowaną na każdej stronie.
• Błąd tylko w panelu administracyjnym najczęściej oznacza wtyczkę działającą w zapleczu albo zbyt niski limit pamięci.
• Błąd tylko przy jednej czynności, na przykład przy wysyłaniu zdjęcia lub zapisywaniu wpisu, kieruje uwagę na limity serwera albo uprawnienia do plików.
• Błąd, który pojawia się i znika bez żadnych zmian na stronie, sugeruje chwilowe wyczerpanie zasobów konta hostingowego.

Co przygotować, zanim zacznie się cokolwiek zmieniać?

Największe szkody przy błędzie 500 powstają nie z powodu samej awarii, tylko z powodu pośpiesznych napraw. Usunięty folder, nadpisany plik konfiguracyjny albo skasowana wtyczka z ustawieniami potrafią zamienić usterkę na kwadrans w odtwarzanie strony przez kilka dni. Dlatego pierwsze czynności nie dotyczą naprawy, tylko zabezpieczenia.

Potrzebny jest dostęp do plików strony. Daje go menedżer plików w panelu hostingu albo program do połączeń FTP, do którego dane logowania podaje firma hostingowa. Wszystkie opisane niżej czynności da się wykonać jednym i drugim sposobem. Pliki WordPressa znajdują się w głównym katalogu strony, który u wielu dostawców nazywa się public_html albo nosi nazwę domeny.

Przed pierwszą zmianą należy wykonać kopię. Jeśli hosting udostępnia własne kopie bezpieczeństwa, trzeba sprawdzić w panelu, z jakiego dnia pochodzi ostatnia. Niezależnie od tego radzę pobrać na dysk dwa pliki z głównego katalogu: .htaccess oraz wp-config.php. To właśnie one będą za chwilę edytowane. Jak przygotować pełną kopię i upewnić się, że da się z niej odtworzyć stronę, opisuję we wpisie o kopii zapasowej WordPressa.

Trzecia rzecz to krótka notatka: co zmieniło się na stronie tuż przed awarią. Aktualizacja wtyczki, nowy motyw, przekierowanie dopisane do pliku, zmiana wersji PHP w panelu hostingu, przeniesienie strony na inny serwer. W zdecydowanej większości przypadków, z którymi mam do czynienia, błąd 500 pojawia się zaraz po jakiejś zmianie, a cofnięcie tej jednej zmiany przywraca stronę. Jeśli wiadomo, co to było, diagnozę warto zacząć właśnie od tego miejsca.

Jak odczytać dziennik błędów serwera?

Ekran milczy, ale serwer zapisuje przyczynę każdego błędu 500 w dzienniku błędów. To zwykły plik tekstowy, w którym każdy wiersz zawiera godzinę zdarzenia, rodzaj błędu oraz ścieżkę do pliku, w którym on wystąpił. Odczytanie tego wiersza skraca diagnozę z godzin do minut, dlatego zawsze zaczynam od niego, a dopiero potem sięgam po metodę prób.

Położenie dziennika zależy od dostawcy. W panelach hostingowych szuka się go w części poświęconej statystykom, logom albo konfiguracji PHP, pod nazwą zbliżoną do „Dziennik błędów”, „Logi błędów” lub „Error log”. Część serwerów zapisuje go także jako plik error_log w głównym katalogu strony albo w folderze logs poziom wyżej. Jeżeli w panelu nie widać takiego miejsca, najszybciej zapytać pomoc techniczną, gdzie znajduje się dziennik błędów PHP dla danej domeny.

1. Należy otworzyć stronę w przeglądarce i odświeżyć ją, tak aby błąd 500 wystąpił ponownie. Dobrze jest zapisać dokładną godzinę tej próby.
2. W panelu hostingu trzeba otworzyć dziennik błędów dla domeny i przejść na jego koniec, do najnowszych wpisów.
3. Należy odszukać wiersze z zapisaną przed chwilą godziną. Jeśli dziennik podaje czas w innej strefie, pomocne będzie ponowne odświeżenie strony i obserwowanie, który wiersz przybył.
4. Znaleziony wiersz kopiuje się w całości do notatki. Najważniejsze są w nim dwa elementy: opis błędu oraz ścieżka do pliku.
5. Ścieżkę czyta się od folderu wp-content. Fragment /wp-content/plugins/nazwa/ wskazuje konkretną wtyczkę, a /wp-content/themes/nazwa/ konkretny motyw.

Treść wpisu zwykle wprost nazywa przyczynę, choć po angielsku. Poniżej zestawiam sformułowania, które pojawiają się najczęściej, razem z ich znaczeniem.

• Allowed memory size of ... bytes exhausted – skrypt zużył całą przydzieloną pamięć. Naprawa polega na podniesieniu limitu pamięci albo wyłączeniu wtyczki, która zużywa jej zbyt wiele.
• PHP Fatal error: Uncaught Error lub PHP Parse error ze ścieżką do wtyczki albo motywu – błąd w kodzie tego dodatku, często po aktualizacji lub przy niezgodnej wersji PHP.
• Call to undefined function – kod korzysta z funkcji, której nie ma, bo brakuje rozszerzenia PHP, innej wtyczki albo pliki są niekompletne.
• Invalid command, RewriteRule: bad flag albo wzmianka o .htaccess – serwer nie rozumie jednego z wierszy pliku .htaccess.
• Maximum execution time of ... seconds exceeded – skrypt pracował dłużej, niż pozwala serwer. Dotyczy zwykle importów, kopii i ciężkich operacji w panelu.
• Permission denied albo failed to open stream – serwer nie może odczytać lub zapisać pliku, najczęściej z powodu złych uprawnień albo braku pliku.

Jeśli dziennik wskazał konkretną przyczynę, można przejść od razu do sekcji, która jej dotyczy. Jeśli dziennik jest pusty albo hosting go nie udostępnia, pozostaje dziennik samego WordPressa, opisany niżej.

Jak włączyć dziennik WordPressa, gdy serwer nic nie pokazuje?

WordPress ma wbudowany tryb diagnostyczny. Włącza się go trzema wierszami w pliku wp-config.php. Po ich dopisaniu system zapisuje wszystkie błędy PHP do pliku debug.log w folderze wp-content, a jednocześnie nie pokazuje ich odwiedzającym.

Oficjalna dokumentacja WordPressa zaznacza, że narzędzi diagnostycznych nie zaleca się używać na działającej, publicznej stronie. Powód jest prosty: komunikaty błędów zdradzają ścieżki do plików i nazwy wtyczek. Dlatego opisuję ustawienie, w którym błędy trafiają wyłącznie do pliku, które należy traktować jako włączone na czas diagnozy, a nie na stałe.

1. W menedżerze plików należy otworzyć do edycji plik wp-config.php z głównego katalogu strony. Wcześniej trzeba mieć jego kopię na dysku.
2. Należy odszukać wiersz z komentarzem kończącym część do edycji. W polskiej wersji zaczyna się on od słów „To wszystko, zakończ edycję”, w angielskiej od „That’s all, stop editing”.
3. Jeśli w pliku istnieje już wiersz define( 'WP_DEBUG', false );, należy go zastąpić, a nie dopisywać drugi. Dwie definicje tej samej stałej same wywołują ostrzeżenia.
4. Powyżej odszukanego komentarza wstawia się poniższe wiersze i zapisuje plik.
5. Następnie trzeba odświeżyć stronę z błędem, a potem otworzyć plik wp-content/debug.log. Najnowsze wpisy znajdują się na końcu.

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

W pliku debug.log pojawi się wiele wierszy o różnej wadze. Wpisy oznaczone jako Notice, Warning i Deprecated to uwagi, które same nie zatrzymują strony. Błąd 500 wywołują wpisy Fatal error oraz Parse error i to ich należy szukać. Czyta się je tak samo jak dziennik serwera: opis błędu i ścieżka do pliku.

Zdarza się, że plik debug.log w ogóle nie powstaje. To również jest informacja. Oznacza, że awaria następuje, zanim WordPress zdąży się uruchomić, a więc najpewniej w pliku .htaccess, w ustawieniach PHP na serwerze albo w samym pliku wp-config.php, na przykład przez przypadkowo usunięty średnik lub cudzysłów.

Kto woli nie zaglądać do plików serwera i dzienników, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: odczytam dzienniki, wskażę plik lub ustawienie, które wywołuje błąd 500, i przywrócę działanie strony bez utraty treści.

Jak sprawdzić, czy winny jest plik .htaccess?

Według dokumentacji WordPressa najbardziej prawdopodobną przyczyną błędu „Internal Server Error” jest uszkodzony plik .htaccess. To plik konfiguracyjny serwera Apache i zgodnych z nim serwerów LiteSpeed. Zapisują w nim swoje reguły sam WordPress, wtyczki pamięci podręcznej, wtyczki bezpieczeństwa, a także osoby dodające ręcznie przekierowania. Jeden błędny znak w dowolnym wierszu wyłącza całą witrynę, łącznie z panelem.

Plik zaczyna się od kropki, dlatego bywa ukryty. W menedżerze plików trzeba włączyć pokazywanie ukrytych plików, a w programie FTP opcję wymuszenia ich wyświetlania. Na serwerach Nginx plik ten nie jest używany, więc jeśli hosting działa wyłącznie na Nginx, tę sekcję można pominąć.

1. W głównym katalogu strony należy odszukać plik .htaccess i zmienić jego nazwę na .htaccess_old. Pliku nie należy kasować, bo zawiera reguły, które mogą być jeszcze potrzebne.
2. Należy odświeżyć stronę główną. Jeśli się wyświetla, przyczyna została znaleziona.
3. Po zalogowaniu do panelu trzeba otworzyć „Ustawienia”, a następnie „Bezpośrednie odnośniki”.
4. Bez zmieniania czegokolwiek należy kliknąć „Zapisz zmiany”. WordPress utworzy nowy, poprawny plik .htaccess.
5. Na koniec trzeba otworzyć kilka podstron i wpisów. Jeżeli działają, nowy plik jest kompletny.

Gdyby WordPress nie mógł utworzyć pliku samodzielnie, można założyć go ręcznie i wkleić podstawowy zestaw reguł z dokumentacji, właściwy dla strony zainstalowanej 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

Strona działa, ale to jeszcze nie koniec. W starym pliku mogły znajdować się przekierowania, reguły wymuszające połączenie szyfrowane albo ustawienia wtyczki pamięci podręcznej. Reguły wtyczek odtworzą się po ponownym zapisaniu ich ustawień w panelu. Własne przekierowania trzeba przenieść ręcznie, po jednym bloku, odświeżając stronę po każdym z nich. Blok, po którym błąd wraca, zawiera usterkę. Zasady poprawnego zapisu omawiam we wpisie o przekierowaniach 301 w pliku .htaccess.

Jeżeli zmiana nazwy pliku niczego nie zmieniła, należy przywrócić mu pierwotną nazwę i przejść do następnej przyczyny. Zostawienie strony bez tego pliku sprawiłoby, że działałaby tylko strona główna, a podstrony zwracałyby błąd 404.

Jak znaleźć wtyczkę lub motyw, które wywołują błąd?

Drugą pod względem częstości przyczyną jest kod wtyczki albo motywu. Typowy scenariusz to aktualizacja, po której dodatek przestaje być zgodny z wersją PHP, z inną wtyczką albo z samym WordPressem. Jeśli dziennik błędów podał ścieżkę do konkretnego folderu, wystarczy wyłączyć ten jeden dodatek. Jeśli nie podał, trzeba wyłączyć wszystkie i włączać je po kolei.

Gdy panel administracyjny działa

W menu „Wtyczki” należy zaznaczyć wszystkie pozycje, z listy „Masowe działania” wybrać „Wyłącz” i kliknąć „Zastosuj”. Jeśli błąd zniknął, wtyczki włącza się pojedynczo, po każdej odświeżając stronę, na której występował problem. Ta, po której błąd wraca, jest przyczyną. Wyłączenie wtyczki nie kasuje jej ustawień, więc metoda jest bezpieczna dla danych.

Gdy do panelu nie da się wejść

1. W menedżerze plików należy otworzyć folder wp-content.
2. Folderowi plugins zmienia się nazwę na plugins_old. WordPress nie znajdzie wtyczek i uzna je wszystkie za wyłączone.
3. Należy odświeżyć stronę. Jeżeli się wyświetla, choćby w uproszczonej postaci, winna jest jedna z wtyczek.
4. Folderowi przywraca się nazwę plugins. Wtyczki pozostaną wyłączone, a panel będzie już dostępny.
5. W panelu, w menu „Wtyczki”, włącza się dodatki pojedynczo aż do chwili, gdy błąd wróci.
6. Jeśli po włączeniu wadliwej wtyczki panel ponownie przestaje działać, w folderze plugins zmienia się nazwę folderu tej jednej wtyczki, na przykład przez dopisanie _old.

W ten sam sposób sprawdza się motyw. W folderze wp-content/themes zmienia się nazwę folderu aktywnego motywu. WordPress przełączy się wtedy na motyw domyślny z rodziny „Twenty”, o ile jest on zainstalowany. Dlatego jeden taki motyw powinien zawsze pozostawać na serwerze, nawet jeśli nie jest używany. Gdy strona po tej zmianie działa, przyczyna tkwi w motywie, bardzo często w ręcznie dopisanym kodzie w pliku functions.php.

WordPress potrafi też sam wskazać winnego. Po wykryciu poważnego błędu wysyła na adres administratora wiadomość z nazwą dodatku i specjalnym odnośnikiem do trybu odzyskiwania. Po wejściu przez ten odnośnik panel uruchamia się z wstrzymanym wadliwym dodatkiem, dzięki czemu można go wyłączyć albo zaktualizować. Radzę sprawdzić skrzynkę administratora, łącznie z folderem spamu, zanim zacznie się zmieniać nazwy folderów.

Co zrobić ze znalezioną wtyczką? Najpierw trzeba sprawdzić, czy autor wydał nowszą wersję, która usuwa usterkę. Jeśli nie, pozostaje powrót do poprzedniej wersji z kopii zapasowej, zgłoszenie błędu autorowi albo zastąpienie dodatku innym. Nie polecam pozostawiania wadliwej wtyczki włączonej tylko dlatego, że błąd występuje rzadko.

Co zrobić, gdy brakuje pamięci albo wersja PHP nie pasuje?

Każde konto hostingowe ma limit pamięci, jaką może zużyć jedno wywołanie strony. Rozbudowany sklep, kreator stron i kilkanaście wtyczek potrafią ten limit przekroczyć, zwłaszcza w panelu administracyjnym. W dzienniku widać to jako wpis Allowed memory size ... exhausted. Objawem bywa też błąd 500 pojawiający się tylko przy cięższych czynnościach.

Limit, z którego korzysta WordPress, podnosi się jednym wierszem w pliku wp-config.php, wstawionym powyżej komentarza kończącego część do edycji:

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

Trzeba przy tym wiedzieć o jednym ograniczeniu. WordPress nie może przyznać sobie więcej pamięci, niż pozwala serwer. Jeśli po dopisaniu wiersza wpis o wyczerpanej pamięci nadal się pojawia, limit należy zmienić w panelu hostingu, w ustawieniach PHP, pod nazwą memory_limit. Gdy panel nie daje takiej możliwości, zmianę wykonuje pomoc techniczna dostawcy.

Aktualną wartość da się sprawdzić w panelu WordPressa. Należy otworzyć „Narzędzia”, następnie „Stan witryny”, przejść do karty „Informacje” i rozwinąć sekcję „Serwer”. Widać tam wersję PHP, limit pamięci oraz maksymalny czas wykonywania skryptu. To samo miejsce przydaje się przy rozmowie z hostingiem.

Podniesienie limitu jest właściwą naprawą, gdy strona po prostu urosła. Jeśli jednak zużycie pamięci wzrosło nagle, po instalacji jednego dodatku, lepiej potraktować to jako sygnał wady tej wtyczki. Podnoszenie limitu w nieskończoność ukrywa problem i spowalnia stronę.

Niezgodna wersja PHP

Błąd 500 tuż po zmianie wersji PHP w panelu hostingu, albo po tym, jak dostawca sam ją podniósł, oznacza zwykle, że któraś wtyczka lub motyw nie obsługuje nowej wersji. Najszybszym sposobem przywrócenia strony jest powrót do poprzedniej wersji PHP w panelu hostingu. To rozwiązanie tymczasowe. Starsze wersje PHP z czasem tracą wsparcie i poprawki bezpieczeństwa, więc docelowo trzeba zaktualizować albo wymienić dodatek, który blokuje przejście.

Odwrotna sytuacja także się zdarza: nowa wersja wtyczki wymaga nowszego PHP niż to ustawione na koncie. W dzienniku widać wtedy Parse error ze ścieżką do tej wtyczki. Rozwiązaniem jest podniesienie wersji PHP, po wcześniejszym upewnieniu się, że pozostałe dodatki ją obsługują.

Kiedy przyczyną są uszkodzone pliki WordPressa lub uprawnienia?

Jeśli plik .htaccess, wtyczki, motyw i pamięć zostały wykluczone, podejrzenie pada na pliki samego WordPressa. Mogą zostać uszkodzone przez przerwaną aktualizację, niepełne przesłanie przez FTP, zapełniony dysk konta hostingowego albo złośliwy kod. Dokumentacja zaleca w takiej sytuacji ponowne wgranie folderów wp-admin i wp-includes ze świeżej paczki instalacyjnej.

Jest to operacja bezpieczna dla treści pod jednym warunkiem: nie wolno ruszać folderu wp-content ani pliku wp-config.php. W pierwszym znajdują się zdjęcia, wtyczki i motywy, w drugim dane połączenia z bazą. Ich nadpisanie oznacza utratę danych albo strony.

1. Ze strony wordpress.org należy pobrać paczkę z tą samą wersją WordPressa, która działa na stronie, i rozpakować ją na dysku komputera.
2. Z rozpakowanego folderu trzeba usunąć folder wp-content, aby nie przesłać go przez pomyłkę.
3. Foldery wp-admin i wp-includes przesyła się na serwer do głównego katalogu strony, zgadzając się na zastąpienie istniejących plików.
4. Pojedyncze pliki z głównego katalogu paczki również można przesłać, z wyjątkiem pliku wp-config.php, którego w paczce i tak nie ma pod tą nazwą.
5. Po zakończeniu przesyłania należy odświeżyć stronę i zalogować się do panelu.

Jeżeli panel działa, tę samą czynność wykonuje się wygodniej: w menu „Kokpit”, w pozycji „Aktualizacje”, znajduje się przycisk ponownej instalacji bieżącej wersji. WordPress sam pobierze i podmieni swoje pliki, nie naruszając treści.

Uprawnienia do plików i folderów

Część serwerów odpowiada błędem 500, gdy pliki mają zbyt szerokie albo zbyt wąskie uprawnienia. Zdarza się to po przeniesieniu strony albo po ręcznych zmianach. Dokumentacja WordPressa podaje jako właściwe wartości 755 dla folderów i 644 dla plików. Uprawnienia sprawdza się w menedżerze plików, w kolumnie „Uprawnienia” albo we właściwościach pliku.

Wartość 777, czasem polecana na forach jako szybkie rozwiązanie, pozwala każdemu na zapis do pliku. Jest to poważne ryzyko dla bezpieczeństwa, a na wielu serwerach samo w sobie wywołuje błąd 500. Nie należy jej stosować.

Po czym poznać, że naprawa zadziałała, i co po niej posprzątać?

Wyświetlenie strony głównej to dopiero połowa potwierdzenia. Błąd 500 potrafi dotyczyć tylko wybranych miejsc, dlatego po naprawie trzeba przejść przez całą witrynę w sposób uporządkowany.

• Strona główna, kilka podstron i wpisów otwierają się w oknie prywatnym przeglądarki oraz na telefonie.
• Do panelu administracyjnego da się zalogować, a zapisanie dowolnego wpisu kończy się powodzeniem.
• Formularz kontaktowy wysyła wiadomość, a w sklepie da się dodać produkt do koszyka i przejść do zamówienia.
• Przesłanie zdjęcia do biblioteki mediów nie wywołuje błędu.
• W dzienniku błędów nie przybywają nowe wpisy typu Fatal error po odświeżeniu strony.

Jeśli strona korzysta z wtyczki pamięci podręcznej albo z usługi CDN, trzeba wyczyścić pamięć podręczną. W przeciwnym razie część odwiedzających może jeszcze przez pewien czas otrzymywać zapisaną wcześniej stronę błędu.

Następnie należy uporządkować to, co zostało po diagnozie. W pliku wp-config.php wiersz define( 'WP_DEBUG', true ); zmienia się na define( 'WP_DEBUG', false );, a pozostałe wiersze diagnostyczne można usunąć. Plik wp-content/debug.log trzeba skasować z serwera, ponieważ bywa dostępny z zewnątrz pod przewidywalnym adresem i zawiera informacje o budowie strony. To samo dotyczy pliku .htaccess_old oraz folderów z dopiskiem _old, gdy nie są już potrzebne.

Właściciele firm często pytają, czy awaria zaszkodziła widoczności w Google. Krótka przerwa zazwyczaj nie zostawia śladu. Dokumentacja Google wyjaśnia, że przy błędach serwera robot ogranicza tempo odwiedzin, a adresy, które zwracają błąd przez dłuższy czas, mogą zostać usunięte z indeksu. W Google Search Console skutki widać w raporcie „Indeksowanie stron” w wierszu „Błąd serwera (5xx)”. Po naprawie warto tam zajrzeć i, jeśli lista adresów nie jest pusta, skorzystać z przycisku „Sprawdź poprawkę”.

Co zrobić, gdy żaden sposób nie pomógł?

Jeśli plik .htaccess jest poprawny, wtyczki i motyw wyłączone, pamięć podniesiona, pliki WordPressa podmienione, a błąd trwa, przyczyna leży najpewniej po stronie serwera. Może to być przekroczony limit procesów, zapełniony dysk, błędna konfiguracja PHP albo blokada nałożona przez zabezpieczenia hostingu. Tych rzeczy właściciel strony zwykle nie zobaczy i nie zmieni sam.

W takiej sytuacji należy napisać do pomocy technicznej dostawcy. Odpowiedź przyjdzie szybciej i będzie konkretniejsza, jeśli zgłoszenie zawiera wszystko, co potrzebne do odszukania zdarzenia w dziennikach serwera. Można posłużyć się poniższą treścią, uzupełniając ją własnymi danymi:

Dzień dobry, strona pod adresem [adres domeny] zwraca błąd 500. Błąd występuje od [dzień i godzina], ostatnia próba miała miejsce o godzinie [godzina]. Dotyczy [całej strony / tylko panelu / jednej czynności]. Sprawdzono już: plik .htaccess (odtworzony), wtyczki i motyw (wyłączone), limit pamięci PHP (podniesiony), pliki WordPressa (wgrane ponownie). Proszę o sprawdzenie dziennika błędów serwera dla tej domeny z podanej godziny oraz o informację, czy konto nie przekracza limitów zasobów lub miejsca na dysku.

Drugą drogą jest przywrócenie kopii bezpieczeństwa sprzed awarii. To rozwiązanie skuteczne, ale ma swoją cenę: znikają wszystkie zmiany wprowadzone po dniu wykonania kopii, w tym zamówienia w sklepie, zgłoszenia z formularzy i nowe wpisy. Przed przywróceniem kopii trzeba ustalić, co zostanie utracone, i w miarę możliwości wyeksportować te dane. Przywrócenie kopii nie wyjaśnia też przyczyny, więc błąd może wrócić przy następnej aktualizacji.

Czego nie robić w trakcie naprawy

• Nie należy kasować wtyczek ani motywów zamiast je wyłączać. Zmiana nazwy folderu daje ten sam efekt i jest odwracalna.
• Nie należy wprowadzać kilku zmian naraz. Po każdej trzeba odświeżyć stronę, inaczej nie będzie wiadomo, która zmiana pomogła.
• Nie należy wklejać do plików fragmentów kodu z przypadkowych źródeł, zwłaszcza do .htaccess i functions.php.
• Nie należy instalować ponownie całego WordPressa instalatorem z panelu hostingu. Taki instalator potrafi nadpisać istniejącą stronę i bazę danych.
• Nie należy pozostawiać włączonego trybu diagnostycznego ani wyświetlania błędów na ekranie po zakończeniu pracy.

Najczęstsze pytania

Czy błąd 500 oznacza, że strona została zhakowana?

W większości przypadków nie. Najczęstsze przyczyny to wadliwy wiersz w pliku .htaccess, konflikt wtyczek po aktualizacji albo brak pamięci. O włamaniu można myśleć wtedy, gdy na serwerze widać nieznane pliki, w dzienniku pojawiają się ścieżki do plików, których nikt nie wgrywał, albo błąd wraca mimo podmiany plików WordPressa.

Czy podczas naprawy można stracić treści i zdjęcia?

Opisane czynności nie dotykają bazy danych ani folderu z przesłanymi plikami, więc wpisy, strony i zdjęcia pozostają na miejscu. Ryzyko powstaje dopiero przy kasowaniu folderów, nadpisaniu folderu wp-content lub pliku wp-config.php oraz przy przywracaniu starej kopii. Dlatego każdą zmianę wykonuje się przez zmianę nazwy, a nie przez usunięcie.

Dlaczego błąd pojawia się tylko czasami?

Błąd występujący nieregularnie wskazuje zwykle na zasoby: chwilowe wyczerpanie pamięci, limit jednoczesnych procesów na koncie hostingowym albo zbyt długo trwające zadanie w tle. Najwięcej powie dziennik błędów z godziny, w której awaria wystąpiła. Jeśli wpisy powtarzają się o stałych porach, warto sprawdzić, jakie zadania zaplanowane uruchamiają się wtedy na stronie, na przykład kopia lub import.

Strona działa, ale panel administracyjny zwraca błąd 500. Od czego zacząć?

Panel zużywa więcej pamięci niż część publiczna i ładuje wtyczki, które na stronie się nie uruchamiają. Należy zacząć od dziennika błędów, a gdy nic nie wskazuje, od wyłączenia wtyczek przez zmianę nazwy folderu plugins i od podniesienia limitu pamięci.

Czy przeglądarka może sama powodować błąd 500?

Nie. Kod 500 pochodzi z serwera i nie zależy od urządzenia odwiedzającego. Przeglądarka albo usługa pośrednicząca może natomiast pokazywać zapamiętaną wcześniej stronę błędu, mimo że awaria została już usunięta. Dlatego wynik naprawy sprawdza się w oknie prywatnym i na drugim urządzeniu, po wyczyszczeniu pamięci podręcznej strony.

Ile czasu Google toleruje stronę, która zwraca błąd 500?

Google nie podaje jednej sztywnej granicy. Z dokumentacji wynika, że robot najpierw zwalnia tempo odwiedzin, a adresy trwale zwracające błąd serwera z czasem usuwa z indeksu. W praktyce oznacza to, że awarię trwającą kilka godzin strona zwykle znosi bez strat, natomiast awaria ciągnąca się przez wiele dni wymaga już sprawdzenia raportu „Indeksowanie stron” po naprawie.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Nie każdy chce zmieniać nazwy plików na serwerze, gdy od działania strony zależą zamówienia i zapytania klientów. To zrozumiałe. Chętnie zajmę się taką awarią od początku do końca: zabezpieczę kopię, odczytam dzienniki serwera i WordPressa, ustalę, czy winny jest plik konfiguracyjny, wtyczka, motyw, pamięć czy sam serwer, usunę przyczynę i sprawdzę, czy formularze, panel i sklep działają jak przed awarią. Na koniec przekażę prostym językiem, co się stało i jak zmniejszyć ryzyko powtórki.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz chwilę, w której błąd pojawił się po raz pierwszy. Resztą zajmę się sam.