Начнем с интересного: в Cloudflare Radar появилась вкладка AI-insights, где в реальном времени можно смотреть, что происходит с ИИ-агентами, AI-трафиком на сайты, поведением нейросетей и проч. Дашборд выстроен на основе анализа 200 тысяч наиболее посещаемых доменов, разбитых на категории. 

Картинка впечатляющая, вот лишь один скриншот:

Судя по диаграмме ниже, Cloudflare прав, когда говорит о неготовности интернета к AI-нашествию. Даже с доступностью robots.txt у наиболее посещаемых (!) сайтов интернета не все в порядке. Приглядитесь — максимум на графике =14%. 

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

Мы решили посмотреть, что умеет измерять публичный сервис, выпущенный Cloudflare в апреле 2026 года —  Agent Readiness Score isitagentready.com. Предполагается, что инструмент показывает, как агенты будут находить и использовать контент и API сайта. Cloudflare позиционирует проработку измеряемых здесь параметров как ключевой шаг для перехода от классического SEO к оптимизации под агентов (GEO|AEO).

Обескураживающие результаты: интернет не готов к визиту AI-агентов?

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

Хм, ну ОК.

Основные сайты Рунета вообще недоступны для проверки. Логично. Сходим в бурж.

Ну так же не может быть.

Шта?

Ну хоть у Cloudflare все неплохо.

Эээээ… как?!

Но:

В общем, проверка “в лоб” показала, что сервис точно что-то измеряет, и что его собственный сайт оптимизирован неплохо. 

Хотя после таких занятных результатов доверие к сервису уже несколько пошатнулось, мы решили узнать, что и как на самом деле считает сервис isitagentready (Is Your Site Agent-Ready). Читайте дальше, мы обнаружили причину таких “веселых” показателей.

Даем слово нашим техническим специалистам, которые без шуток проанализировали все показатели, заявленные Cloudflare, и узнали много интересного.

Что обещает инструмент isitagentready.com

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

На лендинге инструмента указано, что он сканирует сайт и проверяет внедрение нескольких групп стандартов: 

• Discoverability (robots.txt, sitemap, Link‑заголовки), 

• Content Accessibility (markdown for agents), 

• Bot Access Control (AI‑правила в robots.txt, Content Signals, Web Bot Auth),

• Protocol Discovery (MCP, Agent Skills, WebMCP, API Catalog, OAuth/OIDC, Agentic Commerce Protocol и др.). 

Заявлена также оценка Commerce (x402, MPP, UCP, ACP), но она пока опциональна и не включается в итоговый балл.

Cloudflare не только подчеркивает, что аудит дает интегральный «Agent Readiness score», но и публикует Agent Skills index с SKILL‑документами по каждому стандарту, чтобы разработчики понимали, что именно и как нужно исправить.

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

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

Источник: Introducing the Agent Readiness score. Is your site agent-ready?

Реальное положение дел: проверка опирается на драфты и собственные стандарты Cloudflare

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

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

Проблема A: зависимость от Cloudflare

Документ зависим от сканера Cloudflare и от его внутренней трактовки стандартов. 

Примерно половина проверок (Link headers с rel="api-catalog", API Catalog, MCP Server Card SEP-1649, Agent Skills index, /.well-known/acp.json) отражает именно интерпретацию Cloudflare, а не задокументированное поведение AI-провайдеров. 

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

Проблема B: черновой статус стандартов

Документ не разграничивает финализированные RFC (Request for Comments), такие как 8288, 8414, 9309, 9728, и черновики/policy без законченной спецификации:

• Content Signals — Cloudflare CC0 + IETF AIPREF Draft, 

• Web Bot Auth — IETF Draft, 

• MCP SEP-1649 — Draft, 

• Cloudflare Agent Skills Discovery RFC — Draft, 

• WebMCP — W3C Community Group Draft Report, 

• Agentic Commerce Protocol (ACP) — Beta. 

Кто и почему рекомендует этот инструмент

С момента запуска инструмент активно продвигает сама Cloudflare через блог, X и контент для разработчиков, позиционируя isitagentready.com как базовый чек‑лист «готовности к AI‑агентам» и показывая на демо, как выводы отчета превращаются в задачи для инженеров. 

Технические лиды и разработчики из AI‑ и SaaS‑компаний используют его как рабочий чек‑лист. В кейсах это демонстрируют как набор конкретных шагов, позволяющий за разумное время «дотянуть» инфраструктуру до рекомендуемого уровня.

Вот, к примеру, кейс о достижении 100 баллов (23→100), скриншот ниже снят при подготовке статьи. 

