Агентная коммерция: чек-лист для интернет-магазина

Чек-лист агентной коммерции для интернет-магазина состоит из восьми слоёв: от страниц товаров, доступных краулерам, до API чекаута, который может вызвать агент. Первые два слоя и фид Merchant Center — обычная инженерия, их можно закончить и проверить за неделю. Остальное зависит от того, через какие ИИ-поверхности вы продаёте, а Google и OpenAI часть этих слоёв закрывают одобрением.

Это коммерческий этаж стека готовности. Сначала агент должен прочитать страницу товара без запуска JavaScript (сайты на JavaScript), а поверх лежит ваша разметка (структурированные данные). Магазин добавляет данные о товарах, документы обнаружения вроде /.well-known/ucp и чекаут. Поддержка неравномерна: руководство Google по UCP прямо говорит, что не все возможности спецификации доступны на его поверхностях (Google). Общую картину см. в материале что такое готовность к ИИ-агентам.

Ключевые выводы

• Агенты-покупатели читают ваши страницы, ваши данные о товарах и, если вас одобрили, API чекаута. OpenAI сообщает, что ChatGPT при выборе результатов учитывает структурированные метаданные о товарах (OpenAI Help).
• UCP и ACP — разные спецификации. UCP (Shopify и Google) живёт по адресу /.well-known/ucp, последний релиз — v2026-08-25 (UCP). ACP (OpenAI и Stripe) находится в бете, последний релиз — 2026-04-17 (ACP).
• Запуск ограничен: интеграцию UCP до старта одобряет Google, а для подключения фида в ChatGPT продавцы подают заявку в OpenAI (Google, OpenAI).
• Фид ACP отправляется по SFTP или через API, а не обходится краулером, поэтому Product JSON-LD публикуйте в любом случае (OpenAI).
• Агенты, запущенные пользователем, например ChatGPT-User и Google-Agent, могут игнорировать robots.txt, так что проверьте свой WAF. aiSiteReady запускает три проверки коммерции и оценивает магазин от 0 до 100.

Что нужно ИИ-агенту-покупателю от вашего магазина?

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

OpenAI пишет, что фид не нужен, если ChatGPT уже обходит ваш сайт, и что покупки завершаются на сайтах или в приложениях продавцов (OpenAI). Путь Google начинается с настроек Merchant Center (доставка, возвраты и фид товаров) ещё до любого API (Google). Вот восемь слоёв, у каждого — признак, что он готов.

Слои 1, 2, 3, 7 и 8 — обычная инженерия. Слои 4 и 5 — опубликованные спецификации, но Google и OpenAI ограничивают запуск. Слой 6 в основном зависит от вашего платёжного провайдера и пока формируется.

UCP vs ACP vs AP2 vs x402: какой слой за что отвечает?

Они работают на разных уровнях, поэтому это не простые конкуренты. UCP и ACP оба покрывают обнаружение и чекаут, AP2 отвечает за авторизацию платежа, а x402 — за оплату каждого запроса по HTTP.

UCP (Universal Commerce Protocol) — это модель «профиль и возможности»: агенты загружают ваш профиль и договариваются, какие возможности (checkout, catalog, cart, order) поддерживают обе стороны (спецификация UCP). Его совместно разработали Shopify и Google (Shopify Engineering), а теперь в его управляющий совет входит и Stripe (объявления UCP). ACP (Agentic Commerce Protocol) — набор спецификаций для чекаута, делегированной оплаты и товарных фидов; OpenAI пишет, что в ChatGPT сегодня он обеспечивает поиск товаров через переданные данные о них (OpenAI). Практическая разница в обнаружении: UCP забирают с вашего домена, а фид ACP отправляют платформе.

Слой 6: платежи. AP2 (Agent Payments Protocol), опубликованный Google, описывает подписанные мандаты, подтверждающие, что именно разрешил пользователь: мандат на чекаут для продавца и платёжный мандат для платёжной стороны. Он расширяет A2A и UCP, а его стандартизацию продолжают рабочие группы FIDO Alliance (AP2). В UCP это необязательное расширение чекаута (UCP и AP2). Последний релиз AP2 — v0.2.0 (релизы AP2).

