Резкий рост визитов, отказов или нагрузки ещё не доказывает атаку ботов. Причиной может быть рекламная кампания, ошибка счётчика, медленная страница, новый поисковый обход или интеграция, которая слишком часто обращается к API. Надёжная диагностика начинается не с блокировки IP-адресов, а с сопоставления трёх источников: веб-аналитики, журналов веб-сервера и результата действий в CRM или системе заказов.
Каждый источник отвечает на свой вопрос. Метрика показывает структуру визитов и поведение в интерфейсе, access-логи фиксируют фактические HTTP-запросы, а CRM помогает понять, создал ли поток реальные обращения и продажи. По отдельности данные дают неполную картину: клиентский счётчик не увидит часть запросов без JavaScript, лог не знает качества лида, а CRM не объясняет, какой сетевой сценарий привёл к заявке.
Какие признаки требуют проверки
Сигналом для расследования служит не просто необычное значение, а изменение относительно нормального профиля сайта. Для интернет-магазина естественны всплески во время акции, для сезонной услуги — после изменения погоды, для B2B-сервиса — активность в рабочие часы. Сначала сравните одинаковые дни недели и источники трафика, затем проверьте, совпало ли отклонение с релизом, рассылкой, рекламой или технической ошибкой.
- визиты выросли, но число просмотренных страниц, подтверждённых заявок и заказов осталось прежним;
- одна группа страниц получает повторяющиеся переходы с одинаковой глубиной и интервалами;
- увеличились ответы 404, 403, 429 или 5xx, нагрузка на базу данных и время ответа origin-сервера;
- в формах появились серии контактов, которые не подтверждаются звонком, почтой или дальнейшим действием;
- User-Agent выглядит обычным, но клиент не загружает стили, изображения и JavaScript либо обращается прямо к обработчику.
Какие срезы смотреть в Яндекс Метрике и другой аналитике
Начните с периода, в котором видна нормальная база для сравнения: например, семь дней до всплеска и сам проблемный интервал. Разделите поток по источнику, кампании, посадочной странице, устройству, браузеру, региону и времени суток. Среднее значение по всему сайту скрывает серии, поэтому полезно смотреть распределение по часам и отдельным URL.
Короткий визит не равен боту. Пользователь может сразу найти телефон, получить ответ на информационной странице или уйти из-за медленной загрузки. Проверяйте сочетания: одинаковая длительность, отсутствие прокрутки и событий, повторяемый маршрут, необычно высокая частота и отсутствие последующих конверсий. При подозрениях на влияние автоматизации на поиск используйте отдельный чек-лист по поведенческому трафику и SEO-сигналам.
Учитывайте ограничения клиентской аналитики. Браузер может заблокировать счётчик, пользователь уйдёт до его загрузки, а простой HTTP-клиент вообще не выполнит JavaScript. Обратная ситуация тоже возможна: один визит содержит десятки запросов к ресурсам, поэтому число визитов нельзя напрямую сравнивать с количеством строк в access-логе.
Что искать в access-логах веб-сервера
Для первичного анализа нужны время запроса с часовым поясом, метод, URL, код ответа, объём ответа, время обработки, IP, User-Agent и, если политика сервиса это допускает, идентификатор сессии или запроса. Не передавайте в аналитические выгрузки пароли, токены, содержимое форм и лишние персональные данные. Параметры URL также следует проверять: в них могут оказаться email, телефон или секрет интеграции.
Сгруппируйте запросы по временным окнам и маршрутам. Автоматизацию часто выдают стабильные интервалы, последовательный перебор идентификаторов, глубокая пагинация, повторные запросы к поиску и карточкам товаров, обращение к несуществующим адресам или попытки вызвать POST-обработчик без предшествующей загрузки формы. Но одинаковый IP нельзя автоматически считать одним клиентом: корпоративный NAT и мобильный оператор объединяют множество людей.
IP и ASN добавляют контекст, если интерпретировать их вместе с поведением. Жалобы, прокси или сеть дата-центра повышают риск, но не доказывают вредоносность текущего запроса. Подробнее ограничения и порядок проверки разобраны в статье о репутации IP, VPN и ASN; для единичного адреса доступен публичный инструмент проверки IP.
Почему расследование нужно сверять с CRM и заказами
Цель защиты — не уменьшить график трафика любой ценой, а сохранить доступ реальным клиентам и убрать автоматизацию, которая расходует ресурсы или искажает бизнес-процесс. Поэтому отметьте для заявок итоговый статус: подтверждённый контакт, дубль, неверный номер, спам, отмена или продажа. Для заказов полезны подтверждение телефона, оплата, возврат и причина отмены.
Связать веб-событие и CRM безопаснее по внутреннему идентификатору обращения, времени и посадочной странице, чем по персональным данным. Если подозрительная серия визитов совпадает с потоком неподтверждённых заявок и однотипным поведением в логах, гипотеза становится сильнее. Если конверсии сохраняются, причиной отклонения может быть реальная аудитория или ошибка настройки аналитики.
Защита обработчика должна дополнять диагностику: серверная валидация, ограничение размера запроса, контроль частоты и повторная проверка рискованных сценариев. Практические меры собраны в руководстве по защите форм от спам-ботов.
Как сопоставить три источника без сложной платформы данных
- Зафиксируйте точный интервал аномалии и часовые пояса всех систем. Без этого события будут смещены и образуют ложные совпадения.
- Выберите один понятный сценарий: отправку формы, просмотр каталога, поиск по сайту или вход. Не смешивайте маршруты с разной нормальной частотой.
- В аналитике выделите источник, страницы, устройства и поведенческие признаки подозрительного сегмента.
- В логах найдите тот же интервал и маршрут, затем сравните частоту, коды ответа, время обработки, последовательность URL и технические профили.
- Проверьте итог в CRM или заказах: долю подтверждённых обращений, дублей, отмен и продаж относительно обычного периода.
- Сформулируйте проверяемую гипотезу, например: «серия прямых POST-запросов без загрузки формы создаёт неподтверждённые лиды».
Для регулярного контроля зафиксируйте базовые показатели и владельца каждого действия. Удобный состав управленческой сводки приведён в статье о метриках бот-трафика для предпринимателя.
Как вводить защитные меры и проверять ложные срабатывания
Начинайте с меры, соответствующей риску конкретного действия: наблюдение, мягкий rate limit, дополнительная проверка или блокировка очевидной автоматизации. Ограничение для поиска по каталогу и для оформления заказа не обязано быть одинаковым. Не блокируйте целую страну, ASN, VPN или User-Agent только потому, что этот признак часто встречался в одной серии.
После изменения сравните минимум два сопоставимых интервала. Контролируйте долю 403 и 429, время ответа, нагрузку на origin, число подтверждённых заявок, конверсию и обращения в поддержку. Отдельно проверяйте доступ официальных поисковых роботов: поддельную строку User-Agent нужно фильтровать, а подтверждённому краулеру нельзя мешать индексировать сайт. Механика проверки описана в материале о Googlebot и Яндекс.Боте.
Краткий чек-лист расследования бот-трафика
- сравнить аномальный период с нормальной базой и учесть рекламу, релизы и сезонность;
- выделить конкретный источник, маршрут и бизнес-сценарий;
- сверить визиты с фактическими HTTP-запросами и кодами ответа;
- проверить частоту, последовательность URL, технический профиль, IP и ASN;
- сопоставить поток с подтверждёнными заявками, заказами и нагрузкой на инфраструктуру;
- применить пропорциональное правило и заранее определить способ отката;
- после запуска контролировать конверсию, ошибки, поисковых роботов и обращения пользователей.
BotProtection фильтрует запросы на внешнем контуре до origin-сервера и помогает сопоставлять сетевые и поведенческие признаки. Результат зависит от структуры сайта и состава трафика, поэтому правила следует проверять на собственных данных и регулярно пересматривать.