Мониторинг работоспособности сайта

Мониторинг работоспособности сайта нужен не для красивых графиков, а для того, чтобы вы узнали о падении раньше клиента и раньше поискового робота. Разница между «сайт лежал сорок минут ночью, никто не заметил» и «сайт лежал двое суток, потому что уведомление ушло на почту, которую никто не открывает» измеряется в потерянных заявках и в просевших позициях. Сама поломка при этом обычно копеечная: закончилось место на диске, истёк сертификат, обновление плагина уронило шаблон.

В SEO я с 2005 года и регулярно вижу одну и ту же картину: владелец приходит с вопросом «почему упали позиции», а в отчётах обхода за прошлый месяц — сплошные ошибки соединения. Сайт то ли жил, то ли нет, и робот половину визитов получал таймаут. Никакие тексты и ссылки этого не перебивают. Ниже — как устроен мониторинг, что мониторить кроме «главная открывается» и как реагировать, чтобы простой не превращался в потерю трафика.

Что происходит с сайтом за время простоя

Потери от недоступности накапливаются нелинейно. Короткий сбой в глухое время суток проходит почти бесследно, а вот повторяющиеся отказы дают эффект, который потом объясняют чем угодно, кроме реальной причины.

Длительность и характер	Что теряет бизнес	Что видит поисковик
Единичный сбой до 5 минут	Практически ничего	Одна неудачная попытка, повторит позже
Час в рабочее время	Заявки за этот час, часть уходит к конкурентам	Несколько ошибок обхода, обычно без последствий
Сутки	Дневная выручка, звонки, рекламный бюджет впустую	Снижение частоты обхода, страницы могут выпадать
Несколько дней	Потеря позиций, возврат занимает недели	Массовое исключение страниц из поиска
Регулярные короткие отказы	Незаметная утечка заявок, жалобы «у вас не открывается»	Робот снижает нагрузку, обход замедляется на всём сайте

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

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

Как устроен мониторинг доступности

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

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

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

Что мониторить кроме «главная открывается»

Проверка	Что ловит	Как настраивается
Ответ главной страницы	Полное падение сервера	Код ответа 200, интервал 1–5 минут
Динамическая страница	Отказ базы данных при живом кэше	Карточка товара или страница поиска, код 200
Наличие ключевого слова	Белый экран, страница-заглушка хостера	Проверка на присутствие фразы в html
Отсутствие ключевого слова	Ошибки PHP, взлом, редирект на чужой сайт	Проверка, что в коде нет слов вроде «Fatal error»
Сертификат	Истечение срока, ошибка цепочки	Предупреждение за 14–30 дней до конца
Регистрация домена	Забытое продление	Напоминание за 30 и за 7 дней
Время ответа сервера	Постепенную деградацию хостинга	Порог по времени, тревога при устойчивом превышении
Место на диске и почта	Переполнение, отказ отправки писем	Средствами панели хостинга

Проверка на отсутствие слова — недооценённый инструмент. Она ловит ситуации, при которых сервер честно отдаёт код 200, а на странице вместо контента текст ошибки, страница-заглушка или посторонний скрипт. Формально сайт «работает», по факту он сломан, и обычный мониторинг доступности этого не заметит.

Тему разбирал отдельно: «СЕО проверка сайта онлайн».

Отдельная группа проверок — сетевые порты. Если на сервере работает почта или другие службы, их доступность отслеживается так же, как доступность сайта, и падают они обычно раньше.

Интервалы, пороги и ложные тревоги

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

• Интервал. Для сайта с заявками разумно раз в минуту или раз в пять минут. Раз в полчаса означает, что получасовой простой вы можете не увидеть вовсе.
• Подтверждение отказа. Тревога отправляется не по первой неудачной попытке, а после двух-трёх подряд с разных точек. Это отсекает случайные сетевые сбои.
• Таймаут. Сколько ждать ответа, прежде чем считать сайт недоступным. Десять секунд — разумная граница: если сервер думает дольше, посетитель уже ушёл.
• Порог по времени ответа. Отдельная тревога не на падение, а на замедление. Настраивается на устойчивое превышение, а не на единичный всплеск.
• Уведомление о восстановлении. Обязательно, иначе непонятно, закончился инцидент или продолжается.
• Мониторинг доступности: сколько заявок утекает, пока сайт лежит ночью

