Мониторинг WordPress: 7 типичных поломок

Сайт на WordPress редко ломается так, чтобы это понимала простая проверка «отвечает ли сервер?». Сервер отвечает. Он отвечает вежливой страницей ошибки, наполовину отрисованной темой или формой входа, до которой никто не может добраться, и часто делает это с кодом HTTP 200.

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

1. База данных пропала, а WordPress вежливо об этом сообщает

Что происходит: MySQL перезапускается, исчерпывает соединения или теряет диск. WordPress выводит «Error establishing a database connection» и отдаёт её с обычным кодом ответа.

Как обнаружить: проверка ключевого слова на главной странице, которая требует фразу с исправной страницы и запрещает Error establishing a database connection. Монитор ключевых слов читает исходное тело ответа, поэтому оба правила работают без браузера. См. мониторинг ключевых слов.

Первый шаг на сервере:

systemctl status mysql          # or mariadb
wp db check                     # WP-CLI, run from the site's directory
df -h /var/lib/mysql            # a full disk stops MySQL

2. Обновление плагина заканчивается фатальной ошибкой или белым экраном

Что происходит: обновление плагина или темы несовместимо с версией PHP или другим плагином. Страница либо пустая с кодом 200, либо отдаёт 500. На виртуальном хостинге всплеск трафика может также вызвать страницы 503 или 508 «лимит ресурсов исчерпан».

Как обнаружить: код ответа плюс ключевое слово, которое должно быть на исправной странице, например wp-content, встречающееся в адресах ресурсов любой правильно отрисованной страницы WordPress. В пустой странице такой строки нет.

Первый шаг: отключите плагины без панели управления.

wp plugin deactivate --all
wp plugin activate woocommerce        # re-enable one by one, starting with the essentials

Без WP-CLI переименуйте wp-content/plugins в plugins-off через SFTP. Если сайт заработал, верните имя и переименовывайте папки отдельных плагинов, пока не найдёте виновника.

3. wp-cron останавливается, и запланированная работа молча умирает

Что происходит: WordPress запускает задачи по расписанию, когда кто-то заходит на сайт. На малопосещаемом сайте или там, где DISABLE_WP_CRON задали без замены, отложенные публикации, резервные копии, письма о заказах и синхронизация остатков просто останавливаются.

Как обнаружить: heartbeat-монитор. Задача по расписанию пингует URL каждые несколько минут, и вы получаете оповещение, когда пинги прекращаются. Heartbeat-мониторы доступны со Starter; полный шаблон есть в руководстве по мониторингу cron.

Первый шаг:

wp cron event list              # what is scheduled, and what is overdue
wp cron event run --due-now     # run overdue events once

Если вы отключили wp-cron намеренно, убедитесь, что настоящая запись cron запускает wp cron event run --due-now каждые несколько минут.

4. Кэш отдаёт всем не ту страницу

Что происходит: кэш страниц или CDN сохраняет то, чего не должен: панель администратора вошедшего пользователя, пустую корзину, страницу обслуживания «скоро вернёмся» или петлю редиректов. Посетители видят это, пока кэш не очищен.

Как обнаружить: проверки ключевых слов на важных страницах (главная, магазин, оформление заказа) и просмотр заголовков ответа. Инструмент для HTTP-заголовков показывает cache-control, age и типичные заголовки CDN, например cf-cache-status. Подсказка — age в несколько часов у страницы, которая должна быть динамической.

Первый шаг: очистите кэш страниц и CDN, затем выясните, что сделало страницу кэшируемой. Корзина, оформление заказа и страницы аккаунта должны быть исключены из кэширования.

5. Никто не может войти, включая вас

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

Как обнаружить: следите за /wp-login.php (или вашим URL входа) с ключевым словом, например user_login. Если WAF блокирует монитор, сначала внесите его в белый список (allow-list); как это сделать, показывает руководство по allow-list в Cloudflare, а адреса есть в списке IP проверок.

6. Истекает сертификат или домен

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

Как обнаружить: мониторы срока действия SSL и домена с оповещениями за 30, 14 и 3 дня. Оба доступны со Starter. См. руководство по сроку действия SSL: там описан подход со списком хостов и проверка одной строкой openssl.

7. Сайт взломан, а отвечает 200

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

Как обнаружить: два способа вместе. Правило ключевого слова «не должно содержать» слов, которым нечего делать на странице (фарма, казино или название известной спам-сети, замеченное в ваших журналах), и монитор изменений главной страницы, который оповещает при неожиданном изменении её содержимого. Обнаружение изменений доступно со Starter; см. обнаружение изменений на веб-страницах.

Первый шаг: сделайте резервную копию до любых изменений, сравните файлы ядра командой wp core verify-checksums и обновите или удалите уязвимый плагин. Затем смените пароли администраторов и ключи.

Как выбрать ключевое слово для каждой проверки

Проверка ключевого слова хороша ровно настолько, насколько хороша выбранная фраза. Берите фразу, которая есть на странице, когда всё работает, и отсутствует, когда что-то не так:

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

Ложные тревоги и кто получает оповещение

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

Минимальный набор на клиентский сайт

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

1. Главная страница: код ответа, обязательный текст, запрещённые строки ошибок (покрывает 1, 2, 4).
2. Страница, которая приносит деньги (оформление заказа, запись): то же самое.
3. Ключевое слово на странице входа (5).
4. Heartbeat для wp-cron (3).
5. Срок действия SSL и домена (6).
6. Обнаружение изменений на главной странице (7), если ваш тариф это включает.

Это шесть мониторов, то есть для портфеля из 40 сайтов — 240. В Tenium это помещается в тариф Pro (300 мониторов, $29 в месяц); тариф Free покрывает 30 мониторов с проверками HTTP и ключевых слов, а Starter ($7) добавляет проверки heartbeat, SSL, домена и изменений. Страница мониторинга WordPress описывает полный набор, а если вы пользуетесь ещё и системой управления WordPress, сравнение Tenium и ManageWP объясняет, как они сочетаются.

Частые вопросы

Читайте также

Связанные страницы Tenium

• Мониторинг WordPress
• Бесплатный инструмент для HTTP-заголовков
• Tenium против ManageWP
• Все материалы блога
• Тарифы