WordPress не работает — что делать и как провести диагностику

Когда WordPress перестаёт работать, это почти всегда происходит не вовремя. Сайт не открывается, админка недоступна, а в логах — тишина. В этот момент легко начать метаться и ломать сайт ещё сильнее.

Обычно всё проще, чем кажется и в большинстве случаев проблема сводится к конфликту плагинов, теме или настройкам сервера после обновления. Люди обычно ищут «wordpress не работает» и не знают, что делать, в тот момент, когда сайт уже лежит и нужно срочно понять, где проблема. В такой ситуации лучше не метаться, а пройтись по шагам и спокойно найти причину.

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

Карта основных причин сбоя:

1. Конфликт плагинов: Одно некорректное обновление плагина может «уронить» весь сайт;
2. Ошибки в теме: Несовместимость кода шаблона с версией PHP;
3. Лимит памяти: Скриптам не хватает выделенной оперативной памяти (PHP Memory Limit);
4. Проблемы с .htaccess: Ошибка в конфигурационном файле сервера;
5. Взлом или вирусы: Вредоносный код блокирует нормальную работу.

Частые ситуации, когда WordPress перестаёт работать

Ниже — разбор самых распространённых сценариев, с которыми сталкиваются владельцы сайтов. Если вы узнали свою ситуацию — переходите к подробной инструкции.

• WordPress не работает после обновления
  Сайт сломался после обновления ядра, темы или плагинов.
  → Как восстановить WordPress после обновления
• Критическая ошибка и белый экран
  Сообщение «Критическая ошибка», пустая страница или фатальные ошибки PHP.
  → WordPress критическая ошибка — как починить
• Ошибка подключения к базе данных
  Сообщение «Error establishing a database connection».
  → Ошибка подключения к базе данных WordPress
• WordPress не пускает в админку
  Редиректы, белый экран или вечная загрузка /wp-admin.
  → WordPress не пускает в админку — что делать
• Ошибка 500 и проблемы с Elementor
  Elementor не загружается, падает admin-ajax.php, ошибка 500.
  → Elementor не загружается и выдаёт ошибку 500
• Конфликт плагинов WordPress
  Сайт перестал работать после установки или обновления плагина.
  → Как отключить все плагины WordPress без админки

Из практики: с какими проблемами WordPress сталкиваются чаще всего

За последние годы работы с сайтами на WordPress я чаще всего сталкивался не с «экзотическими» ошибками, а с банальными конфликтами плагинов и обновлений.

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

В итоге всё сводилось к плагинам или ошибкам PHP — до переустановки CMS доходило редко.

Сайт на WordPress не открывается: быстрая проверка — первая помощь

Очистка кэша браузера и перезагрузка страницы

Браузеры агрессивно кэшируют статические данные для ускорения загрузки и если вы внесли изменения на сайте, а сайт на WordPress не открывается, возможно, вы видите сохраненную копию страницы с ошибкой. Нажмите комбинацию клавиш Ctrl + Shift + R (Windows) или Cmd + Shift + R (macOS) для принудительного обновления кэша.

Обязательно проверьте сайт в режиме «Инкогнито» или в другом браузере.

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

Проверка доступности сайта через сторонние сервисы

Иногда WordPress не работает только у вас из-за сбоя у интернет-провайдера, проблем с DNS на компьютере или блокировки IP-адреса сервером. Воспользуйтесь сервисом для проверки isitdownrightnow.com и введите адрес домена.

Если сервис показывает статус «Up», но у вас сайт недоступен, попробуйте сменить DNS-серверы на 8.8.8.8 (Google) или перезагрузить роутер, если же ресурс недоступен глобально, переходим к диагностике серверной части.

WordPress не работает из-за плагинов или темы

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

Как отключить плагины, если WordPress не запускается

Если админка недоступна, деактивировать плагины можно через файловый менеджер хостинга или FTP-клиент (FileZilla).

1. Подключитесь к серверу и перейдите в папку /wp-content/;
2. Найдите папку plugins;
3. Переименуйте её в plugins_old. Это действие мгновенно отключит все активные расширения, так как CMS потеряет к ним путь;
4. Попробуйте открыть сайт.

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

Проверка темы на конфликт

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

1. Зайдите в директорию /wp-content/themes/ через FTP;
2. Найдите папку вашей текущей темы;
3. Переименуйте её, добавив к названию _old.

WordPress автоматически попытается найти и активировать одну из дефолтных тем (например, Twenty Twenty-Four), если после этого сайт загрузился, проблема кроется в коде вашей темы (часто ошибки возникают в файле functions.php).

Диагностика через Health Check

Если вам удалось войти в админку, но сайт работает со сбоями, установите плагин «Health Check & Troubleshooting». В режиме устранения неполадок он позволяет администратору видеть «чистый» сайт без плагинов и с базовой темой, тогда как для посетителей ничего не меняется. Это безопасный метод поиска конфликтов на работающем проекте.

