Показатель Agent Readiness Score от Cloudflare: все, что нужно знать о нем

На этой неделе готовность к агентам перестала быть абстрактной концепцией и перешла в разряд измеримой инфраструктуры. 17 апреля, во время мероприятия Cloudflare Agents Week, компания запустила сервис isitagentready.com – публичный сканер, оценивающий адаптированность веб-сайта к ИИ-агентам. Вы можете вставить URL, получить оценку, посмотреть, какие проверки пройдены, а какие нет, и ознакомиться с рекомендациями, сгенерированными ИИ, по улучшению результатов. Впервые за долгое время обсуждение приспособленности веб-сайта к агентам сместилось с вопроса «адаптирован ли мой сайт под агенты?» к разбору «мой сайт набрал X из 100 по следующим пяти категориям; вот какие тесты он не прошел».

Agent Readiness Score (показатель готовности сайта к агентам) – изменение существенное. Однако этот инструмент может ввести в заблуждение, особенно если не углубляться в аспекты его функционирования.

Я протестировал сайт nohacks.co и получил 33 балла из 100, уровень 2 («Bot-Aware»). Файл robots.txt прошел проверку. Карта сайта прошла проверку. Правила для ИИ-роботов в robots.txt прошли проверку. Content Signals прошли проверку. Затем оценка резко начала падать – в категориях, которые для контентного блога вообще бесполезны. Подробнее об этом чуть позже.

Начнем с контекста. Компания Cloudflare всю неделю занималась поставкой инфраструктуры для агентов. Инструмент Agent Readiness Score появился одновременно с облачным сервисом Agent Memory, общими словарями (Shared Dictionaries), опцией Redirects for AI Training, технологией сжатия весов LLM под названием Unweight, а также платформой Flagship для управления функциями. Несколько дней назад они выпустили Project Think (новый Agents SDK), и организация OpenAI за пару часов интегрировала его со своим собственным Agents SDK. Сканер готовности сайта к агентам – следующий логичный шаг в этой цепочке: если среды выполнения – это новый браузерный слой, владельцам сайтов нужно убедиться, читабельны ли их проекты для этого слоя. Cloudflare предоставила такой тестер.

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

Что предложила Cloudflare: сканер, API и MCP-эндпоинт, к которому агенты могут обращаться

Сканер доступен по адресу isitagentready.com. Вам нужно вставить URL, выбрать тип сайта (All Checks (все проверки), Content Site (контентный сайт) или API/Application (API/Приложение)), чтобы задать сканируемые сигналы, и нажать «Scan». Сканер получит главную страницу и список известных путей, выполнит ряд проверок для них, после чего вернет отчет с оценками, включающий в себя пометки «пройдено/провалено», коды состояния, тела ответов и сгенерированные ИИ рекомендации по улучшению сайта.

К сканеру можно обратиться и другими способами:

• Он интегрирован в Cloudflare Radar, потому те же проверки запускаются параллельно с анализом существующих URL-адресов в Radar.
• Программно через Cloudflare URL Scanner API для автоматизации.
• Через stateless MCP-сервер по адресу /.well-known/mcp.json; любой MCP-совместимый агент может вызвать сканирование и проанализировать результаты.

Последний пункт заслуживает отдельного внимания. Сканер Cloudflare может использоваться самими агентами для начального аудита веб-сайта, чтобы заранее понять, как взаимодействовать с ним (еще до обращения к ресурсу).

Вернемся к практическому вопросу. Что именно он проверяет?

16 проверок, 5 категорий: что именно тестируется

Все проверки сканера разбиты по 5 категориям. Далее мы приводим их разбор.

Discoverability (3 проверки)

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

• Существование robots.txt. Классический файл политики обхода. Агенту, следующему инструкциям в robots.txt, необходимо, чтобы этот файл существовал и был доступен для обработки.
• Существование sitemap.xml. Карта сайта либо находится по стандартному пути, либо объявлена через директиву Sitemap в robots.txt. Агент, делающий обход страниц, использует sitemap.xml.
• Заголовки ссылок (RFC 8288). Заголовки HTTP Link указывают на канонические, альтернативные или связанные ресурсы. Полезно для агентов, которые анализируют ответы вместо HTML-кода.

