Белый экран и ошибка 500 на WordPress почти всегда вызваны одним из пяти источников: плагином, темой, повреждённым файлом .htaccess, нехваткой памяти PHP или битыми файлами ядра. Проверять их нужно именно в таком порядке, от самого частого и дешёвого к самому редкому, и для большинства шагов программист не нужен: хватит доступа к файлам сайта через FTP или файловый менеджер хостинга.
Типичная ситуация, с которой к нам приходят владельцы сайтов: вчера всё работало, утром вместо сайта пустая белая страница или надпись «Внутренняя ошибка сервера». Паника понятна, ведь это заявки, реклама и репутация. Хорошая новость в том, что сайт при этом обычно цел: файлы и база на месте, не работает один компонент. Ниже пошаговая диагностика, которую можно пройти за час, ничего не сломав и не потеряв.
Чем белый экран отличается от ошибки 500
Белый экран (в англоязычной документации WSOD, white screen of death) это пустая страница без каких-либо сообщений. Официальная справка WordPress описывает его как пустой экран без информации и называет возможной причиной как ошибки PHP, так и ошибки базы данных.
Ошибка 500 (Internal Server Error) это ответ сервера «что-то пошло не так», но без подробностей. Справка отмечает, что причин у неё может быть несколько, и самая вероятная из них, по её словам, повреждённый файл .htaccess.
Для вас, как для владельца сайта, разница практическая. Белый экран чаще указывает на ошибку в коде плагина или темы, а ошибка 500 чаще на конфигурацию сервера. Но диагностика у них во многом общая, поэтому и разбираем их вместе.
Что сделать в первые пять минут, прежде чем что-то трогать
Сначала сделайте три вещи, которые не меняют сайт и сэкономят нервы.
- Проверьте, что недоступен весь сайт, а не только одна страница, и откройте его с телефона через мобильную сеть: так вы исключите локальный кэш и проблемы вашего интернета.
- Проверьте почту администратора сайта. Начиная с WordPress 5.2 при критической ошибке работает режим восстановления: по описанию разработчиков WordPress на адрес администратора приходит уведомление с приватной ссылкой на этот режим. Перейдя по ссылке и войдя в админку, вы увидите, какой плагин или тема приостановлены и с какой ошибкой.
- Сделайте копию сайта: файлы и базу данных. Если хостинг делает автоматические резервные копии, убедитесь, что свежая копия есть, и скачайте её. Все дальнейшие шаги обратимы, но копия нужна на случай, если что-то пойдёт не так.
Режим восстановления стоит выделить. Он действует только для вашего браузера: пока у вас стоит специальная кука, проблемный компонент приостановлен, а остальные посетители продолжают видеть сломанный сайт. Отсюда следует важный вывод: зайдя в режиме восстановления и увидев, что всё работает, не считайте проблему решённой. Нужно отключить или исправить виновника, иначе после выхода из режима ошибка вернётся.
Как включить вывод ошибок и найти причину по журналу
Если письма нет или ссылка не помогла, включите журнал ошибок. WordPress для этого использует константу WP_DEBUG. Согласно справке по отладке WordPress, это глобальная PHP-константа, по умолчанию она выключена, а включается строкой в файле wp-config.php.
Практичный набор из трёх строк выглядит так, и размещают его перед строкой «That’s all, stop editing! Happy blogging.»:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_LOG записывает ошибки в файл debug.log в каталоге wp-content, а WP_DEBUG_DISPLAY со значением false не показывает сообщения посетителям. Значения пишутся без кавычек: справка предупреждает, что ‘false’ в кавычках это строка, которую PHP считает истинной. После этого откройте проблемную страницу ещё раз и загляните в wp-content/debug.log. Первая строка с «Fatal error» обычно содержит путь к файлу, например wp-content/plugins/название-плагина/файл.php. Это и есть виновник.
Справка также прямо говорит, что использовать эти инструменты на рабочем сайте не рекомендуется, лучше работать на тестовой копии. На практике, когда сайт уже лежит, включить журнал на минуты нормально, но после диагностики верните WP_DEBUG в false и удалите файл debug.log: в нём могут быть пути и фрагменты данных, которые не нужны посторонним.
Как проверить плагины, если в админку не попасть
Плагин ломает сайт чаще всего, особенно после обновления. По справке WordPress, плагины нужно отключить все сразу, а затем включать по одному. Если админка недоступна, достаточно переименовать каталог wp-content/plugins в plugins_old через FTP или файловый менеджер хостинга.
Порядок действий такой:
- Подключитесь к сайту по FTP и откройте каталог wp-content.
- Переименуйте папку plugins в plugins_old. WordPress решит, что плагинов нет, и отключит их все.
- Откройте сайт. Если он заработал, виновник среди плагинов.
- Верните имя plugins. Плагины останутся выключенными, потому что WordPress их деактивировал.
- Включайте плагины в админке по одному, проверяя сайт после каждого. Как только ошибка вернулась, вы нашли причину.
Если по журналу вы уже знаете плагин, быстрее переименовать только его папку внутри wp-content/plugins. Найдя виновника, не торопитесь его удалять. Проверьте, нет ли обновления, посмотрите, не конфликтует ли он с версией PHP на вашем хостинге, и только потом решайте, чинить, заменять или убирать.
Как проверить тему
Если плагины ни при чём, следующий подозреваемый тема, особенно если вы недавно её меняли или обновляли. Справка советует активировать стандартную тему, например Twenty Twenty-One для WordPress 5.8 и ниже, поскольку Twenty Twenty-Two требует версии 5.9 и выше. В новых версиях подойдёт любая стандартная тема, которая у вас установлена.
Без доступа в админку используется тот же приём, что и с плагинами: через FTP переименуйте папку активной темы в wp-content/themes. WordPress переключится на доступную стандартную тему. Если сайт заработал, дело в коде вашей темы: чаще всего это файл functions.php, в который кто-то вставил фрагмент кода с синтаксической ошибкой.
Практический совет по нашему опыту сопровождения сайтов на WordPress: код в functions.php вставляют из статей и чатов, не проверяя версию PHP. После обновления PHP на хостинге такая вставка внезапно перестаёт работать, и сайт показывает белый экран. Если вы правили этот файл, сначала проверьте последние изменения.
Как исправить ошибку 500 через файл .htaccess
Если после плагинов и темы ошибка 500 осталась, проверьте файл .htaccess в корне сайта. Справка WordPress называет повреждённый .htaccess самой вероятной причиной этой ошибки и предлагает переименовать его в .htaccess_old, после чего перезагрузить сайт.
Если сайт открылся, зайдите в админку, откройте «Настройки» и «Постоянные ссылки» и просто сохраните страницу. WordPress создаст новый корректный .htaccess. Файл .htaccess скрытый, поэтому в FTP-клиенте включите показ скрытых файлов, иначе вы его не увидите.
Обратите внимание на то, как менялся этот файл. Его правят плагины кэширования, безопасности и редиректов, а иногда вручную подрядчик. Если вы понимаете, что в .htaccess были нужные правила, например редиректы с домена без www на основной или защита каталогов, сохраните старый файл: после восстановления работы эти правила придётся вернуть аккуратно, по одному.
Как проверить лимит памяти PHP
Нехватка памяти даёт и белый экран, и ошибку 500, особенно при тяжёлых плагинах, импорте товаров или генерации миниатюр. Справка перечисляет увеличение лимита памяти PHP как один из шагов при ошибке 500.
В документации по wp-config.php за это отвечает константа WP_MEMORY_LIMIT, пример записи: define( 'WP_MEMORY_LIMIT', '64M' );. По описанию, WordPress пытается поднять память PHP до 40 МБ на обычной установке и до 64 МБ на сети сайтов (multisite). Для административных задач есть отдельная константа WP_MAX_MEMORY_LIMIT, которую по документации нужно размещать до подключения wp-settings.php.
Но есть оговорка, о которой часто забывают. Документация пишет, что некоторые хостинги не позволяют WordPress поднимать лимит самостоятельно, и тогда его нужно увеличивать через поддержку хостинга. Поэтому если вы прописали константу, а ошибка не ушла, это не значит, что причина другая: возможно, хостинг просто проигнорировал ваше значение. Напишите в поддержку хостинга и спросите, какой лимит памяти PHP фактически действует для вашего аккаунта.
Когда нужно заменить файлы ядра
Последний шаг из справки: заново загрузить каталоги wp-admin и wp-includes из свежего дистрибутива WordPress. Это нужно, если файлы ядра повреждены при неудачном обновлении или обрыве загрузки. Загрузка заменяет только системные файлы: ваши плагины, темы и загруженные файлы в wp-content, а также wp-config.php остаются на месте.
Делайте это в самую последнюю очередь и только с резервной копией на руках. Скачайте ту же версию WordPress, которая у вас стоит, или более свежую, распакуйте архив и заменяйте именно эти две папки целиком, а не отдельные файлы. Если после этого ошибка осталась, значит, проблема не в ядре, и следующий шаг уже за администратором сервера или поддержкой хостинга.
Как понять, что дело не в WordPress, а в хостинге или базе данных
Бывает, что сайт ломается без вашего участия. Тогда стоит посмотреть на другие признаки. Если не работает и админка, и страницы, и в журнале ошибок нет записей, возможно, у хостинга авария или закончился лимит дискового пространства либо число файлов. Если на странице видна надпись про ошибку подключения к базе данных, причина в базе: проверьте данные доступа в wp-config.php и состояние сервера баз данных на хостинге.
Справка прямо указывает, что белый экран могут вызывать не только ошибки PHP, но и ошибки базы данных. Поэтому если по журналу и после проверки плагинов и темы причина не найдена, обращайтесь в поддержку хостинга с точным описанием: когда началось, что вы уже проверили, какие строки есть в debug.log. Хорошее обращение сокращает время решения в разы, потому что инженер сразу видит, что искать.
Пример разбора: как это выглядит на практике
Возьмём иллюстративный случай, придуманный для примера. Владелец интернет-магазина обновил плагин доставки, и через минуту главная страница стала белой. Админка при этом открывается с ошибкой. Он включает журнал и видит в wp-content/debug.log запись о фатальной ошибке в файле внутри каталога плагина доставки. Порядок действий дальше простой.
- Через FTP переименовывает папку этого плагина в wp-content/plugins. Сайт открывается.
- Заходит в админку и видит, что плагин деактивирован. Проверяет, есть ли для него более новая версия, и читает список изменений.
- Находит в списке изменений упоминание новой минимальной версии PHP. На хостинге стоит более старая, поэтому плагин и упал.
- Либо обновляет PHP на хостинге после проверки совместимости остальных плагинов, либо возвращает предыдущую версию плагина из резервной копии.
- Выключает WP_DEBUG и удаляет debug.log.
Обратите внимание на то, что здесь не понадобилось ни одной строчки кода и ни одного специалиста. Достаточно было последовательно исключать подозреваемых и читать то, что сайт сам пишет в журнал.
Типичные ошибки при самостоятельной диагностике
Люди в панике делают одни и те же вещи, которые только усложняют ситуацию. Мы видим их из раза в раз.
Одновременно меняют сразу несколько вещей
Владелец переименовывает плагины, меняет тему, правит wp-config.php и переустанавливает WordPress за один подход. Сайт заработал, но никто не знает, что именно помогло, а значит, причина не устранена и проблема вернётся. Меняйте одно действие за раз и после каждого проверяйте сайт.
Оставляют включённым вывод ошибок для посетителей
Сообщения об ошибках на экране показывают пути к файлам и иногда фрагменты запросов. Для диагностики журнал удобнее, поэтому используйте WP_DEBUG_LOG, а вывод на экран отключайте через WP_DEBUG_DISPLAY.
Удаляют, а не переименовывают
Переименование каталога обратимо, удаление нет. Если вы удалили плагин с настройками, а в резервной копии его нет, вернуть конфигурацию будет сложно. Переименовывайте, проверяйте и только потом принимайте решение.
Забывают про кэш
Плагины кэширования и CDN могут показывать устаревшую страницу уже после того, как проблема исправлена. После каждого вмешательства открывайте сайт в приватном окне браузера или очищайте кэш плагина. Только не делайте это очисткой из кода на рабочем сайте без необходимости: на некоторых сайтах массовая очистка кэша сама создаёт нагрузку, которая приводит к новому сбою.
Что передать специалисту, если решили не разбираться самостоятельно
Даже если вы не собираетесь править файлы сами, несколько минут подготовки ускорят решение. Подготовьте для специалиста короткий набор сведений: когда именно сайт перестал работать, что делали на сайте незадолго до этого (обновления, правки, установка плагинов), что показывает страница (белый экран или конкретное сообщение), какая версия PHP стоит на хостинге и есть ли свежая резервная копия. Если вы успели включить журнал, приложите последние строки debug.log.
С такими данными диагностика обычно занимает минуты, а не часы. Без них специалисту приходится восстанавливать картину по косвенным признакам, и время уходит на вопросы.
Отдельно проверьте, не менялась ли версия PHP на хостинге. Многие хостинги позволяют переключать её в панели управления, а иногда обновляют автоматически. Если сбой начался сразу после такого переключения, вернув прежнюю версию, вы за минуту поймёте, что дело в совместимости. Это быстрая и обратимая проверка, и её полезно сделать до любых правок в файлах сайта, потому что она не требует изменять ни один файл WordPress.
Если же версия PHP не менялась, а сбой совпал по времени с обновлением плагина, откатите обновление из резервной копии и отложите его до тех пор, пока автор плагина не выпустит исправление.
Как не допустить повторения
Большинство таких поломок возникает не случайно, а после конкретного действия: обновления плагина, смены версии PHP, правки кода или установки нового расширения. Несколько привычек значительно снижают риск.
- Обновляйте плагины и тему не все сразу, а по одному, и проверяйте сайт после каждого обновления.
- Перед крупными изменениями делайте резервную копию и держите хотя бы одну копию вне хостинга.
- Тестируйте обновления на копии сайта, если сайт приносит заявки или продажи.
- Не вставляйте фрагменты кода в functions.php без проверки, а лучше выносите свои правки в отдельный плагин.
- Следите за адресом администратора в настройках: уведомление режима восстановления приходит именно на него.
Если сайт принципиально важен для бизнеса, а рядом нет технического специалиста, разумно заранее договориться о сопровождении. Команда B2BPRO.KZ занимается разработкой и сопровождением сайтов на WordPress: мы диагностируем такие поломки, настраиваем резервное копирование и обновления так, чтобы они не роняли сайт.
Частые вопросы
Что делать, если после включения WP_DEBUG сайт всё равно показывает белый экран?
Проверьте файл wp-content/debug.log: при включённом WP_DEBUG_LOG ошибки записываются туда, даже если на экране ничего не видно. Если файла нет, значит, ошибка возникает до загрузки WordPress, и причину нужно искать в журналах ошибок хостинга или .htaccess.
Можно ли просто удалить проблемный плагин через FTP?
Да, удаление или переименование папки плагина в wp-content/plugins отключает его. Но сначала сохраните его копию и посмотрите по журналу, правда ли виновник именно он: удаление не того плагина добавит проблем, а настройки плагина могут пропасть.
Почему ошибка 500 появляется только на некоторых страницах?
Чаще всего дело в плагине или шаблоне, который работает только на этих страницах, либо в нехватке памяти на тяжёлых страницах. Откройте журнал ошибок сразу после обращения к проблемной странице и найдите строку с этим запросом.
Сколько стоит восстановление сайта после белого экрана?
Универсальной цены нет: она зависит от причины, объёма работ и состояния резервных копий. Простые случаи с плагином или .htaccess решаются быстро, а повреждение базы данных или отсутствие копий требует больше времени. Для оценки напишите нам, что именно вы видите и когда это началось.
Нужен ли программист, чтобы всё это сделать?
Для большинства шагов нет: достаточно доступа по FTP или к файловому менеджеру хостинга и внимательности. Программист нужен, если ошибка находится в самописном коде темы или плагина, либо если проблема лежит на уровне сервера и базы данных.