x402 устроен иначе: сервер отвечает HTTP 402 с заголовком PAYMENT-REQUIRED, а клиент платит и повторяет запрос. Он оценивает один запрос ресурса, поэтому естественнее подходит для API и платного контента, чем для корзины с доставкой и налогами (x402). Для большинства магазинов и AP2, и x402 — слои, за которыми стоит следить, а не строить.

Как сделать страницы товаров читаемыми для агентов?

Начните со страницы: на неё указывают все остальные слои. Слой 1: каждому товару (или варианту с собственным URL) нужна стабильная страница, доступная краулерам, с ценой в исходном HTML. Правила Google для merchant listings задают минимум (merchant listings в Google):

• Подходят только страницы, где покупатель может купить товар.
• Страница не должна быть закрыта robots.txt, noindex или логином.
• Разметку Product нужно размещать в исходном HTML, потому что разметка, сгенерированная JavaScript, может сделать обходы для Shopping реже и менее надёжными, а цена и наличие меняются быстро.
• Для нескольких валют нужен отдельный URL на каждую валюту.

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

Слой 2: Product JSON-LD, совпадающий со страницей. Google требует у Product поля name, image и offers, а у Offer — price больше нуля и priceCurrency. Рекомендуются availability, brand, GTIN или MPN, itemCondition, а также данные о доставке и возвратах, лучше как единая глобальная политика в разметке Organization, на которую offer ссылается через @id (merchant listings в Google).

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trail running shoes, black",
  "image": [
    "https://shop.example.com/img/trail-black-1x1.jpg",
    "https://shop.example.com/img/trail-black-4x3.jpg"
  ],
  "description": "Waterproof trail shoes with a rubber outsole.",
  "sku": "TRAIL-BLK-10",
  "gtin14": "00012345600012",
  "brand": { "@type": "Brand", "name": "Northline" },
  "offers": {
    "@type": "Offer",
    "url": "https://shop.example.com/products/trail-black",
    "priceCurrency": "USD",
    "price": 79.99,
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "hasMerchantReturnPolicy": { "@id": "https://shop.example.com/returns#policy" },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "hasShippingService": { "@id": "https://shop.example.com/shipping#policy" }
    }
  }
}
</script>

Три детали, на которых спотыкаются. Для availability используйте полный URL schema.org: Google принимает и короткие имена, но URL однозначен. Указывайте GTIN, только если уверены, что он верный: Merchant Center отклоняет товары с неверным. И держите разметку равной видимой цене и вашему фиду, ведь Google относит расхождения между фидом и сайтом к частым причинам проблем с товарами (Merchant Center).

Готово выглядит так: в исходном HTML есть один Product, у чьего Offer указаны цена и валюта, Rich Results Test показывает валидный merchant listing, а значения совпадают с тем, что видит покупатель.

Как опубликовать данные о товарах, которые агенты смогут загрузить?

Слой 3 — товарный фид: файл или API, который вы отправляете каждой платформе, а не то, что агенты обходят сами. Важны два фида, и работают они по-разному.

Google принимает фид в Merchant Center как текстовый файл, XML или через Merchant API. Его спецификация помечает как обязательные id, title, description, link, image_link, availability и price и рекомендует GTIN (Merchant Center). Чекаут UCP в Google строится на том же фиде: товары включаются атрибутом native_commerce, а id из фида должен совпадать с идентификатором товара в вашем API чекаута, иначе сопоставьте их через merchant_item_id (Google).

OpenAI принимает файл по SFTP (предпочтителен Parquet; jsonl.gz, csv.gz и tsv.gz тоже подходят) в виде полного снимка не реже раза в сутки либо API с эндпоинтами Feeds, Products и Promotions для инкрементальных обновлений (OpenAI, Get started). Для каждого товара обязательны девять полей (OpenAI).

