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

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

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

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

Что на самом деле означает код 500

По HTTP-стандарту 500 Internal Server Error — общий ответ на неожиданное состояние сервера. Браузер видит результат, но не знает, на каком уровне произошёл сбой.

Запрос к WordPress проходит несколько уровней:

1. домен и DNS направляют посетителя на сервер;
2. Apache или Nginx принимает запрос;
3. PHP запускает WordPress;
4. ядро загружает тему, плагины и конфигурацию;
5. WordPress обращается к базе и внешним сервисам;
6. сервер формирует HTTP-ответ.

Ошибка на любом этапе может завершиться кодом 500. Поэтому текста в браузере почти никогда не достаточно для диагноза.

Не путайте 500 с другими ошибками

Исходный код ответа можно проверить в DevTools или через проверку HTTP-заголовков. Тестируйте проблемный адрес, а не только главную страницу.

План первых 15 минут

При аварии действуйте по короткой схеме:

1. Проверьте сайт в приватном окне и через другую сеть.
2. Запишите точное время, URL и действие перед ошибкой.
3. Определите масштаб: весь сайт, админка, одна страница, форма или checkout.
4. Сделайте снимок текущего состояния или резервную копию.
5. Откройте журнал ошибок хостинга, PHP или WordPress.
6. Если перед сбоем было обновление, сначала проверяйте этот компонент.
7. Меняйте одну вещь за раз и ведите краткий журнал действий.
8. После восстановления проверьте формы, корзину, оплату и админку.

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

Сначала определите масштаб проблемы

Масштаб сразу сужает поиск.

Ошибка на всём сайте и в /wp-admin/

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

Публичная часть не работает, а админка открывается

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

Админка падает, но сайт работает

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

Ошибка только на одной странице

Смотрите шаблон страницы, shortcode, виджет, отдельный запрос к базе, внешний API или повреждённые данные. Отключать весь сайт из-за локальной проблемы не нужно.

Ошибка только при сохранении, импорте или оплате

Проверяйте AJAX/REST-запрос, память, max_execution_time, размер запроса, PHP-FPM, webhook или ответ платёжного сервиса. В Network браузера зафиксируйте URL, метод, код и время неудачного запроса.

Логи ошибок: самый короткий путь к причине

Начинайте с фактов, а не предположений. В панели хостинга нужный файл может называться Error Log, PHP Log, Apache Error Log или Nginx Error Log. WordPress может временно записывать события в wp-content/debug.log.

В wp-config.php, перед финальной строкой об окончании редактирования, добавьте:

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

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

Как читать типичную запись

PHP Fatal error: Uncaught TypeError ...
in /wp-content/plugins/example-plugin/file.php on line 184

Важны:

• тип ошибки: Fatal error, TypeError, Allowed memory size exhausted;
• полный путь к файлу;
• название плагина или темы;
• номер строки;
• время, совпадающее с вашим тестом.

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

Причина 1. Несовместимый или повреждённый плагин

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

Если админка доступна

1. Отключите последний изменённый плагин.
2. Очистите только связанный кеш.
3. Повторите точное действие, которое давало 500.
4. Если сайт заработал, сравните лог и журнал изменений плагина.
5. Не оставляйте старую уязвимую версию постоянным решением.

Если админка недоступна

Через SFTP или файловый менеджер переименуйте папку подозреваемого плагина:

wp-content/plugins/example-plugin
wp-content/plugins/example-plugin.disabled

Если подозреваемого нет, можно временно переименовать весь каталог plugins, но это отключит все обычные расширения. На WooCommerce действие может затронуть корзину, оплату, доставку, письма и интеграции. После возврата имени включайте плагины по одному.

Must-use плагины и drop-ins

Каталог wp-content/mu-plugins загружается автоматически и не отключается через обычный список. Если стандартные плагины отключены, а ошибка осталась, проверьте MU-плагины и файлы object-cache.php, advanced-cache.php, db.php.

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

Причина 2. Ошибка в теме

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

Если WordPress Recovery Mode отправил письмо, войдите по защищённой ссылке и отключите проблемную тему. Если письма нет, переименуйте папку активной темы через SFTP. WordPress попробует перейти на установленную стандартную тему.

