Сайт WordPress не работает: что проверить, если не открывается или не загружается

Сайт на WordPress может «не работать» совершенно по-разному.

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

Поэтому первое, что стоит сделать, — не менять плагины, PHP и настройки наугад, а определить точный симптом.

Упрощённо диагностика выглядит так:

Сайт не работает
↓
Что именно происходит?
↓
не отвечает вообще
долго загружается
403 / 404
500
критическая ошибка
ошибка базы данных
сайт работает, админка нет
сломался после обновления

От ответа зависит, что проверять дальше.

Сайт WordPress вообще не открывается

Если браузер долго ждёт, а затем показывает сообщение вроде:

Не удаётся получить доступ к сайту

или:

ERR_CONNECTION_TIMED_OUT

это ещё не означает, что проблема находится в WordPress.

Запрос проходит несколько уровней:

браузер
↓
DNS
↓
сервер
↓
Nginx / Apache
↓
PHP
↓
WordPress
↓
база данных

Сбой на любом из них может выглядеть для пользователя одинаково: сайт просто не открывается.

Сначала проверьте сам домен

Попробуйте открыть:

https://ваш-сайт.ru/

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

Если одновременно не работают:

• сайт;
• админка;
• статические файлы;
• другие сайты на том же сервере,

вероятность проблемы на уровне сервера или сети выше.

Проверьте, работает ли сервер

Если есть доступ к VPS или панели хостинга, посмотрите:

• запущен ли сервер;
• работает ли web server;
• работает ли PHP;
• не закончилась ли память;
• не заполнен ли диск;
• нет ли аварии у хостинга.

На VPS полезно проверить хотя бы:

disk space
RAM
CPU
web server
PHP
database

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

Не начинайте с переустановки WordPress

Если сервер вообще не отвечает, переустановка CMS не устранит проблему.

Сначала нужно определить, доходит ли HTTP-запрос до WordPress.

Сайт WordPress очень долго загружается

Медленная загрузка и полностью неработающий сайт — разные ситуации.

Если страница всё же открывается через 20–60 секунд, возможны:

• медленный PHP-код;
• тяжёлый плагин;
• медленный запрос к базе данных;
• внешний API;
• нехватка ресурсов сервера;
• проблемы с DNS;
• зависший HTTP-запрос;
• cron-задача;
• очень тяжёлая тема;
• большое количество активных плагинов.

Посмотрите, медленный весь сайт или одна страница

главная — 2 секунды
каталог — 3 секунды
оформление заказа — 40 секунд

В этом случае проблема, скорее всего, связана не со всем WordPress, а с конкретной функциональностью.

Другой вариант:

любая страница — 30 секунд
/wp-admin/ — 30 секунд
/wp-login.php — 30 секунд

Здесь уже логично проверять сервер, PHP, базу данных и общие WordPress-процессы.

Обратите внимание на внешние сервисы

Сайт может ждать ответа от:

• CRM;
• платёжной системы;
• API доставки;
• стороннего сервиса;
• SMTP;
• внешнего виджета.

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

WordPress показывает ошибку 403 или 404

Ошибка 403 Forbidden

403 означает, что сервер получил запрос, но отказывает в доступе.

Проверять стоит:

• .htaccess;
• правила Nginx;
• security-плагин;
• WAF;
• firewall хостинга;
• блокировку IP;
• права на файлы и директории.

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

изменили security settings
↓
появился 403

Это гораздо полезнее, чем случайное отключение всех плагинов.

Ошибка 404 Not Found

404 означает, что запрашиваемый адрес не найден.

Если 404 появляется только на отдельных страницах, а главная работает, возможна проблема с:

• permalink rules;
• .htaccess;
• маршрутизацией;
• изменённым slug;
• удалённой страницей.

Если 404 возвращает даже:

/wp-login.php

нужно дополнительно проверить правильность домена, расположение WordPress и конфигурацию web server.

Для отдельной диагностики страниц и записей полезно открыть руководство по ошибке 404 в WordPress.

WordPress возвращает ошибку 500

Ошибка:

500 Internal Server Error

обычно указывает уже не на отсутствие страницы, а на внутренний сбой при обработке запроса.

Причиной могут быть:

• PHP fatal error;
• конфликт плагинов;
• ошибка темы;
• пользовательский код;
• .htaccess;
• несовместимая версия PHP;
• серверная конфигурация;
• нехватка ресурсов.

Если сайт показывает именно 500, полезно отдельно прочитать Ошибка 500 WordPress: причины и что проверить.