{"item_id":"TRAIL-BLK-10","title":"Trail running shoes, black, size 10","description":"Waterproof trail shoes with a rubber outsole.","url":"https://shop.example.com/products/trail-black?size=10","brand":"Northline","seller_name":"Northline Outdoor","image_url":"https://shop.example.com/img/trail-black-1x1.jpg","availability":"in_stock","price":"79.99 USD"}

Продавцы подают заявку на подключение фида, а портал самообслуживания OpenAI обещает запустить до конца 2026 года. Шопинг работает для пользователей в США, а каталоги Shopify и Etsy уже интегрированы (OpenAI). В репозитории ACP Feed API назван push-моделью: продавцы отправляют данные каталога агенту, а агенты их не забирают (changelog ACP). У UCP фида нет: ваш сервер отвечает на capability каталога (поиск и lookup) вживую, а авторитетным остаётся чекаут (UCP).

Готово выглядит так: нет блокирующих ошибок, а выборочная проверка двадцати SKU показывает одинаковые цену, наличие и URL в фиде и в JSON-LD.

Как выглядят документы обнаружения и эндпоинты чекаута?

Слой 4 — небольшой JSON-файл по well-known URL, который сообщает, какой протокол вы поддерживаете и где находится API; слой 5 — сам API. Публикуйте файл, только если API за ним существует: агенты действуют по тому, что он обещает.

Файл UCP лежит по адресу /.well-known/ucp. Обязательные члены — ucp.version, ucp.services и ucp.payment_handlers (реестры должны присутствовать, даже если пусты) (спецификация UCP). Профиль должен отдаваться по HTTPS без редиректов, с Cache-Control: public и max-age не меньше 60 секунд (правила хостинга UCP). Google добавляет: файл должен быть публичным и не требовать аутентификации (Google). Урезанный профиль:

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": [
        {
          "version": "2026-08-25",
          "spec": "https://ucp.dev/2026-08-25/specification/overview/",
          "transport": "rest",
          "endpoint": "https://shop.example.com/ucp/v1",
          "schema": "https://ucp.dev/2026-08-25/services/shopping/rest.openapi.json"
        }
      ]
    },
    "capabilities": {
      "dev.ucp.shopping.checkout": [
        {
          "version": "2026-08-25",
          "spec": "https://ucp.dev/2026-08-25/specification/shopping/checkout",
          "schema": "https://ucp.dev/2026-08-25/schemas/shopping/checkout.json"
        }
      ]
    },
    "payment_handlers": {}
  }
}

Заполните payment_handlers по спецификации handler'а вашего платёжного провайдера; все члены описаны в гайде как опубликовать /.well-known/ucp.

Файл ACP — /.well-known/acp.json. Он есть в changelog и JSON-схеме релиза 2026-04-17, хотя текст RFC всё ещё называет себя предложением. Аутентификация не нужна, файл должен кэшироваться, а 404 означает «ACP здесь нет» (RFC обнаружения ACP).

{
  "protocol": {
    "name": "acp",
    "version": "2026-04-17",
    "supported_versions": ["2026-04-17"]
  },
  "api_base_url": "https://shop.example.com/acp/v1",
  "transports": ["rest"],
  "capabilities": { "services": ["checkout"] }
}

Одна оговорка, если вы сканируете этот файл: по состоянию на октябрь 2026 проба aiSiteReady всё ещё ожидает, что protocol — простая строка, поэтому помечает такой документ по спецификации как неполный (см. ограничения сканера в конце).

Оба файла статичны, поэтому веб-сервер может отдавать их напрямую.

location = /.well-known/ucp {
    alias /var/www/well-known/ucp.json;
    default_type application/json;
    add_header Cache-Control "public, max-age=3600" always;
    add_header Access-Control-Allow-Origin "*" always;  # наша проверка его ищет; спецификация этого не требует
}

