Критическая ошибка и белый экран WordPress: как вернуть сайт в работу
Критическая ошибка WordPress и белый экран требуют поиска причины по журналам и последним изменениям. Сначала сохраните текущее состояние сайта, проверьте письмо для входа в режим восстановления и установите, какой компонент или запрос перестал работать. Затем исправляйте подтверждённую проблему и проверяйте результат вне административной сессии.
Для владельца бизнеса цель — вернуть страницы, заявки и заказы, сохранив данные. Ниже — последовательность действий при сообщении «На сайте произошла критическая ошибка», пустой странице и сбое после обновления. Она поможет провести первичную диагностику и подготовить точное обращение разработчику или хостеру.
Что означает критическая ошибка WordPress
Сообщение о критической ошибке обычно появляется, когда выполнение PHP-кода прерывается и WordPress не может закончить обработку запроса. Само сообщение скрывает технические подробности: по нему нельзя определить конкретный плагин, строку кода или подходящий способ ремонта.
Белый экран WordPress — симптом, при котором вместо ожидаемой страницы виден пустой результат. Он может сопровождать ошибку PHP, проблему темы или другой сбой. Официальный справочник WordPress рассматривает белый экран, критическое сообщение и другие типы ошибок отдельно. Поэтому сначала уточняют наблюдаемое поведение, а затем выбирают направление проверки.
| Что наблюдается | Что проверить сначала | Какой вывод делать рано |
|---|---|---|
| Критическое сообщение на всех страницах | Письмо восстановления, журнал PHP, последнее обновление или изменение среды | Что обязательно повреждена база или нужно переустановить весь сайт |
| Белая только одна страница или действие | Конкретный URL, шаблон, обработчик формы и запись в журнале в этот момент | Что весь сервер перестал работать |
| Сайт открывается, а административная часть — нет | Ошибка административного запроса и компоненты, работающие в панели | Что достаточно сменить пароль |
| Точный текст об ошибке соединения с базой | Подключение к СУБД и состояние услуги базы данных | Что это обычный конфликт темы |
| Сообщение о техническом обслуживании после обновления | Состояние обновления и механизм maintenance | Что обновление уже завершено и блокировку можно сразу убрать |
HTTP 500 тоже не называет причину. Такой статус может сформировать приложение или сервер. А пустая страница иногда возвращается с кодом 200. Сохраните и видимый результат, и код ответа, если умеете посмотреть его в инструментах браузера или панели хостинга.
Первые действия, если WordPress перестал работать
До изменения файлов определите границы сбоя и сохраните возможность вернуться к исходному состоянию. Несколько одновременных «исправлений» затрудняют диагностику: после них уже непонятно, какая настройка помогла, а какая создала новую проблему.
Запишите время, адрес и последнее изменение
Откройте главную, одну внутреннюю страницу и административную часть. Уточните, возникает ли ошибка у всех посетителей или только после определённого действия. Запишите время с часовым поясом и точный URL без конфиденциальных параметров. Не повторяйте реальную оплату ради воспроизведения ошибки.
Вспомните, что менялось перед сбоем: плагин, тема, WordPress, версия PHP, настройки кеша, пользовательский фрагмент кода или файлы при публикации. Совпадение по времени задаёт приоритет проверки, но не доказывает причину. Фоновое автообновление тоже могло пройти без ручного запуска владельцем.
Сохраните текущие данные и журналы
Если доступ к панели хостинга сохранился, сделайте копию файлов и базы либо запросите её у провайдера. Для полного восстановления обычного WordPress нужны обе части — это отдельно объясняется в руководстве по резервным копиям. Текущий комплект может быть неисправным, но он сохраняет свежие заказы и сведения для разбора.
Найдите последнюю проверенную копию до сбоя и выясните её дату. Не восстанавливайте старую базу автоматически: новые заявки, пользователи и оплаты после этой даты требуют отдельного учёта. Сохраните фрагменты журналов до их ротации и запишите каждое выполняемое изменение.
Определите режим работы на время проверки
Если сломано оформление заказа или приём обращений, согласуйте временное ограничение этих функций и понятное уведомление посетителей. Это уменьшает количество незавершённых действий. Размещённая поверх главной заглушка не обязательно останавливает API, фоновые задания и уведомления от платёжного сервиса.
Испытания проводите на изолированной копии, когда это возможно. У неё должны быть отдельная база и отключённые реальные отправки, платежи и обмены. Для срочной работы на основном сайте заранее определите одно изменение, способ проверки и действие возврата.
Как войти в режим восстановления WordPress
Recovery Mode помогает войти в панель при некоторых фатальных ошибках. Проверьте административную почту: письмо содержит подробности и специальную ссылку.
- Сопоставьте письмо со своим доменом и моментом сбоя.
- Откройте специальную ссылку и войдите в учётную запись администратора.
- Прочитайте уведомление о приостановленном компоненте и сохраните сведения об ошибке.
- Выберите подтверждённое действие: временно деактивировать компонент либо исправить его на подготовленной копии.
- После исправления выйдите из режима восстановления и проверьте сайт как обычный посетитель.
Приостановка проблемного расширения в Recovery Mode действует для вашей административной сессии. Успешный вход в панель ещё не означает, что ошибка исчезла у посетителей. Механизм и порядок выхода описаны в официальной инструкции Recovery Mode.
Если письма нет, проверьте доставку и переходите к журналам: часть сбоев не запускает этот механизм.
Как найти причину критической ошибки по журналу
Начните с уже существующих журналов в панели хостинга: ошибок PHP, веб-сервера или приложения. Путь и название раздела зависят от услуги. Выбирайте журнал нужного сайта и периода, а не первый файл со словом error.
Сопоставьте запись с конкретным запросом
Один раз воспроизведите безопасное действие и отметьте время. Найдите соответствующую новую запись, учитывая часовой пояс сервера. Если в аккаунте несколько сайтов, сопоставьте путь к файлу с каталогом нужного проекта.
Смотрите тип ошибки, сообщение, файл, строку и цепочку вызовов. Путь внутри плагина указывает место, где выполнение остановилось, но не всегда первопричину: компонент мог получить неподходящие данные от другого расширения. Важна связка с последним изменением и воспроизводимым сценарием.
| Признак в журнале | Направление проверки | Практический следующий шаг |
|---|---|---|
| Parse error или Syntax error | Синтаксис изменённого PHP-файла | Сравнить последнюю правку с рабочей версией и исправить её на копии |
| Uncaught Error или TypeError | Несовместимый вызов, тип данных или отсутствующая зависимость | Изучить первое относящееся к запросу сообщение и стек вызовов |
| Allowed memory size exhausted | Лимит памяти и операция, которая его исчерпала | Проверить фактический лимит и рост потребления |
| Failed opening required | Недостающий файл, неверный путь, неполная загрузка или доступ | Сверить комплект компонента и разрешения |
| Maximum execution time exceeded | Зависшая или слишком долгая операция | Найти обработчик, внешнее ожидание или повторяющуюся работу |
| Только Notice, Warning или Deprecated | Предупреждения, которые могут сопровождать основной сбой | Продолжить поиск причины остановки, не объявлять последнюю строку виновником автоматически |
Не удаляйте строку кода только потому, что её номер указан в ошибке: сначала выясните причину остановки.
Если нужных записей нет
Проверьте, что запрос действительно попал на текущий сервер, а не был обслужен кешем или CDN. Уточните у хостера, где регистрируются ошибки PHP для этой услуги. Отсутствие файла debug.log не доказывает исправность сайта: WordPress мог не дойти до настройки собственного журналирования.
Как включить диагностику, не показывая ошибки посетителям
Встроенная отладка WordPress полезна, когда существующего журнала недостаточно. Предпочтительно включать её на тестовой копии. Если воспроизведение возможно только на рабочем сайте, согласуйте короткий диагностический период и последующее возвращение штатных настроек.
Подготовьте wp-config.php и закрытое место для журнала
Сохраните исходный файл. Найдите уже существующие определения констант: их редактируют, а не дублируют ниже. Параметры должны находиться до загрузки wp-settings.php; в стандартном конфигурационном файле — до комментария о завершении редактирования.
Ниже пример значений для временной диагностики. Путь учебный: замените его существующим каталогом вне публичной директории сайта. Процесс PHP должен иметь право записывать туда журнал, а посторонние пользователи — не должны получать к нему доступ.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/account/private-logs/wp-errors.log' );
@ini_set( 'display_errors', 0 );Это фрагмент внутри существующего PHP-файла, а не повод добавить ещё один открывающий PHP-тег. Значения true и false пишутся без кавычек. Сочетание параметров и возможность указать отдельный путь описаны в руководстве WordPress по отладке.
Проверьте, что журнал действительно записывается
Воспроизведите исходный безопасный сценарий и убедитесь, что появилась новая запись. Не назначайте широкие права всему сайту, если файл не создаётся: выясните разрешённый путь и владельца процесса. Если платформа управляет журналированием сама, используйте её предусмотренный механизм.
В реализации wp_debug_mode запись и показ сообщений управляются раздельно. Включение журнала не требует демонстрировать посетителю пути и подробности ошибки. Однако настройки WordPress не исправляют серверную конфигурацию и не охватывают любой сбой до загрузки приложения.
PHP отдельно управляет log_errors, error_log и отображением ошибок. В руководстве PHP отмечены ограничения изменения этих параметров во время выполнения: например, нужная настройка в скрипте может не выполниться при ранней фатальной ошибке. Тогда требуется журнал и настройка на стороне сервера.
Завершите диагностику
После получения материала и проверки исправления отключите временную отладку: измените существующее значение WP_DEBUG на false, верните согласованные настройки журналирования и сохраните нужный фрагмент в закрытой документации. Проверьте, что подробности не выводятся в HTML, а накопленный лог не доступен по веб-адресу. Штатный серверный журнал ошибок при этом продолжает выполнять свою задачу.
Как проверить, вызвана ли ошибка плагином
Если журнал или последнее изменение указывает на конкретный плагин, начните с него. Временная деактивация помогает проверить гипотезу, но может отключить связанную функцию: оплату, формы, авторизацию или отображение каталога.
Когда административная часть доступна
Зафиксируйте название и версию компонента, его назначение и зависимые модули. На копии либо в согласованное окно деактивируйте один подозреваемый плагин, повторите исходный запрос и проверьте журнал. Если ошибка исчезла, установите совместимую исправленную версию или передайте воспроизводимый пример разработчику компонента.
Не включайте проблемную версию обратно только ради прежнего количества активных плагинов. Если без неё сайт временно работает, обозначьте недоступную функцию и подготовьте полноценное исправление. После изменения версии учитывайте возможные миграции данных: возврат старых файлов не всегда равнозначен откату всего состояния.
Когда вход в wp-admin невозможен
Через файловый менеджер или SFTP найдите каталог установленного компонента внутри обычной папки plugins. Сохраните точное исходное имя и временно переименуйте только этот каталог, например sample-plugin в sample-plugin.disabled. Это пример имени, а не название конкретного расширения для обязательного отключения.
Способ временного исключения компонента через его папку предусмотрен документацией Recovery Mode. Не удаляйте каталог и не смешивайте файлы разных версий. Возвращайте исходное имя только после исправления причины или подтверждённой деактивации плагина. Простой возврат папки может снова загрузить прежний код и вернуть ошибку: WordPress учитывает сохранённый список активных плагинов и наличие их файлов.
Если подозреваемый компонент не найден
Проверку без всех обычных плагинов проводите на копии или в согласованное окно, предварительно сохранив их список и состояние. Возвращайте компоненты по одному, начиная с необходимых зависимостей, и повторяйте один и тот же сценарий. Так можно обнаружить конфликт, который проявляется только при определённом сочетании.
Если тесты без плагинов не изменили ошибку, верните исходную конфигурацию и переходите к следующей подтверждённой гипотезе.
MU-plugins и drop-ins проверяются отдельно
Обычный список расширений не охватывает всё исполняемое дополнение. MU-plugins загружаются автоматически из отдельного каталога и не отключаются обычной кнопкой в панели. Хостер может использовать их для интеграции со своей платформой. Отдельные drop-in-файлы, например advanced-cache.php, также участвуют в загрузке; связь этого файла с WP_CACHE описана в документации конфигурации.
Не удаляйте такие файлы наугад. Установите их происхождение и согласуйте проверку с ответственным за площадку. Если специалист использует WP-CLI, ему важно учитывать: параметр --skip-plugins не исключает MU-plugins. Поэтому удачная проверка без обычных расширений не означает, что загружено только ядро.
Как проверить тему и пользовательские изменения
Если сбой появился после правки functions.php, добавления сниппета или обновления темы, сравните изменённый компонент с рабочей версией. Одна синтаксическая ошибка может прервать весь запрос, даже когда исправлялся небольшой визуальный элемент.
Верните конкретную проверенную правку
Если известен изменённый файл, восстановите его корректную версию из системы контроля версий или подходящей копии. Убедитесь, что она совместима с остальными файлами текущей темы. Не вставляйте случайный «лечащий» код в functions.php: он может добавить зависимость и скрыть исходную причину.
При использовании редактора сниппетов способ отключения зависит от самого инструмента. Иногда код хранится в базе и выполняется плагином; удаление произвольного файла темы тогда ничего не изменит. Восстановление проводят по механизму того компонента, который действительно запускает код.
Проверьте на установленной совместимой теме
На тестовой копии переключитесь на исправную стандартную тему, подходящую вашей версии WordPress. Перед проверкой сохраните название активной темы, наличие дочерней темы и пользовательские настройки. Если проблема исчезла, исследуйте шаблон и связанные зависимости.
Переименование активной темы через файлы не гарантирует успешный запасной вариант: подходящая тема должна быть установлена. Это видно и из механизма проверки темы WordPress. На рабочем проекте смена темы может нарушить меню, шаблоны и витрину, поэтому открывшаяся страница ещё не означает завершённое восстановление.
PHP, расширения и память: что проверять по фактам
Если ошибка возникла после изменения серверной среды, сопоставьте её параметры с требованиями WordPress, темы и плагинов. У разных сайтов в одном аккаунте могут быть разные обработчики и версии PHP; важно проверить именно тот, который выполняет проблемный веб-запрос.
Совместимость важнее случайного выбора версии
Используйте официальные требования WordPress как отправную точку, затем проверьте условия конкретных расширений. Версия, с которой работает ядро, не гарантирует совместимость каждого старого плагина. Если в журнале указана отсутствующая функция или расширение, выясните, требуется ли обновление компонента или настройка среды.
Не переключайте PHP последовательно на все доступные варианты. Подготовьте совместимую конфигурацию и испытайте её на копии. Временный возврат среды должен быть согласованным способом восстановления, а не бессрочным сохранением неподдерживаемой версии.
Увеличение памяти не является универсальным ремонтом
Сначала подтвердите исчерпание памяти соответствующим сообщением в журнале. Посмотрите, какая операция его вызывает: импорт, обработка изображения, запрос каталога или действие плагина. Не путайте лимит памяти одного PHP-процесса с общим объёмом оперативной памяти сервера.
WordPress использует настройки WP_MEMORY_LIMIT и WP_MAX_MEMORY_LIMIT, но возможность изменения зависит от сервера. В коде начальной настройки лимитов учитывается текущая конфигурация PHP. Простая запись большого значения в wp-config.php не создаёт дополнительные ресурсы и не отменяет ограничения хостинга.
При обоснованном повышении лимита повторите тот же сценарий и оцените потребление. Если оно продолжает расти или проблема возвращается, исследуйте код и данные. Постоянно увеличивать лимит вместо поиска причины — ненадёжный план для сайта с заказами.
Что делать после неудачного обновления WordPress
Сбой обновления может оставить неполный комплект файлов или несовместимые версии компонентов. Уточните, что именно обновлялось, когда остановился процесс и есть ли сообщение инструмента обновления.
Сначала подтвердите, что процесс завершён или остановлен
Сообщение об обслуживании связано с отдельным механизмом. WordPress проверяет файл .maintenance и сведения о времени обновления — это описано в wp_is_maintenance_mode. Наличие такого файла не является универсальным объяснением любого белого экрана.
Если процесс ещё работает, не убирайте его блокировку. Если обновление действительно прервано, сначала установите состояние файлов и данных, затем завершите восстановление по инструкции CMS или провайдера. Остаточный файл обслуживания убирают после проверки состояния, а не ради открытия посетителям частично обновлённого приложения.
Проверьте файлы ядра без потери содержимого сайта
Для специалиста с WP-CLI доступна проверка файлов по контрольным суммам:
wp core verify-checksums --path=/home/account/siteПуть заменяют каталогом своей установки. Документация команды описывает сравнение с контрольными суммами WordPress.org и необходимость учитывать версию и локаль. Проверка выполняется до загрузки WordPress. Несовпадение требует анализа; оно само по себе не устанавливает причину изменения и не проверяет безопасность всех плагинов и пользовательских данных.
Если подтверждена неполная поставка ядра, восстановите согласованный комплект из официального источника по процедуре для нужной версии. Инструкция обновления WordPress отдельно выделяет сохранность wp-config.php, wp-content и пользовательских настроек. Не заменяйте работающий проект новой пустой установкой и не импортируйте поверх него случайную базу.
Когда восстанавливать сайт из резервной копии
Копия полезна, если исправление отдельных компонентов не укладывается в допустимое время или состояние проекта невозможно надёжно восстановить иначе. Но откат должен соответствовать характеру сбоя: ошибка в одном файле не всегда требует возвращать всю базу на вчерашнюю дату.
Сначала проверьте выбранную копию на отдельной площадке. Сопоставьте её файлы, базу и среду, затем определите, какие данные появились после создания. Для магазина отдельно учитывают заказы, оплаты и загруженные документы; внешняя платёжная система не откатывается вместе с WordPress.
- Сохраните текущее состояние, журналы и сведения о последних операциях.
- Выберите проверенную точку до сбоя и определите состав восстановления.
- Подготовьте способ сохранить или согласовать более новые данные.
- Проверьте восстановленный проект и только затем верните рабочую запись.
Если сайт после отката сразу получает то же обновление или выполняет тот же ошибочный сценарий, сбой может повториться. Зафиксируйте причину и план окончательного исправления. При признаках посторонних изменений нужна отдельная проверка безопасности: сам белый экран не доказывает взлом, а восстановление старой версии не устраняет автоматически путь повторного повреждения.
Как убедиться, что WordPress снова работает
Проверка завершается за пределами Recovery Mode и без исключительных условий административного сеанса. Пройдите исходный проблемный маршрут, затем основные действия посетителя. Если кеш скрывает изменение, обновите нужный слой предусмотренным способом; очистка кеша не заменяет исправление ошибки PHP.
| Область | Что проверить | Как подтвердить результат |
|---|---|---|
| Страницы | Главную, внутренние URL, каталог, поиск, изображения | Ожидаемое содержимое и отсутствие повторного сбоя |
| Административная часть | Вход, открытие редактора, сохранение тестового изменения по плану | Операция завершается и данные доступны после повторного открытия |
| Заявки и заказы | Форму, корзину, уведомление, интеграцию с CRM | Тестовое событие дошло до предусмотренной системы |
| Обслуживание | Очереди, задачи, резервирование и журналы | Нет пропусков, повторных действий и новых относящихся к сбою ошибок |
| Конфигурация | Отключённые компоненты, тему, временную отладку и ограничения | Все изменения учтены, рабочие настройки возвращены осознанно |
У платежей используйте предусмотренный тестовый сценарий и проверьте обработку уведомлений. Не оценивайте результат только по сообщению «успешно» в интерфейсе. После приёмки некоторое время наблюдайте за свежими запросами и реальными обращениями, особенно если сбой проявлялся лишь при определённых данных.
Сохраните краткий итог: причина, изменённые файлы или версии, выполненные проверки и оставшиеся ограничения. Если важный плагин всё ещё выключен, проект восстановлен лишь частично; это нужно явно передать тому, кто отвечает за продажи и обслуживание.
Когда обращаться к хостеру или разработчику
Хостер помогает разобраться с журналами, доступом к файлам, обработчиком PHP, ресурсами и состоянием своей платформы. Разработчик приложения исследует конфликт модулей, ошибку пользовательского кода и корректность бизнес-операций. Иногда нужны обе стороны; точное описание быстрее связывает их работу.
- Домен, затронутый URL и время ошибки с часовым поясом.
- Действие, после которого возникает сбой, и круг затронутых посетителей.
- Версии WordPress, PHP и подозреваемого компонента.
- Последнее изменение и уже выполненные проверки с результатами.
- Фрагмент журнала вокруг нужного события без паролей, токенов и клиентских данных.
- Сведения о резервной копии, свежих заказах и допустимом окне работ.
Фраза «белый экран» становится полезной заявкой, когда к ней добавлены воспроизводимый шаг и ошибка из нужного периода. Доступы передавайте предусмотренным защищённым способом; публикация полного wp-config.php для диагностики не нужна.
Чтобы выстроить понятный порядок реакции на такие сбои, познакомьтесь с SiteGuard и обсудите задачи сопровождения вашего сайта. Подготовьте перечень критичных страниц, форм и интеграций: это поможет согласовать, какой результат необходимо восстанавливать и как его проверять.
Частые вопросы о критической ошибке WordPress
Что делать, если на сайте возникла критическая ошибка и письмо не пришло?
Проверьте административный адрес и доставку почты, затем переходите к журналам хостинга. Отсутствие письма не отменяет сбой и не требует ждать неопределённое время. Сохраните время, URL и последнее изменение; при необходимости запросите у провайдера соответствующую запись PHP.
Почему администратор видит сайт, а посетитель — ошибку?
Причина может быть в Recovery Mode, различиях ролей, кеше или коде, который выполняется только для определённых пользователей. Проверяйте в обычном посетительском сеансе и воспроизводите конкретное действие. Одна успешная загрузка в панели недостаточна.
Можно ли сразу отключить все плагины?
Такой тест может помочь на изолированной копии. На рабочем сайте он способен выключить формы, оплату и важные интеграции. Если журнал указывает на один компонент, начните с него. Для общей проверки сохраните список и предусмотрите контролируемый возврат.
Поможет ли увеличение WP_MEMORY_LIMIT?
Только если причина связана с лимитом, изменение разрешено сервером и доступные ресурсы соответствуют задаче. Оно не исправляет синтаксическую ошибку или несовместимый вызов. Подтвердите проблему журналом и проверьте, почему операция потребляет память.
Нужно ли переустанавливать WordPress?
Обычно сначала локализуют ошибку. Восстановление файлов ядра уместно при подтверждённой проблеме их состава, с сохранением конфигурации и содержимого. Новая пустая установка не является универсальным способом вернуть существующий сайт.
Как снизить вероятность повторения белого экрана?
Проверяйте обновления на подходящей копии, сохраняйте пригодные резервные комплекты, фиксируйте изменения и контролируйте критичные действия после выпуска. Поддерживайте совместимую среду и назначьте ответственного за журналы и реакцию на сбои. Это делает восстановление предсказуемее, хотя не исключает все возможные ошибки.