Контроль AI-краулеров становится частью SEO: что изменил Cloudflare и как владельцам сайтов защитить свой контент

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

Раньше отношения между владельцами сайтов и поисковыми системами были достаточно простыми: поисковый робот сканировал страницы, добавлял их в индекс, а затем поисковая система возвращала на сайт посетителей.

Сайт отдавал контент — поисковик отдавал трафик.

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

Редакция Sitezilla ознакомилась с материалом Cloudflare «Your site, your rules: new AI traffic options for all customers», опубликованным 1 июля 2026 года. В нем компания предлагает перейти от примитивного разделения «AI-бот или не AI-бот» к более точному контролю, основанному на том, что именно автоматизированная система делает с контентом сайта.

Разбираемся, что именно изменилось, почему управление AI-краулерами постепенно становится частью SEO и какую политику доступа к контенту стоит использовать владельцам интернет-магазинов, корпоративных сайтов и контентных проектов.

Старый обмен «контент в обмен на трафик» больше не работает как прежде

На протяжении десятилетий владельцы сайтов фактически соглашались на неформальный обмен:

1. поисковый робот получает доступ к страницам;

2. поисковая система индексирует информацию;

3. пользователь видит страницу в результатах поиска;

4. сайт получает переход, показ рекламы, заявку или продажу.

Именно на этой модели построены классическое SEO, контент-маркетинг, информационные порталы, партнерские сайты и большая часть электронной коммерции.

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

По наблюдениям Cloudflare, которые компания приводила во время первого Content Independence Day, соотношение сканирований к полученным переходам для крупных AI-операторов могло составлять от примерно 118 сканирований на один переход до почти 50 000 сканирований на один переход. Это означает, что сервер может десятки тысяч раз отдать контент автоматизированной системе, прежде чем сайт получит хотя бы одного посетителя.

Для владельца сайта это создает сразу несколько проблем:

• AI-бот расходует серверные ресурсы и пропускную способность;

• контент может стать основой для готового ответа стороннего сервиса;

• пользователь получает ответ, не открывая первоисточник;

• сайт не получает просмотра, рекламы, лида или продажи;

• автору сложно определить, кто именно использовал его материалы и зачем.

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

Не каждый AI-бот выполняет одинаковую работу

Один из главных тезисов нового подхода Cloudflare — отказ от попыток называть весь автоматизированный AI-трафик одним словом.

Понятие «AI-бот» стало слишком широким.

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

Последствия для владельца сайта в каждом случае разные.

Cloudflare предлагает оценивать автоматизированный трафик по трем вопросам:

• что бот делает на сайте;

• какую информацию он сохраняет;

• как он может повторно использовать или показать контент.

Для практического управления Cloudflare выделяет три основных класса: Search, Agent и Training.

Search: сканирование для поиска и ответов

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

По логике Cloudflare, владелец сайта, разрешающий такое сканирование, должен ожидать как минимум одну из двух форм ценности:

• переходы на сайт;

• иную справедливую форму компенсации.

Для интернет-магазина доступ поисковых систем к товарам, категориям, брендам и полезным статьям остается важным. Полное блокирование всех систем, использующих AI, может снизить видимость магазина в новом поколении поиска.

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

Agent: действия от имени конкретного пользователя

Категория Agent охватывает автоматизированные системы, которые открывают сайт в реальном времени для выполнения конкретной задачи пользователя.

Например, AI-агент может:

• прочитать страницу, ссылку на которую отправил пользователь;

• найти характеристики товара;

• проверить наличие;

• сравнить несколько моделей;

• заполнить форму;

• добавить товар в корзину;

• помочь оформить заказ.

В этом случае за действиями бота обычно стоит реальный человек, который ожидает результат.

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

Для e-commerce это потенциально полезный вид трафика. В будущем AI-агенты могут стать новым каналом продаж: не только рекомендовать товар, но и проходить часть пути покупателя.

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

Training: использование контента для обучения моделей

Категория Training — это сканирование, при котором информация собирается для обучения или дообучения AI-модели.

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

Такой доступ не обязательно приносит сайту:

• переходы;

• упоминания бренда;

• ссылки на источник;

• заявки;

• прямой доход.

Именно поэтому многие издатели и владельцы уникальных баз данных наиболее осторожно относятся к Training-краулерам.

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

Главное изменение Cloudflare: отдельные правила вместо глобальной блокировки

Раньше Cloudflare предлагал функцию Block AI Bots, которая позволяла одним переключателем блокировать роботов, связанных со сбором данных для обучения моделей.

Однако универсальная блокировка оказалась недостаточно гибкой.

Поэтому Cloudflare внедрил отдельное управление тремя сценариями:

Для каждого типа поведения Cloudflare позволяет выбрать одну из базовых политик:

