Ошибка 500 в WordPress: причины и способы исправления

Ошибка 500 Internal Server Error в WordPress означает, что сервер не смог корректно обработать запрос, но не сообщает посетителю точную причину сбоя. Поэтому сама надпись «500» — не диагноз. За ней может скрываться фатальная ошибка PHP, конфликт после обновления плагина, повреждённый .htaccess, несовместимая версия PHP, нехватка памяти, ошибка темы или проблема на стороне хостинга.

Главная ошибка при таком сбое — начинать хаотично переустанавливать WordPress, удалять плагины и менять настройки сервера. Правильная стратегия обратная: сначала зафиксировать момент появления ошибки и прочитать логи, затем локализовать компонент, который её вызывает. Так восстановление обычно занимает меньше времени и не создаёт дополнительных проблем.

Что означает ошибка 500 в WordPress

Код HTTP 500 относится к серверным ошибкам. Браузер отправил запрос, сервер его получил, но во время выполнения произошёл сбой, из-за которого нормальный ответ сформировать не удалось.

В WordPress это особенно часто связано с PHP-кодом. Плагин или тема могут вызвать фатальную ошибку ещё до того, как WordPress успеет вывести обычную страницу. Более того, сам WordPress Core может вернуть HTTP 500 на раннем этапе загрузки, например если сервер не соответствует обязательным требованиям PHP или не хватает необходимых расширений.

Внешне ситуация может выглядеть по-разному: белый экран, стандартная страница хостинга «Internal Server Error», сообщение о критической ошибке WordPress или ошибка только в отдельных запросах — например при сохранении страницы, работе REST API, AJAX, Elementor или WooCommerce.

Что проверить в первую очередь

Перед любыми изменениями вспомните, что происходило непосредственно перед ошибкой. Это резко сужает круг поиска.

• обновлялся ли WordPress, плагин или тема;
• менялась ли версия PHP;
• устанавливался ли новый плагин;
• редактировался ли functions.php, кастомный плагин или .htaccess;
• переносился ли сайт на другой сервер;
• появилась ли ошибка после изменения постоянных ссылок;
• возникает ли 500 на всём сайте или только в конкретном разделе.

Если сайт рабочий и коммерческий, перед экспериментами сделайте резервную копию файлов и базы данных либо проводите диагностику на staging-копии. Особенно это важно перед заменой системных файлов, изменением прав доступа или массовым отключением плагинов.

1. Посмотрите PHP- и server error log

Самый быстрый путь к причине 500 — не перебор настроек, а журнал ошибок. На разных хостингах он может называться error.log, PHP Error Log, Web Server Log или находиться в панели управления сервером.

Ищите запись, совпадающую по времени с запросом, который вернул 500. Типичные маркеры:

• PHP Fatal error;
• Allowed memory size exhausted;
• Uncaught TypeError;
• Call to undefined function;
• Parse error;
• путь к файлу конкретного плагина или темы.

Если лог прямо указывает на файл вида /wp-content/plugins/plugin-name/..., начинать диагностику нужно именно с этого плагина, а не со всего WordPress.

2. Включите журнал отладки WordPress

Если серверный лог недоступен или в нём недостаточно информации, можно временно включить встроенную отладку WordPress. Для production-сайта ошибки лучше записывать в файл, но не показывать посетителям.

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

Эти строки размещают в wp-config.php до комментария /* That's all, stop editing! */. После повторения ошибки журнал обычно появляется в wp-content/debug.log.

Важно: после диагностики режим отладки на публичном сайте следует отключить. Логи могут содержать пути к файлам, технические сообщения и другую информацию, которую не стоит оставлять доступной без необходимости.

Если вместо 500 WordPress показывает сообщение «На сайте возникла критическая ошибка», полезно также проверить письмо администратора: начиная с WordPress 5.2 механизм Recovery Mode может прислать ссылку для входа и указать компонент, вызвавший фатальный сбой. Подробно эту ситуацию мы разбирали в статье «Критическая ошибка WordPress: причины и способы исправить».

3. Проверьте плагины WordPress

Плагины — одна из самых частых причин серверных ошибок после обновлений. Конфликт может появиться из-за несовместимости с новой версией PHP, WordPress, WooCommerce, другим плагином или из-за ошибки в собственном коде расширения.