location = /.well-known/acp.json {
    alias /var/www/well-known/acp.json;
    default_type application/json;
    add_header Cache-Control "public, max-age=3600" always;
}

Слой 5 в обоих протоколах устроен одинаково: создать, обновить и завершить сессию чекаута. UCP добавляет конечный автомат и continue_url, который передаёт покупателя на вашу страницу, когда агент не может довести дело до конца (Shopify Engineering). Спецификация чекаута ACP описывает пять эндпоинтов по HTTPS, обязательное ядро — create, update и complete, — и вебхуки событий заказа (OpenAI). Google просит три базовых REST-эндпоинта (Google).

Обе платформы ограничивают доступ к чекауту. Google просит встать в лист ожидания и пишет, что интеграцию должны одобрить до запуска в AI Mode в Google Поиске и в Gemini (обзор UCP от Google). OpenAI пишет, что первой версии Instant Checkout не хватало нужной гибкости, поэтому продавцы теперь используют собственный чекаут, а сама компания сосредоточена на поиске товаров (OpenAI, март 2026); спецификация чекаута при этом всё ещё опубликована. Поэтому строить слой 5 стоит тогда, когда об этом просит поверхность, через которую вы реально продаёте, а сначала выяснить, что уже умеет ваша платформа.

Агенты, которые управляют вашей страницей вместо API, работают со скриншотами, исходным HTML и деревом доступности (web.dev), поэтому настоящая кнопка button с понятным именем по-прежнему важна.

Как не дать заблокировать агентов-покупателей?

Слой 7: трафик агентов должен получать 200 на путях товаров, корзины и API, а для агентов, запущенных пользователем, привратник — ваш WAF, потому что robots.txt к ним может не применяться. OpenAI перечисляет OAI-SearchBot для поиска, GPTBot для обучения и ChatGPT-User для действий, которые запускает человек, и для последнего правила robots.txt могут не действовать (OpenAI). Google описывает Google-Agent — агентов, которые ходят по вебу и действуют по запросу пользователя, — и пишет, что фетчеры, запущенные пользователем, как правило, игнорируют robots.txt (Google). Синтаксис для первых двух задач — в материале как управлять ИИ-краулерами в robots.txt.

FAQ Google по UCP даёт маркеры для третьей задачи: заголовок UCP-Agent, User-Agent, начинающийся с Google/UCP, и проверки здоровья от Google-UCP-Prober/1.0. User agent можно подделать, поэтому сверяйтесь с опубликованными диапазонами IP и аутентифицируйте токенами, а не блокируйте по странам (Google). Страницы-challenge и общие лимиты по IP могут оборвать агента посреди оформления заказа, поэтому посмотрите, что ваш сервер им ответил.

grep -E 'ChatGPT-User|OAI-SearchBot|Google-Agent|Google/UCP' /var/log/nginx/access.log \
  | awk '{print $9}' | sort | uniq -c | sort -rn

Пример вывода:

  412 200
   37 304
    9 403

Любой 403 или 429 стоит разобрать. Проверка категории Правила для ботов в aiSiteReady читает robots.txt и не видит поведения WAF. Если ваш WAF блокирует сам сканер ответом 403 или 429 на странице, проверки коммерции вернут unknown вместо fail, но баллов это всё равно не принесёт; а если WAF блокирует только пути /.well-known/, сканер решит, что документа нет вовсе.

Как проверить каждый слой и не дать проверке устареть?

Выполните несколько команд curl по публичному URL и поставьте их на расписание: слой 8 — это и есть оно. Берите публичный edge-URL, а не localhost: большинство поломок живёт в шаблонах, CDN и правилах WAF.

SHOP=https://shop.example.com

# Слой 2: сколько блоков JSON-LD в исходном HTML (JavaScript не исполняется)?
curl -sSL "$SHOP/products/trail-black" | grep -c 'application/ld+json'

# Слой 4: статус, тип и заголовок CORS документа обнаружения
curl -sSI "$SHOP/.well-known/ucp" | grep -iE '^(HTTP|content-type|access-control)'