• блокировать на всем сайте;

• блокировать только на страницах с рекламой;

• не блокировать.

Новые настройки доступны через раздел управления политиками AI-ботов в Cloudflare Security Settings, в том числе и для клиентов бесплатного тарифа.

Что изменится 15 сентября 2026 года

Cloudflare объявил, что 15 сентября 2026 года изменит стандартные настройки для новых доменов, подключающихся к платформе.

На страницах, где Cloudflare определит наличие рекламы:

• Training-боты будут блокироваться по умолчанию;

• Agent-боты будут блокироваться по умолчанию;

• Search-краулеры будут оставаться разрешенными.

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

При этом Search остается разрешенным, поскольку именно поисковая функция чаще всего связана с потенциальным возвращением аудитории на сайт.

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

Cloudflare планирует применять к таким роботам наиболее ограничительное из установленных правил. Например, если владелец разрешил Search, но заблокировал Training, смешанный краулер с двумя назначениями может быть заблокирован.

В материале Cloudflare среди примеров многоцелевых систем названы Googlebot, Applebot и Bingbot. Поэтому перед включением жесткой блокировки Training необходимо проверить, не повлияет ли правило на обычную поисковую индексацию.

Разрешить доступ — еще не значит разрешить делать с контентом всё

Cloudflare также развивает концепцию content use — уровня допустимого использования контента после его сканирования.

Предложено три уровня:

Immediate

Система может взаимодействовать со страницей в текущий момент, но не должна сохранять или повторно использовать полученный контент.

Такой режим может подходить для агента, выполняющего разовую задачу пользователя.

Reference

Система может индексировать информацию, показывать короткие отрывки и ссылаться на первоисточник.

Cloudflare рассматривает этот уровень как стандартный вариант.

Full

Система может создавать развернутые пересказы и воспроизводить информацию значительно шире.

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

Таким образом, будущая политика доступа может выглядеть не просто как «разрешить AI-поиск», а, например:

Разрешить поисковым AI-системам индексировать страницы, цитировать короткие фрагменты и обязательно ссылаться на источник, но не разрешать полное воспроизведение материалов.

Это значительно точнее, чем обычное разрешение или блокировка User-Agent.

Новые сигналы в robots.txt

Cloudflare тестирует расширение Content Signals, которое позволяет указывать пожелания владельца сайта непосредственно в файле robots.txt.

Пример такой политики:

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

Эта запись означает:

• сканирование для поиска разрешено;

• использование для обучения AI нежелательно;

• контент разрешено использовать на уровне ссылки, индексации и короткого цитирования.

При этом Cloudflare прямо отмечает, что Content Signals в robots.txt выражают пожелания владельца, но сами по себе не являются технической блокировкой. Для реального запрета нужно применять правила безопасности, Bot Management, WAF или другие серверные механизмы.

Это принципиально важно.

robots.txt — это декларация правил для добросовестных роботов. Вредоносный или неправильно идентифицированный сканер может ее проигнорировать.

Что такое Pay Per Crawl

Cloudflare предлагает третий вариант между бесплатным доступом и полной блокировкой — Pay Per Crawl.

Модель позволяет владельцу сайта установить плату за успешное получение страницы AI-краулером.

Базовая схема работает так:

1. краулер запрашивает защищенный материал;

2. Cloudflare сообщает, что доступ платный;

3. сервер возвращает статус HTTP 402 Payment Required и указывает цену;

4. краулер может согласиться с условиями;

5. после подтверждения он получает страницу;

6. событие фиксируется для последующих расчетов.

Cloudflare выступает технической платформой и Merchant of Record — стороной, обрабатывающей коммерческую часть сделки между владельцем контента и оператором краулера.

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

• Allow — предоставить бесплатный доступ;

• Charge — требовать оплату;

• Block — полностью запретить доступ.

В документации Cloudflare за 2026 год описано установление цены для домена, дополнительные правила ценообразования и мониторинг платных запросов. Минимальная базовая цена, указанная Cloudflare, составляет 0,01 доллара США за одно успешное сканирование. Доступность функции и конкретных настроек нужно проверять в учетной записи Cloudflare.

Pay Per Crawl вряд ли сразу станет значительным источником дохода для обычного интернет-магазина. Тем не менее, само появление такого механизма важно: доступ автоматизированной системы к контенту впервые рассматривается как отдельная экономическая операция, а не как безусловное право любого робота.

Почему полное блокирование всех AI-ботов может быть ошибкой

На первый взгляд самым простым решением кажется полный запрет AI-трафика.

Однако для большинства коммерческих сайтов такая политика может быть слишком агрессивной.

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

Для малого бизнеса существует двойной риск:

• открыть всё и разрешить неограниченное использование контента;