Content (1 проверка)

Markdown для агентов. Согласование контента. Сканер отправляет Accept: text/markdown и проверяет, возвращает ли веб-сайт Markdown вместо HTML. Это собственное предложение Cloudflare, а не спецификация IETF, хотя механизм является стандартным (HTTP-согласование контента через заголовок Accept). В реальных средах выполнения агентов предпочтительнее использовать Markdown, поскольку его дешевле токенизировать и проще парсить, чем HTML. Некоторые первопроходцы (включая саму Cloudflare и отдельные сайты с документациями) поддерживают согласование контента Markdown; большинство сайтов не предлагают подобного.

Bot Access Control (3 проверки)

Правила для ИИ-ботов в robots.txt (RFC 9309). Содержит ли robots.txt директивы для ИИ user agents (GPTBot, ClaudeBot, PerplexityBot и т. д.).

Content Signals в robots.txt. Новая спецификация для выражения правил доступа для каждого URL в robots.txt. Имеет следующий вид: User-agent: * с последующими директивами Content-signal:. В настоящее время используется минимально.

Подпись запросов Web Bot Auth. Подписи HTTP-сообщений в /.well-known/http-message-signatures-directory позволяют агентам криптографически подтверждать свою личность. Это часть сервиса Agent Name Service, который Cloudflare совместно с GoDaddy представила ранее в рамках конференции Agents Week. Вне платформ Cloudflare использование практически нулевое.

API, Auth, MCP & Skill Discovery (6 проверок)

• API Catalog (RFC 9727). Машиночитаемый индекс API-эндпоинтов веб-сайта, хранящийся по адресу /.well-known/api-catalog.
• Обнаружение OAuth / OIDC (RFC 8414). Метаданные стандартного сервера авторизации OAuth 2.0, которые находятся по адресам /.well-known/oauth-authorization-server и /.well-known/openid-configuration.
• OAuth Protected Resource (RFC 9728). Веб-сайт, указывающий, какие эндпоинты защищены OAuth и как пройти аутентификацию.
• MCP Server Card (SEP-1649). MCP-сервер, конфиги которого заданы в /.well-known/mcp/server-card.json. SEP-1649 – это черновик предложения в рамках процесса разработки спецификации MCP.
• Индекс Agent Skills. Список навыков, вызываемых агентами; находится по адресу /.well-known/agent-skills/index.json.
• WebMCP (экспериментальная опция). Встроенный в страницу JavaScript API, регистрирующий инструменты, вызываемые агентом, через navigator.modelContext. Сканер использует рендеринг в headless-браузере, чтобы определить, регистрирует ли сайт какие-либо инструменты WebMCP при загрузке страницы.

Commerce (3 необязательных проверки, не учитываются на некоммерческих сайтах)

• Протокол платежей Инфраструктура HTTP 402 Payment Required для платежей, осуществляемых через агентов.
• Профиль UCP (Universal Commerce Protocol). Стандарт метаданных продавцов Google, хранящийся по адресу /.well-known/ucp.
• Документ обнаружения ACP (Agentic Commerce Protocol). Его URL: /.well-known/acp.json.

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

Последняя деталь имеет значение. Она свидетельствует о том, что Cloudflare предвидели проблему, о которой будет сказано далее.

Nohacks.co набрал 33/100 и получил уровень 2 Bot-Aware

Я провел сканирование сайта nohacks.co. Результат: 33 из 100, уровень 2, «Bot-Aware».

Несколько слов об этом числе: после первого сканирования я добавил директивы Content Signals в robots.txt, что увеличило значение Bot Access Control с 50 до 100, и общий балл вырос на 8 пунктов с первоначальных 25. Все остальные категории остались без изменений по сравнению с первым сканированием. К исправлению Content Signals и причинам, по которым я это сделал, я вернусь в конце раздела.

