Максим Дорохов 
Мониторинг сайта на WordPress: на что смотреть отдельно
WordPress ломается не так, как статичный сайт: чаще всего виноват не хостинг, а собственное обновление — плагин, тема или сама платформа. Разбираем, какие поломки специфичны именно для WordPress и что стоит проверять отдельно от общих правил мониторинга.
Автообновления — самый частый источник простоя
Плагин или тема обновились автоматически ночью, конфликт с другим плагином — и утром сайт встречает администратора «белым экраном смерти» или ошибкой PHP. Для владельца сайта это особенно неприятно: обновление прошло без его участия, а значит и без предупреждения о риске. Регулярная внешняя проверка доступности — единственный способ узнать об этом раньше, чем напишет первый посетитель.
robots.txt и sitemap — управляются плагинами, а не вами напрямую
На WordPress robots.txt и XML-карту сайта чаще всего генерируют SEO-плагины (Yoast, RankMath и подобные), а не вы редактируете их руками. Это удобно, пока плагин работает штатно — но при сбое обновления такой плагин может тихо переписать robots.txt так, что закроет сайт от индексации целиком, или перестать обновлять sitemap, оставив в нём удалённые страницы. Отследить такую поломку вручную сложно именно потому, что файл технически существует и открывается — просто содержимое в нём внезапно не то.
Плагины защиты от ботов и брутфорса могут агрессивно блокировать автоматический трафик — включая легитимных поисковых роботов и внешний мониторинг, если их специально не исключить из правил. Симптом тот же, что при блокировке WAF: сайт недоступен для проверки, но открывается у живых посетителей.
Товарные фиды из WooCommerce — отдельная точка отказа
Если магазин работает на WooCommerce и выгружает фид для маркетплейсов через отдельный плагин, у этого плагина своя логика генерации, независимая от остального сайта. Обновление WooCommerce или конфликт с другим плагином может сломать именно генератор фида, оставив основной каталог сайта нетронутым, — тот же принцип, что и с любым другим товарным фидом, просто источник специфичен для платформы.
Плюс внешнего мониторинга именно для WordPress
Мониторинг, встроенный внутрь самого WordPress как ещё один плагин, зависит от той же платформы, за которой должен следить: если сайт упал целиком, такой плагин упал вместе с ним и ничего не сообщит. Внешняя проверка не привязана к работоспособности самого WordPress — она видит сайт снаружи, ровно как его видит обычный посетитель, независимо от того, что происходит внутри административной панели.
Пруфен не требует установки на сайт — это внешний наблюдатель, который проверяет доступность robots.txt и конкретные блоки контента независимо от того, что происходит внутри самого WordPress. Для магазинов на WooCommerce актуальна отдельная проверка товарного фида.
Чек-лист: что настроить в первую очередь
| Что проверять | Почему именно на WordPress |
|---|---|
| Доступность сайта целиком | Базовая точка: ловит «белый экран смерти» после конфликта плагинов и ошибки PHP при автообновлении |
| wp-admin / wp-login | Может быть недоступна отдельно от публичной части — например, из-за плагина безопасности или брутфорс-защиты |
| robots.txt | Генерируется SEO-плагином — сбой обновления может тихо закрыть сайт от индексации целиком |
| XML sitemap | Та же логика: генератор карты сайта может перестать обновляться, оставив в ней удалённые страницы |
| SSL-сертификат | Не специфично для WordPress, но часто забывают именно на сайтах, где хостинг и продление настроены давно и без контроля |
| Товарный фид (если WooCommerce) | Отдельный плагин со своей логикой генерации — может сломаться независимо от остального каталога |
| Ключевой блок контента на важной странице | После обновления темы верстка может съехать так, что кнопка или форма формально есть в HTML, но не видна пользователю |
Частые вопросы
Нужен ли отдельный плагин мониторинга, если уже настроен внешний? Обычно нет — внешний мониторинг видит сайт так же, как посетитель, и не зависит от работоспособности самой платформы, в отличие от плагина внутри WordPress.
Как часто обновления реально ломают сайт? Зависит от количества установленных плагинов и того, насколько активно они обновляются — чем больше сторонних плагинов, тем выше шанс конфликта при очередном обновлении одного из них.
Стоит ли проверять wp-admin отдельно? Если для вас критичен постоянный доступ редакции к панели — да, это отдельная точка, которая может быть недоступна даже когда публичная часть сайта работает нормально.
Может ли обновление плагина безопасности заблокировать сам мониторинг? Да, это тот же принцип, что с WAF, — стоит проверить логи плагина безопасности на предмет блокировки внешних автоматических запросов, если проверка внезапно стала показывать недоступность.