Что делать, если сайт на WordPress упал (пошаговое руководство)

Без паники

Итак, у тебя упал сайт на WordPress. Возможно, это белый экран. Возможно, ошибка 500 Internal Server Error. Возможно, страница просто бесконечно загружается. Сделай вдох-выдох. Сайты на WordPress падают постоянно, и 90% сбоев имеют одни и те же причины. В этой статье я расскажу, как локализовать и устранить причины этих сбоев.

Шаг 1: Убедись, что сайт действительно не работает

Прежде чем приступать к отладке, исключи очевидное:

Проверь с другого устройства/сети — возможно, проблема в интернет-провайдере, браузере, расширениях, кеше или DNS
Попробуй режим инкогнито или другой браузер — исключает проблемы с кэшем браузера или расширениями
Проверь страницу статуса хостинга — возможно, сам сервер не работает
Попробуй curl -I https://yoursite.com — посмотри код ответа HTTP

Если в ответе статус 200, но сайт выглядит сломанным, это проблема в теме сайта. Если в ответе 500, 502 или 503, идём дальше.

Шаг 2: Проверь журнал ошибок

Если есть доступ по SSH:

 
1
2
3
4
5
6
7
tail -50 /var/log/apache2/error.log

# или
tail -50 /var/log/nginx/error.log

# или специфичный для WordPress:
tail -50 /var/www/yoursite/wp-content/debug.log

Если нет доступа по SSH, проверь журналы ошибок в панели управления хостингом. Большинство хостеров предоставляют к ним доступ через cPanel/Plesk или любую другую панель.

Журнал ошибок почти всегда точно указывает, в чём проблема. Например:

PHP Fatal error: Allowed memory size exhausted → лимит памяти
PHP Fatal error: Cannot redeclare function → конфликт плагинов
Error establishing a database connection → ошибка установки соединения с базой данных
PHP Parse error: syntax error → ошибка в синтаксисе, или же файл повреждён

Шаг 2.1: Включи режим отладки в wp-config.php

Если журналы сервера молчат, заставь WordPress выводить ошибки прямо на экран или в отдельный файл. Открой wp-config.php и найди строку с WP_DEBUG. Измени её (или добавь), чтобы получилось так:

 
1
2
3
4
5
6
7
8
// Включает режим отладки
define( 'WP_DEBUG', true );

// Записывает ошибки в файл /wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Не выводить ошибки в HTML-коде сайта (чтобы не пугать юзеров), только в лог
define( 'WP_DEBUG_DISPLAY', false );

Шаг 3: Тест плагинов

Одна из наибоее частых проблем на WordPress это проблемные плагины. Особое внимание удели плагинам кеширования и ускорения (WP Rocket, Autoptimize, W3 Total Cache, LiteSpeed Cache). Часто именно они «ломают» верстку или вызывают критические ошибки после обновления PHP или самого ядра.

Если у тебя есть доступ по SSH:

 
1
2
3
cd /var/www/yoursite/wp-content
mv plugins plugins_disabled
mkdir plugins

Бывают ситуации, когда нет доступов ни к хостингу, ни по SSH. Если у тебя есть доступы по FTP, просто перейди в директорию /var/www/yoursite/wp-content и переименуй папку plugins в plugins_disabled. Также можно выполнять поочерёдное переименование каждого отдельного плагина. Поочерёдное исключение плагинов может помочь найти источник проблем.

Перезагрузи сайт. Если он работает, причиной сбоя был плагин. Выполни удаление и верни плагины обратно.

 
1
2
rm -rf plugins
mv plugins_disabled plugins

Затем активируй плагины по одному через wp-admin, пока сбой не повторится. Это метод обратный тому, что был описан выше.

Если есть WP-CLI:

 
1
2
3
wp plugin deactivate --all
# Сайт работает? Активируйте по одному:
wp plugin activate plugin-name

Шаг 4: Проверь wp-config.php

Если исключение плагинов не помогло:

Открой wp-config.php и проверь наличие синтаксических ошибок (отсутствующие точки с запятой, незакрытые кавычки)
Проверь параметры подключения базы данных — не изменился ли пароль от БД?
Проверь недавние правки: посмотри на даты изменения файлов.

Распространённая ошибка: копирование wp-config.php из другого проекта без обновления данных подключения, смотри на имя или пароль базы данных.

Шаг 5: Проверь базу данных

Если ты видишь «Error establishing a database connection»:

Убедись, что MySQL работает: mysqladmin -u root -p status
Проверь учётные данные: mysql -u wp_user -p wp_database
Проверь дисковое пространство: df -h — базы данных не могут записывать, если диск заполнен
Восстанови таблицы: Добавь define('WP_ALLOW_REPAIR', true); в wp-config.php, затем перейди на yoursite.com/wp-admin/maint/repair.php

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

Шаг 6: Проверь память php

Если журнал ошибок показывает превышение лимита памяти:

Добавь в wp-config.php:

 
1
2
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Если это не помогает, реальная проблема в плагине или теме, которые потребляют неразумное количество памяти. Увеличение памяти — временное решение; найди и исправь утечку.

Шаг 7: Переключись на тему по умолчанию

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

1
wp theme activate twentytwentyfour

Или через FTP: переименуй папку активной темы. WordPress переключится на тему по умолчанию.

Шаг 8: Проверь права доступа к файлам

Неправильные права доступа к файлам могут вызывать ошибки 500:

 
1
2
3
4
# Стандартные права для WordPress
find /var/www/yoursite -type d -exec chmod 755 {} \;
find /var/www/yoursite -type f -exec chmod 644 {} \;
chmod 600 wp-config.php

Шаг 9: Переустанови ядро WordPress

Если ничего не помогает, возможно, файлы ядра повреждены:

1
wp core download --force --skip-content

Если у тебя есть доступ к WP-Toolkit, это делается в пару кликов.

Переустановка ядра WordPress заменяет файлы ядра, не затрагивая wp-content (плагины, темы и загрузки). Это безопасно и исправляет повреждения от неудачных обновлений или кривых исправлений ядра выполненных вручную.

Шаг 10: Сброс постоянных ссылок (Permalinks)

Бывает так: главная страница работает, а все внутренние выдают ошибку 404. Или ссылки просто ведут «не туда». Это часто случается после переноса сайта или манипуляций с файлом .htaccess.

Решение до смешного простое:

Зайди в админку WordPress.
Перейди в раздел Настройки → Постоянные ссылки.
Ничего не меняя, просто нажми кнопку «Сохранить изменения» внизу страницы.

Это действие принудительно обновляет правила перенаправления и пересоздает файл .htaccess. В 99% случаев 404-е ошибки на внутренних страницах исчезают.

Когда не хочется чинить самостоятельно

Сайт упал, поток посетителей прекратился, надо срочно искать программиста, или просто нет времени ковыряться в коде?

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

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

Профилактика

Большинство сбоев WordPress можно предотвратить:

Поддерживай плагины в актуальном состоянии — но только не на продакшене. Сначала тестируйте на dev-окружении.
Ограничь количество плагинов — каждый плагин является потенциальной точкой отказа, а ещё они замедляют быстродействие сайта.
Следи за здоровьем базы данных — разрастание autoload и медленные запросы со временем ухудшают производительность
Используй менеджер конфигурации вместо ручного редактирования wp-config.php
Автоматизируй резервное копирование — ежедневно, на удалённое хранилище.