Вот что повлияло на оценку по каждой категории:

• Discoverability: 67. Файлы robots.txt и sitemap.xml прошли проверку. Заголовки ссылок не прошли проверку, поскольку этот веб-сайт не передает заголовки Link: в своих ответах.
• Content: 0. Согласование контента Markdown не настроено. Веб-сайт возвращает HTML независимо от заголовка Accept.
• Bot Access Control: 100. Обе проверки пройдены успешно. Правила для ИИ-ботов в robots.txt (у меня есть явные правила для ИИ user agents) и Content Signals в robots.txt (я добавил их после первого сканирования). Подпись запросов Web Bot Auth перечислена в этой категории как информирующая проверка; она не учитывается в расчете 2/2.
• API, Auth, MCP & Skill Discovery: 0. Все шесть проверок провалены. Нет API Catalog. Нет обнаружения OAuth. Нет метаданных OAuth Protected Resource. Нет MCP Server Card. Нет индекса Agent Skills. Нет инструментов WebMCP на странице.
• Commerce: не оценивается. На сайте nohacks.co электронная коммерция не ведется. Все проверки по категории «Коммерция» провалены, но категория корректно исключена из сводной оценки.

В итоге я получил 33 балла. Правда, я считаю, что мой сайт достаточно хорошо спроектирован для агентов. Файл robots.txt чистый и понятный. Контент представляет собой машиночитаемый HTML-код, генерируемый сервером, с четкой семантической структурой. Карта сайта актуальна. URL-адреса работают. Если бы вы спросили меня неделю назад, готов ли этот сайт к использованию агентами, мой ответ был бы где-то между «в целом да» и «для того, что ему нужно делать, — да».

И всё же: 33, Уровень 2.

Несколько слов об исправлении Content Signals, поскольку оно имеет отношение к аргументу Гудхарта, который будет рассмотрен далее в этой статье. Content Signals – это предложение Cloudflare; оно используется только в краулерах, адаптирующих стандарты Cloudflare. Эта правка показалась мне оправданной. Ибо, во-первых, исправление носит декларативный, а не декоративный характер. Директивы определяют реальную политику в отношении моего контента, и это утверждение имеет смысл, даже если спецификация не выполняется. Во-вторых, для сайта, который пишет о своей готовности к агентам, публичное объявление политики в отношении контента является редакционной практикой вне зависимости от того, какой краулер ее соблюдает. Исправление – это один коммит в public/robots.txt.

Один и тот же веб-сайт получает оценку 33 или 67 в зависимости от выбранного режима

В режиме «All Checks» сайт nohacks.co набирает 33 балла из 100 с уровнем 2 «Bot-Aware». В режиме «Content Site» тот же сайт, в тот же день, но с другой конфигурацией сканирования, набирает 67 баллов с уровнем 2 «Bot-Aware». Это почти вдвое больше. Разница в 34 балла — это разница между двумя конфигурациями сканирования одного и того же сканера.

Вот что изменяет режим «Content Site» в конфигурации сканирования:

При запуске этого пресета на nohacks.co был получен следующий результат:

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

Корректный переключатель скрыт, а дефолтный балл ошибочен

Сканер просто делает свою работу. Он знает, что блогу не требуется MCP Server Card. Он знает, что архив подкастов не публикует API catalog. Content Site – это не просто косметический пресет. В нем нет лишних проверок, а потому контентный веб-сайт получает точную оценку соответствия стандартам, которые действительно были реализованы.

Проблема в том, что пресет скрыт. Когда пользователь заходит на isitagentready.com и вставляет URL-адрес, сканирование по умолчанию включает «All Checks». Переключатель Site Type, позволяющий выбрать «Content Site» или «API/Application», находится в выпадающем меню «Customize», которое большинство пользователей никогда не откроют. Пользователь нажимает «Scan», получает итоговый балл, делает снимок экрана и делится им. Результат, который распространяется в социальных сетях, тот, по которому сравнивают конкурентов, — это итог проверки «All Checks».

