Главная страница отвечает 200, однако карточки товаров открываются с ошибкой. Такой инцидент показывает слабость контрольной выборки: она представляет домен, но пропускает отдельный шаблон и его источник данных. Исправить выборку можно за один рабочий сеанс: сначала пройти пользовательские действия, затем отметить технические пути.
Нарисуйте пять пользовательских маршрутов
Запишите действия, ради которых люди приходят на сайт. Для интернет-магазина это поиск, переход в категорию, открытие карточки, добавление товара и оформление заказа. Для B2B-сервиса — вход, работа в кабинете, отправка заявки и загрузка документа. Для медиа — открытие выпуска, статьи и подписки.
Один URL подтверждает только свой участок маршрута. Открытая форма свидетельствует о загрузке интерфейса; приём данных API остаётся отдельным условием. Доступная корзина столь же мало говорит о создании операции платёжным шлюзом. Обычная HTTP-проверка подходит для страницы и устойчивого текста. Отправка формы или тестовый заказ требуют отдельного синтетического сценария, специальных учётных записей и безопасных данных.
Отметьте последствие отказа каждого шага: потеря обращения, невозможность войти, недоступность справки, ухудшение обхода. Так в ядро попадёт редко посещаемое восстановление пароля, если без него клиенты теряют доступ, а очередная информационная страница останется за пределами частых запросов.
Интервалы и условия тревоги удобно уточнить по руководству по uptime-мониторингу, когда состав маршрутов уже известен.
Найдите технических представителей
Теперь сгруппируйте страницы по способу формирования. Обычно различаются главная, листинг, карточка, статья, статическая страница, поиск и авторизация. У мультиязычного проекта локали могут обслуживаться одним шаблоном или разными приложениями; это нужно выяснить, прежде чем считать одну русскую страницу представителем всех языков.
Для каждого шаблона выберите стабильный адрес с обычными данными. Добавьте крайний случай, только если он проходит другой код: пустой список, пагинация, отсутствующее изображение, длинное название. Десять карточек на одном API и одном шаблоне дают мало нового покрытия. Одна карточка со старого backend и одна с нового уже способны различить две причины отказа.
Полезный вопрос для разработчика: «Какие из этих URL могут сломаться независимо друг от друга?» Ответ выявляет отдельные сервисы, шарды, хранилища изображений и правила маршрутизации, которые не видны из меню сайта.
Добавьте поисковые и инфраструктурные адреса
Пользовательские страницы не показывают состояние robots.txt, sitemap, XML-фидов и поддоменов статических ресурсов. Внесите такие точки отдельными строками и задайте каждой своё ожидание. Для robots.txt одного ответа 200 мало: нужен контроль согласованного содержимого. У sitemap проверяют формат XML, чтобы обнаружить HTML-заглушку с успешным статусом.
Старый домен, www и HTTP могут быть нужны как точки перехода. Для них ожидаемым результатом будет конкретная цепочка до основного HTTPS-адреса. Если у проекта есть региональные домены, отдельные API или CDN для изображений, включайте по представителю каждого публичного пути.
Географические проверки добавляют при реальной разнице маршрутов: нескольких CDN-регионах, локальном DNS или региональных ограничениях. Одна ошибка удалённой точки требует подтверждения, однако она может означать локальный сбой для настоящих пользователей. Набор метрик для сопоставления таких сигналов приведён в статье о дашборде мониторинга.
Соберите постоянное ядро и ротацию
Постоянное ядро состоит из стабильных URL, по которым нужна сопоставимая история: главная, ключевой пользовательский маршрут, представители критичных шаблонов и служебные файлы. Ротация расширяет охват каталога: каждый запуск или каждый день проверяется новый сегмент карточек.
Правило ротации должно воспроизводиться. Подойдут последовательный обход категорий, выбор страниц по дате обновления или псевдослучайная выборка с сохранённым идентификатором запуска. Формулировка «берём несколько случайных товаров» затруднит повторный тест найденного дефекта.
Временные результаты поиска, одноразовые ссылки и сезонные акции плохо подходят для постоянного ядра. После закономерного удаления они начнут создавать тревоги. Для них используют тестовый объект с известным жизненным циклом либо контролируют общий шаблон.
Заполните реестр контрольных URL
Не оставляйте выборку списком ссылок. Для каждой строки нужны причина включения и проверяемое ожидание. Вот пример реестра магазина:
| URL | Что представляет | Ожидаемый результат | Маркер | Что остаётся за рамками |
|---|---|---|---|---|
/ | Публичная витрина | 200 после HTTPS | «Каталог» | Работа корзины |
/catalog/chairs/ | Листинг и каталоговый API | 200 | H1 категории | Другие категории в ротации |
/product/test-chair/ | Шаблон карточки | 200 | Код тестового товара | Добавление в корзину |
/login/ | Вход | 200 | Поле email | Успешная авторизация |
/robots.txt | Правила обхода | 200, текстовый файл | Согласованная строка Sitemap | Директивы для отдельных агентов |
Добавьте к рабочей версии частоту, критичность и контакт владельца. Эти поля нужны для эксплуатации, однако не должны подменять главную задачу реестра: объяснить, какую независимую поломку представляет адрес.
Маркер выбирайте устойчивый. Цена, дата и рекламный слоган меняются штатно. Название тестового товара или технический атрибут лучше переживают редакционные обновления. Если содержимое появляется только после JavaScript, HTTP-проверка его не увидит; понадобится браузерный сценарий или серверный признак.
Проведите проверку пробелов
Соберите рядом столбцы «сценарий», «шаблон», «источник данных», «домен» и «регион». Затем отметьте, какие строки реестра покрывают каждую категорию. Пустая клетка означает осознанный пробел или задачу на новый тест.
Проверьте выборку тремя мысленными отказами:
- каталоговый API возвращает 500, главная работает;
- сертификат поддомена изображений истёк, основной домен исправен;
- редактор случайно изменил SEO-поля одного шаблона.
Для каждого случая должен существовать либо сигнал, либо записанное решение обнаруживать его другим способом. Если три URL сообщат об одном и том же отказе, решите, нужна ли такая избыточность. При критичном маршруте она может быть оправдана; для обычного шаблона достаточно одного стабильного представителя и ротации.
Подход к техническим SEO-признакам можно сверить с руководством по SEO-мониторингу.
Распределите точки по способам проверки
Полный реестр не обязан помещаться в один сервис. Например, дашборд мониторинга reChecker позволяет задать основной и один дополнительный критичный URL с ожидаемым текстом, но не выполняет ротацию каталога и браузерный тест заказа. Отметьте эти две точки в реестре, а остальные маршруты распределите между релизной приёмкой, внутренними метриками и специализированными тестами.
После первого месяца добавьте в реестр два фактических поля: сколько раз точка обнаружила уникальную проблему и сколько тревог потребовали ручного уточнения. Удаляйте потерявшие смысл адреса после закрытия акции или замены шаблона. Новую точку вносите вместе с новым публичным маршрутом, чтобы список не отставал от устройства сайта.