• закрыть всё и потерять видимость в новых каналах поиска.

Сам Cloudflare признает, что универсальное блокирование подходит не всем. Именно поэтому компания переходит к отдельному управлению Search, Agent и Training вместо политики «блокировать всю автоматизацию».

По мнению Sitezilla, правильное решение — не глобальный запрет, а политика доступа по типам страниц и поведению краулера.

Рекомендованная политика Sitezilla для интернет-магазинов

Ниже представлена практическая модель, которую можно использовать в качестве основы для e-commerce проекта.

Это не универсальная официальная рекомендация Cloudflare, а практическая интерпретация новых инструментов от Sitezilla.

Товарные страницы и категории

Такие страницы должны оставаться доступными для Search-краулеров. Именно они помогают AI-поиску понять:

• что продает магазин;

• какие характеристики имеет товар;

• какова актуальная цена;

• есть ли товар в наличии;

• какие способы доставки и оплаты доступны;

• чем один товар отличается от другого.

Для этих страниц особенно важны структурированные данные, корректная разметка Product, Offer, BreadcrumbList, Brand и актуальные цены.

Блоговые статьи

Блог стоит открывать для поиска, но не обязательно разрешать неограниченное использование для обучения моделей.

Для типичных SEO-статей можно применить политику use=reference: индексация и короткое цитирование разрешены при условии ссылки на источник.

Для уникальных исследований, авторских баз данных, сравнений, инструкций и дорогого экспертного контента можно рассматривать блокировку Training или платный доступ.

Фильтры и внутренний поиск

AI-бот не должен бесконтрольно генерировать тысячи комбинаций параметров.

Например:

/category?color=red&size=42&sort=price&page=17

Массовое сканирование таких URL:

• создает дубликаты;

• тратит серверные ресурсы;

• засоряет аналитику;

• увеличивает нагрузку на базу данных;

• не обязательно создает полезную поисковую ценность.

Для фильтров необходимы canonical, правила индексации, ограничения параметров и контроль частоты запросов.

Административные и персональные разделы

Административная панель, личный кабинет, история заказов, служебные API и внутренние маршруты должны быть закрыты не только от AI-ботов, но и от всех неавторизованных автоматизированных систем.

Здесь недостаточно robots.txt. Нужны:

• авторизация;

• правила WAF;

• ограничение частоты запросов;

• проверка сессий;

• защита API;

• блокировка подозрительной автоматизации.

AI-краулеры нужно не только блокировать, но и анализировать

Одной настройки Cloudflare недостаточно.

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

Cloudflare развивает для этого BotBase и Attribution Business Insights. BotBase классифицирует известных роботов по поведению, а Attribution Business Insights показывает объем бот-трафика, использованную пропускную способность, соотношение сканирований к переходам и текущее действие — разрешение или блокировку.

По мнению Sitezilla, подобный отчет стоит иметь и в собственной системе веб-аналитики.

Что должен показывать отчет «AI-краулеры»

Для каждого робота желательно собирать:

• название или определенного оператора;

• User-Agent;

• подтвержденный или неподтвержденный статус;

• IP-адреса и страны;

• количество запросов;

• количество уникальных URL;

• объем переданных данных;

• среднее время ответа;

• коды 200, 301, 404, 403, 429 и 500;

• страницы с наибольшим количеством обращений;

• частоту повторного сканирования;

• полученные переходы от соответствующего AI-сервиса;

• соотношение сканирований к переходам;

• созданные заявки или заказы;

• приблизительную стоимость серверной нагрузки.

Отдельно стоит отслеживать известных операторов поисковых систем, AI-платформ и агентов, не полагаясь только на текст User-Agent. Его можно подделать, поэтому для важных решений необходимо использовать подтверждение IP, DNS, Web Bot Auth или классификацию Cloudflare.

Как оценивать пользу конкретного краулера

Предположим, что за месяц определенный робот:

• выполнил 100 000 запросов;

• загрузил 20 ГБ данных;

• регулярно обращался к тяжелым страницам фильтров;

• создал дополнительную нагрузку на MySQL;

• привел двух посетителей;

• не создал ни одного заказа.

Такой доступ вряд ли выгоден магазину.

Другой оператор может:

• выполнить 2 000 запросов;

• сканировать только основные товарные страницы;

• привести 200 пользователей;

• создать несколько ассоциированных конверсий.

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

Поэтому решение нужно принимать не по названию компании и не по общему ярлыку «AI», а по реальному поведению.

Пошаговый план внедрения политики AI-краулеров

Шаг 1. Провести аудит автоматизированного трафика

Нужно проанализировать серверные логи и определить:

• какие роботы посещают сайт;

• какие URL они сканируют;

• как часто возвращаются;

• какие создают ошибки;

