Допустим, интернет-магазин прошёл приёмку: каталог открывается, тестовый заказ появился в системе, HTTPS работает. Что проверять дальше? Ежедневно повторять весь путь покупателя вручную неудобно, а одна открывающаяся главная мало говорит о состоянии остального сайта.
Я развиваю reChecker — сервис технических проверок и мониторинга сайтов. На его примере разберу три задачи после запуска: заметить сбой доступа, увидеть изменение важной страницы и найти проблемы при более широком обходе. У них разный охват и разная частота проверки. Если свести их к одному индикатору «сайт работает», часть изменений останется за кадром.
Магазин в примерах условный.
Сначала — отвечает ли нужный адрес
В reChecker монитор доступности рассчитан на проверку каждые пять минут. В истории сохраняются HTTP-статус, время ответа и причина сбоя. Алгоритм подтверждает отказ повторными проверками, чтобы не сообщать о падении по одной неудачной попытке.
В коде проверки сетевой отказ или HTTP-ошибка от 500 могут привести к состоянию падения. Ответ ниже 500 без дополнительных условий считается достижимым: даже 404 сам по себе не означает падения. Если включены обязательный текст или порог времени, проверяются и они. Отсутствие фразы в полученном HTML либо превышение порога дают статус ухудшения (degraded), в том числе при HTTP 200. Текст ищется с учётом регистра; замер времени не описывает полную загрузку страницы в браузере.
Для основного URL код предусматривает уведомления о подтверждённом падении и восстановлении достижимости. Нарушение дополнительных условий само по себе не вызывает отдельного сообщения — его нужно смотреть в истории. Уведомление о восстановлении тоже не гарантирует, что текст и порог времени уже в порядке.
После сигнала ответственный открывает тот же URL и сверяет время и ошибку с журналами сервера. Проверка ответа не заменяет проверку заказа или получения заявки.
Сайт отвечает, но страница изменилась
Теперь другая ситуация. Категория рюкзаков открывается с HTTP 200, но её основной заголовок (H1) сменился с «Рюкзаки для походов» на общее «Каталог». Это могла быть согласованная правка, ошибка шаблона или временно отданная версия страницы. По одному ответу причину не установить.
Для выбранных адресов в reChecker есть монитор изменений SEO-полей. Публично для него указан интервал 30 минут. Он сохраняет прежние и новые значения, поэтому человек может увидеть конкретную правку, а не только сообщение «страница изменилась».
В коде сравнения первый пригодный снимок — набор полученных полей страницы — становится базой. Если следующий отличается, процесс делает ещё два запроса с паузой. Новое состояние принимается, когда минимум два из трёх снимков совпали. Пробелы перед сравнением приводятся к одному виду; сравнивается весь снимок, а не каждое поле отдельным голосованием.
Вернёмся к категории. В этом примере отслеживание H1 включено. Пусть остальные поля во всех ответах одинаковы, а H1 пришёл в такой последовательности:
Запрос | Полученный H1 |
|---|---|
Первый | Каталог |
Повторный | Рюкзаки для походов |
Ещё один повторный | Каталог |
Вариант с «Каталог» повторился дважды: в историю попадёт смена H1. Если подтвердилось прежнее состояние или устойчивого совпадения нет, база сохранится. Неопределённый результат не доказывает, что изменений не было.
Правило подтверждает повторяемость, а не правильность: ошибочный шаблон тоже может повториться. После события человек сверяет изменение с задачей и публикациями в CMS; намеренная правка не становится ошибкой. Монитор не устанавливает автора правки, не измеряет поисковые позиции и не исполняет JavaScript: он видит HTML-ответ, который может отличаться от страницы после работы скриптов в браузере.
Что осталось за пределами выбранных страниц
У магазина может исправно открываться главная и сохраняться нужный H1 категории, а внутри каталога остаться ссылка на удалённый товар. Два точечных монитора её не заметят, если она находится на другой странице.
Для этого нужен более широкий обход. В подписке «Контроль сайта» описан ежедневный технический аудит до 100 страниц. В изученной реализации планировщик ставит подходящий по расписанию аудит в очередь; законченный отчёт появляется после обработки. Сам факт постановки в очередь ещё не означает, что страницы проверены.
В условном магазине аудит может обнаружить, что на проверенной странице категории ссылка ведёт на товар с ответом 404. Полезный результат здесь — два адреса: где расположена ссылка и куда она ведёт, вместе с результатом запроса. С такими данными разработчик может открыть исходную страницу, пройти по ссылке и решить, нужно ли убрать её, заменить адрес или настроить переход на другой товар.
В изученной реализации обход ограничен не только числом страниц: есть лимит дополнительных запросов к ссылкам и изображениям. Если он исчерпан, часть целей останется непроверенной. В результатах сохраняются числа найденных и проверенных целей и признак неполного охвата. Для проблемных целей сохраняются исходные страницы; неполученные данные отделяются от подтверждённых битых ссылок.
Число 100 здесь — предел охвата, а не обещание проверить весь каталог. Если нужная категория не попала в обработанный набор, отсутствие замечаний о ней ничего не подтверждает. Список проверенных URL стоит сверять с теми страницами, за которые команда отвечает в первую очередь.
Как собрать это в рабочий порядок
Для условного магазина стартовая схема может быть такой:
Что контролировать | Какой адрес выбрать | Как часто | Что делать после сигнала или записи в истории |
|---|---|---|---|
Доступность и заданные условия ответа | Главная или ключевая категория; обязательная фраза должна присутствовать в её HTML | Каждые 5 минут | Открыть тот же URL, разобрать HTTP-ошибку либо нарушение текста или порога времени |
Изменения полей | Важная категория; включить отслеживание нужных полей, например H1 | Каждые 30 минут | Сопоставить «было → стало» с задачей и публикацией в CMS |
Технические проблемы и ссылки | Сайт с проверкой, что важные категории вошли в фактически обработанный набор | Ежедневно, до 100 страниц в рассматриваемой подписке | Проверить охват; для битой ссылки открыть исходную страницу и адрес назначения |
Интервалы — периодичность проверок, а не сроки получения сообщения: подтверждение требует времени, короткий сбой может попасть между запросами. Для каждой строки нужен ответственный и настроенный канал. В reChecker предусмотрены подключённые и разрешённые каналы, включая Telegram.
Покупательский путь остаётся отдельной проверкой команды. После релиза, затронувшего заказ, нужен тестовый заказ с проверкой его появления в системе; после изменения формы — проверка получения заявки адресатом. Описанные мониторы эти действия не выполняют.
