---
title: Мониторинг WordPress в 2026 — почему аптайм-плагина уже не хватает
description: Аптайм-плагин говорит «сайт работает» — а WP-Cron стоит, письма не уходят, ядро изменено и плагины дырявые. Что видно только изнутри WordPress и как это ловить автоматически.
source: https://pingvera.ru/blog/monitoring-wordpress-iznutri.html
---
# Мониторинг WordPress в 2026: почему аптайм-плагина уже не хватает

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

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

### 1. Встал WP-Cron

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

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

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

WordPress по умолчанию шлёт почту через PHP-mail. Такие письма всё чаще не проходят проверки SPF и DKIM: почтовый сервер их либо отбрасывает, либо кладёт в спам. Клиент видит «Спасибо, заявка отправлена» — и не видит заявку. Мы [разбирали этот сценарий отдельно](https://pingvera.ru/blog/ne-prihodyat-zayavki-s-sayta.html), потому что он самый дорогой.

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

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

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

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

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

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

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

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

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

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

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

- **Целостность ядра** — сверка контрольных сумм файлов с официальными. Расхождение — критичное событие с алертом.
- **WP-Cron** — отключён ли, есть ли отставание задач.
- **Обновления** — устаревшее ядро, устаревшие плагины.
- **Почта** — настроен ли SMTP или письма уходят через PHP-mail.
- **Безопасность** — доступный на запись wp-config, администратор с логином admin, включённый вывод отладки на боевом сайте.
- **Производительность** — размер autoload, наличие объектного кеша.
- **PHP-фаталы** — свежие фатальные ошибки с указанием виновного плагина.
- **REST-петля** — отвечает ли сайт сам себе (от этого зависит половина функций админки).
- **WooCommerce** — если магазин: поток заказов, всплеск сорвавшихся оплат, платёжный шлюз в тест-режиме, суточный [тестовый прогон конвейера заказа](https://pingvera.ru/blog/magazin-rabotaet-a-zakazov-net.html).

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

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

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

- **Вы узнаёте о проблеме раньше клиента** — включая проблемы, которые клиент заметит через месяц по просевшим заявкам, а не сегодня по недоступности сайта.
- **Взлом ловится в день взлома**, а не когда Яндекс пометит сайт как заражённый и трафик обнулится — и уж точно раньше, чем клиент заметит, что часть заявок [перехватывают на чужой домен](https://pingvera.ru/blog/perehvat-klientov-s-sayta.html).
- **Отчёт клиенту наполняется содержанием.** «Аптайм 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?**

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