При этом внешние эксперты подчеркивают важные ограничения этого подхода. 

Значительная часть проверок отражает именно модель мира Cloudflare: MCP Server Card, Agent Skills index, WebMCP, ACP и другие «emerging standards» пока не являются универсальными требованиями всех AI‑провайдеров и во многом остаются кандидатными сигналами. 

Композитный скор легко переоценить: он смешивает зрелые RFC (8288, 8414, 9309, 9728) с экспериментальными драфтами и политиками (Content Signals, Web Bot Auth, MCP, Agent Skills, WebMCP, ACP), а также измеряет только инфраструктурную «доставку» для агентов, но не качество контента или реальную ценность сайта. 

В LinkedIn‑дискуссиях (например, у Dachary Carey) дополнительно подчеркивается, что разные «agent readiness»‑метрики (Cloudflare, Fern и др.) дают противоречивые оценки одним и тем же сайтам. Поэтому результаты isitagentready.com полезно использовать как ориентир, а не как единственный и объективный арбитр готовности сайта к GEO|AEO.

Краткая сводка: 13 проблем, из них две — критичные ошибки

Всего заявлено 17 разделов, в них выявлено 13 проблем (включая критические, значимые и требующие уточнения).

1. Критичные ошибки (смешение стандартов или путей)

В этих разделах формулировки расходятся с официальными спецификациями или подменяют одни стандарты другими:

• Раздел 12 (Agent Skills index) — смешение стандартов: описание /.well-known/agent-skills/index.json относится к черновому Cloudflare RFC, а не к официальному открытому стандарту Agent Skills от Anthropic (где нет .well-known).

• Раздел 16 (ACP) — путь не из спецификации: /.well-known/acp.json в официальной спецификации ACP (OpenAI + Stripe) не определён; это исключительно проверочная эвристика сканера Cloudflare.

2. Стандарты в разработке или неподтвержденные официально AI-провайдерами

Эти разделы проверяют экспериментальные протоколы, внутренние политики или черновики (Drafts). Они пока не стали обязательными стандартами, и их поддержка крупными LLM не доказана:

• Раздел 6 (Web Bot Auth) — базируется на IETF Draft (не финализирован).

• Раздел 7 (Content Signals) — Cloudflare policy + ранняя стадия в IETF AIPREF. Ни один крупный AI-провайдер публично не обязался их соблюдать.

• Раздел 8 (API Catalog) — RFC существует, но нет подтверждения его систематического использования AI-ботами.

• Раздел 11 (MCP Server Card) — статус Draft (SEP-1649), существуют конкурирующие версии пути (SEP-1960).

• Раздел 13 (WebMCP) — W3C Community Group Draft Report (не Standards Track), экспериментальная технология, доступная только за флагом в Canary.

• Раздел 14 (x402) — индустриальная инициатива (open-source протокол от консорциума), не является финализированным стандартом IETF.

• Раздел 17 (MPP) — находится в статусе Internet-Draft в IETF, экспериментальная технология.

3. Без ошибок (стандарты финализированы и соответствуют описанию)

В этих разделах описание стандартов и их проверка корректны, механизмы финализированы:

• Раздел 1 (robots.txt)

• Раздел 2 (sitemap.xml)

• Раздел 3 (Link headers RFC 8288)

• Раздел 4 (Markdown for Agents)

• Раздел 5 (AI bot rules in robots.txt)

• Раздел 9 (OAuth / OIDC discovery RFC 8414) (проверяется вместе со специфичными расширениями для ботов)

• Раздел 10 (OAuth Protected Resource RFC 9728)

• Раздел 15 (UCP profile)

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

Discoverability — Easy wins

1. robots.txt

Что за показатель

Наличие и корректность файла /robots.txt с валидным синтаксисом и понятными правилами обхода для ботов.

Как проверяется

• Выполняется запрос к https://домен/robots.txt.

• Ожидается код ответа 200 и Content-Type: text/plain.

• Проверяется структура директив: User-agent, Disallow, Allow, Sitemap, а также отсутствие синтаксических ошибок.

Зачем это нужно

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

• Даёт возможность закрыть служебные и дублирующиеся разделы от обхода.

• Может содержать ссылки на sitemap, чтобы ускорить обнаружение важных URL.

Влияние на AEO/GEO

• Для LLM и AI-ботов это базовый слой доступа: чрезмерно жесткие правила могут ограничить попадание важного контента в индексы и retrieval-системы моделей.

2. sitemap.xml

Что за показатель

Наличие XML-карты сайта с корректной структурой и перечнем канонических URL.

Как проверяется

• Из robots.txt извлекаются директивы Sitemap:.