# Слой 4: что объявляет документ
curl -sS "$SHOP/.well-known/ucp" | python3 -c 'import sys, json; u = json.load(sys.stdin)["ucp"]; print(u["version"], list(u["services"]), list(u.get("capabilities", {})))'

Пример вывода для магазина, который публикует UCP:

1
HTTP/2 200
content-type: application/json
access-control-allow-origin: *
2026-08-25 ['dev.ucp.shopping'] ['dev.ucp.shopping.checkout']

Первое число должно быть больше нуля, а 404 на /.well-known/acp.json — нормальный ответ, если вы не используете ACP. Этот скрипт запускает те же проверки и завершается с ненулевым кодом при сбое, так что по нему cron или CI может поднять тревогу.

#!/usr/bin/env bash
# использование: check-store.sh https://shop.example.com /products/trail-black
set -u
SHOP="${1:?usage: check-store.sh https://shop.example.com /products/sku}"
PRODUCT="$SHOP${2:?product path}"
rc=0
pass() { echo "OK    $1"; }
fail() { echo "FAIL  $1"; rc=1; }
skip() { echo "SKIP  $1"; }

# Слои 1–2: цена и валюта в серверном JSON-LD
if curl -fsSL "$PRODUCT" | python3 -c '
import sys, re, json
def as_list(value):
    return value if isinstance(value, list) else [value]
def nodes(data):  # обходит @graph, массивы и варианты ProductGroup
    for item in as_list(data):
        if isinstance(item, dict):
            yield item
            for key in ("@graph", "hasVariant"):
                yield from nodes(item.get(key, []))
def priced(offer):  # Offer или AggregateOffer, внутри которого он лежит
    if not isinstance(offer, dict):
        return False
    if offer.get("price") and offer.get("priceCurrency"):
        return True
    return any(priced(inner) for inner in as_list(offer.get("offers", [])))
html = sys.stdin.read()
for block in re.findall(r"<script[^>]*application/ld\+json[^>]*>(.*?)</script>", html, re.S):
    try:
        data = json.loads(block)
    except ValueError:
        continue
    for node in nodes(data):
        if "Product" in as_list(node.get("@type")) and any(priced(o) for o in as_list(node.get("offers", []))):
            sys.exit(0)
sys.exit(1)'; then
  pass "Product + Offer with price and priceCurrency in the raw HTML"
else
  fail "no Product + Offer with price and priceCurrency in the raw HTML"
fi

# Слой 4: документы обнаружения (404 значит «не внедрено», а не сбой)
for path in .well-known/ucp .well-known/acp.json; do
  read -r code ctype < <(curl -sS -o /dev/null -w '%{http_code} %{content_type}\n' "$SHOP/$path")
  if [ "$code" = "404" ]; then
    skip "/$path is not published"
  elif [ "$code" = "200" ] && [[ "$ctype" == application/json* || "$ctype" == *+json* ]]; then
    pass "/$path answers 200 with JSON"
  else
    fail "/$path answered $code ($ctype)"
  fi
done
exit $rc

Я запустил эти проверки 2 октября 2026 года на одной странице товара у каждого из 15 известных интернет-магазинов. Исходный HTML я забирал из сессии браузера, потому что несколько витрин ограничивают обычный curl с моего подключения. На двенадцати страницах серверный JSON-LD содержал Product с Offer, в котором указана цена. У остальных трёх узла Product не было вовсе, а одна из них не отдавала JSON-LD совсем. Одна страница прошла только потому, что её цена лежала в Offer внутри AggregateOffer, — поэтому скрипт и обходит вложенные offers.

Документы обнаружения разделились по платформам. Пять магазинов ответили на /.well-known/ucp JSON-документом, и все они работают на витрине, которую хостит Shopify; два магазина на Shopify с собственным фронтендом вернули 404. acp.json не отдал никто. Один магазин ответил на оба пути HTML-страницей с кодом 200 — это та самая заглушка на любой путь, ради которой в скрипте и проверяется content type.

