Анонс Cloudflare от июля 2026 года легко принять за очередной спор «издатели против скрейперов». На самом деле он важнее. Cloudflare пытается превратить автоматический доступ к вебу в слой правил по назначению: одни правила для поисковой индексации, другие для агентов, действующих от имени пользователя, и третьи для обучения моделей.

Сетевой edge-шлюз сортирует трафик поисковых, агентных и обучающих ботов через правила доступа

Это важно, потому что старая сделка веба ломается. Десятилетиями crawler читал страницу, потому что поисковик приводил людей обратно. Сайт получал discoverability, переходы, рекламу, подписки или узнаваемость. AI answer engines и браузерные агенты делают обмен менее очевидным: система может прочитать страницу, вытащить ответ, выполнить задачу или заземлить ответ модели, а человек так и не зайдёт на источник.

Ответ Cloudflare — не просто «заблокировать AI». В посте от 1 июля компания делит AI-centered use cases на Search, Agent и Training. Search собирает или индексирует контент, чтобы потом отвечать на вопросы. Agent действует, часто в реальном времени, от имени пользователя. Training забирает контент для обучения или fine-tuning модели. С 15 сентября 2026 года Cloudflare обещает новые defaults: для новых клиентов и новых сайтов Search останется разрешённым, а Training и Agent будут блокироваться на страницах с рекламой. В пресс-релизе также сказано, что existing free customers, которые не поменяют настройки к этой дате, перейдут на такие defaults. Настройки можно менять.

Практический вывод: теперь недостаточно спросить, кто этот бот. Нужно спрашивать, зачем он пришёл.

Старая сделка: crawler читает, поиск возвращает трафик

Публичный веб вырос на грубом компромиссе. Сайты публикуют страницы. Crawlers индексируют. Поисковики ранжируют. Пользователи кликают. Система была далека от идеала, но стимулы были понятны. Издатель мог спорить о сниппетах, SEO-манипуляциях и scraping, но понимал, зачем нужна индексация.

AI search и agentic browsing усложняют этот контракт. Обычный поисковый результат — дверь. AI answer может стать конечной точкой. Browser agent может прочитать несколько страниц, сравнить цены, пересказать документацию, заполнить форму или извлечь факт без визита человека на каждый источник. Пользователю это удобно. Сайту это может убрать экономический сигнал, который финансировал страницу.

Исследование Pew Research Center по Google в 2025 году показывает, почему издатели нервничают. В американской панели Pew пользователи кликали по обычному результату в 8% визитов, когда появлялся AI summary, и в 15% визитов, когда summary не было. По ссылкам внутри AI summary кликали только в 1% визитов. Это не универсальный закон для всех стран и поисковиков, но цифры хорошо объясняют конфликт: ответы могут уменьшать исходящее внимание.

Cloudflare находится почти в точке приложения силы. Компания говорит, что за её сетью находится более 20% веба. Это не значит, что Cloudflare «контролирует интернет», но значит, что множество запросов проходит через edge-слой, где политику можно применить до origin-сервера.

Search, Agent, Training: зачем нужны три корзины

Search проще всего защищать. Crawler индексирует контент и в лучшем случае даёт discoverability. Cloudflare пишет, что Search должен либо возвращать referral traffic, либо поддерживать equitable compensation. Это оставляет место для обычного поиска, AI search и платных моделей, но отделяет индексирование от обучения модели.

Agent — самая сложная категория. Cloudflare описывает такой трафик как автоматизацию, которая действует от имени человека, часто в реальном времени. Это могут быть chat fetch bots и browser-use agents, например система, управляющая Chrome для выполнения задачи. Здесь будущий веб становится запутанным. Если пользователь просит агента забронировать перелёт, сравнить цены SaaS или прочитать support page, запрос действительно исходит из намерения пользователя. Но для сайта это всё равно может выглядеть как бот, который потребляет страницу без нормального ad impression, analytics session или покупки.

Training — категория, которую издатели понятнее всего хотят контролировать. Это не разовый ответ и не задача конкретного пользователя. Это сбор контента для улучшения модели. Cloudflare описывает это как permanent absorption в архитектуру модели. Можно спорить о философии, но операционно разница важна: многие владельцы сайтов готовы быть в поиске, но не хотят бесплатно отдавать архивы на обучение.

Таксономия также давит на AI-компании: разделяйте crawler’ы по назначению. Cloudflare прямо говорит о mixed-purpose crawlers и обещает применять наиболее ограничительное правило. Если один crawler используется и для search, и для training, владелец сайта, блокирующий Training, может заблокировать всё. Поэтому история важна для infrastructure teams: user-agent, который раньше означал «крупная поисковая платформа», теперь слишком расплывчат.

Сентябрьский default уже заголовка, но всё равно важен

Самая сильная формулировка была бы неверной: Cloudflare не говорит, что заблокирует всех AI-ботов на всех сайтах. Default привязан к pages that display ads. Search по умолчанию разрешён. Клиенты могут менять настройки. Дата 15 сентября относится к новым клиентам, новым сайтам существующих клиентов и existing free customers, которые не изменят настройки, согласно пресс-релизу Cloudflare и материалам TechCrunch и Engadget.