• Запрашиваются sitemap.xml и другие указанные карты сайта.

• Проверяется валидный XML-формат (`<urlset>` или `<sitemapindex>`), а также доступность URL.

Зачем это нужно

• Ускоряет обнаружение и индексацию ключевых страниц сайта.

• Помогает роботам обходить крупные сайты с документацией, блогом и множеством лендингов.

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

Влияние на AEO/GEO

• Для LLM sitemap работает как удобный список первоочередных URL, который облегчает машинное извлечение контента и формирование knowledge-base.

3. Link headers (RFC 8288)

Что за показатель

Наличие HTTP-заголовков Link, через которые сайт объявляет связанные машиночитаемые ресурсы, например API-каталог или документацию.

Как проверяется

• Выполняется запрос к главной странице сайта.

• В ответе ищется заголовок Link: в формате RFC 8288, например <...>; rel="api-catalog".

Зачем это нужно

• Позволяет агентам и ботам находить важные сервисные ресурсы без анализа HTML-разметки.

• Дает протокольный способ указать путь к API Catalog, документации и другим discovery-объектам.

Влияние на AEO/GEO

• Для LLM и AI-агентов это упрощает автоматическое подключение к вашим данным и сервисам после одного запроса к главной странице.

Content Accessibility

4. Markdown for Agents

Что за показатель

Поддержка content negotiation, при которой сайт по запросу с Accept: text/markdown возвращает markdown-версию HTML-страницы.

Как проверяется

• Выполняется запрос к странице с заголовком Accept: text/markdown.

• Проверяется, что сервер отвечает Content-Type: text/markdown, а не text/html.

Зачем это нужно

• LLM-агентам проще читать и разбирать Markdown, чем HTML с навигацией, скриптами и декоративной разметкой.

• Это снижает шум, уменьшает токенизацию и улучшает извлечение структуры: заголовков, списков, таблиц, тарифов, FAQ.

Влияние на AEO/GEO

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

Bot Access Control

5. AI bot rules in robots.txt

Что за показатель

Наличие отдельных секций User-agent для AI-ботов, а не только общих правил или правил для классических поисковых роботов.

Как проверяется

• Анализируется robots.txt на наличие правил для AI-ботов вроде GPTBot, Claude-Web, PerplexityBot и других.

• Если специальных секций нет, считается, что к AI-ботам применяются только общие wildcard-правила.

Зачем это нужно

• Позволяет задавать отдельную политику доступа именно для AI-агентов.

• Даёт возможность разрешать поиск, но ограничивать обучение, либо наоборот, в зависимости от стратегии сайта.

Влияние на AEO/GEO

• Для LLM это прямой инструмент контроля над тем, какие разделы сайта попадут в индексы и retrieval пайплайны AI-систем.

6. Web Bot Auth request signing

Что за показатель

Наличие инфраструктуры Web Bot Auth для подписи исходящих bot/agent-запросов сайта через /.well-known/http-message-signatures-directory.

Как проверяется

• Выполняется запрос к /.well-known/http-message-signatures-directory.

• Проверяется, существует ли каталог подписи и отдает ли он нужные данные для верификации подписанных запросов.

Зачем это нужно

• Позволяет сайту или его ботам подтверждать подлинность своих автоматических запросов.

• Может использоваться как слой доверия в интеграциях между сайтами и агентами.

Влияние на AEO/GEO

• Для LLM и агентной инфраструктуры это важно скорее на стороне исходящих действий и доверенной автоматизации, чем на стороне контентной видимости.

Проблема 1:

Утверждение: путь /.well-known/http-message-signatures-directory подаётся как стандарт.

Требует доработки: путь корректен, но базируется на IETF Internet-Draft draft-meunier-http-message-signatures-directory (последняя редакция — 4 марта 2026, срок действия — до 5 сентября 2026). Это НЕ финализированный RFC. IETF только в 2026 г. сформировал рабочую группу WebBotAuth WG (целевая дата выхода Standards Track-спецификации в IESG — апрель 2026). Документ не отмечает черновой статус.

Источник: datatracker.ietf.org/doc/draft-meunier-http-message-signatures-directory, developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth — прямая формулировка «relies on two active IETF drafts».

Проблема 2:

Утверждение: «Для LLM и агентной инфраструктуры это важно скорее на стороне исходящих действий и доверенной автоматизации, чем на стороне контентной видимости».

Оценка: формально верно, но нужно уточнить, что сам AI-провайдер (OpenAI, Anthropic) свои боты через Web Bot Auth по состоянию на апрель 2026 г. публично ПОКА не подписывает — это делают, например, Cloudflare Browser Rendering, Goose, Anchor Browser, Parallel Web Systems. 

