Ошибка 500 Internal Server Error в WordPress обычно означает не «сломался WordPress вообще», а то, что сервер не смог корректно обработать запрос. На практике причина чаще всего в повреждённом файле .htaccess, конфликте плагина или темы, нехватке лимита памяти PHP, проблеме с правами доступа или ошибке на стороне хостинга. Задача здесь не угадывать, а быстро локализовать источник сбоя и вернуть сайт в рабочее состояние без лишних изменений.
Если сайт внезапно перестал открываться и вместо страницы вы видите 500 ошибку, начинайте с самых безопасных и обратимых проверок: сначала логи и .htaccess, потом плагины, затем тему и настройки PHP. Такой порядок экономит время и снижает риск усугубить проблему.
С чего начать диагностику
Сначала определите, где именно возникает ошибка. Если не открывается только главная страница, а админка доступна, круг поиска уже. Если не открывается весь сайт, включая /wp-admin, причина может быть глубже: сервер, PHP, права на файлы или критическая ошибка в коде.
Полезно сразу проверить три вещи:
- появлялась ли ошибка после обновления плагина, темы, WordPress или PHP;
- есть ли доступ к панели хостинга, FTP/SFTP или файловому менеджеру;
- есть ли у хостинга журналы ошибок сервера.
Если у вас есть доступ к логам, это лучший способ не действовать вслепую. В журнале часто видно конкретную причину: синтаксическую ошибку PHP, нехватку памяти, запрет доступа к файлу или падение модуля.
Проверьте файл .htaccess
Повреждённый или конфликтующий .htaccess — одна из самых частых причин 500 ошибки в WordPress. Это особенно актуально после изменения постоянных ссылок, установки редиректов или переноса сайта.
Сначала сделайте резервную копию текущего файла. Затем временно переименуйте .htaccess, например в .htaccess.bak. Если сайт после этого открылся, причина почти наверняка в правилах внутри файла.
После проверки можно восстановить стандартный файл 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Если после восстановления стандартного файла сайт заработал, значит проблема была в старых или некорректных правилах. Тогда добавляйте свои редиректы обратно по одному и проверяйте результат после каждого изменения.
Если сайт на Nginx, файла .htaccess может не быть вовсе. Тогда эта проверка не поможет, и искать нужно в конфигурации сервера или в PHP-ошибке.
Отключите плагины без входа в админку
Когда ошибка 500 появилась после установки или обновления плагина, самый быстрый способ проверки — временно отключить все плагины. Если админка недоступна, это делается через файловую систему.
Переименуйте папку wp-content/plugins в, например, plugins-old. WordPress перестанет видеть плагины и загрузится без них. Если сайт открылся, значит один из плагинов вызывает конфликт или фатальную ошибку.
Дальше возвращайте папке исходное имя и отключайте плагины по одному: переименовывайте папку конкретного плагина внутри wp-content/plugins и каждый раз проверяйте сайт. Так вы быстро найдёте виновника.
Если после отключения всех плагинов ошибка не исчезла, переходите к теме оформления.
Проверьте активную тему
Ошибка 500 может быть вызвана не только плагином, но и самой темой: ошибкой в functions.php, несовместимостью с версией PHP или конфликтом с дочерней темой. Особенно часто это случается после ручного редактирования файлов темы.
Чтобы проверить тему, временно переключитесь на стандартную тему WordPress, например twentytwentyfour или другую доступную из ядра. Если админка недоступна, можно переименовать папку активной темы в wp-content/themes. WordPress попытается перейти на другую установленную тему.
Если сайт ожил после смены темы, ищите проблему в коде активной темы или дочерней темы. Проверьте:
- недавние правки в
functions.php; - подключение файлов через
requireилиinclude; - использование функций, которых нет в текущей версии WordPress или PHP;
- ошибки в кастомных шаблонах.
Если вы редактировали тему вручную и не уверены в правках, лучше сравнить файлы с резервной копией или исходной версией из репозитория.
Проверьте лимит памяти и версию PHP
Иногда 500 ошибка появляется не из-за конкретного плагина, а из-за того, что WordPress или один из его компонентов упирается в лимит памяти PHP. Это часто заметно после установки тяжёлых плагинов, импорта данных или обновления на более требовательную версию PHP.
Для проверки можно временно увеличить лимит памяти в wp-config.php. Добавьте строку перед комментарием /* That's all, stop editing! Happy publishing. */:
define('WP_MEMORY_LIMIT', '256M');Это не всегда решает проблему, потому что реальный потолок задаёт хостинг. Если хостинг ограничивает память ниже, WordPress не сможет превысить этот лимит. Но как диагностический шаг это полезно: если после увеличения лимита сайт заработал, причина была именно в нехватке памяти.
Также проверьте версию PHP. Слишком старая версия может быть несовместима с современными плагинами и темами, а слишком новая — выявить старый код, который раньше «терпел» ошибки. Если ошибка появилась сразу после смены версии PHP, временно верните предыдущую версию и проверьте сайт. Это безопаснее, чем менять код вслепую.
Посмотрите журнал ошибок сервера
Логи — самый точный источник информации при 500 ошибке. В них обычно видно, какой файл и на какой строке вызвал сбой. Это особенно полезно, когда сайт падает без явных признаков, а админка недоступна.
Ищите в журнале сообщения вида PHP Fatal error, Allowed memory size exhausted, Parse error, Permission denied или упоминание конкретного плагина, темы и файла. Если в логе указан путь вроде /wp-content/plugins/... или /wp-content/themes/..., направление поиска уже понятно.
Если у вас нет доступа к логам, запросите их у хостинга. Это нормальная практика: без журнала вы часто будете перебирать причины вручную, а с журналом можно сразу выйти на конкретный файл.
Проверьте права доступа и владельца файлов
Неверные права доступа тоже могут приводить к 500 ошибке, особенно после переноса сайта, восстановления из бэкапа или ручной загрузки файлов. WordPress должен иметь возможность читать файлы, а в некоторых случаях — записывать в каталог wp-content.
Обычно для файлов используют права 644, для каталогов — 755. Но это не универсальное правило для всех хостингов: на некоторых серверах важен ещё и корректный владелец файлов. Если права выставлены слишком широко, например 777, это уже не решение, а риск безопасности.
Если после переноса сайта ошибка 500 появилась сразу и ничего больше не менялось, проверьте именно права и владельца. На shared-хостинге это часто делает поддержка, потому что у клиента может не быть доступа к смене владельца.
Если ошибка остаётся: как сузить причину без риска
Когда базовые проверки не помогли, не спешите массово менять настройки. Безопаснее двигаться от последнего изменения к более общим причинам:
- откатить последнее обновление плагина, темы или WordPress, если есть резервная копия;
- временно отключить все плагины;
- переключиться на стандартную тему;
- проверить логи сервера;
- сверить версию PHP и лимиты хостинга;
- обратиться в поддержку хостинга с точным временем ошибки и фрагментом лога.
Если сайт критичен для бизнеса, сначала восстановите доступ к рабочей версии из бэкапа, а уже потом ищите первопричину. Это безопаснее, чем долго держать сайт в нерабочем состоянии ради диагностики.
Как проверить, что проблема действительно устранена
После исправления ошибки не ограничивайтесь открытием главной страницы. Проверьте несколько типовых сценариев:
- главная страница сайта;
- несколько внутренних страниц;
/wp-adminи вход в админку;- страница записи, если используется ЧПУ;
- формы, поиск и другие важные элементы, если они есть.
Если ошибка исчезла только после отключения плагинов, включайте их по одному и сразу проверяйте сайт. Так вы не пропустите конфликт, который проявляется только при определённом запросе.
Если причина была в .htaccess или лимите памяти, полезно ещё раз открыть сайт в обычном режиме и убедиться, что ошибка не возвращается после очистки кэша, повторного входа в админку и обновления нескольких страниц. Иногда проблема проявляется не сразу, а только под нагрузкой или на конкретном URL.
В большинстве случаев 500 Internal Server Error в WordPress удаётся локализовать без переустановки сайта: сначала проверяют .htaccess, затем плагины, тему, память PHP и логи сервера. Если действовать по порядку и не менять всё сразу, причину обычно можно найти за один цикл проверки и вернуть сайт в рабочее состояние без лишнего риска.