Если проблема появилась сразу после обновления конкретного плагина и wp-admin недоступен, безопаснее сначала отключить именно подозреваемый компонент: через файловый менеджер или SFTP переименовать его каталог в wp-content/plugins/. WordPress перестанет загружать этот плагин.

Если виновник неизвестен, можно временно отключить все обычные плагины для диагностики и затем включать их по одному. При этом не забывайте о каталоге wp-content/mu-plugins: must-use плагины загружаются автоматически и не отключаются обычной кнопкой в админке.

Если лог показывает именно фатальную PHP-ошибку, дополнительно посмотрите материал «Fatal Error в WordPress: как найти причину».

4. Исключите проблему темы

Тема может вызывать HTTP 500 после обновления, ручного изменения functions.php, подключения устаревшей библиотеки или конфликта с новой версией PHP.

Если админка открывается, временно переключитесь на стандартную тему WordPress и повторите проблемное действие. Если доступа к панели нет, диагностику лучше проводить на резервной или staging-копии. Простое удаление рабочей темы на production без резервного плана — плохая практика.

Если после переключения ошибка исчезает, проверяйте PHP-лог: он обычно указывает конкретный файл и строку. Это намного полезнее, чем полностью переписывать тему или заменять её «на всякий случай».

5. Проверьте .htaccess — только если сервер работает на Apache

На Apache WordPress использует .htaccess для правил постоянных ссылок. Повреждённая директива, некорректное правило редиректа или код, добавленный плагином, могут привести к Internal Server Error.

Сделайте копию текущего файла, затем временно переименуйте .htaccess и проверьте сайт. Если 500 исчезла, создайте корректные правила заново через Настройки → Постоянные ссылки → Сохранить изменения и отдельно верните только необходимые пользовательские правила.

Не путайте серверы: Nginx не использует .htaccess. Если сайт работает на Nginx, причина находится в конфигурации виртуального хоста, PHP-FPM или приложении, а переименование несуществующего .htaccess ничего не изменит.

6. Проверьте PHP: версию, расширения и память

После переключения PHP сайт может получить 500 из-за несовместимого кода плагина или темы. Обратная ситуация тоже возможна: слишком старая версия PHP или отсутствие обязательного расширения мешают загрузке WordPress.

Проверьте:

• какая версия PHP фактически используется доменом;
• не менялась ли она непосредственно перед сбоем;
• есть ли в журнале TypeError, Deprecated, undefined function или сообщения об отсутствующем расширении;
• не исчерпан ли PHP memory_limit;
• работает ли нужная версия PHP-FPM после изменения настроек.

Сообщение Allowed memory size exhausted действительно указывает на нехватку памяти, но бессмысленно бесконечно увеличивать лимит в WordPress. Фактическое ограничение задаётся PHP и хостингом, а чрезмерное потребление памяти может быть симптомом проблемного плагина, тяжёлого запроса или зацикленного кода.

7. Если ошибка появилась после обновления WordPress

При неудачном обновлении часть файлов Core может загрузиться не полностью. В такой ситуации сначала исключите плагины и PHP, а затем проверяйте целостность ядра.

Не заменяйте весь сайт случайным архивом. При ручном восстановлении WordPress сохраняют wp-config.php, каталог wp-content и пользовательские файлы, а системные файлы заменяют чистой копией той же актуальной ветки WordPress. Перед этим обязательна резервная копия.

Если одновременно видите белый экран без полезного сообщения, посмотрите отдельную инструкцию «Белый экран WordPress: причины и способы восстановления».

8. Ошибка 500 только в Elementor, WooCommerce или AJAX

Иногда главная страница работает, но HTTP 500 появляется только при сохранении страницы в Elementor, оформлении заказа WooCommerce, работе admin-ajax.php или REST API. Это важный диагностический признак: сервер в целом отвечает, а падает конкретный PHP-сценарий.

В таком случае проверяйте лог именно в момент проблемного запроса. Для Elementor у нас есть отдельная инструкция «Устранить ошибку 500 в Elementor». Она дополняет эту статью и помогает избежать смешивания общей серверной ошибки WordPress с проблемами редактора.

9. Проверьте права на файлы и владельца файлов

После миграции или ручной загрузки файлов сервер может потерять доступ к отдельным каталогам. Но решение «поставить 777 на всё» небезопасно и часто маскирует настоящую проблему.