Появилась критическая ошибка WordPress

Сообщение:

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

означает, что WordPress обнаружил серьёзный PHP-сбой.

Типичные причины:

• обновление плагина;
• обновление темы;
• несовместимый PHP;
• custom code;
• повреждённый компонент;
• конфликт нескольких компонентов.

Полезны дополнительные шаги из материала Критическая ошибка WordPress: что проверить и как восстановить сайт.

Проверьте почту администратора

В некоторых случаях WordPress отправляет письмо о технической проблеме и ссылку Recovery Mode.

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

WordPress не может подключиться к базе данных

Если вместо сайта появляется сообщение:

Error establishing a database connection

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

Причиной могут быть:

• неправильные реквизиты подключения;
• база данных недоступна;
• MySQL/MariaDB остановлена;
• изменился пароль;
• проблема на сервере;
• повреждены таблицы;
• превышен лимит подключений.

Используйте отдельное руководство по ошибке подключения к базе данных WordPress.

Не нужно одновременно менять пароль базы, wp-config.php, плагины и PHP. Сначала определить, работает ли сама база и соответствуют ли текущие реквизиты конфигурации.

Сайт работает, но не открывается админка WordPress

Если публичная часть сайта доступна:

https://site.ru/

но:

https://site.ru/wp-admin/

не работает, проблема уже гораздо уже.

Например:

• неправильный пароль;
• login loop;
• cookies;
• изменённый URL входа;
• security plugin;
• 403;
• PHP error только в административной части;
• проблема после переноса;
• несогласованные HTTP/HTTPS или www.

Используйте инструкцию Админка WordPress: как войти и что делать, если не заходит.

Сайт WordPress сломался после обновления или изменений

Очень важный вопрос:

что произошло непосредственно перед поломкой?

обновили плагин
↓
сайт перестал работать

или:

перешли на новую версию PHP
↓
появилась ошибка

или:

изменили DNS
↓
сайт перестал открываться

Последнее изменение часто даёт самое сильное направление для поиска.

После обновления плагина

Возможны:

• несовместимость с PHP;
• несовместимость с другим плагином;
• изменение API;
• ошибка новой версии;
• изменение структуры данных.

После обновления темы

Проверяйте:

• custom code;
• child theme;
• несовместимость шаблона;
• hooks;
• functions.php.

После обновления WordPress

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

После изменения PHP

PHP 7.4
↓
PHP 8.x

может проявить старые ошибки в плагинах или теме, которые раньше оставались незаметными.

Не откатывайте всё подряд

Если сайт коммерческий, перед любым rollback желательно иметь резервную копию файлов и базы данных.

WordPress завис в режиме технического обслуживания

После обновления иногда вместо сайта остаётся сообщение о технических работах.

Это может происходить, если процесс обновления завершился некорректно.

Во время обновления WordPress временно включает maintenance mode.

Если процесс оборвался, сайт может остаться в этом состоянии.

В таком случае нужно сначала проверить, завершилось ли обновление, а уже затем аккуратно убирать оставшееся состояние обслуживания.

Не стоит сразу повторно запускать десяток обновлений одновременно.

Что проверить на сервере, в DNS и HTTPS

Если нет явной WordPress-ошибки, проблема может находиться вообще снаружи CMS.

DNS

Если домен указывает не на тот IP, WordPress на правильном сервере может быть полностью исправен, но пользователь его не увидит.

Проверьте:

• A-запись;
• AAAA-запись;
• www;
• недавние изменения DNS;
• правильный сервер назначения.

HTTPS

Проблема SSL может выглядеть как полностью недоступный сайт.

Проверьте:

• срок действия сертификата;
• правильный домен сертификата;
• цепочку сертификатов;
• redirect HTTP → HTTPS.

Nginx или Apache

Web server должен:

• принимать запрос;
• находить правильный virtual host;
• передавать PHP-запросы;
• отдавать статические файлы.

Если вместо вашего сайта открывается:

Default Nginx page

или страница другого проекта, проблема явно находится не в WordPress.

PHP

Если HTML и картинки отдаются, а PHP-запросы дают 502/500, нужно проверять PHP-FPM или аналогичный обработчик. При ошибке загрузки файла отдельно проверьте временную папку WordPress.

База данных

Если PHP работает, но приложение зависает при обращении к БД, WordPress тоже может долго загружаться или возвращать ошибку.

Как проверить сайт без случайных изменений

