Skip to content

Всё для WordPress, веб-разработки — и не только

🔧 Как исправить внутреннюю ошибку сервера WordPress 500
WordPress
6 мин1,281 слов2 730

🔧 Как исправить внутреннюю ошибку сервера WordPress 500

Белый экран. Пять цифр: 500. Ни админки, ни сайта, ни намёка на причину. Знакомая картина?

Внутренняя ошибка сервера WordPress 500, самая немая из всех ошибок. Она не говорит, что именно сломалось, и от этого паника только сильнее. Но реальность прозаична: в 9 из 10 случаев виноваты плагин, тема или одна кривая строка в .htaccess. Сервер не сошёл с ума, он просто наткнулся на код, который не может выполнить.

Сейчас разберём три главных сценария, и пошагово починим каждый. Без паники, без звонка хостеру в три часа ночи. Своими руками, за 15 минут.

💡 Быстрый обзор:

  • Отключите все плагины разом, переименуйте папку plugins через FTP, ошибка исчезла? Виновник среди них
  • Сбросьте .htaccess до стандартного WordPress: кривая директива кэширования или редиректа ломает сайт мгновенно
  • Включите WP_DEBUG в wp-config.php, увидите конкретный файл и строку с фатальной ошибкой
  • Если сайт только что переехал на новый хостинг, проверьте версию PHP: WordPress с 2026 года требует PHP 8.3 или новее, и старые плагины часто несовместимы

Коды ответа HTTP: что сервер пытается вам сказать

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

Ноутбук с программным кодом и инструментами отладки
  • 1xx, информационные: «соединение устанавливается, ждите». К ошибкам отношения не имеют.
  • 2xx, успех. Знаменитый 200 OK означает, что сервер отдал страницу без нареканий.
  • 3xx, перенаправления. Например, 301 (постоянный редирект) или 307 (временный). Браузер переходит по новому адресу молча, это команда, не ошибка.
  • 4xx, ошибка на стороне клиента. 404 Not Found, страница удалена или URL набран с опечаткой. Сервер жив, контента просто нет.
  • 5xx, ошибка на стороне сервера. Вот здесь начинается наша территория.

Среди 5xx три главных «пациента»: 503 Service Unavailable (сервер перегружен, лечится кэшированием или переходом на более мощный тариф), 502 Bad Gateway (PHP-FPM упал или потерял соединение с веб-сервером, проблема конфигурации) и, наконец, **500 **Internal Server Error, самая общая и потому самая коварная. О ней и поговорим.

Три главные причины ошибки 500 и пошаговое исправление

Ошибка 500 не загадочна, она просто общая. Сервер говорит: «я не смог выполнить код, но не скажу какой». Диагностика, методичный перебор трёх стандартных виновников.

1. Несовместимость версий PHP при переносе сайта

Классика жанра: вы перенесли сайт со старого хостинга, где крутился PHP 7.4, на новый, с PHP 8.3 или 8.4. И сразу получили белый экран.

Причина банальна: старый плагин или тема используют функции, которые в новых версиях PHP объявлены устаревшими (deprecated) или удалены вовсе. Интерпретатор отказывается их выполнять, и сайт падает.

Как чинить. Сделайте полный бэкап папок wp-content/plugins/ и wp-content/themes/. Затем переименуйте папку plugins в plugins_old через FTP или файловый менеджер хостинга, это мгновенно отключит все плагины разом. Ошибка исчезла? Виновник среди плагинов. Возвращайте их по одному, каждый раз проверяя сайт. Тот, после которого 500-я вернулась, и есть проблема.

С темами та же логика: переключитесь на стандартную тему WordPress (Twenty Twenty-Five или новее). Сайт ожил? Проблема в вашей теме, обновите её или замените.

Этот сценарий чаще всего проявляется при переносе сайта между хостингами с разными версиями PHP. Большинство хостеров уже не предлагают PHP 7.x в панели управления, минимальные требования WordPress с 2026 года начинаются с PHP 8.3. Старый код без обновлений на таком окружении обречён.

2. Повреждённый.htaccess, невидимый убийца

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

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

Как чинить. Подключитесь к сайту по FTP или через файловый менеджер хостинга. Найдите .htaccess в корневой папке (public_html, www или htdocs). Скопируйте его содержимое в текстовый файл как бэкап. Затем замените всё содержимое на стандартный WordPress-шаблон:

1 # BEGIN WordPress
2 
3<IfModule mod_rewrite.c>
4RewriteEngine On
5RewriteBase /
6RewriteRule ^index\.php$ - [L]
7RewriteCond %{REQUEST_FILENAME} !-f
8RewriteCond %{REQUEST_FILENAME} !-d
9RewriteRule . /index.php [L]
10</IfModule>
11 
12 # END WordPress

Этот код восстанавливает стандартные правила перезаписи URL (ЧПУ) и убирает всё лишнее. Сайт должен ожить сразу. Дальше можно заново настроить плагин, но теперь вы знаете, куда смотреть, если что-то пойдёт не так.

