Водительское удостоверение сообщает, кто человек и что он сдал экзамен по вождению, но не гарантирует, что он будет управлять автомобилем ответственно в будущем. То же самое относится к ботам: подтверждение того, кто им управляет, создаёт ответственность, но доверие зависит от того, что бот будет делать дальше. Известный бот всё ещё может игнорировать предпочтения сайтов, перегружать источники или обходить ограничения. Это не всегда зловредно — часто причина в некорректной настройке или баге.
Как мы писали в предыдущем блоге о поведении ботов, мы стремимся подтвердить два вопроса: «Являетесь ли вы тем, за кого себя выдаёте?» и «Можно ли вам доверять?» Чтобы стать Cloudflare Verified Bot, в общих чертах нужно соответствовать трём критериям:
- точно и безопасно идентифицировать себя;
- не причинять вреда;
- соблюдение других установленных требований.
Боты используют Web Bot Auth для подписания запросов, которые устанавливают их личность, а BotBase затем каталогизирует их в открытом формате. После того как идентификация решена, наше внимание переключается на вторую основную заповедь Verified-ботов: не причинять вреда.
Сегодня мы представляем систему для оценки и отчётности, когда поведение Verified-бота начинает отклоняться от этой заповеди, чтобы ответ на вопрос «Можно ли вам доверять?» оставался «Да».
Здесь важна разница между риском и доверием:
- Риск описывает вероятность того, что конкретный запрос или действие в данный момент времени может быть вредоносным, и он может меняться от момента к моменту.
- Доверие строится со временем посредством повторяющегося и последовательного поведения.
Например, мы исключили бот Perplexity из списка Verified в 2025 году, когда он попытался получить доступ к ресурсам на сайтах, которые отказались от скрапинга, а затем попытался обойти ограничения, когда эти запросы были заблокированы.
Эта простая требование звучит как само собой разумеющееся, но в нём много нюансов. Когда краулеры не уважают предпочтения сайта, это подрывает доверие. Когда сайты просят краулер не сканировать или замедлиться, а краулер игнорирует эти просьбы, это подрывает доверие.
Мы разработали систему для измерения того, насколько часто краулер уважает предпочтения сайтов. Эти наблюдения будут переводиться в объяснимую шкалу доверия: диапазон, показывающий, насколько последовательно бот соблюдает предпочтения сайтов и какие наблюдаемые поведения повлияли на эту оценку, а не в виде окончательного приговора боту или его оператору. Первичные сигналы, которые мы оцениваем, включают в себя следующее.
Мы считаем их «правилами здравого смысла», вежливостью по отношению к операторам, которые предоставляют информацию, которую боты ищут. В будущем мы будем публиковать эти оценки публично на Radar, а также расширять способы измерения. Эта оценка даёт ответственным операторам ботов способ продемонстрировать, что доверие поддерживается со временем. Проверяйте, но непрерывно перепроверяйте.
Файл robots.txt является основным способом сообщить предпочтения владельца сайта. Наша система учитывает, соответствует ли наблюдаемый трафик бота опубликованным предпочтениям сайта с течением времени.
Robots.txt указывает всем (или конкретным) ботам сканировать только определённые части веб-сайта. Изолированные нарушения и другие единичные случаи могут быть незначительными. Мы смотрим скорее на повторяющиеся паттерны поведения, которые игнорируют предпочтения сайта. Ожидание простое: ответственные боты должны проверять и соблюдать предпочтения, которые публикуют сайты, в соответствии с RFC 9309.
И чтобы было ясно: robots.txt задаёт минимальные правила того, чего боты и агенты не должны делать. Но это не означает, что всё, что не указано, разрешено. Например, robots.txt не обязан указывать, что бот должен остановиться, если сайт может сообщить о нежелательности дальнейшего доступа через другие сигналы.
Не навязывай другим того, чего не желаешь себе
Боты могут оставаться полностью в пределах разрешённых путей и при этом оказывать значительную нагрузку на посещаемые сайты. Один из самых явных способов, которым сайт может дать обратную связь — ответ HTTP 429 («Too Many Requests»). 429 — это директива для посетителя снизить скорость запросов, иногда с указанием, как долго стоит ждать перед следующей попыткой.
Наша система учитывает, адаптирует ли трафик бота своё поведение после получения этого сигнала. Замедляется ли он, делает ли паузу, или продолжает отправлять запросы с той же скоростью? Мы затем включаем это поведение в шкалу доверия бота со временем: последовательное замедление или пауза повышают доверие, тогда как многократное игнорирование сигнала понижает его.
Наблюдение за этими сигналами — лишь первый шаг к тому, чтобы сделать верифицированную автоматизацию ответственной со временем. Сопоставляя идентичность бота с доказательствами продолжающегося поведения, мы можем дать владельцам сайтов больше уверенности в том, что боты, которым они разрешают доступ, уважают их предпочтения, дать операторам ботов способ продемонстрировать, что им можно доверять, и обеспечить контекст владельцам сайтов относительно автоматизированного трафика, который к ним поступает.
Эта система вместе с Bot Preference Sync и Bot Management образует цикл ответственности для автоматизированного трафика. Bot Preference Sync помогает владельцам сайтов публиковать свои предпочтения, а наблюдение за тем, как боты взаимодействуют с этими предпочтениями, показывает, соблюдают ли Verified-боты их последовательно со временем. Bot Management позволяет владельцам сайтов решать, как обрабатывать этот трафик. Вместе они помогают гарантировать, что доверие зарабатывается прозрачным, подотчётным поведением, а не предполагается на основании только идентичности.
Мы уже используем эту систему внутри компании, чтобы оценивать, насколько последовательно Verified-боты соблюдают предпочтения сайтов. Поскольку доверие строится со временем, мы оцениваем устойчивые паттерны, а не изолированные события. Мы используем этот начальный этап для накопления истории и уточнения того, как эти наблюдения превращаются в полезные рекомендации. Опираясь на эту основу, мы планируем сделать систему доступной всем клиентам Cloudflare, которые смогут выбирать порог доверия, используемый для принятия решения о том, как обрабатывать трафик Verified-ботов. Наша цель проста: сохранить значимость предпочтений сайтов и гарантировать, что доверие зарабатывается путём последовательного поведения.
Хотите узнать больше о том, как управлять ботами? Клиенты Cloudflare уже могут использовать Bot Management для управления автоматизированным трафиком и Bot Preference Sync для согласования опубликованных предпочтений с настроенными политиками. Чтобы изучить постоянно растущую популяцию Verified-ботов, смотрите тренды на Radar.
Если вы заинтересованы в участии в создании будущего идентификации и подотчётности ботов, изучите открытые вакансии в Cloudflare.
Подпишитесь, чтобы получать уведомления о новых публикациях.