Эта точность важна. Cloudflare использует рекламу как сигнал, что страница рассчитана на монетизацию человеческого внимания. Если AI agent прочитал страницу и ответил пользователю где-то ещё, сайт мог потерять этот момент монетизации. Блокировка Agent и Training на рекламных страницах — попытка защитить экономический intent и при этом оставить Search.

Нерешённый вопрос — технический: как именно Cloudflare определяет, что страница показывает рекламу? Публичные материалы описывают политику, но не дают полной спецификации ad detection, override signals и false positives. Это важно: монетизация бывает через display ads, affiliate-блоки, спонсорство, paywall, продуктовые страницы, документацию и бренд. Реклама — полезный сигнал, но не вся экономика веба.

Для команд на Cloudflare первая задача не идеологическая, а операционная: проверить dashboard до сентября, особенно на free plan, и понять, подходит ли default бизнесу. Documentation site, marketing site и news site могут требовать разных правил.

Pay Per Crawl был первой пробой; Pay Per Use интереснее

Cloudflare Pay Per Crawl 2025 года был грубым, но важным экспериментом. Владелец сайта мог разрешить crawler, заблокировать его или потребовать оплату. Если нужна оплата, crawler получал HTTP 402 Payment Required и price header, затем мог повторить запрос с willingness to pay. Cloudflare выступал Merchant of Record. Модель использовала Web Bot Auth, чтобы crawler доказывал identity подписанными запросами, а не просто писал красивый user-agent.

HTTP 402 здесь почти символичен. Статус Payment Required давно зарезервирован, но браузеры не имеют стандартного пользовательского 402 payment flow. MDN отмечает, что браузеры обычно показывают его как обычную 4xx ошибку. Cloudflare не создаёт browser paywall. Он тестирует machine-to-machine negotiation для crawler’ов.

Но цена за crawl — грубый proxy. Запрос страницы, которая не попала в ответ пользователю, не равен фрагменту, ставшему главным источником для дорогого запроса. Поэтому июльский пост “Making AI search smarter” двигает идею к Pay Per Use. Публично названы Ceramic.ai и You.com. Ceramic описан как pay-per-query model: publisher получает оплату, когда его content appears in AI search results, и видит отчёты по queries, snippets и ranking. You.com — как сценарий, где agents can pay on demand за конкретный premium content.

Это ещё не доказательство зрелого рынка. Это направление: экономика crawler’ов смещается от “can I fetch this URL?” к “что этот контент сделал для пользователя и кто получает оплату?”.

Identity бота становится инфраструктурой, а не вежливостью

Robots.txt остаётся важным, но его мало. RFC 9309 стандартизирует Robots Exclusion Protocol, знакомый способ публиковать правила для crawler’ов. Проблема в том, что robots.txt доброволен. Это не authentication и не enforcement. Он не остановит того, кто игнорирует правила или притворяется известным ботом.

Cloudflare Content Signals Policy расширяет robots.txt machine-readable preferences: search, ai-input, ai-train. Это помогает выразить intent: поиск разрешён, обучение запрещено, real-time AI input может быть отдельным решением. В июле Cloudflare добавил поле use, например reference. Но Content Signals сами по себе — preference signals. Они становятся сильнее вместе с edge controls, WAF, bot management и коммерческими соглашениями.

Поэтому важен Web Bot Auth. Модель Cloudflare требует, чтобы crawlers подписывали запросы через HTTP Message Signatures и Ed25519 identities. Зарегистрированный crawler доказывает, что он именно тот, за кого себя выдаёт. Cloudflare может классифицировать его, применить policy и в Pay Per Crawl сценарии списать оплату или отказать. Экосистема RFC 9421 шире конкретной реализации Cloudflare, но принцип понятен: identity ботов становится криптографической.

Для crawler developers это культурный сдвиг. “У нас есть user-agent и мы соблюдаем robots.txt” может быть недостаточно для premium sites. Новый checklist длиннее: разделять crawlers по purpose, подписывать запросы, публиковать identity metadata, уважать Content Signals, указывать contact info, обрабатывать 402/payment flows и не смешивать search, agent и training в одном opaque pipeline.

Что получают издатели и чем рискуют

Издатели получают рычаг. Маленький сайт не может отдельно договариваться с каждой AI-компанией. Если edge provider даёт переключатели Search, Agent и Training, publisher получает практическую панель управления. Можно остаться discoverable, но сказать нет training. Можно тестировать paid access. Можно блокировать unsigned или mixed-use automation. Можно спросить, делится ли AI-answer value с источником.

Риск — фрагментация open web. Если каждый крупный edge provider, группа издателей и AI-вендор введёт свои crawler classes, payment headers, licensing signals и exceptions, маленькие разработчики окажутся в лабиринте. Крупные AI и search companies договорятся. Малые agent startups, research tools, accessibility tools, independent search engines и полезные personal automations могут попасть под правила, созданные против индустриального extraction.

