Сообщение WordPress «На сайте произошла критическая ошибка» означает фатальную ошибку PHP. Белый экран или недоступная админка не показывают первопричину, поэтому сначала нужно получить точный текст ошибки и сохранить текущее состояние сайта.
Не переустанавливайте WordPress сразу. Создайте копию файлов и базы, найдите свежую fatal error в логах, затем временно отключите только виновный плагин или тему.
Коротко: что сделать
- Сохранить резервную копию файлов и базы
- Проверить письмо администратора с ссылкой режима восстановления
- Открыть PHP error log и wp-content/debug.log
- Сопоставить время ошибки с обновлениями
- Проверить совместимость PHP, темы и плагинов
Почему возникает проблема
WordPress показывает общее сообщение, когда выполнение PHP остановлено. Чаще всего это конфликт версий или ошибка стороннего кода.
- Несовместимый плагин после обновления
- Ошибка в functions.php или дочерней теме
- Смена версии PHP на хостинге
- Недостаточный memory_limit
- Поврежденные файлы ядра или автозагрузки
- Конфликт двух плагинов, использующих одинаковый класс или функцию
Пошаговая диагностика
Проверку лучше проводить на одном воспроизводимом примере и фиксировать результат каждого шага. Так можно быстро отделить первопричину от побочных ошибок и не менять несколько компонентов одновременно.
- Найти первую fatal error, а не последние каскадные предупреждения
- Проверить путь и номер строки в стеке
- Переименовать каталог подозрительного плагина через файловый менеджер
- Временно переключить тему на стандартную
- Сверить требования плагина с версией PHP
- Проверить сайт и wp-admin после каждого одного изменения
Как исправить
Сначала верните доступ к сайту минимальным изменением, затем исправьте или замените несовместимый компонент.
- Откатить только проблемный плагин на рабочую версию
- Исправить фатальную ошибку в коде темы
- Выбрать поддерживаемую версию PHP
- Увеличить лимит памяти только при подтвержденной нехватке
- Восстановить файлы ядра без замены wp-content и wp-config.php
- Проверить обновление на тестовой копии перед возвратом в продакшен
Как проверить результат
- Открыть главную, несколько внутренних страниц и wp-admin
- Проверить форму, корзину или другие ключевые сценарии
- Просмотреть лог на новые fatal error
- Очистить серверный и браузерный кэш
- Проверить cron WordPress и фоновые задачи
Как не допустить повторения
Обновления WordPress безопаснее выполнять на тестовой копии с возможностью быстрого отката.
- Настроить ежедневные резервные копии
- Хранить изменения темы в дочерней теме или репозитории
- Тестировать плагины перед обновлением
- Контролировать срок поддержки PHP и компонентов
Чего не стоит делать
- Не удалять базу и wp-content
- Не включать display_errors для всех посетителей
- Не обновлять одновременно все компоненты во время диагностики
- Не восстанавливать неизвестную старую копию поверх актуальных заказов
Что подготовить для диагностики
- Доступ к хостингу или SSH
- Текст fatal error и время сбоя
- Список последних обновлений
- Версии WordPress и PHP
- Рабочая резервная копия
Частые вопросы
Можно ли вернуть сайт без доступа в админку?
Да. Плагин можно отключить переименованием его каталога, а тему переключить через файлы или базу после создания копии.
Нужно ли включать WP_DEBUG?
На время диагностики можно писать ошибки в закрытый лог. Показывать их посетителям не следует.
Почему ошибка появилась без обновления?
Хостинг мог сменить PHP, закончилась память, изменился внешний API или отложенная задача запустила проблемный код.
Когда стоит обратиться за помощью
Нужна помощь, если сайт принимает заказы, резервная копия неизвестного качества, ошибка затрагивает базу или после отключения плагина остаются новые fatal error.
Итог
Правильный порядок — копия, точный лог, изоляция виновного компонента и проверка на тестовой среде. Восстановить WordPress без потери актуальных данных можно с помощью @rabotator_support.