Правила для AI-ботов: разрешать, ограничивать или блокировать

AI-боты быстро стали отдельным классом трафика. Раньше владельцу сайта обычно хватало простого выбора: пускать поисковые краулеры или закрывать их через robots.txt, rate limit и правила firewall. Теперь картина сложнее. Одни роботы индексируют страницы для поиска, другие выполняют действия от имени пользователя, третьи собирают данные для обучения моделей. Для backend- и homelab-проектов это уже не абстрактная тема: даже небольшой сайт с документацией, блогом или публичным API может внезапно получить нагрузку от сканеров, которые не приносят понятной пользы.

Полный запрет выглядит привлекательным, но редко оказывается лучшим решением. Поисковая видимость может быть полезна, ассистенты могут приводить аудиторию, а часть автоматизированных клиентов действительно работает в интересах пользователя. Более практичный подход — разделять AI-трафик по назначению и задавать разные правила для поиска, агентных сценариев и обучения.

Почему одного robots.txt уже недостаточно

robots.txt остается важным сигналом, но это не механизм безопасности. Добросовестные краулеры учитывают его, недобросовестные — игнорируют. Кроме того, файл плохо описывает современные сценарии. В нем можно закрыть путь /private/ или запретить конкретного user-agent, но сложнее выразить политику уровня «страницы документации можно использовать для ответа пользователю, а массовое скачивание для обучения — нельзя».

Есть и техническая проблема: user-agent легко подделать. Если правило основано только на строке заголовка, злоумышленник или агрессивный скрапер может представиться обычным браузером. Поэтому управление AI-трафиком постепенно смещается к комбинации сигналов: проверка известных ботов, анализ поведения, ограничение частоты запросов, защита дорогих страниц и явные политики доступа.

Для небольшого проекта это не значит, что нужно срочно строить сложную антибот-платформу. Но стоит перестать воспринимать всех автоматических клиентов одинаково. Разница между индексирующим поисковиком и ботом, который скачивает весь сайт с высокой параллельностью, принципиальна.

Три типа AI-трафика

Первый тип — поисковые и ответные системы. Их задача похожа на классическую индексацию: найти страницу, понять ее содержимое и показать ссылку или краткий ответ пользователю. Такой трафик может быть полезен для публичных материалов: документации, статей, changelog, описаний open source-проектов. Для него разумно оставлять доступ, но контролировать частоту обхода и закрывать технические разделы.

Второй тип — агентные боты. Они действуют не просто как индексатор, а как исполнитель задачи: открыть страницу, заполнить форму, сравнить цены, проверить статус, скачать файл. Здесь риски выше. Агент может создавать нагрузку, обходить UI не так, как ожидал разработчик, или случайно выполнять действия, которые для человека были бы осознанными. Для таких клиентов особенно важны rate limits, CSRF-защита, проверка авторизации и отдельные правила для write-операций.

Третий тип — обучающие краулеры. Их цель — собрать данные для датасетов или дообучения моделей. Польза для владельца сайта не всегда очевидна, а нагрузка может быть значительной. Для коммерческих страниц, закрытых баз знаний, форумов и материалов с лицензиями обычно логично вводить более жесткие ограничения: запрет в политике, блокировку известных краулеров, лимиты на массовое скачивание и мониторинг аномалий.

Что можно сделать на своем сайте

Начать стоит с инвентаризации публичных зон. У большинства сайтов есть страницы, которые можно спокойно показывать всем: главная, блог, документация, публичные релизы. Есть зоны, которые нежелательно сканировать: поиск по сайту, страницы фильтров, корзина, личный кабинет, временные preview-ссылки, endpoints с дорогими SQL-запросами. Даже простое разделение этих путей уже снижает риск.

Дальше полезно обновить robots.txt. Он не защитит от всех, но задаст понятные правила для добросовестных клиентов. Например, можно закрыть внутренний поиск и параметры сортировки, разрешив основные статьи и документацию. Если проект публикует данные с ограничениями по лицензии, стоит явно описать политику использования контента: что разрешено для индексации, а что запрещено для обучения моделей.

На уровне reverse proxy или CDN стоит добавить rate limiting. Для homelab-сайта на Nginx это может быть несколько зон лимитов: мягкая для обычных страниц, более строгая для поиска и API, отдельная для подозрительных user-agent. Важно не ставить слишком агрессивные значения сразу: сначала лучше собрать access logs и понять нормальный профиль трафика.

Защита страниц с монетизацией и дорогими операциями

Отдельного внимания заслуживают страницы, где автоматический просмотр напрямую влияет на экономику или инфраструктурную стоимость. Это могут быть рекламные страницы, платные материалы, каталоги с большим количеством фильтров, генерация PDF, предпросмотр изображений, поиск по большой базе. AI-краулер может не кликать рекламу, но создавать показы и нагрузку; агент может массово дергать endpoint, который для человека используется редко.

Для таких мест лучше применять более строгую модель: кэширование, лимиты на IP и сессию, защита от перебора параметров, требование авторизации для тяжелых функций. Если endpoint действительно дорогой, его нельзя оставлять доступным только потому, что ссылка не видна в интерфейсе. Боты хорошо находят URL через sitemap, HTML, JavaScript и старые ссылки.

В backend-коде стоит проверять не только факт авторизации, но и намерение пользователя. Write-операции должны требовать токены, подтверждения и идемпотентность. Если агент случайно повторит запрос, система не должна создавать десять одинаковых заявок или запускать десять тяжелых задач.

Наблюдаемость важнее идеального списка ботов

Списки известных AI-краулеров полезны, но они всегда будут неполными. Новые боты появляются быстрее, чем обновляются правила. Поэтому хорошая стратегия строится вокруг наблюдаемости. В логах стоит отслеживать user-agent, ASN, частоту запросов, глубину обхода, долю ошибок, количество уникальных URL за сессию и обращение к дорогим маршрутам.

Для небольшого проекта достаточно регулярного анализа access logs. Например, можно раз в день строить топ user-agent по количеству запросов, топ IP по уникальным URL и список маршрутов с необычным ростом. Если сайт обслуживается через CDN, часть такой аналитики уже доступна в панели. Для self-hosted окружения подойдут GoAccess, Grafana Loki, ClickHouse или обычные скрипты поверх Nginx-логов.

Хороший сигнал — резкий рост обхода старых страниц, параметризованных URL или sitemap. Еще один тревожный признак — высокая параллельность запросов без загрузки статических ресурсов. Обычный браузер обычно берет HTML, CSS, JS и изображения, а краулер может качать только HTML или API-ответы.

Практический минимум политики

Базовая политика может быть простой. Публичные статьи и документация доступны для поисковой индексации. Внутренний поиск, личные страницы, preview, админка и тяжелые API закрыты для краулеров и дополнительно защищены техническими лимитами. Агентные действия, связанные с изменением состояния, требуют авторизации, CSRF-защиты и понятных подтверждений. Массовое скачивание ограничивается по частоте и объему.

Такой подход не решает все юридические и этические вопросы вокруг обучения моделей, но дает инженерный контроль. Владелец сайта перестает выбирать между «пустить всех» и «запретить всех» и начинает управлять трафиком как набором разных сценариев с разной ценностью и разным риском.

Главный вывод: AI-трафик стоит проектировать так же, как любой другой внешний доступ. Нужны правила, лимиты, наблюдаемость и безопасные defaults. Тогда сайт остается видимым для полезных клиентов, но не превращается в бесплатный и неограниченный источник данных или нагрузки для всех автоматических систем подряд.