Есть и gatekeeper problem. Cloudflare решает реальную проблему, но становится арбитром intent. Если Cloudflare считает bot Training, а не Search, или Agent, а не user-driven browsing, эта классификация влияет на доступ к большой части веба. Enterprise customers увидят больше BotBase metadata. Free customers получат сильные defaults, но меньше контекста. False positives и appeals будут важны.

Это не аргумент против идеи. Это повод воспринимать её как infrastructure policy, а не как очередной toggle.

Что меняется для SEO и answer optimization

SEO-команды раньше спрашивали: видит ли Googlebot страницу, корректен ли sitemap, верный ли canonical URL, отвечает ли страница intent. Этот мир остаётся. Но рядом возникает другой набор вопросов: разрешать ли AI answer engines использовать контент, должны ли они цитировать, платить, и надо ли real-time agents отличать от indexing crawlers?

Пример Ceramic указывает на новую отчётность. Publisher хочет знать, какие queries подняли его content, какой snippet был использован и где он оказался в AI result. Это похоже не только на rank tracking, но и на licensing analytics. Answer optimization становится одновременно editorial, technical и contractual.

Трудность в discoverability. Слишком жёсткая блокировка защищает контент, но может сделать его невидимым для систем, которыми всё чаще пользуются люди. Слишком мягкий доступ сохраняет видимость, но ослабляет монетизацию. Универсального ответа нет. SaaS documentation site может хотеть широкий AI access, потому что хорошие ответы снижают support tickets и помогают продаже продукта. News publisher может хотеть строгие controls, потому что summaries заменяют visits. Marketplace может разрешать search, но блокировать agents, которые скрейпят prices без коммерческих правил.

Старый бинарный выбор index/noindex превращается в матрицу.

Что меняется для AI agents и browser automation

Разработчикам agent systems стоит внимательно смотреть на Cloudflare, потому что политика целится в категорию, которой ещё недавно почти не было в веб-управлении. Browser agent — не совсем crawler, не совсем человек и не совсем API client. Он может нести реальное user intent, но масштабироваться как automation.

Агент, который пересказывает support article платящему клиенту, может быть желанным на одном сайте и заблокированным на другом. Shopping agent, сравнивающий цены, может быть user empowerment для покупателя и margin leakage для продавца. Enterprise agent, читающий vendor portals, может быть легитимен для клиента, но выглядеть как scraping, если приходит через headless Chrome без signed identity.

Инженерный ответ — делать purpose visible. Если в продукте есть отдельные search indexing, real-time retrieval, user-agent browsing и training pipelines, они не должны пользоваться одним мутным crawler. Logs должны различать их. Headers и signatures должны идентифицировать их. Product teams должны закладывать paid access там, где content owners потребуют оплату. Legal и procurement должны знать, какая часть продукта зависит от scraping, а какая — от APIs или licensed data.

Это неудобно. Но это может оздоровить agent ecosystem. Чем больше agents действуют от имени пользователей, тем сильнее сайты будут требовать способ отличить legitimate user-delegated action от model-training vacuum cleaner.

Что делать infrastructure teams

Для Cloudflare customers первый шаг — inventory. Какие zones на Cloudflare? Какие pages display ads? Какие страницы являются documentation, marketing, support, community, pricing, product data или logged-in content? Какие из них должны быть видны для search, AI answers, real-time agents или training crawlers?

Затем проверьте controls: AI traffic settings, Bot Management, WAF rules, verified bot settings, robots.txt, Content Signals Policy, sitemap strategy и logs. Если используется managed robots.txt, поймите, что Cloudflare выставляет по умолчанию, а что остаётся undecided. Если компания сидит на Cloudflare free plan, проверьте September 15 default change и решите, нужен opt-out или custom policy.

Потом посмотрите на зависимости в обратную сторону. Ваш продукт сам скрейпит web? Data enrichment зависит от страниц, которые скоро могут блокировать Agent или Training? AI assistant fetches pages in real time? Один crawler identity используется для indexing, retrieval и training? Если да, вы ровно тот mixed-purpose bot, который Cloudflare пытается заставить разделиться.

Подготовьте fallbacks. Используйте official APIs, где они есть. Лицензируйте valuable data, если scraping — business dependency. Кэшируйте ответственно. Уважайте robots и Content Signals. Подписывайте bot requests, если экосистема это поддерживает. Делайте понятный user-facing failure mode, когда site blocks an agent. Хороший продукт не должен делать вид, что весь веб — бесплатная база данных без правил.

Open web становится программируемым и договорным

Главный сдвиг — не конкретный toggle Cloudflare. Веб получает machine-readable способы сказать: search may index this, AI input may use this, training may not, agents may need payment, signed crawlers get different treatment from unsigned ones.

Это может защитить creators и publishers. Но это может и закрепить веб как patchwork of private rules. Итог зависит от деталей: transparency, appeal paths, open standards, reasonable defaults, fair pricing и того, смогут ли small sites и small AI developers участвовать без тонны paperwork.

Анонс Cloudflare — предупреждение и preview. AI agents будут жить не только по законам моделей. Они будут жить по правилам доступа на edge веба. Следующим преимуществом может оказаться не больший context window, а знание, какие двери агент имеет право открыть, что он должен подписать и где обязан заплатить.