Не помогло? Верните старый .htaccess из бэкапа и переходите к следующему шагу. На Nginx .htaccess не работает, смотрите логи /var/log/nginx/error.log, проблема в конфигурации серверного блока.

3. Фатальная ошибка в PHP-коде

Плагин или тема вызывают функцию, которой нет, передают неверный тип аргумента или обращаются к несуществующему классу. PHP прерывает выполнение, и перед вами та самая 500-я.

Без отладочной информации вы гадаете на кофейной гуще. К счастью, WordPress умеет показывать ошибки, нужно лишь включить режим отладки.

Включаем WP_DEBUG

Откройте файл wp-config.php в корне сайта. Найдите строку:

1define( 'WP_DEBUG', false );

Замените false на true. Если такой строки нет, добавьте её перед /* That's all, stop editing! */:

1define( 'WP_DEBUG', true );
Экран компьютера с редактором кода и программным кодом

После сохранения обновите страницу. Вместо белого экрана вы увидите сообщение вроде:

1Fatal error: Call to undefined function wpsupercache_gc() in
2/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

В ошибке указаны: тип проблемы (undefined function), файл-виновник (wp-cache.php) и строка (342). Это прямой указатель на плагин, вызвавший падение. Отключите его, переименуйте папку плагина, сайт заработает. Дальше обновите плагин, найдите замену или свяжитесь с разработчиком.

Обязательно верните WP_DEBUG в false после диагностики. На боевом сайте вывод ошибок посетителям не нужен и может раскрыть внутренние пути сервера. Если хотите собирать логи без показа на экране, добавьте в wp-config.php строки define( 'WP_DEBUG_LOG', true ); и define( 'WP_DEBUG_DISPLAY', false );. Ошибки будут писаться в wp-content/debug.log.

⁉️🤔 Частые вопросы

Можно ли просто перезагрузить сервер, чтобы убрать ошибку 500?

Нет. В отличие от 503, которая часто уходит после перезагрузки (снимается пиковая нагрузка), ошибка 500 вызвана проблемой в коде. Перезагрузка сервера её не исправит: после запуска сайт снова наткнётся на тот же битый код и упадёт.

Как определить, плагин или тема виноваты, если админка недоступна?

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

Обязательно включать WP_DEBUG на рабочем сайте?

Нет, на работающем сайте WP_DEBUG должен быть выключен (false). Включайте его только на время диагностики и сразу выключайте. Для постоянного сбора ошибок без показа посетителям используйте связку WP_DEBUG_LOG (пишет в wp-content/debug.log) и WP_DEBUG_DISPLAY (отключает вывод на экран).

Что делать, если ни один из трёх способов не помог?

Проверьте лимит памяти PHP, memory_limit в php.ini. Иногда скриптам не хватает выделенных мегабайт, и они падают с 500-й. Увеличьте до 256M или 512M. Не помогло, обратитесь в поддержку хостинга: попросите посмотреть логи ошибок сервера (error_log Apache/Nginx). Там будет точная причина, которую вы не видите со стороны WordPress.

Сайт на Nginx, что делать с.htaccess?

Nginx не использует .htaccess. Правила перезаписи прописываются в конфигурации серверного блока (nginx.conf или sites-available/your-site). Если вы на Nginx и получили 500-ю, смотрите логи /var/log/nginx/error.log. Неверный .htaccess на Nginx-сервере проблем не вызывает, он просто игнорируется.

Как предотвратить ошибку 500 в будущем?

Три правила профилактики. Первое: обновляйте плагины, темы и ядро WordPress своевременно, каждый месяц, не раз в год. Второе: не держитесь за брошенные разработчиками расширения; если плагин не обновлялся больше года, ищите живую замену. Третье: перед установкой любого плагина проверяйте дату последнего обновления и совместимость с вашей версией PHP на странице плагина в каталоге WordPress. Десять минут профилактики в месяц экономят часы экстренной отладки.

Что делать прямо сейчас, если сайт лежит с 500-й

Ошибка 500, головоломка с предсказуемым решением. В подавляющем большинстве случаев вы почините сайт за четверть часа, пройдясь по трём шагам в правильном порядке: отключить плагины, сбросить .htaccess, включить WP_DEBUG. Порядок важен, от самого вероятного и быстрого к самому подробному.

Если переносили сайт на новый хостинг, начинайте с проверки PHP. Если настраивали кэширование или редиректы, с .htaccess. Если обновляли плагины и сайт упал, с WP_DEBUG. А если ничего не делали, а 500-я появилась сама, пройдите все три шага подряд, один из них почти наверняка сработает.

Не откладывайте диагностику: каждая минута простоя сайта, потерянные посетители и позиции в поиске. Откройте FTP, сделайте бэкап, и вперёд.

Редакция
РедакцияРедакционная команда→ Все публикации

Профессиональная команда авторов и редакторов, специализирующихся на создании качественного контента.