Что делать, если WordPress-сайт внезапно перестал открываться

Если WordPress-сайт внезапно перестал открываться, главное — не начинать хаотично нажимать всё подряд в админке, обновлять плагины, менять тему, чистить базу и удалять папки «на удачу». Когда сайт уже лежит, любое резкое действие может не починить проблему, а похоронить следы, по которым её можно было быстро найти.

Если после восстановления выяснится, что проблем накопилось несколько, их лучше сразу зафиксировать и расставить по приоритету — так проще собрать доработки WordPress в единый список без хаоса.

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

WordPress поддерживает режим отладки через WP_DEBUG, который помогает выявлять ошибки в процессе диагностики. В официальной документации WordPress указано, что эта константа обычно выключена по умолчанию и включается в wp-config.php для отладки. Но на рабочем сайте ошибки лучше логировать, а не выводить посетителям на экран.

Как выглядит проблема

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

Симптом	Что это может означать
Белый экран	фатальная PHP-ошибка, конфликт плагина или темы
«На сайте возникла критическая ошибка»	WordPress поймал fatal error
Ошибка 500	серверная ошибка, PHP, .htaccess, плагин, тема
Ошибка подключения к базе данных	база недоступна, неверные доступы, проблема MySQL
Бесконечная загрузка	сервер, PHP, внешние запросы, кэш, конфликт
Циклический редирект	HTTPS, www/без www, плагины, настройки URL
Админка не открывается	плагин, тема, права, сервер, cookies, PHP
Работает только часть сайта	проблема шаблона, плагина, конкретного типа страниц
Ошибка после обновления	несовместимость плагина, темы, PHP или ядра

Белый экран WordPress часто связан с фатальной ошибкой, которая не даёт системе нормально отрендерить страницу. В документации WordPress среди типовых причин упоминаются конфликты плагинов и тем; если админка недоступна, один из способов диагностики — отключение плагинов через FTP или файловый менеджер.

Что могло её вызвать

Самая частая причина — обновление. Обновили плагин, тему, WordPress, PHP на хостинге, модуль кэширования или SEO-плагин, и сайт перестал открываться. Не потому что обновления зло. А потому что сайт — это связка кода, версий, зависимостей и старых решений. Иногда один новый файл встречает старый костыль, и они вместе устраивают владельцу утро.

Вторая причина — конфликт плагинов. Один плагин изменил поведение, второй использует тот же хук, третий оптимизирует скрипты, четвёртый кэширует результат, пятый отвечает за безопасность. Потом сайт показывает 500, а все участники делают вид, что они просто стояли рядом.

Третья причина — тема или кастомный код. Ошибка в functions.php, подключённом файле, шаблоне, обработчике формы, ACF-поле, shortcodes, AJAX или PHP-синтаксисе может положить сайт целиком. Особенно если правка была сделана прямо в редакторе темы без бэкапа. Да, классика. Да, больно.

Четвёртая причина — проблема сервера: закончилась память, диск, лимит процессов, упал MySQL, изменилась версия PHP, сломались права на файлы, истёк SSL, неправильно сработал Nginx/Apache, повреждён .htaccess.

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

Причина	Где обычно искать
Обновление плагина	журнал обновлений, recovery email, логи
Обновление темы	шаблоны, functions.php, дочерняя тема
Новая версия PHP	совместимость плагинов и старого кода
Ошибка в коде	PHP error log, debug.log, FTP
Конфликт кэша	плагины кэша, серверный кэш, CDN
Ошибка базы данных	wp-config.php, MySQL, хостинг
Редирект-петля	HTTPS, домен, .htaccess, плагины
Недостаток памяти	PHP memory limit, логи
Вирусы	подозрительные файлы, редиректы, хостинг

В WordPress 5.2 появился Fatal Error Recovery Mode: он позволяет администраторам попасть в админку и отключить проблемный плагин или тему даже в ситуациях, где раньше сайт мог полностью стать недоступным из-за фатальной ошибки.

Что проверить безопасно

Сначала проверьте, действительно ли сайт не открывается у всех. Откройте его в другом браузере, с телефона, через мобильный интернет, без VPN и с VPN. Иногда проблема локальная: кэш браузера, DNS у провайдера, блокировка IP, cookie или временная ошибка CDN.

Потом посмотрите, открывается ли админка: /wp-admin/. Если админка доступна, не обновляйте всё подряд. Сначала вспомните, что менялось перед поломкой: плагины, тема, PHP, хостинг, SSL, DNS, кэш, новые правки в коде.

