ИИ-краулеры — неоднородный трафик: как сайту определить границы доступа

Сайты хотят, чтобы их находили пользователи, но не хотят, чтобы их контент парсили без ограничений. Эти цели не противоречат друг другу; проблема в том, что когда все автоматические визиты называют «ИИ-краулерами», выбор часто сводится к полной открытости или полной блокировке.

Полезнее различать обращения по цели: предназначен ли конкретный визит для создания поискового индекса, обучения модели или выполнения задачи от имени пользователя. Разные цели означают разную отдачу, нагрузку и требуемые меры контроля. В статье на примере публичных изменений Cloudflare разбирается, как контентным сайтам и главным страницам продуктов проводить такую оценку. Факты проверены по состоянию на 2026-9-5; реальная конфигурация каких-либо сайтов не изменялась.

На момент проверки 2026-9-8 в анонсах и документации по настройке Cloudflare 9-15 по-прежнему значилось как дата будущего изменения настроек по умолчанию. В статье сохранены временные рамки и контекст исходной публикации; вступят ли изменения в силу по плану, когда указанные даты наступят, нужно проверять по официальной документации, и заранее утверждать это здесь нельзя.

От переключателя «ИИ» к цели доступа

В анонсе от 2026-7 Cloudflare дополнительно делит связанный с ИИ трафик на категории Search, Agent и Training. Search служит для сбора или индексации контента для последующих запросов; Agent выполняет текущие задачи от имени пользователей; Training используется для обучения или дообучения моделей. Это продуктовая классификация Cloudflare, а не общепринятый стандарт для всего интернета.

На это разделение стоит обратить внимание, потому что один и тот же публичный документ может играть несколько ролей: поисковая система читает его, чтобы потом помочь другим найти ответ; ассистент читает его прямо сейчас, потому что пользователь отлаживает API; а сбор для обучения может вообще не быть связан с запросом какого-либо текущего посетителя.

Для страниц продукта визиты второго типа не бесполезны сами по себе. Если разработчик спрашивает ассистента, что означает параметр, то от того, получит ли ассистент документацию для нужной версии, зависит, сможет ли пользователь продолжить интеграцию. Эта ценность не обязательно сразу проявляется в виде клика в браузере.

Однако это не значит, что доступ нужно давать всем агентам. Соответствует ли визит разрешённым сценариям использования, требует ли он аутентификации, создаёт ли аномальную нагрузку — всё это по-прежнему нужно оценивать отдельно. Считать весь трафик с «ИИ» в названии возможностью привлечь клиентов так же грубо, как и считать весь такой трафик бесполезным.

График 9-15 нельзя считать действующим для всех сайтов

В документации Cloudflare по настройке указано, что 2026-9-15 планируется изменить ряд настроек по умолчанию: для новых подключённых доменов трафик обучения и агентов будет по умолчанию блокироваться, а поисковый сохраняться; кроме того, обновится то, как политики блокировки обучения применяются к краулерам двойного назначения, которые занимаются и поиском, и обучением.

У этого утверждения есть несколько обязательных оговорок: плановая дата, новые подключённые домены, применимые страницы и правила для визитов смешанного назначения. На момент проверки дата всё ещё 9-5, и пересказывать это как «Cloudflare заблокировал доступ ИИ для всех сайтов» нельзя. Итоговое поведение сайта зависит от его фактических настроек и последующих обновлений продукта.

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

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

Robots.txt, предпочтения в отношении использования и реальная блокировка работают на разных уровнях

RFC 9309 прямо говорит, что правила исключения для роботов — не механизм авторизации доступа. Они подсказывают добросовестным краулерам, как обращаться к сайту, но не заменяют учётные данные для входа, проверку прав и контроль доступа на стороне сервера.

Это значит, что документы, которые должны оставаться конфиденциальными, нельзя скрывать только с помощью robots.txt. И наоборот: пояснения, предназначенные для публики, могут блокироваться другими сетевыми или прикладными правилами, даже если robots.txt разрешает сканирование. Чтобы определить доступность, нужно проверять реальные ответы, а не полагаться на один файл.

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

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

Если страницу прочитали, это ещё не значит, что её процитируют

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

Поэтому запрос краулера в журналах сервера говорит лишь о том, что обращение состоялось. Он не доказывает, что страница попала в поисковый индекс, и тем более что контент использовали в конкретном ответе ИИ. Упоминание бренда в ответе не обязательно означает, что эта страница есть в списке источников.

Для контент-команд это различие меняет повседневную оценку. Когда статья только опубликована, команда может сначала проверить публичную доступность, ссылки и корректность контента, а затем отслеживать индексацию и показ в поисковых системах. Если с самого начала принимать работу только по критерию «процитировал ли её ИИ», можно преждевременно признать неудачу или принять случайные упоминания за долгосрочный рост.

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

Решайте по назначению страницы, а не по отношению к ИИ

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

Для каждой категории страниц можно задать четыре конкретных вопроса:

1. Кто и в каком контексте должен это читать: потенциальные пользователи, которые знакомятся с продуктом, или текущие пользователи, которые решают проблему?
2. Может ли автоматический доступ помочь выполнить эту задачу и какие наблюдаемые данные это подтверждают?
3. Какие сценарии доступа выходят за ожидаемые рамки и нужны ли для них указание предпочтений, управление трафиком или строгая аутентификация?
4. Если политики изменятся, как убедиться, что целевые пользователи не пострадали и что исходные настройки можно восстановить?

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

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

Как оценить отдачу и не помешать обычному использованию

После изменения политик отслеживайте метрики в одинаковых окнах наблюдения: объём автоматического трафика и долю ошибок в нём, доступность ключевых страниц, показы и клики в поиске, проверяемые ссылки на источники и действия пользователей, ведущие к работе с документацией или завершению интеграции. Не сводите эти цифры в расплывчатую метрику «ИИ-трафика».

Часть отдачи может пока не поддаваться атрибуции. Например, если пользователь узнал о продукте через ассистента, а потом зашёл на главную страницу напрямую, обычное отслеживание источников может не увидеть весь путь. Правильно оставить эту неизвестную часть как есть, а не подставлять оценочные цифры, чтобы доказать эффективность политики.

Управление ИИ-доступом становится всё детальнее, и управление сайтом должно идти следом. Сначала определите, какой контент кому предназначен, затем проверьте цели доступа, фактические правила и результаты использования. Для главных страниц, которые должны находить пользователи, цель — не максимальное число записей от автоматических ботов в журналах; для защищённого контента — не блокировка всех автоматических запросов. Задача в том, чтобы дать нужным людям и инструментам надёжную информацию, достаточную для выполнения их задач в разрешённых рамках.