Запускайте его после каждого деплоя темы или плагина: разметка живёт в шаблонах, и правка там может убрать её без видимых отличий. Со стороны Google валидаторы — это Rich Results Test и диагностика Merchant Center. Для слоёв за пределами коммерции так же устроен 30-минутный аудит готовности к ИИ-агентам.

Чек-лист агентной коммерции для печати

• Слой 1: страницы товаров отдают 200 с названием, ценой и наличием в исходном HTML, один URL на вариант и валюту.
• Слой 2: JSON-LD Product с name, image и Offer, у которого есть price, priceCurrency и URL availability из schema.org.
• Слой 2: корректный GTIN или никакого; доставка и возвраты подключены из разметки Organization.
• Слой 3: фид принят Merchant Center, а если заявку одобрили, то и OpenAI, без блокирующих ошибок.
• Слой 3: цена, наличие и URL совпадают в фиде и в JSON-LD на выборке из двадцати SKU.
• Слой 4: /.well-known/ucp публичен, это JSON, в нём только то, что вы обслуживаете; /.well-known/acp.json есть, только если есть API ACP.
• Слой 5: create, update и complete чекаута работают в песочнице.
• Слой 6: платёжные handlers соответствуют вашему провайдеру; AP2 и x402 остаются в списке наблюдения.
• Слой 7: в логах 200, а не 403 или 429, для user agent'ов агентов-покупателей.
• Слой 8: скрипт curl запускается по расписанию и после каждого деплоя, с оповещением.

Как проверить весь магазин на готовность к агентной коммерции?

Проверить одну страницу товара вручную — нормально; проверять каждый шаблон после каждой смены темы — нет, и именно эту работу делает aiSiteReady. Он загружает вашу страницу так, как это сделал бы агент: через защищённый от SSRF фетчер только для чтения, без исполнения JavaScript, — и в категории Коммерция у него три проверки. Профиль «Интернет-магазин» удваивает вес этой категории, а профили «Контентный сайт» и «API/приложение» её пропускают. В остальных случаях на сайте вообще без коммерческих сигналов проверки «Структурированные данные товаров» и «Сигналы агентной коммерции» возвращают N/A вместо FAIL, тогда как «Подсказки товарного фида» всё равно дают FAIL. Точные веса — на странице методологии.

Четыре ограничения, которые стоит знать, прежде чем верить зелёному результату:

• Один URL. Сканируйте страницу товара, а не главную: на главных редко бывает полная разметка Product и Offer.
• Опубликовано, а не работает. Сканер никогда не вызывает ваши эндпоинты чекаута, api_base_url и URL фидов. Файл UCP за редиректом он всё равно засчитывает, хотя спецификация запрещает там редиректы, а ссылку, которая лишь называет протокол, засчитывает, не загружая файл за ней.
• Отправленные фиды не видны. Он находит ссылки и метаданные, но не загрузки, а голая ссылка на llms.txt в HTML считается сигналом обнаружения, что щедро.
• Два правила строже спецификаций. По состоянию на октябрь 2026 проба ACP ожидает, что protocol — простая строка, тогда как схема 2026-04-17 делает его объектом, поэтому файл по спецификации помечается как неполный. А профиль UCP без Access-Control-Allow-Origin — лишь частичный, если это единственный протокольный сигнал, хотя спецификация UCP про CORS ничего не говорит: это наше правило.

Запустите бесплатное сканирование с профилем «Интернет-магазин» на странице товара и посмотрите, какие слои агент находит, — на английском, украинском или русском. Смежные гайды: структурированные данные для ИИ-агентов, как опубликовать /.well-known/ucp и правила для ИИ-краулеров в robots.txt.

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

У IMozz 20 лет в разработке ПО, а последний год он строит продукты с помощью LLM. Он развивает aiSiteReady, сканер только для чтения, который проверяет, может ли ИИ-агент прочитать сайт. Сканер серверно рендерит собственный контент как рабочий пример.