Мониторинг WordPress в 2026: почему аптайм-плагина уже не хватает

12 июля 2026 · 8 мин чтения

Типичный мониторинг клиентского WordPress выглядит так: стоит плагин, он раз в пять минут пингует сайт и присылает письмо, если тот не открылся. Хорошая новость: такой сайт действительно не упадёт незаметно. Плохая: почти всё, что реально ломается в WordPress, при этом продолжает отдавать честные 200 OK.

Пять поломок, при которых сайт «работает»

1. Встал WP-Cron

Планировщик WordPress устроен коварно: он запускается не по расписанию сервера, а при заходе посетителя. Нет трафика — нет и запусков. А если кто-то прописал в конфиге DISABLE_WP_CRON и забыл настроить настоящий cron, задачи не выполняются вообще.

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

2. Письма перестали доходить

WordPress по умолчанию шлёт почту через PHP-mail. Такие письма всё чаще не проходят проверки SPF и DKIM: почтовый сервер их либо отбрасывает, либо кладёт в спам. Клиент видит «Спасибо, заявка отправлена» — и не видит заявку. Мы разбирали этот сценарий отдельно, потому что он самый дорогой.

3. Изменены файлы ядра

Самый недвусмысленный признак взлома. Файлы ядра WordPress имеют официальные контрольные суммы — их можно сверить с эталоном. Если файл ядра отличается от эталонного, в 99 % случаев это внедрённый код: скрытые редиректы, спам-ссылки, бэкдор. Снаружи сайт выглядит как обычно — вредонос обычно не трогает витрину, он показывает мусор только поисковым роботам или посетителям с определённых источников.

4. Устаревшее ядро и дырявые плагины

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

5. Разбух autoload и нет объектного кеша

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

Что видно снаружи, а что только изнутри

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

Как это устроено у нас

Мы ставим в WordPress обычный плагин — через админку, как любой другой. Он раз в час собирает диагностику и отправляет наружу только вердикты. Никакого удалённого управления сайтом: плагин сам проверяет и сам шлёт, мы не имеем возможности что-либо выполнить на сервере клиента. Это осознанное архитектурное решение, а не недоработка.

Что он проверяет по факту:

• Целостность ядра — сверка контрольных сумм файлов с официальными. Расхождение — критичное событие с алертом.
• WP-Cron — отключён ли, есть ли отставание задач.
• Обновления — устаревшее ядро, устаревшие плагины.
• Почта — настроен ли SMTP или письма уходят через PHP-mail.
• Безопасность — доступный на запись wp-config, администратор с логином admin, включённый вывод отладки на боевом сайте.
• Производительность — размер autoload, наличие объектного кеша.
• PHP-фаталы — свежие фатальные ошибки с указанием виновного плагина.
• REST-петля — отвечает ли сайт сам себе (от этого зависит половина функций админки).
• WooCommerce — если магазин: поток заказов, всплеск сорвавшихся оплат, платёжный шлюз в тест-режиме, суточный тестовый прогон конвейера заказа.

Критичное (изменённое ядро, сломанный чекаут) сразу становится событием с алертом в Telegram, почту или Max. Предупреждения копятся в панели здоровья сайта и попадают в отчёт клиенту — вместе с внешними проверками, аптаймом и инцидентами.

Что это даёт студии

Не «ещё одну панель с графиками». Три вещи, за которые платят:

• Вы узнаёте о проблеме раньше клиента — включая проблемы, которые клиент заметит через месяц по просевшим заявкам, а не сегодня по недоступности сайта.
• Взлом ловится в день взлома, а не когда Яндекс пометит сайт как заражённый и трафик обнулится.
• Отчёт клиенту наполняется содержанием. «Аптайм 99,98 %» ничего не говорит владельцу бизнеса. «Обновили ядро и три плагина с уязвимостями, починили cron, из-за которого не уходили письма» — говорит.

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

Что такое WP-Cron и почему он ломается незаметно?

WP-Cron — планировщик WordPress, который запускается не по расписанию системы, а при заходе посетителя. Если трафика мало, задачи копятся; если WP-Cron отключён константой DISABLE_WP_CRON и настоящий cron не настроен, они не выполняются вообще. Тихо перестают работать автообновления, отложенные публикации, письма, резервные копии и задачи плагинов — сайт при этом открывается нормально.

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

WordPress по умолчанию отправляет письма функцией wp_mail через PHP-mail. Такие письма часто не проходят проверки SPF и DKIM и уходят в спам или отбрасываются почтовым сервером. Внешний мониторинг этого не видит: страница отдаёт 200, форма показывает «спасибо», а заявка не доходит.

Как понять, что WordPress взломали, если внешне всё нормально?

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

Достаточно ли одного плагина мониторинга внутри WordPress?

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

Читайте также: Магазин работает, а заказов нет и Сайт работает, а заявки не приходят.