Ошибка 500 означает, что сервер не смог обработать запрос. Сам WordPress обычно не показывает посетителю, что именно сломалось: причиной могут быть PHP fatal error, неисправный плагин, повреждённый файл, правила .htaccess или ограничения хостинга. Начните с журналов ошибок и последних изменений — это быстрее и безопаснее, чем отключать всё подряд.
Перед правками сохраните резервную копию файлов сайта и базы данных. Если сайт работает частично, зафиксируйте, какие страницы и действия вызывают ошибку: открывается ли главная, панель /wp-admin/, только отдельная страница или сайт падает после отправки формы. Эти различия помогут сузить поиск.
Сначала проверьте, где возникает ошибка
Откройте сайт в приватном окне и проверьте несколько адресов: главную страницу, страницу входа и /wp-admin/. Если ошибка появляется только на одном URL, вероятнее проблема связана с конкретным запросом, функцией плагина или правилом сервера. Если недоступны весь сайт и админка, проверяйте PHP, файлы, плагины и состояние сервера.
Уточните, когда началась проблема. После обновления WordPress, установки плагина, смены темы или переноса сайта сначала проверяйте именно это изменение. Также проверьте страницу статуса хостинга и уведомления в панели управления: сбой PHP-FPM, исчерпание дискового пространства или авария на сервере не исправляются настройками WordPress.
Если в WordPress включён режим восстановления, на адрес администратора может прийти письмо со ссылкой для входа и названием плагина или темы, вызвавших критическую ошибку. Проверьте папку спама. Такой режим помогает отключить проблемное расширение, но не заменяет проверку журнала ошибок.
Найдите конкретную причину в журнале ошибок
Самый полезный источник — журнал ошибок PHP на хостинге. Обычно его можно открыть в панели управления сайтом, разделе журналов или PHP. Названия разделов зависят от хостинга. Найдите записи, появившиеся в момент ошибки, и обратите внимание на сообщение PHP Fatal error, путь к файлу и название плагина или темы. Если обращение к сайту завершается ошибкой раньше, чем WordPress успевает запуститься, журнал сервера особенно важен.
Если журнал хостинга недоступен, временно включите запись отладочных ошибок WordPress. В wp-config.php добавьте настройки до строки с комментарием That's all, stop editing!. Если константы уже объявлены, измените существующие значения, а не добавляйте повторные определения.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );После этого воспроизведите ошибку и проверьте файл wp-content/debug.log, если сервер разрешает WordPress создать его. Не включайте показ ошибок посетителям: сообщения PHP могут раскрыть внутренние пути и детали сайта. Журнал также может содержать техническую информацию, поэтому не оставляйте отладку включённой после диагностики. Отключите её и удалите или защитите файл журнала. На некоторых хостингах запись в этот файл отключена или перенаправлена в системный лог — в таком случае запросите журнал у поддержки.
Проверьте файлы и правила сервера
Если ошибка началась после изменения файлов, временно исключите повреждённый файл или правило. Для доступа используйте файловый менеджер хостинга или FTP/SFTP. Не удаляйте файлы наугад: сначала скачайте их копии.
Проверьте .htaccess, если сайт работает на Apache
Правила в .htaccess применяются на Apache и совместимых конфигурациях, например на части серверов с LiteSpeed. Ошибка в этом файле может вызвать 500 ещё до запуска WordPress. Переименуйте файл, например в .htaccess.backup, и проверьте сайт. Если ошибка исчезла, проблема связана с одним из правил. Не удаляйте резервную копию: в файле могут находиться настройки перенаправлений, кеширования и защиты.
Когда админка снова доступна, откройте Настройки → Постоянные ссылки и нажмите «Сохранить изменения», не меняя структуру ссылок. WordPress попробует сформировать стандартные правила. Это работает, только если сервер поддерживает запись в файл; при необходимости правила придётся восстановить вручную с помощью хостинга. На Nginx файл .htaccess не используется — проверяйте конфигурацию сервера через поддержку.
Проверьте целостность файлов WordPress
Если ошибка появилась после ручной правки или неудачного обновления, повреждённый файл ядра может вызывать сбой. Восстановите файлы WordPress из чистого пакета той же версии: заменяйте каталоги wp-admin и wp-includes и файлы ядра в корне, но не перезаписывайте wp-config.php и не удаляйте wp-content. Перед заменой сделайте копию сайта. Если вы не уверены, какие файлы менялись, попросите хостинг или разработчика проверить их: простая перезапись не исправит проблему в теме, плагине или конфигурации PHP.
Отключите плагины и проверьте тему
Если журнал указывает на конкретный плагин, отключите только его: в панели WordPress или переименуйте каталог этого плагина внутри wp-content/plugins через файловый менеджер. Затем проверьте сайт. Если админка недоступна и неизвестно, какое расширение вызывает сбой, переименуйте каталог plugins, например в plugins.off. Это временно сделает обычные плагины недоступными. После проверки верните каталогу исходное имя и включайте расширения по одному в панели, каждый раз проверяя проблемную страницу.
На сайте с несколькими администраторами предупредите коллег о диагностике. Не удаляйте каталоги плагинов и не оставляйте их переименованными после теста: цель — временно исключить расширения, а затем определить конкретный источник ошибки.
Если сбой совпал со сменой темы или журнал указывает на файл темы, переключитесь на установленную стандартную тему через админку. Если админка недоступна, не удаляйте активную тему и не меняйте базу данных вслепую: способ переключения зависит от доступа к WP-CLI, версии WordPress и набора установленных тем. Попросите хостинг или разработчика выполнить переключение на совместимую стандартную тему. Если после смены темы сайт открывается, проверьте обновления темы и её совместимость с текущей версией PHP и WordPress.
Когда плагины не объясняют ошибку, проверьте также каталоги wp-content/mu-plugins и специальные файлы вроде wp-content/object-cache.php. Такие расширения и drop-in-файлы не всегда отключаются обычным переключателем плагинов. Меняйте их только после резервного копирования и с пониманием, за что они отвечают.
Исключите ограничения PHP и хостинга
Запись в журнале помогает отличить проблему кода от ограничений сервера. Сообщения о нехватке памяти или превышении времени выполнения указывают на лимиты PHP либо на слишком тяжёлую операцию. Попросите хостинг проверить лимит памяти PHP, время выполнения, свободное место и число файловых дескрипторов, а также ошибки PHP-FPM или веб-сервера. Доступные лимиты зависят от тарифного плана и конфигурации: изменение настройки в WordPress не всегда может их превысить.
Если сбой происходит во время обновления, импорта или резервного копирования, нагрузка может временно превышать возможности тарифа. Не добавляйте случайные значения в wp-config.php и не увеличивайте лимиты командами из инструкций для другого сервера: часть параметров задаётся только хостингом. Передайте поддержке время ошибки, адрес страницы и фрагмент журнала. Это позволит проверить серверные записи, недоступные из панели WordPress.
Обычные права доступа часто выставляют как 755 для каталогов и 644 для файлов, но точные требования зависят от владельца файлов и настройки сервера. Не применяйте массовую смену прав ко всему сайту наугад: неверные права или владелец файлов могут нарушить обновления и создать угрозу безопасности. Если журнал сообщает об отказе в доступе, попросите хостинг проверить владельца файлов и права для конкретного пути.
Проверьте результат и верните сайт в рабочее состояние
После каждого изменения проверяйте одну и ту же страницу, на которой раньше возникала ошибка, а затем главную и админку. Если проблема исчезла после отключения плагина, включайте остальные по одному, пока не найдёте виновника. Обновите или замените проблемное расширение только после проверки совместимости; если причина не устранена, оставьте его отключённым и обратитесь к разработчику плагина.
Перед завершением диагностики верните временно переименованные каталоги и нужные файлы, восстановите рабочие правила сервера, отключите отладку и проверьте, что журнал не доступен посетителям. Если ошибка сохраняется после проверки файлов, плагинов и темы, отправьте поддержке хостинга точное время сбоя, затронутый URL и строки из журнала. Ошибка 500 — общий ответ сервера, поэтому без этих данных нельзя надёжно определить, вызвана ли она WordPress или серверной конфигурацией.