Что проверить	Безопасное действие
Сайт у других пользователей	открыть с телефона и другого интернета
Админка	проверить /wp-admin/
Почта администратора	найти письмо WordPress о критической ошибке
Хостинг	посмотреть статус сервера и базу данных
SSL	проверить, не истёк ли сертификат
Последние изменения	вспомнить обновления и правки
Кэш	очистить кэш без удаления настроек
Логи	скачать или открыть error log
Бэкап	проверить наличие свежей копии
Диск хостинга	убедиться, что место не закончилось

Если WordPress отправил письмо о критической ошибке, в нём может быть ссылка на Recovery Mode. Такой режим позволяет войти в админку в ограниченном режиме и отключить проблемный компонент. Это безопаснее, чем вслепую удалять папки плагинов.

Если есть доступ к файлам, можно включить логирование ошибок, но аккуратно. Рекомендуемая схема для диагностики на рабочем сайте — включить WP_DEBUG, отключить вывод ошибок на экран и включить запись в wp-content/debug.log. Так ошибку можно увидеть в логе, не показывая её посетителям.

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

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

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

Чего делать не стоит

Не стоит сразу переустанавливать WordPress. Если проблема в плагине, теме, PHP-версии, базе данных или .htaccess, переустановка ядра может не помочь. Зато появится риск затереть важные файлы или усложнить диагностику.

Не стоит удалять папку plugins, тему или файлы ядра без бэкапа. Для диагностики иногда действительно переименовывают папку плагина или временно отключают тему, но это делается осознанно, с пониманием последствий и возможностью вернуть всё назад.

Не стоит править functions.php прямо через редактор темы, если сайт уже нестабилен. Одна ошибка синтаксиса может окончательно закрыть доступ к сайту. Лучше работать через FTP/SFTP или файловый менеджер хостинга, чтобы можно было откатить файл.

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

Не стоит делать	Почему
Обновлять всё подряд	можно усугубить конфликт
Удалять плагины без бэкапа	можно потерять настройки
Чистить базу данных наугад	риск потерять данные
Менять тему без понимания	можно сломать внешний вид и шаблоны
Править код через админку	можно потерять доступ
Игнорировать логи	причина часто уже записана там
Восстанавливать старый бэкап вслепую	можно потерять свежие заявки и контент
Отключать безопасность надолго	риск взлома и спама

Перед любыми серьёзными изменениями нужен бэкап файлов и базы данных. Это скучно, но именно бэкап отделяет нормальную диагностику от ритуала «а теперь молимся, что сайт вернётся».

Когда уже нужна техподдержка

Техподдержка нужна, если сайт не открывается полностью, админка недоступна, ошибка повторяется после отключения кэша, в логах есть PHP fatal error, сайт упал после обновления, есть проблемы с базой данных, редиректами, сервером или подозрение на взлом.

Для нормальной диагностики специалисту могут понадобиться доступы к WordPress, хостингу, FTP/SFTP, базе данных, логам, панели домена, SSL, CDN и резервным копиям. Без логов и доступа к файлам ремонт часто превращается в гадание по скриншоту. Гадание, конечно, древняя технология, но для WordPress лучше всё-таки error log.

Ситуация	Что понадобится
Белый экран	логи PHP, FTP/SFTP, доступ к плагинам и теме
Критическая ошибка	recovery email, логи, доступ к админке или файлам
Ошибка базы данных	хостинг, MySQL, wp-config.php
Ошибка 500	server error log, PHP log, .htaccess, плагины
Редирект-петля	настройки домена, HTTPS, плагины, сервер
Сайт упал после обновления	бэкап, список обновлений, доступы
Подозрение на вирус	файлы, логи, хостинг, сканирование
Периодические падения	логи нагрузки, cron, серверные лимиты

Если сайт перестал работать и на нём есть заявки, реклама или важный контент, лучше не тратить часы на случайные правки, а подключить техническую поддержку сайта. Задача техподдержки — не просто «нажать что-то в админке», а найти причину, аккуратно восстановить работу и не потерять данные.

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

Если диагностика показывает, что аварии связаны уже не с одним плагином, а с устаревшей архитектурой, большим количеством конфликтующих зависимостей и накопленным техническим долгом, иногда рациональнее рассматривать разработку WordPress-сайта под ключ, а не постоянно восстанавливать старую конструкцию после очередного сбоя. Такое решение имеет смысл принимать только после восстановления проекта и понимания, какие данные, URL и рабочие сценарии нужно сохранить.