Большинство крупных AI-краулеров (GPTBot, ClaudeBot, PerplexityBot) всё ещё идентифицируют себя по User-Agent и IP-диапазонам. Документ риска не несёт, но LLM-ценность пункта для типичного контентного сайта близка к нулю.

Источник: blog.cloudflare.com/signed-agents — список первых signed agents.

7. Content Signals in robots.txt

Что за показатель

Наличие директив Content-Signal в robots.txt, описывающих предпочтения сайта по использованию контента AI-системами.

Как проверяется

• Анализируется robots.txt на наличие строк Content-Signal:.

• Проверяются поддерживаемые значения вроде ai-train, search, ai-input.

Зачем это нужно

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

• Это более тонкий уровень политики, чем простой запрет/разрешение обхода.

Влияние на AEO/GEO

• Content Signals скорее задают предпочтения владельца сайта по использованию контента (обучение, поиск, live‑ответы), чем выступают техническим сигналом ранжирования. 

• Крупные AI‑провайдеры официально не обещали соблюдать эти директивы, а RFC 9309 их не определяет. 

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

Проблема:

Утверждение: «Наличие директив Content-Signal в robots.txt… Проверяются поддерживаемые значения вроде ai-train, search, ai-input».

Факт: директива реальна (Cloudflare Content Signals Policy, анонс 24 сентября 2025 г.), но:

1. Это не IETF-стандарт, а политика под лицензией CC0, опубликованная Cloudflare. Стандарт находится в ранней стадии в рабочей группе IETF AIPREF, не финализирован.

2. Ни один AI-провайдер публично НЕ обязался соблюдать Content-Signal. Google в рамках антимонопольного дела US v. Google прямо подтвердил, что через Google-Extended можно отказаться только от тренировки Gemini, но не от использования контента в Google Search/AI Overviews; Content-Signal Google также не одобрил. OpenAI, Anthropic, Perplexity в своей документации (platform.openai.com/docs/gptbot, docs.anthropic.com/en/docs/claude/claude-web-crawler, docs.perplexity.ai/bot) Content-Signal не упоминают.

3. RFC 9309 (robots.txt) Content-Signal не определяет.

Рекомендация: документ подает директиву как работающий policy-сигнал для LLM, но это пока декларация (reservation of rights под EU DSM Directive Art. 4), а не технический контроль, исполняемый AI-ботами.

Источник: blog.cloudflare.com/content-signals-policy, searchengineland.com/cloudflare-content-signals-462538, RFC 9309 (datatracker.ietf.org/doc/html/rfc9309).

Protocol Discovery

8. API Catalog (RFC 9727)

Что за показатель

Наличие /.well-known/api-catalog с машиночитаемым перечнем API и связанных ресурсов.

Как проверяется

• Выполняется запрос к /.well-known/api-catalog с приёмом application/linkset+json.

• Проверяется формат linkset JSON и наличие ссылок на описание API, документацию и статусные endpoints.

Зачем это нужно

• Позволяет агентам автоматически обнаруживать API сайта и понимать, как с ними работать.

• Упрощает машинную интеграцию без ручного поиска OpenAPI и документации.

Влияние на AEO/GEO

• Для LLM и агентных систем API Catalog по RFC 9727 потенциально даёт удобную точку входа для автоматического обнаружения ваших API и связанных с ними описаний, но на апрель 2026 г. крупные AI‑провайдеры публично не заявляли, что их боты или клиенты систематически запрашивают /.well-known/api-catalog и используют application/linkset+json при обходе сайтов. 

• В контексте GEO это стоит рассматривать как перспективную, но пока экспериментальную инвестицию в машиночитаемое discovery: наличие API Catalog может упростить будущие интеграции с агентами и специализированными наборами инструментов, но не является подтвержденным «сильным сигналом» для текущей видимости или цитируемости в ответах LLM.

Проблема:

Неточность: RFC 9727 — реальный стандарт. Однако ни один крупный AI-провайдер публично не документировал автоматическое потребление /.well-known/api-catalog с application/linkset+json. 

Это теоретически перспективный путь, но на практике это индикатор сканера Cloudflare. Формулировка «один из самых сильных сигналов» не подкреплена ни документацией провайдеров, ни исследованиями. Нет официального подтверждения поддержки AI-агентами.

Источник: datatracker.ietf.org/doc/html/rfc9727 — сам RFC есть, упоминаний в документации AI-краулеров нет.

9. OAuth / OIDC discovery (RFC 8414)

Что за показатель