Диагностика полезнее, если сначала собрать факты.

Зафиксируйте:

• точный URL;
• HTTP status;
• текст ошибки;
• когда проблема появилась;
• что менялось перед этим;
• работает ли /wp-login.php;
• работает ли /wp-admin/;
• работает ли статический файл;
• есть ли PHP error;
• что записано в server logs.

HTTP-код

200 — сервер страницу отдал
301/302 — redirect
403 — доступ запрещён
404 — не найдено
500 — внутренняя ошибка
502 — проблема upstream/backend
503 — сервис временно недоступен
504 — backend не ответил вовремя

Важно смотреть не только красивую страницу браузера, но и фактический HTTP response.

Нужно ли включать WP_DEBUG

WP_DEBUG полезен при PHP/WordPress-ошибках, но сам по себе ничего не исправляет.

На production нежелательно выводить технические ошибки прямо посетителям.

Если нужен диагностический лог, его лучше писать в файл и затем отключить диагностический режим после завершения проверки.

Что искать в логах

Полезны:

• Fatal error;
• Uncaught;
• название плагина;
• путь к теме;
• конкретный PHP file;
• stack trace;
• database errors.

Одна конкретная запись в логе часто полезнее, чем отключение двадцати плагинов наугад.

Когда стоит проверить плагины

Плагины — частая причина проблем, но не каждая поломка WordPress вызвана плагином.

Проверять их особенно логично, если:

• проблема появилась сразу после установки;
• только что произошло обновление;
• ошибка содержит путь к плагину;
• Recovery Mode указывает на него;
• PHP log содержит его файлы.

Если админка доступна, подозрительный плагин можно отключить штатно.

Если нет — возможна временная деактивация через файловую систему.

Но на production-сайте не нужно автоматически переименовывать всю папку:

wp-content/plugins

если можно сначала определить конкретного кандидата.

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

Когда стоит проверить тему

Тема более вероятна как причина, если:

• проблема появилась после её обновления;
• менялся functions.php;
• добавлялся custom code;
• ошибка содержит путь к активной теме;
• проблема возникает только на frontend.

Если /wp-admin/ работает, а публичная часть падает, вероятность проблемы в теме или frontend-коде действительно выше.

Но и здесь сначала желательно посмотреть лог.

Что делать, если WordPress не загружается только у вас

Иногда сайт работает, но не на конкретном компьютере или соединении.

Проверьте:

1. приватное окно браузера;
2. другой браузер;
3. смартфон через мобильный интернет;
4. другой DNS;
5. VPN — только как диагностическое сравнение;
6. очистку DNS/cache.

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

Быстрая диагностика: что проверять по порядку

Если сайт просто «не работает» и пока неизвестно почему:

1. открыть главную страницу;
2. зафиксировать точный текст ошибки;
3. определить HTTP status;
4. открыть /wp-login.php;
5. открыть /wp-admin/;
6. проверить сайт с другого соединения;
7. вспомнить последние изменения;
8. проверить доступность сервера;
9. проверить свободное место и ресурсы;
10. проверить web server и PHP;
11. проверить базу данных;
12. посмотреть PHP/server logs;
13. проверить последний изменённый плагин или тему;
14. только после этого менять конфигурацию.

Так область поиска постепенно сужается:

интернет / DNS
↓
сервер
↓
web server
↓
PHP
↓
WordPress
↓
плагин / тема
↓
конкретный код

Чего не стоит делать, если WordPress перестал работать

Несколько действий часто только усложняют восстановление.

Не переустанавливайте WordPress первым делом

Если проблема в сервере, БД, PHP или плагине, переустановка ядра ничего не даст.

Не удаляйте базу данных

Даже если WordPress сообщает о проблеме с подключением, база может быть полностью исправна.

Не меняйте одновременно много вещей

Плохой сценарий:

сменили PHP
отключили все плагины
поменяли тему
переписали .htaccess
обновили WordPress

Если после этого сайт заработает или сломается сильнее, уже будет непонятно почему.

Не отключайте резервные копии ради экономии места

Перед восстановительными действиями backup особенно полезен.

Не публикуйте технические логи целиком

В них могут находиться:

• пути на сервере;
• email;
• токены;
• ключи API;
• строки подключения;
• другая чувствительная информация.

DNS отвечает
↓
server доступен
↓
Nginx работает
↓
PHP работает
↓
WordPress запускается
↓
БД подключается
↓
ломается конкретный plugin

сервер доступен
↓
PHP уже возвращает 500