Для контентного сайта значение 33 – слишком низкое. Оно не соответствует типу сайта. Точное значение – 67, но его можно получить только в режиме Content Site. Два числа от одного и того же сканера для одного и того же сайта. Вот только неправильное число доступно сразу же, а для правильной проверки придется еще покопаться в настройках.

Для протокола: оценка 67 меня беспокоит. Я хочу получить 100. Меня отделяют от сотни всего два исправления. Оба займут минут пять. Оба соответствуют реальному поведению агента во время выполнения (заголовки Link, согласование контента Markdown), так что мотивация вполне законна, это не погоня за рейтингом. Но подобное предостережение точь-в-точь соответствует тому, что говорят все охотники за очками. Публичные оценки – это гравитационное поле. Даже человек, пишущий длинную статью об их ненадежности, в конечном счете сам оказывается им подвержен.

Сканер измеряет только качество доставки

Все категории, которые проверяет сканер Agent Readiness, касаются доставки: обнаруживаемость, согласование контента, доступ для ботов, наличие API, коммерческие протоколы. Ни одна из них не проверяет качество самого месседжа.

Сканер не говорит, понятны ли ваши заголовки, убедительны ли описания товаров, хорошо ли ваш контент отвечает на запрос, хорош ли ваш текст. Это вопросы SEO и CRO. Они относятся к дисциплине улучшения месседжа. Показатель Agent Readiness принадлежит к совершенно другой дисциплине. Он говорит о том, может ли агент получить ваш контент, спарсить его, аутентифицироваться на ваших эндпоинтах, вызвать ваши функции.

Вот в чём заключается главное различие. Классическая веб-оптимизация (SEO, CRO) — это то, что вы доносите и насколько убедительно вы это делаете. Готовность к взаимодействию сайта с агентом — это то, как вы доносите свой месседж до нечеловеческого читателя. Два веб-сайта могут публиковать идентичный контент слово в слово. Один предоставляет его в виде отрендеренного сервером HTML-кода с семантической разметкой, отвечает на Accept: text/markdown, выводит структурированные данные и возвращает предсказуемые коды ответа. Другой предоставляет его в виде отрендеренного JS одностраничного приложения, без согласования контента и с непоследовательной системой обработки ошибок. Месседж идентичен. Способ доставки различен. Показатель готовности к взаимодействию сайта с агентом будет разным. И это будет правильно, потому что агент взаимодействует именно со способом доставки.

Именно поэтому исправления, направленные на повышение адаптированности к агентам, часто не связаны напрямую с работами по SEO и CRO. Вы можете улучшить показатель agent-readiness, не переписывая ни единого слова своего контента. Вы также можете иметь топовый контент, который получает 10 баллов в сервисе, потому что ваш пайплайн доставки не был разработан для машинных потребителей. SEO и CRO работают на уровне контента. Готовность к использованию агентов работает на уровне транспорта и протоколов. Это смежные, но не одинаковые области деятельности, и рассматривать их как одно и то же — ошибка, которая превращает проект по повышению адаптированности к агентам в проект по переписыванию контента.

3 риска, связанные с законом Гудхарта

Закон Гудхарта гласит, что когда показатель становится целью, он перестаёт быть хорошим показателем. Индикатор Agent Readiness Score – хороший продукт; но теперь эта метрика стала общедоступной, легко распространяемой и сравниваемой, что в реальных условиях приводит к трём предсказуемым поведенческим ошибкам.

Первый риск заключается в том, что владельцы веб-сайтов будут оптимизировать показатель, ориентируясь на цифры, а не на реальное поведение агентов. Почему бы не добавить схему MCP Server Card, которая ведет в никуда, ведь сканер требует её наличия? Почему бы не опубликовать индекс Agent Skills без указания реальных навыков? Почему бы не поставить инструмент WebMCP, который ничего не делает, просто чтобы пройти проверку обнаружения? Результат повысится, но ничего не изменится для агентов, посещающих веб-сайт.

