HTTP-ответ
Смотрим код, заголовки и фактический HTML. Белый экран с 200 отличается от 500, обрыва PHP и пустого шаблона.
Аварийное восстановление
Пустая страница часто скрывает fatal error, который сервер не выводит посетителю. Сохраняем текущее состояние, читаем журналы и проверяем последний изменённый компонент.
Диагностика
Мы не включаем показ PHP-ошибок для всех посетителей. Диагностика опирается на безопасный журнал, код ответа, недавние изменения и воспроизведение на копии, если правка может затронуть работающие разделы.
Смотрим код, заголовки и фактический HTML. Белый экран с 200 отличается от 500, обрыва PHP и пустого шаблона.
Ищем fatal error, stack trace, нехватку памяти, несовместимую версию PHP и точный файл, где остановилось выполнение.
Сопоставляем время сбоя с обновлениями. Отключаем только подозрительный компонент и проверяем зависимости.
Проверяем активную тему, дочерний шаблон, functions.php и подключаемые файлы. Сохраняем пользовательские изменения.
Сверяем соединение, повреждённые данные, object cache, CDN и серверный кэш, которые могут отдавать пустой ответ.
Если HTML есть, проверяем CSS, JavaScript, загрузчик и перекрывающие слои. Браузерный белый экран не всегда вызван PHP.
Результат
В отчёте есть компонент, файл или конфигурация, которые вызвали пустую страницу, а не перечень общих догадок.
Сайт и админка открываются на ключевых URL, формы и основные сценарии проходят контрольную проверку.
Исправляем совместимость или код, возвращаем безопасные настройки журналирования и даём рекомендацию по обновлениям.
Порядок работ
Пришлите URL, время появления белого экрана и последнее действие перед сбоем. Доступ к панели хостинга или SSH потребуется только после внешней проверки и может быть ограничен каталогом сайта.
Сохраняем файлы, базу и версии окружения. Не обновляем компоненты поверх неизвестной ошибки.
Читаем серверный/PHP-журнал или безопасно включаем запись отладки без вывода технических данных посетителям.
Проверяем подозрительный плагин, тему, фрагмент кода, лимит памяти или соединение с базой.
Устраняем причину, очищаем нужный слой кэша и проверяем публичные страницы, вход и формы.
WordPress указывает, что белый экран могут вызвать PHP- и database errors, конфликт плагина или темы; рекомендации собраны в официальном справочнике распространённых ошибок. Встроенный Recovery Mode помогает при части fatal errors, а журнал отладки следует включать без показа ошибок посетителям.
Границы работ
Увеличение memory_limit или отключение всех плагинов может временно вернуть страницу, но не объясняет источник и иногда ломает интеграции. Мы не оставляем WP_DEBUG с выводом ошибок на рабочем сайте и не удаляем компонент без резервной копии. Если сервер возвращает подтверждённый HTTP 500, используем сценарий исправления ошибки 500. После взлома нужна отдельная проверка вредоносного кода.
Вопросы
Частые причины: fatal error PHP, конфликт плагина или темы, нехватка памяти, проблема базы либо пустой ответ из кэша. Если HTML загружен, проверяем также CSS и JavaScript.
На рабочем сайте это раскрывает пути и технические данные. Ошибки записывают в закрытый журнал и выключают режим отладки после проверки.
Сначала подтверждаем связь по журналу и времени. Затем откатываем или изолируем конкретный компонент, сохраняя базу и файлы.
Возможны кэш браузера, расширение, DNS или CDN. Сравниваем чистый профиль, другую сеть и прямой ответ сервера до изменения сайта.
Первый шаг
Укажите CMS, время появления ошибки и последнее обновление или изменение перед сбоем.