Помогу с продвижением: продвижение сайта с гарантией результата — вывожу сайты в топ Яндекса белыми методами.

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

Ещё одно правило: уведомления должны идти минимум в два канала, и хотя бы один — с пробуждением. Почта не работает как сигнал тревоги, её открывают утром. Мессенджер или пуш на телефон работают. И у канала должен быть конкретный получатель: адрес вида info@ читают все и не читает никто.

Если интересно направление с сайтами — базу даю в своём курсе:

8:14

Тихие поломки, которые не ловит мониторинг доступности

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

• Форма заявки не отправляет письма. Самая частая и самая дорогая. Отправка ломается после смены хостинга, обновления плагина, переполнения почтового ящика или попадания домена в спам-листы. Проверяется только реальной отправкой.
• Оплата не проходит. Истёк ключ платёжного модуля, сменились реквизиты, обновился протокол. Пользователь молча уходит, вы узнаёте по падению заказов.
• Поиск по сайту выдаёт пустоту. Слетел индекс поиска после обновления. Каталог работает, поиск возвращает ноль результатов по любому запросу.
• Сломалась корзина на мобильных. Кнопка перекрыта элементом вёрстки после обновления темы. На десктопе всё хорошо, а мобильные заказы обнулились.
• Пропали изображения. Переезд на CDN, смена путей, чистка папки загрузок. Страницы открываются, товары без фото.
• Сайт заражён и отдаёт другой контент роботам. Посетитель видит обычную страницу, робот — рекламный текст. Проверяется инструментом просмотра страницы в Вебмастере.
• Мониторинг доступности: сколько заявок утекает, пока сайт лежит ночью

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

Смежный материал по теме — «Как выполнить аудит контента сайта».

Мониторинг скорости и времени ответа

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

Время ответа сервера	Оценка	Что обычно за этим стоит
До 200 мс	Хорошо	Кэширование настроено, ресурсов хватает
200–500 мс	Приемлемо	Обычный виртуальный хостинг без кэша
500–1000 мс	Плохо	Тяжёлые запросы к базе, лишние плагины
Свыше 1000 мс	Требует вмешательства	Нехватка ресурсов, соседи по серверу, неоптимальный код

Полезно смотреть не на среднее значение, а на график за месяц. Он показывает то, чего не видно в разовом замере: ежедневные пики в часы нагрузки, ночные провалы во время резервного копирования, регулярные всплески по расписанию из-за крона. Такая картина сразу подсказывает, где искать причину, — она почти всегда во внутренних процессах, а не в «плохом интернете у клиента».

Второй источник данных, который есть у каждого и почти никем не используется, — статистика обхода в Яндекс Вебмастере. Там видно время ответа по запросам робота и число ошибок за период. Если график ошибок обхода коррелирует с вашими просадками показов, дальше искать нечего: причина техническая.

Как поисковики реагируют на недоступность

Реакция зависит от того, что именно отдал сервер, и это ключевая деталь, о которой забывают при плановых работах.

• Таймаут или ошибка соединения. Робот считает попытку неудачной и повторит позже. Единичные случаи безвредны, систематические ведут к снижению темпа обхода.
• Ошибка 500. Трактуется как поломка. При длительном повторении страницы начинают исключаться из поиска.
• Ошибка 503 с заголовком времени повтора. Правильный ответ на время плановых работ: робот понимает, что сайт временно занят, и приходит позже без последствий.
• Код 200 со страницей-заглушкой. Худший вариант. Робот считает, что содержимое страницы теперь такое, и заменяет им прежнее. После восстановления придётся ждать переобхода всего сайта.
• Редирект всего сайта на заглушку. Поисковик решает, что весь сайт переехал на одну страницу, и склеивает адреса. Восстановление занимает недели.
• Мониторинг доступности: сколько заявок утекает, пока сайт лежит ночью

Отсюда простое правило для любых работ дольше пятнадцати минут: заглушка должна отдавать код 503 с указанием ориентировочного времени возврата, а не код 200. Это настройка на уровне сервера или одна строка в конфигурации CMS, и она превращает потенциальную аварию в незаметное событие.

Регламент реакции: первые пятнадцать минут

Если нужна помощь по теме — курсы SEO-оптимизации.

Уведомление пришло. Дальше нужен порядок действий, написанный заранее, потому что в момент аварии никто не изобретает методику.

