Белый экран. Пять цифр: 500 Internal Server Error. Сайт лежит, клиент в мессенджере, а вы не знаете, за что хвататься.

Пятисотая, самый неприятный из HTTP-статусов. В отличие от 404 («страница не найдена») или 403 («доступ запрещён»), она не называет виновника. Просто «на сервере что-то пошло не так». А дальше сами: плагин, тема, кривой PHP, хостинг, битый .htaccess, вариантов десятки, и каждый требует разного лечения.

Хорошая новость: ошибка 500 всегда чинится. Без паники, без переустановки WordPress с нуля и в большинстве случаев, без разработчика. За 7 шагов, от 30-секундной диагностики до хирургической замены системных файлов, вы найдёте причину и поднимете сайт. Каждый метод, с конкретными файлами, строками кода и скриншотами.

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

• Шаг 1: включаем WP_DEBUG и читаем логи, сразу видим, какой файл виноват
• Шаг 2: исключаем проблемы хостинга, пока копаетесь в коде
• Шаг 3: чиним .htaccess, причина номер один по статистике поддержки
• Шаг 4: поднимаем лимит памяти PHP, частый виновник при загрузке медиафайлов и входе в админку
• Шаг 5: перезаливаем ядро WordPress, когда файлы повреждены сбоем автообновления
• Шаг 6: отключаем плагины через FTP, метод, который закрывает больше половины случаев
• Шаг 7: сбрасываем тему на дефолтную, шаг, который часто упускают

Что такое ошибка 500 и откуда она берётся

HTTP 500, это ответ сервера, означающий «внутреннюю ошибку». Запрос от браузера дошёл, Apache или Nginx его приняли, PHP начал выполняться, и споткнулся. В отличие от 404 или 403, где сервер осознанно отвечает «нет», пятёрка в начале кода говорит: что-то сломалось внутри скрипта, и сервер не знает, что именно.

В WordPress ошибка 500 возникает в четырёх типичных сценариях:

• Установили или обновили плагин, а он конфликтует с другим кодом в системе.
• Изменили .htaccess, и синтаксическая ошибка обрушила Apache.
• PHP-скрипт исчерпал выделенную память (белый экран с Allowed memory size of X bytes exhausted в логах).
• Файлы ядра повреждены, сбой при автообновлении, битая загрузка по FTP, кривой плагин, залезший в системные папки.

Реже, тема с фатальной ошибкой в functions.php, проблемы на стороне хостинга (перегрузка, отключение PHP-модуля) или битый шорткод удалённого плагина внутри контента страницы.

Прежде чем начать: сделайте полную резервную копию сайта. Без бэкапа любое действие с файлами сервера, это риск. Большинство хостеров дают кнопку бекапа в панели управления (cPanel, ISPmanager, aaPanel) в два клика.

1. Включите WP_DEBUG и прочитайте логи

Самый быстрый способ узнать причину, заставить WordPress показать её. По умолчанию ядро скрывает PHP-ошибки за белым экраном (это режим «не пугать посетителей»). Но в WordPress есть встроенный механизм отладки, константы WP_DEBUG.

Подключение режима отладки

Откройте wp-config.php в корне сайта через FTP или файловый менеджер хостинга. Найдите строку:

1
/* That's all, stop editing! Happy blogging. */

Перед ней вставьте блок:

1
// Включаем режим отладки
2
define( 'WP_DEBUG', true );
3
 
4
// Пишем ошибки в файл /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Не показываем ошибки посетителям на экране
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Что здесь происходит:

• WP_DEBUG, главный рубильник; без true остальные константы не работают.
• WP_DEBUG_LOG, направляет все ошибки в wp-content/debug.log, а не на экран. Посетители не видят пугающих сообщений.
• WP_DEBUG_DISPLAY + @ini_set, принудительно прячет ошибки из вывода страницы.

Сохраните файл, обновите проблемную страницу сайта и скачайте wp-content/debug.log по FTP. В логе вы увидите конкретный файл и строку: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Выключите отладку после диагностики. Закомментируйте или удалите добавленные строки. WP_DEBUG на боевом сайте замедляет работу, а debug.log со временем разрастается до гигабайт.

2. Свяжитесь с хостинг-провайдером