Второй риск заключается в том, что консалтинговые компании начнут предлагать «оптимизацию Agent Readiness Score» как услугу, продавая сами цифры, а не базовую архитектуру. Мы уже видели, как это происходило в SEO. PageRank стал целью, и вокруг него выросла экономика ссылочного спама, длящаяся десять лет. Core Web Vitals также стал целью, и за ним последовало поколение бессмысленных и беспощадных оптимизаций. Показатель готовности к агентам — это более продуманная метрика, но имеющая тот же самый гравитационный потенциал.

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

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

6 исправлений, которые соответствуют реальным агентским средам выполнения

Ниже приведены исправления, которые должен осуществить веб-специалист, в порядке убывания приоритета:

1. Исправьте ошибки проверок, которые возникают при работе с реальными агентскими средами выполнения.
   1. Файл robots.txt. Если он отсутствует, добавьте его. Если он присутствует, убедитесь, что он содержит конкретные правила для ИИ user agents (GPTBot, ClaudeBot, PerplexityBot, Google-Extended и т. д.).
   2. Файл sitemap.xml. Если он отсутствует, сгенерируйте его и добавьте ссылку на него в robots.txt. Поддерживайте его в актуальном состоянии.
   3. Согласование контента в формате Markdown. Настройте свой источник или CDN так, чтобы он возвращал text/markdown, когда заголовок Accept запрашивает это. Собственная система Cloudflare AI Crawl Control обеспечивает первоклассную поддержку этой функции. Другие провайдеры требуют кастомной серверной логики.
   4. Структурированные данные. Используйте схему schema.org JSON-LD для типов контента, публикуемых на вашем веб-сайте (Article, Product, Organization, BreadcrumbList). Это наиболее эффективное решение для улучшения цитируемости во всех развернутых в настоящее время средах выполнения агентов.
2. Форматы, которые находятся на этапе предложения, внедряйте аккуратно. llms.txt, Content Signals в robots.txt, Web Bot Auth, API Catalog, MCP Server Card, Agent Skills, WebMCP, ACP, UCP – в некотором смысле это реально работающие стандарты. Но они пока не используются массово. Следите за ними. Добавляйте их только при необходимости.
3. Выполняйте повторное сканирование после внесения изменений. Сканер быстрый, бесплатный; он доступен через URL Scanner API, если вы хотите включить регрессионное тестирование в свой конвейер развертывания.
4. Забудьте о консалтинговых компаниях, предлагающих оптимизацию Agent Readiness Score.

Сканер – это просто инструмент. Работу за вас он не сделает.

Нас ожидает появление сканеров от других компаний

Сканер Agent Readiness предлагает проверки по фиксированному списку протоколов и форматов, одни из которых утверждены (RFC 8288 Link headers, RFC 9309 robots.txt rules, RFC 8414 OAuth discovery, RFC 9727 API Catalog, RFC 9728 OAuth Protected Resource), в то время как другие — нет (MCP SEP-1649, WebMCP, Content Signals, Web Bot Auth, x402, UCP, ACP, llms.txt). Дальнейшее развитие экосистемы предсказуемо: компании будут выпускать собственные сканеры, используя свои предпочтительные списки. Пересечение будет значительным, поскольку большинство утвержденных стандартов не вызывают споров. Различия будут заключаться в том, по каким предложениям каждый поставщик будет проводить проверку.

Именно это расхождение и делает историю с измерением адаптированности к агентам такой интересной. Сканер Cloudflare, проверяющий Web Bot Auth и UCP, стал первой ласточкой. Сканер Google, если его зарелизят, будет тестировать те же параметры плюс некоторые другие (у Google есть UCP, но нет Web Bot Auth). Сканер Perplexity будет проверять ещё один набор параметров. В итоге владельцы веб-сайтов получат разные оценки от разных сканеров для одного и того же сайта.

Это не должно отпугивать. Показатель Agent Readiness Score реален. Текущая оценочная система – лишь первая итерация; она будет иметь десятки версий, каждая из которых будет отражать видение той или иной компании.

Источник: https://www.searchenginejournal.com