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

Чек-лист агентної комерції для інтернет-магазину складається з восьми шарів: від сторінок товарів, доступних краулерам, до 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). Його останній реліз — v0.2.0 (релізи AP2).

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

Як зробити сторінки товарів читабельними для агентів?

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

• Підходять лише сторінки, де покупець може купити товар.
• Сторінка не повинна бути закрита 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 (Google, merchant listings).

<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 Search і в 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 з мого підключення. Дванадцять сторінок містили Product з Offer із ціною в серверному JSON-LD. У решти трьох вузла Product не було взагалі, а одна з них не віддавала жодного JSON-LD. Одна сторінка пройшла лише тому, що ціна стояла в Offer усередині AggregateOffer, — саме тому скрипт обходить вкладені Offer.

Файли виявлення розділилися за платформами. П'ять магазинів відповіли на /.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, тоді як «Підказки товарного фіду» однаково провалюються. Точні ваги — на сторінці методології.

Чотири обмеження, які варто знати, перш ніж вірити зеленому результату:

• Один 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, сканер лише для читання, що перевіряє, чи може ШІ-агент прочитати сайт. Сканер серверно рендерить власний контент як робочий приклад.