Аварийное восстановление

Белый экран на сайте

Пустая страница часто скрывает fatal error, который сервер не выводит посетителю. Сохраняем текущее состояние, читаем журналы и проверяем последний изменённый компонент.

Диагностика

Пустая страница
тоже оставляет следы

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

01

HTTP-ответ

Смотрим код, заголовки и фактический HTML. Белый экран с 200 отличается от 500, обрыва PHP и пустого шаблона.

02

Журнал ошибок

Ищем fatal error, stack trace, нехватку памяти, несовместимую версию PHP и точный файл, где остановилось выполнение.

03

Плагины и модули

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

04

Тема и шаблон

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

05

База и кэш

Сверяем соединение, повреждённые данные, object cache, CDN и серверный кэш, которые могут отдавать пустой ответ.

06

Frontend

Если HTML есть, проверяем CSS, JavaScript, загрузчик и перекрывающие слои. Браузерный белый экран не всегда вызван PHP.

Результат

Страница снова показывает содержимое, а причина задокументирована

Ошибка локализована

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

Работа восстановлена

Сайт и админка открываются на ключевых URL, формы и основные сценарии проходят контрольную проверку.

Повторение ограничено

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

Порядок работ

Сначала копия и журнал, затем изменение

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

01

Фиксируем состояние

Сохраняем файлы, базу и версии окружения. Не обновляем компоненты поверх неизвестной ошибки.

02

Получаем ошибку

Читаем серверный/PHP-журнал или безопасно включаем запись отладки без вывода технических данных посетителям.

03

Изолируем компонент

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

04

Исправляем и тестируем

Устраняем причину, очищаем нужный слой кэша и проверяем публичные страницы, вход и формы.

WordPress указывает, что белый экран могут вызвать PHP- и database errors, конфликт плагина или темы; рекомендации собраны в официальном справочнике распространённых ошибок. Встроенный Recovery Mode помогает при части fatal errors, а журнал отладки следует включать без показа ошибок посетителям.

Границы работ

Скрыть ошибку недостаточно

Увеличение memory_limit или отключение всех плагинов может временно вернуть страницу, но не объясняет источник и иногда ломает интеграции. Мы не оставляем WP_DEBUG с выводом ошибок на рабочем сайте и не удаляем компонент без резервной копии. Если сервер возвращает подтверждённый HTTP 500, используем сценарий исправления ошибки 500. После взлома нужна отдельная проверка вредоносного кода.

Вопросы

Перед диагностикой

Почему на сайте белый экран?

Частые причины: fatal error PHP, конфликт плагина или темы, нехватка памяти, проблема базы либо пустой ответ из кэша. Если HTML загружен, проверяем также CSS и JavaScript.

Можно ли просто включить показ ошибок?

На рабочем сайте это раскрывает пути и технические данные. Ошибки записывают в закрытый журнал и выключают режим отладки после проверки.

Что делать после обновления плагина?

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

Белый экран только у меня. Это сайт?

Возможны кэш браузера, расширение, DNS или CDN. Сравниваем чистый профиль, другую сеть и прямой ответ сервера до изменения сайта.

Первый шаг

Пришлите URL белой страницы

Укажите CMS, время появления ошибки и последнее обновление или изменение перед сбоем.