• Наличие стандартных well-known endpoints для discovery авторизации и аутентификации (/.well-known/openid-configuration и/или /.well-known/oauth-authorization-server), а также поддержка расширений для автономных агентов.

Как проверяется

• Выполняются запросы к обоим путям discovery.

• Проверяется наличие базового JSON с обязательными полями (issuer, authorization_endpoint, token_endpoint, jwks_uri и др.).

• Дополнительно проверяется поддержка параметров динамической регистрации клиентов (Dynamic Client Registration) и наличие специфических scope-разрешений для ботов.

Зачем это нужно

• Позволяет клиентам и AI-агентам автоматически узнавать, как безопасно аутентифицироваться в системе.

• Снижает порог интеграции с защищенными API.

• Дает возможность автономным ботам самостоятельно регистрироваться в качестве клиентов (клиентских приложений) и получать токены без ручного участия разработчика или пользователя.

Влияние на AEO/GEO

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

Важный нюанс (специфика проверки):

Хотя сам стандарт RFC 8414 полностью финализирован и широко используется, наличие обычного OAuth-сервера недостаточно для успешного прохождения аудита. Инструмент isitagentready.com проверяет не только базовый конфигурационный файл, но и его расширения. 

Сканер Cloudflare целенаправленно ищет поддержку Dynamic Client Registration для ботов и специфические Scope-разрешения, созданные специально для автономных систем. Если OAuth-сервер настроен только для классических (человеческих) клиентских приложений, инструмент не засчитает этот пункт как полностью пройденный.

10. OAuth Protected Resource (RFC 9728)

Что за показатель

Наличие /.well-known/oauth-protected-resource, описывающего защищённый ресурс и связанные authorization servers.

Как проверяется

• Выполняется запрос к /.well-known/oauth-protected-resource.

• Проверяется наличие полей resource, authorization_servers, scopes_supported и другой metadata.

Зачем это нужно

• Дает агентам понимание, как именно получить доступ к защищенным API-ресурсам.

• Это дополняет OAuth/OIDC discovery и дает агентам готовые машиночитаемые подсказки: откуда брать токены, какие scopes нужны и к каким именно ресурсам они дают доступ, без ручного перебора настроек.

Влияние на AEO/GEO

• Для LLM и агентных интеграций это улучшает способность систем безопасно подключаться к защищённым ресурсам сайта.

11. MCP Server Card (SEP-1649)

Что за показатель

Наличие MCP Server Card — машиночитаемого описания MCP-сервера сайта.

Как проверяется

• Выполняются запросы к нескольким кандидатным путям вроде /.well-known/mcp/server-card.json.

• Проверяется наличие JSON с данными о сервере, транспорте и capabilities.

Зачем это нужно

• Позволяет LLM-клиентам обнаруживать MCP-сервер и подключать его как инструмент.

• Формализует интеграцию сайта в экосистему agentic tools.

Влияние на AEO/GEO

MCP Server Card потенциально упрощает автоматическое подключение сайта как инструмента (tool) и делает его более заметным для клиентов и экосистем, которые уже экспериментально поддерживают MCP. 

Но стандарт остаётся в статусе draft и конкретный путь (/.well-known/mcp/server-card.json или /.well-known/mcp) еще может измениться. В контексте GEO это скорее подготовка к будущей интеграции с агентами, чем гарантированный текущий сигнал: отсутствие MCP Server Card не мешает моделям читать и цитировать ваш контент, а наличие лишь повышает шансы быстрой интеграции там, где MCP внедрен.

Проблема:

Утверждение: путь /.well-known/mcp/server-card.json подаётся как стандарт.

Требует доработки: стандарт не финализирован.