Логи пустые или не записались, ошибка может быть на стороне сервера, а не в коде WordPress. Особенно часто на дешёвых тарифах shared-хостинга с жёсткими лимитами на процессы.

Откройте тикет в поддержку и приложите три вещи:

• Точное время появления ошибки с часовым поясом сервера.
• URL страницы, на которой ошибка воспроизводится.
• Скриншот ошибки, если есть.

Техподдержка проверит серверные логи Apache или Nginx, нагрузку на процессор и память, доступные PHP-модули. На этом шаге проблема часто решается: администратор хоста перезапускает PHP-FPM или правит лимит на количество процессов.

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

Создайте файл info.php с одной строкой:

1
<?php phpinfo(); ?>

Загрузите его в корень сайта по FTP и откройте ваш-сайт.com/info.php. Увидели таблицу с параметрами PHP, сервер работает, ошибка в коде WordPress. Увидели 500, ошибка на уровне сервера, несите этот URL в поддержку.

После проверки **удалите **info.php. phpinfo() раскрывает версии, пути и модули сервера, это дыра в безопасности.

3. Почините файл.htaccess

.htaccess, конфигурационный файл Apache в корне сайта. WordPress использует его для человеко-понятных URL, редиректов и базовых правил безопасности. Одна лишняя скобка, конфликт правил от двух плагинов, и весь сайт ложится с ошибкой 500. По статистике обращений в поддержку именно .htaccess оказывается причиной номер один.

Быстрая проверка: переименуйте .htaccess в .htaccess_old через FTP и обновите сайт. Заработал, проблема точно в этом файле.

Теперь восстановите .htaccess: зайдите в админку WordPress, Настройки → Постоянные ссылки и нажмите «Сохранить изменения», не меняя структуру. WordPress сгенерирует новый, чистый .htaccess со стандартными правилами:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

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

4. Увеличьте лимит памяти PHP

PHP-скриптам WordPress нужна оперативная память. Когда плагин или тема запрашивают больше выделенного, скрипт падает. Результат: ошибка 500 или белая страница с Allowed memory size of X bytes exhausted.

Стандартный лимит у многих хостеров до сих пор, 64 MB. Для современного сайта на WordPress с десятком плагинов этого катастрофически мало. Рекомендуемый минимум, 256 MB.

Способ 1: через wp-config.php (приоритетный)

Добавьте в wp-config.php перед /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Эта константа переопределяет лимит PHP для фронтальной части сайта. Для админки WordPress автоматически поднимает планку до WP_MAX_MEMORY_LIMIT (по умолчанию 256 MB).

Способ 2: через php.ini (если хостинг не даёт править wp-config)

Создайте файл php.ini с содержимым:

1
memory_limit = 256M

Загрузите его в корень сайта и в папку wp-admin/. Не помогло, создайте или отредактируйте .user.ini в корне сайта с той же строкой.

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

5. Перезалейте файлы ядра WordPress

Повреждённый файл ядра, нечастая, но коварная причина. Сбой при автообновлении, битый FTP-трансфер, плагин, изменивший системные файлы, и wp-admin или wp-includes содержат мусор.

Порядок действий:

• Скачайте свежий ZIP-архив WordPress с wordpress.org.
• Распакуйте архив на компьютере.
• По FTP зайдите в корень сайта и удалите папки wp-admin и wp-includes (только их, не трогайте wp-content!).
• Залейте папки wp-admin и wp-includes из свежего архива.
• Не перезаписывайте wp-content, там ваши темы, плагины и загрузки.

Корневые файлы (wp-settings.php, index.php и другие) тоже можно заменить свежими из архива. **Кроме **wp-config.php, его не трогайте, в нём доступ к базе данных. После замены обновите сайт, ошибка уйдёт, если причина была в битых системных файлах.

6. Отключите плагины

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

Если админка работает

Зайдите в Плагины → выберите все → групповое действие «Деактивировать» → «Применить». Ошибка исчезла, включайте плагины по одному, обновляя сайт после каждого. Нашли виновника, удалите или сообщите разработчику.

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

Зайдите на сервер по FTP и переименуйте папку wp-content/plugins в plugins_off. WordPress перестанет загружать все плагины, и сайт оживёт. Верните папке исходное имя и переименовывайте подпапки плагинов по одной, так найдёте проблемный, не заходя в админку.

