WordPress не работает после обновления: критическая ошибка, 500 и белый экран

Если после обновления WordPress, плагина, темы или PHP сайт показывает ошибку 500, белый экран или сообщение о критической ошибке, сначала сохраните текущее состояние и найдите запись в журнале. Отключение всего подряд может скрыть причину и усложнить восстановление.

«На сайте возникла критическая ошибка»: что это значит

Это сообщение WordPress показывает, когда при загрузке страницы случается фатальная ошибка PHP. Чаще всего её вызывает плагин, тема или свой код сразу после обновления. Защиту от «белого экрана» добавили в WordPress 5.2: вместо пустой страницы посетители видят короткое сообщение, а на почту администратора сайта уходит письмо со ссылкой на режим восстановления.

Режим восстановления

Ссылка из письма открывает вход в панель в режиме восстановления. Сломанный плагин или тема ставятся на паузу только для вашей сессии, посетители по-прежнему видят сообщение об ошибке, а в панели появляется уведомление, какой компонент упал. Его отключают в разделе «Плагины» или «Внешний вид → Темы», проверяют сайт и выходят из режима кнопкой в верхней панели.

Если письмо не пришло

Так бывает часто: если ошибка случилась до загрузки SMTP-плагина, письмо уходит прямо с сервера и попадает в спам или теряется. Тогда причину ищут вручную:

• включите журнал ошибок: в wp-config.php перед строкой «That's all, stop editing!» добавьте три строки ниже, и ошибка запишется в wp-content/debug.log;
• отключите плагин, который указан в журнале, переименовав его папку в wp-content/plugins через FTP или файловый менеджер хостинга;
• проверьте в панели хостинга версию PHP: обновлённому плагину может понадобиться более новая.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

После ремонта отладку выключите: держать WP_DEBUG включённым на рабочем сайте не рекомендуют сами разработчики WordPress.

Определите симптом до ремонта

Ошибка 500 означает, что сервер не смог корректно обработать запрос. Белый экран обычно скрывает PHP-ошибку. Сообщение «На сайте возникла критическая ошибка» может содержать ссылку на режим восстановления, но письмо не всегда доходит владельцу.

Проверьте отдельно главную, wp-admin, страницу входа, REST API, форму и корзину WooCommerce. Если не работает только один URL, причина может находиться в конкретном шаблоне или плагине. Если недоступно всё, проверяйте PHP, конфигурацию сервера и последний пакет изменений.

Что сохранить перед исправлением

1. Копию файлов и базы данных в текущем состоянии.
2. Журнал PHP и веб-сервера за время возникновения ошибки.
3. Версии WordPress, PHP, темы и обновлённых плагинов.
4. Точное время и действие, после которого сайт перестал работать.
5. Список активных интеграций: платежи, SMTP, кеш, CDN и безопасность.

Где искать точную причину ошибки 500

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

Fatal error и TypeError

Обычно указывают на несовместимый код плагина или темы. Сопоставьте файл с последним обновлением и версией PHP. Не редактируйте ядро WordPress как постоянное решение.

Allowed memory size exhausted

Увеличение лимита памяти может временно вернуть страницу, но нужно найти плагин, запрос или импорт, который расходует ресурс. Иначе проблема повторится под нагрузкой.

Ошибки базы данных

Проверьте доступность сервера базы, реквизиты подключения, повреждение таблиц и незавершённую миграцию. Перед repair-командами нужна резервная копия.

Как проверить конфликт плагина или темы

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

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

Версия PHP, лимиты и конфигурация сервера

После смены PHP старый плагин может использовать удалённую функцию, а новый плагин может требовать более свежую версию. Сверьте требования всех критичных компонентов. Также проверьте права на файлы, .htaccess, OPcache, лимиты времени, памяти и размера запроса.

Если ошибка появилась после миграции, проверьте пути, домен, HTTPS, сериализованные значения в базе и правила перенаправления. Простая замена строк в SQL может повредить сериализованные данные.

Безопасная последовательность восстановления

1. Сохранить текущее состояние и логи.
2. Определить последний изменённый компонент.
3. Воспроизвести ошибку на копии или в окне обслуживания.
4. Отключить или заменить один проблемный элемент.
5. Очистить кеш сервера и CDN после исправления.
6. Проверить wp-admin, формы, поиск, мобильную версию и WooCommerce.
7. Обновить резервную копию только после полного теста.

Если вместе с ошибкой появились редиректы, спамовые страницы или предупреждение браузера, проверьте вредоносное перенаправление WordPress и предупреждение Google об опасном сайте. Для заражения требуется отдельная очистка WordPress от вирусов.