Проверяйте владельца файлов, группу, права каталогов и файлов в соответствии с конфигурацией конкретного сервера. Если после переноса права изменились, лучше исправить ownership и корректные разрешения, а не делать каталог доступным на запись всем пользователям системы.

10. Когда причина находится на стороне хостинга

Если код сайта не менялся, плагины и тема исключены, а в WordPress-логах нет фатальной ошибки, переходите к серверной диагностике. HTTP 500 может быть связан с PHP-FPM, лимитами процессов, ошибкой конфигурации веб-сервера, модулем безопасности, повреждённым пулом PHP или инфраструктурным сбоем.

При обращении в поддержку хостинга полезно передать не «у меня ошибка 500», а конкретные данные: точное время запроса, URL, IP при необходимости, шаги воспроизведения и фрагмент server error log. Это позволяет администратору найти событие намного быстрее.

Чего не стоит делать при ошибке 500

• Не переустанавливать WordPress без диагностики. Если проблема в плагине или PHP, это не поможет.
• Не удалять плагины вместе с данными. Для теста достаточно деактивации.
• Не выставлять 777 на файлы и каталоги. Это создаёт лишний риск безопасности.
• Не оставлять WP_DEBUG_DISPLAY включённым на production. Ошибки не должны выводиться посетителям.
• Не восстанавливать старый backup поверх текущего сайта до выяснения причины. Можно потерять новые заказы, формы, пользователей и изменения базы данных.
• Не менять одновременно несколько параметров. Иначе вы не поймёте, какое действие действительно устранило сбой.

Краткий алгоритм диагностики ошибки 500

1. Зафиксировать, после какого действия появилась ошибка.
2. Сделать резервную копию или staging-копию.
3. Открыть server/PHP error log.
4. При необходимости включить WP_DEBUG_LOG без вывода ошибок посетителям.
5. Если лог указывает на плагин — отключить его и проверить совместимость.
6. Исключить тему.
7. На Apache проверить .htaccess; на Nginx — серверную конфигурацию.
8. Проверить PHP, расширения и лимит памяти.
9. После неудачного обновления проверить целостность WordPress Core.
10. Если приложение не показывает причину — обратиться к server log и поддержке хостинга.

Нужно быстро восстановить WordPress?

Если сайт недоступен, а ошибка 500 появилась после обновления, переноса, изменения PHP или без очевидной причины, лучше не экспериментировать на рабочем проекте. На MakerPress есть отдельная услуга «Исправление ошибок WordPress»: диагностика начинается с логов и причины сбоя, а не с случайного отключения всего подряд.

FAQ

Почему WordPress внезапно начал показывать ошибку 500?

Чаще всего причина появляется после изменения среды: обновления плагина или темы, переключения PHP, изменения .htaccess, переноса сайта или изменения серверных настроек. Точную причину нужно искать в PHP/server error log.

Может ли плагин вызвать Internal Server Error?

Да. Фатальная PHP-ошибка, несовместимость версий, конфликт классов или превышение лимита памяти внутри плагина могут привести к HTTP 500. Если лог указывает на каталог конкретного плагина, его временная деактивация — логичный следующий шаг.

Поможет ли увеличение memory limit?

Только если журнал действительно содержит сообщение об исчерпании памяти. При этом важно проверить реальный PHP memory_limit на сервере и понять, почему процесс потребляет столько памяти. Простое увеличение лимита не всегда устраняет первопричину.

Что делать, если ошибка 500 появилась после обновления плагина?

Проверьте PHP-лог, затем временно отключите обновлённый плагин. Если сайт восстановился, проверьте changelog, совместимость с текущими версиями WordPress и PHP и наличие исправленной версии. На рабочем сайте откат лучше делать из проверенной резервной копии или через staging.

Можно ли исправить 500 без доступа в wp-admin?

Да. Для диагностики можно использовать панель хостинга, SFTP/SSH, server error log и файловый менеджер. Подозреваемый плагин можно временно отключить переименованием его каталога, а повреждённый .htaccess — проверить после создания резервной копии.

Ошибка 500 и критическая ошибка WordPress — это одно и то же?

Не всегда. Критическая ошибка WordPress обычно связана с фатальным PHP-сбоем, который WordPress смог перехватить своим механизмом восстановления. HTTP 500 — более общий серверный статус и может возникать ещё до полноценной загрузки WordPress или из-за конфигурации веб-сервера.