До проверки убедитесь, что стандартная тема установлена. Не удаляйте активную тему и не заменяйте её случайным архивом: сохраните копию, версию, локальные изменения и связь с дочерней темой.

Если падает один шаблон, сравните его с последней рабочей версией. Частые причины:

• синтаксическая ошибка после ручного редактирования;
• вызов удалённой функции;
• более строгие типы после обновления PHP;
• бесконечная рекурсия;
• тяжёлый запрос внутри цикла;
• зависимость от отключённого плагина.

Причина 3. Повреждённый .htaccess

На Apache синтаксическая ошибка или запрещённая директива в .htaccess может вызвать 500 ещё до запуска WordPress.

Безопасная проверка:

1. Скачайте копию текущего .htaccess.
2. Переименуйте его в .htaccess.old.
3. Проверьте главную и проблемный URL.
4. Если сайт заработал, откройте «Настройки → Постоянные ссылки» и сохраните структуру, чтобы создать базовые правила.
5. Возвращайте дополнительные блоки по одному и проверяйте каждый.

Не копируйте чужой .htaccess целиком. В нём могут быть правила другого домена, PHP handler, кеш, защита или директивы, запрещённые вашим сервером.

Nginx не использует .htaccess. Там проверяют virtual host, error_log, PHP-FPM и reverse proxy.

Причина 4. Память или время выполнения PHP

Allowed memory size exhausted прямо говорит, что процесс исчерпал память. Но это не означает, что достаточно увеличить лимит. Память может съедать цикл, тяжёлый импорт, большое изображение, запрос или конфликт.

Временное увеличение помогает диагностике, однако сначала зафиксируйте текущие значения. На управляемом хостинге реальный лимит может задаваться через php.ini, .user.ini, панель, pool PHP-FPM или политику тарифа.

Похожие записи:

• Maximum execution time exceeded — процесс работал слишком долго;
• upstream timed out — сервер не дождался PHP-FPM;
• server reached max_children — все PHP-процессы заняты;
• MySQL server has gone away — потеряно соединение с базой;
• No space left on device — закончилось место или inode.

Регулярное исчерпание лимитов требует профилирования запроса, cron, плагина, базы и тарифа. Надёжный хостинг для сайта важен, но более мощный сервер не исправляет бесконечный цикл в коде.

Причина 5. Несовместимая версия PHP

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

Проверьте:

• версию PHP конкретного домена;
• требования WordPress, темы и критических плагинов;
• необходимые расширения PHP;
• лог сразу после переключения;
• одинаковы ли версии для web и CLI/cron.

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

Причина 6. Неправильные права или владелец файлов

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

Не ставьте 777 как универсальное решение. Это расширяет доступ и скрывает проблему owner/group. Конкретные права зависят от сервера; часто используются 644 для файлов и 755 для каталогов, но ориентироваться нужно на правила хостинга.

Сравните проблемный файл с соседними рабочими и найдите точный Permission denied в журнале.

Причина 7. Повреждённые файлы ядра WordPress

Незавершённое обновление, ошибка диска, неполное копирование или заражение могут повредить ядро. До переустановки убедитесь, что причина не в wp-content и не в конфигурации.

Контролируемый порядок:

1. создать полную копию;
2. зафиксировать версию WordPress;
3. получить чистый официальный пакет той же или осознанно новой версии;
4. заменить файлы ядра, не затрагивая wp-content и wp-config.php;
5. проверить логи, админку, медиа, формы и cron.

Если файлы снова меняются после замены, ищите заражение или процесс, который их перезаписывает.

Причина 8. Сервер, WAF, диск или база

Когда код не менялся, а 500 появляется волнами или под нагрузкой, проверяйте инфраструктуру:

• CPU, RAM, I/O и число процессов;
• свободное место и inode;
• состояние PHP-FPM;
• ошибки Apache/Nginx;
• доступность MySQL/MariaDB;
• ModSecurity или другой WAF;
• rate limit и блокировку IP;
• cron, импорт, бекап и очереди;
• внешние API, блокирующие запрос.

