Cloudflare предложила платить за обход сайтов ИИ-ботами

Cloudflare 1 июля 2025 года представила Pay per Crawl — механизм, с которым владелец сайта может не только разрешать или запрещать распознанным ИИ-краулерам доступ к страницам, но и указывать, что доступ предполагает оплату. Важно не переоценивать анонс: на момент объявления это была закрытая бета, а не готовая касса для любого сайта и любого бота.

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

Что именно показала Cloudflare

В схеме участвуют сайт, распознанный краулер и инфраструктура Cloudflare. Для каждого бота владелец домена выбирает одно из трёх правил: allow — отдать страницу бесплатно, block — не отдавать её, charge — запросить оплату по заданной для домена цене.

Если бот не заявил готовность платить, пограничный сервер может вернуть HTTP-ответ 402 Payment Required с информацией о цене. В описании беты Cloudflare предусмотрела и второй путь: краулер заранее указывает максимальную цену, которую готов заплатить. При подходящей цене запрос получает обычный успешный ответ; событие фиксируется для расчёта. Компания берёт на себя инфраструктурную часть и роль расчётного посредника, но обе стороны должны настроить платёжные данные в своих аккаунтах.

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

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

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

Pay per Crawl пытается добавить к этому более явный сигнал: «контент не выдан, но у владельца есть условия для разговора». Для небольшого сайта это не повод рассчитывать на новую выручку. Зато это повод аккуратнее описать свою политику: какие разделы открыты для поиска, какие материалы нельзя использовать для обучения, кому писать по вопросам лицензирования.

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

Что изменилось для новых доменов

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

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

Где у механизма границы

Первая граница — статус запуска. В исходном анонсе Pay per Crawl назван private beta. Публичный 402 в панели и полноценные расчёты с конкретным краулером — разные вещи. В августе 2025 года Cloudflare отдельно расширила возможность отправлять настраиваемый ответ 402 платным клиентам, при этом сам Pay per Crawl продолжал развиваться в бете.

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

Третья — экономика. Цена за запрос ещё не доказывает ценность конкретной страницы. Один материал могут скачать один раз и использовать много раз, а другой — часто сканировать без заметного эффекта. Владельцу полезнее сначала измерить объём автоматического трафика и нагрузку, чем назначать цену наугад.

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

1. Сохранить текущие настройки ботов и выгрузку логов хотя бы за неделю. Это даст точку сравнения после любых изменений.
2. Разделить страницы по смыслу: общая навигация, открытые статьи, личные кабинеты, архивы и технические URL не должны иметь одно правило только ради удобства.
3. Проверить, какие боты действительно нужны. Запросите адреса, user-agent и цель обхода у команды, отвечающей за сайт, а не добавляйте правила из случайной таблицы.
4. Сначала протестировать запрет или разрешение на небольшой группе URL, затем вручную проверить доступность страниц и изменения в логах.

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

Вывод редакции

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

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

Как проверить решение на своём домене

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

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