SEP-1649 имеет статус Draft (Issue #1649 в репозитории modelcontextprotocol/modelcontextprotocol). В декабре 2025 года появился SEP-1960 (/.well-known/mcp) — альтернативное предложение.

В начале 2026 г. автор SEP-1649 (@dsp-ant) выложил новую итерацию как PR #2127 («SEP-2127: MCP Server Cards»), что само по себе сигнал: первоначальный путь и структура ещё не стабильны. Создан официальный Server Card Working Group в MCP (в январе 2026), что подтверждает: спецификация ещё формируется.

Документ ссылается конкретно на SEP-1649, хотя на момент публикации существуют конкурирующие/ревизионные предложения, и в финальной версии путь может оказаться /.well-known/mcp.json (как в SEP-1960), а не /.well-known/mcp/server-card.json.

Источник: github.com/modelcontextprotocol/modelcontextprotocol/issues/1649 (status: Draft), github.com/modelcontextprotocol/modelcontextprotocol/pull/2127, github.com/modelcontextprotocol/modelcontextprotocol/issues/1960, modelcontextprotocol.io/community/server-card/charter.

12. Agent Skills index

Что за показатель

Наличие индекса навыков агентов в /.well-known/agent-skills/index.json или legacy-path /.well-known/skills/index.json.

Как проверяется

• Выполняется запрос к основному и legacy-пути.

• Проверяется JSON со схемой и массивом skills, где у каждого навыка есть имя, описание, URL и digest.

Зачем это нужно

• Позволяет агентам автоматически находить доступные на сайте действия и capabilities.

• Это более высокий уровень machine discovery, чем просто API-документация.

Влияние на AEO/GEO

Для LLM и агентных платформ наличие Agent Skills index может упростить автоматическое обнаружение доступных действий сайта там, где экспериментально поддерживается Cloudflare Agent Skills Discovery (например, отдельными тулчейнами и CLI). Но это не официальный веб‑стандарт Anthropic Agent Skills и не зафиксированный протокол для ChatGPT, Claude, Gemini или Perplexity. 

Отсутствие /.well-known/agent-skills/index.json сейчас не мешает моделям читать и цитировать ваш контент, а наличие такого индекса скорее готовит сайт к возможным будущим интеграциям в экосистему skills‑совместимых агентов, чем гарантирует эффект для GEO прямо сегодня.

Проблема 1 (критичная — смешение двух разных стандартов):

Утверждение: «Наличие индекса навыков агентов в /.well-known/agent-skills/index.json или legacy-path /.well-known/skills/index.json. Проверяется JSON со схемой и массивом skills, где у каждого навыка есть имя, описание, URL и digest».

Ошибка/неточность: описание соответствует Cloudflare Agent Skills Discovery RFC (github.com/cloudflare/agent-skills-discovery-rfc), а НЕ официальному открытому стандарту Agent Skills от Anthropic (опубликован 18 декабря 2025 г., agentskills.io). Это разные вещи:

• Anthropic Agent Skills — стандарт упаковки SKILL.md + вспомогательных файлов в папку для локальной установки в агенты (Claude Code, ChatGPT, Codex, Cursor, VS Code и др.). Распространяется через ~/.claude/skills/, ~/.codex/skills/, GitHub-репозитории. /.well-known в спецификации Anthropic отсутствует.

• Cloudflare Agent Skills Discovery RFC — отдельная инициатива Cloudflare (черновик, schema v0.2.0), которая добавляет web-обнаружение этих же SKILL.md-артефактов через /.well-known/agent-skills/index.json. Это драфт, не финализирован, не принят ни одним AI-провайдером как обязательный.

Документ называет этот пункт просто «Agent Skills index» без указания, что он основан на непринятой инициативе Cloudflare, а не на основном стандарте Anthropic.

Источник: github.com/cloudflare/agent-skills-discovery-rfc (Cloudflare RFC), github.com/agentskills/agentskills (Anthropic-standard), agentskills.io/specification — в официальной спецификации Anthropic нет .well-known.

Проблема 2:

Нет публично подтвержденных примеров потребления /.well-known/agent-skills/index.json основными LLM-платформами (ChatGPT, Claude.ai, Gemini, Perplexity) в продакшен-сценариях. 

Поддержку заявляют отдельные инструменты: Mintlify, Hermes Agent, Astro плагин, Vercel skills CLI — это экосистема Cloudflare RFC, а не мейнстримные AI-платформы. Нет официального подтверждения, что ChatGPT или Claude фетчат этот endpoint в обычном браузинге.

13. WebMCP (Experimental)

Что за показатель

• Наличие браузерной интеграции WebMCP, при которой сайт регистрирует инструменты (навыки) через API navigator.modelContext.registerTool().

Как проверяется

• Целевая страница загружается в headless-браузере с WebMCP-shim.

• Проверяется, зарегистрированы ли инструменты (tools) во время загрузки страницы через Imperative API (JavaScript) или Declarative API (HTML-формы).

Зачем это нужно

• Позволяет сайту отдавать агенту структурированные инструменты напрямую в браузере, без необходимости поднимать отдельный MCP-сервер на бэкенде.

• Агент (встроенный в браузер или работающий через расширение) может вызвать функцию (например, add_to_cart или book_ticket с нужными параметрами) напрямую через API браузера, без необходимости “прокликивать” элементы интерфейса или парсить DOM-дерево.

Влияние на AEO/GEO

• Для LLM и браузерных агентов WebMCP потенциально упрощает использование интерфейса сайта как набора инструментов.

• Однако это спецификация для выполнения действий (agentic execution), а не для поисковой оптимизации. Большинство LLM по‑прежнему просто читают HTML/Markdown, чтобы ответить на вопросы пользователя, и не требуют WebMCP для того, чтобы процитировать ваш контент.

Проблема:

Утверждение: Сам факт наличия WebMCP как проверяемого слоя, влияющего на готовность к AI.

Требует доработки (статус стандарта): Документ корректно называет пункт «Experimental», но для ясности следует указать статус технологии. WebMCP разрабатывается в рамках W3C Community Group (Draft Report), и спецификация прямо заявляет: «NOT a W3C Standard, nor is it on the W3C Standards Track».

На весну 2026 года технология доступна исключительно в качестве раннего превью (early preview) за флагами разработчика — начиная с Chrome 145+ Canary. Другие крупные вендоры (Mozilla Firefox, Apple Safari) публично не заявили о поддержке и сроках внедрения этого стандарта. Следовательно, оптимизация под WebMCP сегодня — это экспериментальная работа на отдаленную перспективу, и отсутствие этого показателя не делает сайт "не готовым" к приходу современных AI-агентов.

Источник: webmachinelearning.github.io/webmcp/ (официальный W3C Community Group Draft), dev.to/czmilo/chrome-webmcp-the-complete-2026-guide-to-ai-agent-protocol-1ae9.

Commerce Optional

14. x402 payment protocol

Что за показатель

• Наличие поддержки HTTP-платежей по протоколу x402 для машинного взаимодействия.

Как проверяется

• Аудит делает запросы к потенциальным payment-aware ресурсам и проверяет наличие сценариев со статусом HTTP 402 Payment Required.

• Проверяется присутствие заголовка PAYMENT-REQUIRED с base64-закодированным JSON-объектом, содержащим цену, сеть (network), принимаемый токен (например, USDC) и адрес получателя.

Зачем это нужно

• Позволяет AI-агентам автоматически, без участия человека, оплачивать доступ к API-лимитам, платным данным и контенту (agentic commerce).

• Замыкает цикл оплаты внутри одного HTTP-взаимодействия: агент получает ошибку 402, читает инструкцию в заголовке, подписывает транзакцию в стейблкоинах и заново делает запрос, передавая подпись в заголовке PAYMENT-SIGNATURE.

Влияние на AEO/GEO

• Для LLM это опциональный коммерческий слой, а не базовый фактор читаемости или индексируемости. Это узкоспециализированная настройка, нужная исключительно для монетизации API-интерфейсов через агентов.

Проблема:

Утверждение: Протокол преподносится как финализированный стандарт.

Ошибка: На апрель 2026 года x402 не является финализированным стандартом (RFC) в IETF или другой официальной организации. Это open-source протокол, продвигаемый консорциумом x402 Foundation (учрежденным Coinbase и Cloudflare в сентябре 2025 года). 

В отличие от классических RFC, у него нет формального статуса в Internet Engineering Task Force. x402 использует кастомные PAYMENT-* HTTP-заголовки, а не стандартную схему WWW-Authenticate, что подчеркивает его статус индустриальной, а не академической инициативы.

Источник: blog.cloudflare.com/x402/, coinbase.com/blog/coinbase-and-cloudflare-will-launch-x402-foundation, blog.quicknode.com/x402-vs-mpp/. 

15. UCP profile

Что за показатель

Наличие /.well-known/ucp с профилем Universal Commerce Protocol.

Как проверяется

• Выполняется запрос к /.well-known/ucp.

• Проверяется наличие protocol version, services, capabilities и endpoints.

Зачем это нужно

• Дает агентам возможность обнаруживать commerce-capabilities сайта.

• Используется для сценариев автоматизированной покупки и оплаты.

Влияние на AEO/GEO

• Для LLM это не обязательный слой, а специализированная функция для commerce-интеграций.

16. ACP discovery document

Что за показатель

• Наличие /.well-known/acp.json для Agentic Commerce Protocol discovery.

Как проверяется

• Выполняется запрос к /.well-known/acp.json.

• Проверяется наличие protocol name, version, api_base_url, transport и capabilities metadata.

Зачем это нужно

• Позволяет AI-агентам обнаруживать commerce API сайта без ручной настройки.

• Актуально для платформ, где AI-ассистент должен не только рекомендовать, но и проводить транзакцию.

Влияние на AEO/GEO

• Для LLM это узкоспециализированный слой agentic commerce, а не обязательный критерий качества контента или индексации.

Проблема (значимая):

Утверждение: «Наличие /.well-known/acp.json для Agentic Commerce Protocol discovery. Проверяется наличие protocol name, version, api_base_url, transport и capabilities metadata».

Ошибка/неточность: официальная спецификация ACP (OpenAI + Stripe, репозиторий github.com/agentic-commerce-protocol/agentic-commerce-protocol) НЕ определяет /.well-known/acp.json как обязательный discovery-endpoint. 

Основной механизм обнаружения ACP-продавцов — загрузка структурированного продуктового feed в OpenAI (developers.openai.com/commerce) и регистрация через ChatGPT merchant onboarding portal. Эндпоинты create/update/complete/cancel checkout устанавливаются напрямую через API-соглашение с AI-платформой, а не через /.well-known.

Индикатор /.well-known/acp.json — это проверка из сканера Cloudflare (isitagentready), но не требование протокола. Сторонние гайды упоминают разные варианты (/.well-known/acp/config.json, /.well-known/acp/manifest.json), что подтверждает: стандартизированного .well-known пути у ACP на данный момент нет.

Источник: github.com/agentic-commerce-protocol/agentic-commerce-protocol, docs.stripe.com/agentic-commerce/protocol, developers.openai.com/commerce/guides/get-started — ни в одной официальной документации путь /.well-known/acp.json не определен.

17. MPP (Machine Payment Protocol)

Что за показатель

• Поддержка стандартизированного протокола Machine Payment Protocol (MPP) для обработки машинных транзакций с использованием нескольких методов оплаты.

Как проверяется

• При запросе к платному ресурсу проверяется ответ сервера со статусом HTTP 402 Payment Required.

• Проверяется использование стандартной схемы авторизации: сервер должен вернуть заголовок WWW-Authenticate: Payment с перечислением доступных методов оплаты (стейблкоины, фиатные карты, Lightning BTC и др.).

Зачем это нужно

• В отличие от x402, который заточен на одну платежную схему за запрос (преимущественно крипто/стейблкоины), MPP позволяет серверу предложить агенту сразу несколько способов оплаты, чтобы клиент мог выбрать подходящий.

• Интегрируется напрямую со стандартными HTTP-схемами авторизации (заголовки WWW-Authenticate и Authorization), что делает его синтаксис более близким к классической архитектуре REST API.

Влияние на AEO/GEO

• Как и x402, MPP относится исключительно к Agentic Commerce.

• Наличие этого протокола никак не влияет на ранжирование контента в AI Overviews или попадание в базу знаний Claude и ChatGPT. Это функция для транзакционных b2b-взаимодействий, а не для маркетинговой видимости (visibility).

Проблема:

Утверждение: Как и в случае с другими пунктами Commerce-блока, протокол измеряется сканером isitagentready.com.

Требует доработки (статус стандарта): В отличие от x402 (open-source проекта корпораций), MPP разрабатывается как формальный стандарт — он находится в статусе Internet-Draft в IETF (продвигается Tempo Labs и Stripe). Однако это всё ещё черновик (Draft), а не утвержденный RFC. Следовательно, это экспериментальная технология, реализация которой может потребовать изменений в коде после финализации стандарта.

Источник: blog.quicknode.com/x402-vs-mpp/.

Стоит использовать сервис от Cloudflare? Ответ: да, но нет

Сервис проверяет исключительно соответствие сайта спецификациям Agentic Web (AEO), большинство из которых — совсем свежие черновики (drafts) от IETF и W3C, активно продвигаемые Cloudflare. Это скорее такой набор “пожеланий” — как должен быть подготовлен сайт с точки зрения Cloudflare.

Инструмент можно использовать для исследовательских целей. Он будет полезен для технических директоров, архитекторов и разработчиков компаний, чей продукт — это API, SaaS-платформа или другой продукт со сложной технической документацией. Для них isitagentready.com послужит отличным опережающим чек-листом для подготовки инфраструктуры к будущему, где AI-агенты станут полноправными потребителями сервисов.

Инструмент не рекомендуется:

1. Для владельцев классических контентных сайтов, интернет-магазинов и блогов. Для них многие проверки избыточны, а высокий балл не гарантирует улучшения позиций в AI-поиске (GEO). Гораздо эффективнее сфокусироваться на проверенных практиках.

2. Для принятия решений о выделении бюджетов и планирования в целом. Сотрудникам, ответственным за AEO/GEO, не следует ставить в KPI показатель «Agent Readiness Score», так как его методология зависит от интерпретации Cloudflare, а не от официальных требований AI-провайдеров.

Резюмируя, скажем, что isitagentready.com — это ценный, но «сырой» прогностический инструмент, который показывает направление движения, а не текущий статус сайта в экосистеме AI. 

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