• какие потребляют больше всего ресурсов.

Желательно анализировать период не менее 30 дней.

Шаг 2. Разделить URL по назначению

Все маршруты нужно сгруппировать:

• публичный коммерческий контент;

• информационный контент;

• уникальные авторские материалы;

• страницы взаимодействия;

• персональные страницы;

• служебные маршруты;

• API;

• параметрические и технические URL.

Шаг 3. Определить ценность каждой группы

Для каждого типа страниц нужно ответить на вопросы:

• нужна ли видимость в поиске;

• может ли AI-агент привести клиента;

• разрешаем ли использование для обучения;

• содержит ли страница уникальные коммерческие данные;

• создает ли сканирование существенную нагрузку;

• можно ли монетизировать доступ.

Шаг 4. Настроить отдельные политики

Не стоит использовать одно глобальное действие для всего домена.

Возможная базовая конфигурация:

• Search — разрешить на публичных страницах;

• Agent — разрешить проверенным системам с rate limiting;

• Training — блокировать или разрешать выборочно;

• внутренние страницы — блокировать для всех автоматизированных систем;

• дорогие авторские материалы — лицензировать или монетизировать.

Шаг 5. Настроить robots.txt и Content Signals

Файл robots.txt должен отражать общую политику сайта, но не быть единственным механизмом защиты.

Для реального контроля его нужно дополнять правилами Cloudflare, WAF, серверными ограничениями и проверкой ботов.

Шаг 6. Отслеживать переходы из AI-сервисов

В системе аналитики стоит отдельно группировать переходы от:

• AI-поиска;

• чат-ботов;

• браузерных ассистентов;

• обычных поисковых систем;

• неопределенных рефереров.

Постепенно это позволит определить, какие AI-платформы реально приводят пользователей.

Шаг 7. Пересматривать политику ежемесячно

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

Поэтому правила не стоит настраивать один раз и навсегда.

SEO превращается в SEO, AEO и GEO одновременно

Классическое SEO оптимизирует сайт для страницы поисковой выдачи.

AEO, или Answer Engine Optimization, помогает контенту попадать в готовые ответы.

GEO, или Generative Engine Optimization, сосредоточено на том, чтобы генеративные системы правильно понимали бренд, товары, факты и первоисточник.

Cloudflare прямо обращает внимание на переход от обычной SEO-среды к миру AEO и GEO, где важно анализировать не только позиции и органический трафик, но и поведение AI-краулеров.

Для владельца сайта это означает появление нового направления работы:

• контролировать доступ к контенту;

• оставаться видимым для полезных AI-систем;

• защищать уникальные материалы;

• измерять AI-переходы;

• формировать машиночитаемую структуру сайта;

• проверять правильность информации о бренде;

• не позволять автоматизации создавать лишнюю нагрузку.

Контроль AI-ботов становится не только задачей системного администратора или специалиста по безопасности. Это уже вопрос SEO, маркетинга, контентной стратегии и экономики сайта.

Позиция Sitezilla

Sitezilla не рекомендует большинству коммерческих сайтов включать глобальную блокировку всех AI-ботов без предварительного анализа.

Полная открытость также не является оптимальным решением.

Рациональная политика должна быть выборочной:

• публичные товары и категории — доступны для Search;

• проверенные агенты, действующие в интересах покупателя, — разрешены с ограничениями;

• обучение моделей — только при осознанном согласии владельца;

• уникальный дорогой контент — защищен, лицензирован или монетизирован;

• фильтры, поиск и технические URL — ограничены;

• корзина, личный кабинет, API и административные маршруты — закрыты;

• вся активность роботов — отдельно логируется и анализируется.

Основной принцип можно сформулировать просто:

Не нужно блокировать весь AI. Нужно понимать, кто пришел на сайт, что он делает, какую ценность получает и что возвращает владельцу контента.

Заключение

Cloudflare фактически предлагает новую модель отношений между сайтами и автоматизированными системами.

Вместо безусловного доступа или полного запрета владелец должен иметь возможность:

• разрешать полезное поисковое сканирование;

• обслуживать агентов реальных пользователей;

• блокировать обучение моделей;

• ограничивать способ повторного использования материалов;

• требовать оплату за доступ;

• видеть реальную статистику сканирований и переходов.

Для владельцев сайтов это означает, что файл robots.txt, SEO и защита от ботов больше не могут рассматриваться отдельно.

В ближайшие годы конкурентное преимущество будут иметь не те сайты, которые просто открыли или закрыли доступ для AI, а те, которые создали управляемую систему:

разрешать полезное, блокировать вредное, измерять результат и устанавливать собственные правила использования контента.

Именно это и есть главная идея Content Independence Day: ваш сайт, ваш контент — и ваши условия доступа.