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

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

Самая полезная стратегия здесь — идти от простых и обратимых проверок к более глубоким. Если начать с удаления файлов или переустановки WordPress, можно потерять время и не найти первопричину. Ниже разберём, как отличить типичные сценарии и что проверять в каждом из них.

Что означает 500-я ошибка и почему она не указывает на одну причину

Код 500 говорит только о том, что сервер не смог корректно обработать запрос. Для WordPress это может быть:

• ошибка в конфигурации веб-сервера или в файле .htaccess;
• фатальная ошибка PHP в плагине, теме или собственном коде;
• неверные права доступа к файлам и папкам;
• нехватка ресурсов на хостинге или превышение лимитов PHP;
• несовместимость версии PHP с темой, плагином или самой установкой WordPress;
• ошибка на уровне хостинга, которая не связана напрямую с WordPress.

Если ошибка появилась сразу после изменения настроек постоянных ссылок, установки плагина, обновления темы или переключения версии PHP, это уже хороший ориентир. Именно последнее действие чаще всего и ломает сайт.

С чего начать диагностику, если сайт недоступен

Перед любыми изменениями сделайте резервную копию файлов и базы данных, если это возможно. Даже если сайт уже не открывается, копия нужна для отката после неудачной проверки. Если доступа к админке нет, используйте панель хостинга, FTP/SFTP или файловый менеджер.

Дальше проверьте три вещи:

1. Появляется ли ошибка на всех страницах или только на одной.
2. Менялось ли что-то прямо перед поломкой.
3. Есть ли доступ к логам ошибок PHP и веб-сервера.

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

Проверьте .htaccess: это частая причина после изменения постоянных ссылок

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

Безопасный способ проверки такой: временно переименуйте .htaccess в, например, .htaccess.bak. Если после этого сайт открылся, причина почти наверняка в правилах внутри файла. Для обычной установки WordPress можно затем заново сохранить настройки постоянных ссылок в админке — WordPress создаст корректные правила автоматически, если сервер это поддерживает.

Если админка недоступна, можно вручную вернуть стандартный набор правил WordPress. Для сайта в корне он обычно выглядит так:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Важно: если у вас были дополнительные правила редиректов, они могли быть нужны для HTTPS, www-версии или ЧПУ. Не удаляйте их без понимания назначения. Сначала проверьте, исчезает ли ошибка на чистом стандартном файле, а потом возвращайте нужные правила по одному.

Права доступа: когда сервер не может прочитать файл или выполнить скрипт

Неверные права доступа тоже способны вызвать 500-ю ошибку, особенно после переноса сайта, распаковки архива или массового изменения файлов через FTP-клиент. Для WordPress обычно ориентируются на такие значения:

• для папок — 755;
• для файлов — 644;
• для wp-config.php часто используют более строгие права, например 640 или 600, если хостинг это допускает.

Не стоит выставлять 777 ради «проверки». Это небезопасно и не решает причину, а только маскирует её. Если после исправления прав сайт заработал, значит проблема была именно в доступе к файлам или папкам. Если нет — ищите дальше.

Проверять нужно не только корень сайта, но и вложенные каталоги, особенно wp-content, plugins, themes и uploads. Иногда ошибка возникает из-за одного файла с неправильным владельцем или правами после миграции между серверами.

Если виноват плагин, важно не отключать всё вслепую

Плагин часто вызывает 500-ю ошибку после обновления, активации или изменения настроек. Но отключать всё подряд не всегда удобно, особенно если сайт рабочий. Лучше изолировать причину.

Если есть доступ к админке, начните с последнего установленного или обновлённого плагина. Отключите его и проверьте сайт. Если ошибка исчезла, причина найдена. Если нет, включайте его обратно и переходите к следующему кандидату.

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

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

Тема и собственный код: когда ошибка появляется после правок оформления

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

Самый безопасный способ проверки — временно переключиться на стандартную тему WordPress, например Twenty Twenty-Four или другую установленную дефолтную тему. Если админка недоступна, можно переименовать папку активной темы в wp-content/themes. WordPress попытается перейти на доступную стандартную тему, если она установлена.