Если нужны детали, смотрите «Счётчики посещений для сайта».

1. Подтвердить, что это не ложная тревога. Открыть сайт с мобильного интернета, не с офисного Wi-Fi, и проверить через сторонний сервис доступности.
2. Определить масштаб. Лежит весь сайт или отдельная страница. Открывается ли админка. Отвечает ли сервер на запрос вообще.
3. Посмотреть, что менялось. Обновление CMS или плагина, правка шаблона, выкладка кода, изменение настроек — за последние сутки. В девяти случаях из десяти причина здесь.
4. Проверить очевидное. Место на диске, срок сертификата, срок домена, статус оплаты хостинга. Эти четыре причины закрывают заметную долю всех падений.
5. Обратиться в поддержку хостинга. С конкретикой: время начала, код ошибки, что проверили. Общее «у меня не работает сайт» удлиняет разбор в разы.
6. Если работы затягиваются — включить корректную заглушку. С кодом 503, контактным телефоном и указанием, когда всё вернётся.
7. После восстановления — запросить переобход. В Вебмастере проверить отчёт об ошибках и отправить на переобход ключевые страницы.

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

Что настроить в первый день

Если мониторинга нет вообще, минимальный набор выглядит так и занимает час.

• Проверка главной страницы с интервалом раз в пять минут и подтверждением отказа с двух точек.
• Проверка одной динамической страницы — карточки товара или страницы услуги.
• Проверка на присутствие ключевой фразы из шапки сайта в коде страницы.
• Уведомления в мессенджер конкретному человеку плюс дублирование на почту.
• Напоминания о сроках сертификата и домена.
• Еженедельная ручная проверка формы заявки и оплаты.
• Ежемесячный просмотр статистики обхода и ошибок в Вебмастере.
• Мониторинг доступности: сколько заявок утекает, пока сайт лежит ночью

Бесплатных тарифов у сервисов мониторинга обычно достаточно для одного-двух сайтов с интервалом в пять минут. Платить есть смысл за минутный интервал, сценарные проверки и SMS-уведомления — то есть тогда, когда простой стоит дороже подписки. Для интернет-магазина это условие выполняется всегда.

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

Не создаёт ли сам мониторинг нагрузку на сайт? Одна проверка раз в минуту — это меньше, чем один посетитель. Заметная нагрузка возникает только при сценарных проверках с частым интервалом, но и она несопоставима с реальным трафиком.

Достаточно ли уведомлений от хостинга? Нет. Хостинг сообщает о проблемах на своей стороне и не видит, что ваш сайт отдаёт ошибку из-за плагина или переполненной базы. Мониторинг смотрит снаружи, глазами посетителя, — это принципиально другая точка обзора.

Как отличить проблему хостинга от проблемы сайта? Признак первый: отвечает ли сервер хоть чем-нибудь. Если соединения нет вовсе — вопрос к хостингу. Если приходит ошибка 500 или белый экран — сервер жив, сломан сайт. Признак второй: работают ли другие сайты на том же аккаунте.

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

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

Что делать, если хостинг падает регулярно? Собрать статистику за два-три месяца из отчётов мониторинга, предъявить её поддержке и потребовать объяснений. Если ответа по существу нет — переезжать. График простоев из независимого сервиса — единственный аргумент, который в таком разговоре работает.

Коротко

• Мониторинг нужен, чтобы узнать о падении раньше клиента и раньше робота: убытки от простоя растут нелинейно, а регулярные короткие отказы вреднее одного долгого.
• Проверять только главную недостаточно — она отдаётся из кэша при мёртвой базе. Нужны динамическая страница и проверка на наличие и отсутствие ключевых фраз в коде.
• Ложные тревоги неизбежны; лечатся подтверждением отказа с нескольких точек, разумным таймаутом и белым списком для проверяющих адресов.
• Уведомления идут минимум в два канала, один из которых будит, и адресуются конкретному человеку, а не общему ящику.
• На время плановых работ сервер обязан отдавать 503, а не 200 с заглушкой: во втором случае поисковик заменит содержимое страниц текстом заглушки.
• Тихие поломки — форма, оплата, поиск по сайту — не ловятся мониторингом доступности, для них нужен еженедельный ручной тест или сценарные проверки.
• Мониторинг доступности: сколько заявок утекает, пока сайт лежит ночью

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