WordPress не запускается: включаем диагностику ошибок

Белый экран смерти (WSOD) скрывает реальную причину падения и чтобы понять, почему WordPress не запускается, необходимо включить вывод системных сообщений.

Как включить WP_DEBUG в wp-config.php

Файл конфигурации wp-config.php находится в корневой папке сайта.

1. Скачайте файл и откройте его в текстовом редакторе (не в Word).
2. Найдите строку define( 'WP_DEBUG', false );.
3. Замените её на следующий код:

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

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

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

Internal Server Error (Ошибка 500) — это общий сигнал сервера о том, что он не может обработать запрос. Для владельца сайта это часто выглядит как белый экран.

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

Причины белого экрана смерти (WSOD)

Белый экран возникает, когда скрипт PHP падает до того, как успевает сгенерировать HTML-код страницы и вот основные причины:

1. Поврежденный файл конфигурации сервера .htaccess;
2. Исчерпание лимита оперативной памяти (PHP Memory Limit);
3. Синтаксическая ошибка в коде (лишняя скобка или запятая).

Исправление ошибки 500

Начните диагностику с файла .htaccess в корне сайта. Он часто повреждается плагинами кэширования или безопасности.

1. Переименуйте файл .htaccess в .htaccess_old.
2. Попробуйте открыть сайт.

Вариант А: Сайт заработал.
Проблема была в файле. Теперь зайдите в админку: «Настройки» — «Постоянные ссылки» и просто нажмите кнопку «Сохранить», WordPress автоматически сгенерирует новый правильный файл.

Вариант Б: Сайт всё ещё не работает.
Вероятно, проблема в нехватке памяти. Попробуйте увеличить лимит, добавьте в wp-config.php перед строкой «That’s all, stop editing» следующий код:

define( 'WP_MEMORY_LIMIT', '512M' );

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

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

Обновление ядра, плагинов или версии PHP — один из самых частых триггеров поломки сайта. В таких случаях диагностика идёт по упрощённому сценарию и часто решается за 10–20 минут.
👉 Перейдите к пошаговой инструкции: «WordPress не работает после обновления — как восстановить сайт»

WordPress не работает из-за вирусов и вредоносного кода

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

Признаки заражения сайта

• Появление в корне файлов со странными именами (случайный набор букв).
• Изменение даты модификации у системных файлов index.php или wp-config.php.
• Посторонние администраторы в разделе «Пользователи».
• Антивирус блокирует переход на сайт.

Проверка WordPress на вирусы

Если ресурс недоступен, появляются различные странные рекламные банеры и есть подозрение на взлом, не пытайтесь искать вредоносный код вручную, если вы не эксперт по безопасности. Используйте встроенные сканеры хостинга (например, ImunifyAV) или внешние сервисы.

Когда требуется восстановление

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

Как восстановить WordPress, если ничего не помогло

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

Когда восстановление из бэкапа — лучший вариант

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

Почему диагностика иногда бесполезна без бэкапа

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

Чек-лист: что делать, если WordPress не работает

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

Используйте этот список для последовательной диагностики. Идите строго по пунктам:

1. Очистка кэша браузера и проверка сайта в режиме «Инкогнито»;
2. Проверка доступности через глобальные сервисы (uptime checkers);
3. Включение логов WP_DEBUG в файле wp-config.php;
4. Полное отключение плагинов (переименование папки plugins);
5. Смена темы на стандартную (переименование папки текущей темы);
6. Пересоздание файла .htaccess (удаление/переименование старого);
7. Проверка прав доступа к файлам (755 для папок, 644 для файлов) через FTP;
8. Обращение в службу технической поддержки хостинга;
9. Полное восстановление сайта из резервной копии (бэкапа).

Часто задаваемые вопросы (FAQ)

1. Пропадут ли мои данные (статьи, товары) при белом экране?
Нет. Белый экран — это ошибка отображения файлов (PHP). Весь контент хранится в базе данных, которая в 99% случаев остается целой.

2. Сколько времени занимает восстановление?
Если есть бэкап — от 5 до 15 минут. Ручная диагностика плагинов может занять от 20 минут до часа.

3. Нужно ли нанимать программиста?
Если выполнение пунктов из чек-листа не помогло, или вы видите ошибки, связанные с базой данных (SQL errors), помощь специалиста желательна.

4. Можно ли предотвратить такие сбои?
Полностью — нет, но можно минимизировать риски: настройте авто-бэкапы в облако и не обновляйте плагины сразу после их выхода (ждите пару дней).

5. Может ли хостинг починить сайт за меня?
Техподдержка обязана обеспечить работу сервера, но не вашего сайта. Однако если WordPress не работает из-за настроек сервера, они могут помочь или подсказать причину ошибки в логах.