Если после смены темы сайт открылся, проблема в шаблоне, дочерней теме или пользовательском коде. Тогда проверяйте:

• functions.php на синтаксические ошибки;
• подключаемые файлы темы;
• кастомные хуки и фильтры;
• код, добавленный вручную в тему или через сниппет-плагин.

Если ошибка появилась именно после правки functions.php, достаточно одной лишней скобки, точки с запятой или вызова несуществующей функции, чтобы сайт перестал открываться. В таком случае удобнее сначала вернуть последнюю рабочую версию файла из резервной копии, а уже потом разбирать код.

PHP-ошибки и лимиты хостинга: как понять, что проблема не в WordPress

Когда сайт падает без явных изменений в WordPress, стоит смотреть логи PHP. Именно там обычно видно, какой файл вызвал фатальную ошибку и на какой строке она произошла. Это самый прямой путь к причине, если у вас есть доступ к логам через панель хостинга.

Ищите в логах сообщения уровня Fatal error, Uncaught Error, Allowed memory size exhausted или похожие записи. По ним можно понять, что сломалось: плагин, тема, несовместимая версия PHP или нехватка памяти.

Если в логе видно, что ошибка связана с несовместимостью версии PHP, проверьте, не обновлялся ли недавно PHP на хостинге. Некоторые старые плагины и темы не работают на новых версиях PHP, а некоторые современные плагины, наоборот, требуют более свежую версию. В таком случае решение зависит от конкретного кода и версии продукта: либо обновлять проблемный компонент, либо временно откатить PHP до совместимой версии, если хостинг это позволяет.

Если в логах встречается нехватка памяти, можно временно увеличить лимит PHP, но это не лечит первопричину. Часто проблема в тяжёлом плагине, слишком ресурсоёмкой теме или в том, что хостинг просто не даёт достаточно ресурсов для текущей нагрузки. Тогда нужно либо оптимизировать виновный компонент, либо переходить на более подходящий тариф.

Когда ошибка появляется только после сохранения настроек

Если 500-я ошибка возникает сразу после изменения настроек в админке, это часто связано не с самим сохранением, а с тем, что WordPress после него перестраивает правила, кэш или выполняет дополнительный код плагина. В таком сценарии полезно вспомнить, что именно меняли:

• постоянные ссылки;
• настройки кэширования;
• SSL или редиректы;
• параметры плагина безопасности;
• настройки темы или конструктора страниц.

Если ошибка началась после сохранения постоянных ссылок, возвращайтесь к .htaccess. Если после изменения настроек плагина — отключайте именно этот плагин и проверяйте, исчезает ли ошибка. Если после переключения версии PHP — верните прежнюю версию и проверьте совместимость.

Иногда проблема проявляется только после сохранения, потому что плагин записывает некорректные данные в базу или пытается выполнить тяжёлую операцию, которая упирается в лимит времени выполнения. В этом случае лог ошибок подскажет, какой именно компонент сработал последним.

Как проверить, что проблема действительно устранена

После исправления не ограничивайтесь открытием главной страницы. Проверьте несколько сценариев:

• открывается ли главная и внутренние страницы;
• доступна ли /wp-admin/;
• сохраняются ли настройки в админке;
• нет ли новых записей об ошибках в логах;
• не возвращается ли 500 после очистки кэша, если он используется.

Если сайт заработал после переименования .htaccess, прав доступа или отключения плагинов, не спешите сразу возвращать всё как было. Сначала убедитесь, что ошибка не появляется повторно при повторном включении одного компонента. Так вы найдёте точную причину, а не просто снимете симптом.

Когда без поддержки хостинга уже не обойтись

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

В поддержку хостинга стоит передать не общий запрос «у меня ошибка 500», а конкретику:

• когда ошибка появилась;
• что меняли перед этим;
• какие проверки уже сделали;
• фрагмент лога ошибок, если он доступен;
• на каких страницах ошибка воспроизводится.

Чем точнее описание, тем быстрее вам смогут сказать, это проблема WordPress, PHP или инфраструктуры сервера. В ряде случаев без доступа к серверным логам и конфигурации дальше двигаться просто некуда.

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