WAF может возвращать 500 или 403 только для конкретного payload, например при сохранении страницы с кодом. Не отключайте защиту глобально. Найдите ID правила в журнале и создайте точечное исключение после проверки запроса.

Если неясно, правильно ли отвечают домен, DNS и сервер, пройдите проверку домена, хостинга и сервера. Ошибку сертификата не стоит маскировать под 500 — для неё есть отдельный гайд про SSL-сертификат и HTTPS.

Матрица «симптом → проверка»

Особый случай: WooCommerce

Для магазина недостаточно вернуть главную. Проверьте:

1. товар и вариации;
2. добавление и удаление из корзины;
3. купон;
4. checkout гостя и пользователя;
5. все активные способы оплаты и доставки;
6. письма покупателю и администратору;
7. webhook, CRM, склад и фискализацию;
8. фоновые задачи и Action Scheduler;
9. создание заказа без двойного списания.

Не повторяйте реальную оплату без контрольного плана. Используйте sandbox платёжной системы или документированный тестовый заказ и сразу проверяйте логи.

Чего не следует делать

Пять изменений одновременно

Вы потеряете причинно-следственную связь и не будете знать, что откатывать.

Публичный вывод PHP-ошибок

Абсолютные пути и структура каталогов полезны не только администратору. Записывайте ошибки в закрытый лог.

Удаление без копии

Переименование обратимо. Удаление плагина, темы или базы — нет.

Права 777

Это небезопасная маскировка проблемы владельца файлов.

Восстановление старой базы поверх новых заказов

Сначала сохраните текущую базу, определите окно инцидента и спланируйте сохранение новых транзакций.

Массовое обновление во время аварии

Оно добавляет новые переменные. Сначала изолируйте причину и верните сервис, затем обновляйте контролируемо.

Как подтвердить полное восстановление

Код 200 на главной — только начало. Проверьте:

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

После восстановления запустите проверку скорости сайта. Если 500 исчезла, но TTFB вырос или сервер продолжает периодически падать, первопричина могла остаться.

Профилактика

1. Обновляйте WordPress, темы и плагины сначала на staging.
2. Делайте автоматические копии и отдельный pre-update backup.
3. Храните логи с ротацией и ограниченным доступом.
4. Отслеживайте HTTP-статус, время ответа, диск и SSL.
5. Удаляйте ненужные плагины, а не только отключайте.
6. Используйте поддерживаемую PHP и тестируйте совместимость.
7. Документируйте ручные изменения кода и конфигурации.
8. Храните список доступов и назначьте ответственного за восстановление.
9. Раз в квартал тестируйте восстановление в отдельной среде.
10. После инцидента записывайте первопричину, а не только действия.

Когда нужен специалист

Обращайтесь за помощью, если:

• сайт принимает платежи или критичные заявки;
• нет проверенной резервной копии;
• 500 возвращается после временного исправления;
• логи указывают на базу, PHP-FPM, WAF или сервер;
• есть признаки заражения;
• нужно сохранить заказы между копией и текущей базой;
• одинаково падают несколько сайтов аккаунта;
• неизвестно, что менял предыдущий подрядчик.

Подготовьте URL, время сбоя, скриншот, последние изменения, доступ к хостингу и WordPress, а также фрагмент лога без паролей и ключей. Это превращает расплывчатую проблему в конкретную проверку. Для контролируемого восстановления свяжитесь с BB STUDIO — локализуем причину, вернём сайт в работу, протестируем критические сценарии и зафиксируем профилактику.

Итоговый чек-лист

• записаны URL, время и действие перед ошибкой;
• определён масштаб сбоя;
• создана текущая копия;
• проверены серверный и PHP-журналы;
• WP_DEBUG_DISPLAY не показывает ошибки посетителям;
• плагины и тема тестируются по одному;
• .htaccess сохранён перед изменением;
• проверены PHP, память, timeout, диск и права;
• после восстановления проверены формы, админка и checkout;
• просмотрены новые записи логов;
• включён мониторинг и создан свежий бекап;
• первопричина записана.