Ошибка 500 в WordPress: как найти причину и починить

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

Чинится это не перебором «попробуйте отключить плагины», а по уликам: сначала открываем лог ошибок — он называет точную причину, — потом устраняем её. На диагностику обычно уходит 10 минут, и большую часть этой статьи занимает главный навык: где искать логи и как их читать.

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

Шаг 1. Найдите лог ошибок

Ошибка 500 всегда оставляет след в логе. Вопрос только в том, где он лежит — это зависит от сервера и хостинга:

Где искать	Что смотреть	Примечание
Панель хостинга	Раздел «Логи» / «Журналы» → error log	Самый простой путь на shared-хостинге
Корень сайта или папки	Файл error_log рядом со скриптом	PHP часто пишет туда при log_errors = On
wp-content/debug.log	Ошибки уровня WordPress	Нужно включить WP_DEBUG_LOG (ниже)
Apache	/var/log/apache2/error.log	Свой сервер / VPS
Nginx	/var/log/nginx/error.log	На связке Nginx + PHP-FPM смотрите оба лога
PHP-FPM	/var/log/php/*-fpm.log и лог пула	Падения процессов, таймауты, лимиты

Откройте лог и найдите записи с временем последней ошибки. Дальше — по типу записи:

• PHP Fatal error ... in .../wp-content/plugins/... — виноват плагин, переходите к шагу 3;
• Allowed memory size exhausted — лимит памяти, шаг 4;
• Invalid command / ... .htaccess: ... — битый .htaccess, шаг 2;
• ничего похожего на ваш сайт — проблема на уровне сервера, шаг 5.

Чтобы WordPress вёл собственный лог, добавьте в wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После починки верните WP_DEBUG в false.

Шаг 2. Проверьте .htaccess

На серверах Apache (и LiteSpeed) файл .htaccess в корне сайта управляет перезаписью адресов. Одна кривая строка — и сервер отвечает 500 на все запросы. Файл ломают плагины кеширования и безопасности, ручные правки и сбои при миграции.

Проверка занимает минуту. По FTP переименуйте .htaccess в .htaccess.bak и обновите сайт:

• Сайт ожил — причина найдена. Создайте чистый .htaccess со стандартным содержимым WordPress:

# 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

Затем зайдите в админку: «Настройки» → «Постоянные ссылки» → «Сохранить» — WordPress перезапишет правила. Директивы плагинов (кеш, сжатие, безопасность) вернутся, когда вы пересохраните их настройки; не копируйте их из старого файла вслепую — среди них и была сломанная.

• Сайт не ожил — верните файлу прежнее имя и идите дальше.

На Nginx файла .htaccess нет: правила живут в конфиге сервера, и этот шаг можно пропустить.

Шаг 3. Отключите плагины и тему

Если лог указал на конкретный плагин — отключите его: через админку, а если она тоже отдаёт 500 — переименуйте папку плагина в wp-content/plugins/ по FTP. Через WP-CLI:

wp plugin deactivate имя-плагина
# или радикально, если виновник неизвестен:
wp plugin deactivate --all

Дальше стандартная бисекция: включайте плагины по одному, после каждого проверяя сайт. Тему проверяют так же — временным переключением на стандартную (wp theme activate twentytwentyfive).

Типичный сценарий 500-ки «после вчерашнего обновления»: автообновление плагина привезло несовместимый код. Поэтому в логе первым делом смотрите на дату — что менялось на сайте прямо перед первой ошибкой.

Шаг 4. Поднимите лимиты PHP

500-ка, которая возникает только на тяжёлых операциях — импорт, загрузка файлов, генерация страниц магазина, — это почти всегда лимиты. Ключевые параметры:

Параметр	За что отвечает	Разумное значение
memory_limit	Память на один запрос	256M (для магазинов 512M)
max_execution_time	Время работы скрипта	60–120 сек для админки
upload_max_filesize	Размер загружаемого файла	64M и больше по задаче
post_max_size	Размер POST-запроса	≥ upload_max_filesize

Где менять — зависит от хостинга: у большинства панелей есть раздел «PHP» с этими настройками. Лимит памяти для WordPress дополнительно задаётся в wp-config.php:

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

Важно: константы WordPress не могут превысить серверный memory_limit — если он зажат хостингом, сначала поднимайте его.

И проверьте версию PHP: WordPress быстрее и стабильнее всего работает на актуальном PHP 8.2+. Но резкая смена версии — сама по себе частая причина 500-ки: старый код не совместим с новым PHP. Меняйте версию на тестовой копии, а не сразу на проде.

Шаг 5. Права на файлы и серверные причины

Если логи сайта чисты, проверьте инфраструктуру:

• Права на файлы. Стандарт для WordPress: папки 755, файлы 644, wp-config.php можно 600. Права 777 — дыра в безопасности, а слишком строгие права (или неверный владелец файлов после миграции) дают 500 на ровном месте. Поправить по SSH:

find /путь/к/сайту -type d -exec chmod 755 {} \;
find /путь/к/сайту -type f -exec chmod 644 {} \;

• PHP-FPM. Упавший или перегруженный пул процессов отдаёт 500/502/504. Признак — в логе FPM записи о достигнутом max_children. На shared-хостинге это лечит поддержка, на VPS — увеличение пула или оптимизация сайта.
• Диск и ресурсы. Переполненный диск, исчерпанные inode, лимит процессов на тарифе — всё это даёт плавающие 500-ки под нагрузкой.
• Модули сервера. Ошибка после включения опции на хостинге (например, ModSecurity) — проверьте её выключением.

Если сами доступа к этим уровням не имеете — пишите в поддержку хостинга, приложив время ошибки и записи из доступных вам логов: с уликами вопрос решается в разы быстрее.

Не путайте 500 с соседями: 502, 503, 504

Коды из пятисотой серии похожи, но указывают на разные уровни проблемы, и это экономит время диагностики:

• 500 — упал код сайта или конфигурация (наш случай, причины выше);
• 502 Bad Gateway — прокси-сервер (Nginx, CDN) не получил внятного ответа от PHP: обычно упал или перегружен PHP-FPM;
• 503 Service Unavailable — сервис намеренно недоступен: у WordPress это ещё и штатный ответ во время обновления (файл .maintenance в корне — если обновление зависло, удалите его);
• 504 Gateway Timeout — бэкенд отвечал слишком долго: медленный запрос к базе, внешний API, нехватка ресурсов.

Если видите 502/504 — начинайте сразу с шага 5 (сервер и ресурсы), а не с плагинов: код сайта в этих случаях чаще жертва, чем причина.

Шпаргалка: диагноз по поведению ошибки

Как проявляется 500	Наиболее вероятная причина
На всех страницах сразу после правок/миграции	Битый .htaccess или синтаксическая ошибка в PHP
После обновления плагина или темы	Несовместимый код — отключить обновлённое
Только в админке или на одной операции	Лимиты PHP: память, время выполнения
Только при загрузке файлов	upload_max_filesize / post_max_size
Плавающая, под нагрузкой	Ресурсы: FPM, память, тариф хостинга
После смены версии PHP	Несовместимость кода с новым PHP
На ровном месте, логи сайта чисты	Сервер: диск, FPM, модули — в поддержку

После починки

Ошибка 500 — это симптом, и после починки стоит закрыть первопричину: настроить бэкапы перед обновлениями, обновлять плагины по одному, а не пакетом, и следить за ресурсами. Сайт, который регулярно упирается в лимиты, — кандидат не на бесконечное поднятие memory_limit, а на оптимизацию: лишние плагины, тяжёлые запросы к базе и отсутствие кеша съедают ресурсы быстрее любого трафика. С этого и начинается ускорение WordPress — а быстрый сайт заодно и падает реже.