Яндекс пишет, что роботы, которые явно представились своим User-Agent, сразу исключаются из статистики, а вот роботы, которых Метрика распознаёт по поведению, по умолчанию могут оставаться в обычных отчётах. Их нужно отдельно исключать через сегмент или через сравнение «с роботами / без роботов». Яндекс прямо приводит пример, что роботы могут быть причиной роста bounce rate и падения глубины просмотра.
При этом сама метка Chrome ничего не доказывает: User-Agent — ненадёжный признак, его легко подделать, и MDN отдельно предупреждает, что опираться на UA для уверенного определения клиента плохо. То есть «много Chrome» ≠ «много живых пользователей Chrome».
Что делать сейчас.
1. Сначала подтвердить или снять гипотезу про роботов в Метрике
Откройте Отчёты → Мониторинг → Роботы и возьмите тот же период, когда выросли отказы и просели позиции. Яндекс рекомендует именно этот отчёт для анализа неестественных всплесков и отдельно советует при повторяющихся аномалиях включать фильтрацию роботов строгими фильтрами и по поведению.
Дальше в ключевых отчётах переключите режим «без роботов» и сравните с данными «с роботами». Яндекс прямо пишет, что так можно увидеть, как роботы влияют на метрики, включая рост отказов. Если при исключении роботов всплеск почти исчезает, это сильный признак, что проблема в мусорном/ботовом трафике, а не в реальном ухудшении поведения пользователей.
Срезы, которые надо посмотреть в первую очередь:
• Источник/канал
• Посадочная страница
• Регион
• Устройство
• Браузер
• Помесячно/поминутно в момент аномалии
Если всплеск сидит в 1–2 регионах, на ограниченном наборе URL и почти не меняет поведение после исключения «известных» роботов, это уже повод смотреть защиту на уровне WAF и сервера. Если после режима «без роботов» картина нормализуется — сначала чистите учёт и фильтрацию.
2. Не включайте жёсткую фильтрацию в Метрике вслепую
В настройках тега есть опция Filter robots by behavior, но Яндекс прямо пишет, что это действие необратимо и обычно его рекомендуют только если вы работаете с Logs API и вам принципиально нужны сырые данные уже без роботов. В остальных случаях Яндекс рекомендует не включать это без необходимости, а работать через режим отображения и сегменты.
То есть правильно так:
1. сначала сравнить «с роботами / без роботов»;
2. сохранить сегмент без роботов;
3. только если проблема постоянная и вам мешают именно сырые данные, думать о необратимом фильтре.
3. Параллельно проверить именно Yandex SEO, а не только Метрику
Резкий провал позиций в Яндексе не сводится к отказам. Сам Яндекс пишет, что падение может происходить из-за:
• изменений алгоритмов ранжирования,
• антиспам/антифрод-алгоритмов,
• изменений спроса,
• изменений на самом сайте,
• выпадения страниц из поиска,
• проблем с релевантностью и качеством.
Поэтому в Яндекс.Вебмастере сразу проверьте:
• Website optimization → Security and violations — есть ли угрозы/ограничения; Яндекс пишет, что нарушения и unfair promotion methods могут приводить к ограничениям ранжирования как всего сайта, так и разделов.
• Статистику запросов / Query monitoring — какие именно группы запросов рухнули.
• Demand / Wordstat history — не просел ли спрос, если кажется, что «всё было стабильно». Яндекс сам советует это проверять.
• Проверку URL и индексацию — не выпали ли важные страницы, не стали ли они дублями, не изменился ли ответ сервера для робота. В Вебмастере есть инструменты для проверки статуса URL, доступности для бота и списка дублей.
Отдельно: если сайт долго был лидером, падение составило более 30 позиций, и трафик тоже упал, Яндекс сам советует обращаться в поддержку через Вебмастер. Это как раз очень похоже на ваш кейс.
4. Какую защиту ставить
Если после проверки видно, что это действительно автоматизированный трафик, ставьте WAF/CDN с bot protection и rate limiting. Практически это может быть Cloudflare или аналогичный сервис. Для такой защиты базовая логика правильная:
• allow Verified Bots;
• плохих/подозрительных ботов — challenge или block;
• rate limiting — не на весь сайт, а на тяжёлые и уязвимые точки: /search, фильтры, сортировки, /login, /xmlrpc.php, формы, API, корзина/checkout. Cloudflare рекомендует rate limiting именно для ограничения злоупотреблений и отдельно предупреждает, что применение rate limiting к verified bots может повредить SEO.
Для Яндекса это особенно важно, потому что Yandex bot у Cloudflare относится к Verified Bot, но Cloudflare отдельно пишет, что из-за обновления IP-диапазонов трафик Яндекса иногда может временно блокироваться WAF-правилом. В таких случаях они рекомендуют временное исключение/skip-rule для легитимного Yandex traffic.
Если вы не на Cloudflare, логика всё равно та же:
• не блокировать поисковых ботов;
• не строить защиту по строке Chrome;
• резать частоту запросов на тяжёлых путях;
• challenge/block делать по совокупности сигналов, а не по одному браузеру.
5. Что ещё проверить в Метрике и теге
Яндекс указывает ещё на несколько вещей, которые могут ломать интерпретацию данных:
• если в настройках тега не указаны все Address / Additional address, часть визитов может считаться роботными;
• отчёты могут искажаться, если тэг установлен не на всех посадочных страницах или установлен некорректно;
• в отчётах источников большой direct/unknown иногда связан не только с роботами, но и с особенностями передачи Referrer и разметки тега.
Простой