На что обратить внимание: плагины кеширования (W3 Total Cache, WP Rocket) иногда записывают свои правила в .htaccess и wp-config.php. После деактивации такого плагина ошибка может остаться, проверьте эти файлы и удалите строки между маркерами # BEGIN W3TC и # END W3TC или аналогичными.

7. Переключитесь на дефолтную тему

Активная тема, недооценённый, но реальный источник ошибки 500. Особенно если в functions.php добавили сниппет с фатальной ошибкой.

Проверка простая: через FTP переименуйте папку активной темы в wp-content/themes/ (например, mytheme → _mytheme). WordPress обнаружит, что активная тема исчезла, и автоматически переключится на стандартную, Twenty Twenty-Five или другую дефолтную тему, установленную в системе.

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

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

Что делать, если ошибка 500 появляется только при входе в админку?

Скорее всего, лимита памяти PHP не хватает именно для админ-панели, она грузит все плагины разом и тяжелее фронта. Добавьте в wp-config.php строку define( 'WP_MAX_MEMORY_LIMIT', '512M' );, это отдельный лимит для админки, выше фронтального WP_MEMORY_LIMIT. Проверьте также папку плагинов: по нашей практике чаще всего виноват плагин безопасности вроде Wordfence или бэкап-плагин, потребляющий память при загрузке админ-бара. Отключите их через FTP (папка plugins_off из шага 6) и проверьте.

Можно ли чинить ошибку 500 без FTP-доступа?

Да. Большинство хостеров дают файловый менеджер в панели управления: cPanel → File Manager, ISPmanager → Файлы. Через него переименовываются .htaccess, папки плагинов и тем, правится wp-config.php, все шаги те же. Совсем без доступа к файлам, только через поддержку хостинга. Лайфхак: если установлен плагин для сниппетов (Code Snippets, WPCode) и вы последним действием добавили сниппет, попробуйте открыть ваш-сайт.com/?code_snippets_safe_mode=1 или аналогичный safe-mode URL вашего плагина. Это отключает все сниппеты без FTP.

Ошибка 500 появляется только на одной странице, в чём причина?

Битая функция или шорткод внутри контента этой конкретной страницы. Откройте страницу в редакторе WordPress (если админка работает) и временно удалите все шорткоды, блоки Gutenberg и вставки кода. Если админка недоступна, найдите запись в базе данных через phpMyAdmin (таблица wp_posts), скопируйте содержимое в текстовый редактор и уберите подозрительные шорткоды. Самые частые виновники: шорткоды удалённых плагинов ([dead_plugin] остался, а плагина нет), битый PHP в блоках контента, некорректно вложенные Gutenberg-блоки.

После восстановления ошибка 500 возвращается через пару часов, как найти причину?

Циклическая ошибка с интервалом, почти всегда один из трёх сценариев: cron-задача WordPress запускает битый процесс по расписанию, плагин кеширования генерирует битый кеш, или хостинг периодически упирается в лимит процессов (особенно на дешёвых shared-тарифах). Установите WP Crontrol и проверьте список cron-задач, найдите ту, что совпадает по времени с падением. Сбросьте кеш плагина кеширования. Спросите хостера про лимит Entry Processes или PHP Workers, на shared-тарифах их часто режут до 5-10, и всплеск трафика кладёт сайт.

Нужно ли проходить все 7 шагов или можно пропустить часть?

Первые два шага (WP_DEBUG и хостинг), диагностические: они не ломают сайт и дают информацию. По опыту поддержки WordPress-сайтов, шаг 3 (.htaccess) и шаг 6 (плагины) закрывают подавляющее большинство случаев. Оставшиеся приходятся на память PHP, повреждённое ядро и тему. В типичной ситуации вы решите проблему уже на шагах 3 и 6, не проходя всю цепочку.

С чего начать прямо сейчас

Не повторяйте типичный сценарий: паника → удаление всего подряд → усугубление. Идите по порядку, от диагностики к исправлению:

Главное правило ремонта WordPress: одно действие, одна проверка. Никогда не делайте два исправления за раз, не поймёте, что сработало. И запишите, какой именно плагин или правка вызвали ошибку. В следующий раз почините всё за 30 секунд.