Preparing Commerce for AI Agents
80 checks across 8 scoring dimensions. Agent Ready Scanner measures how prepared a commerce store is for AI agents, from product discovery and protocol compliance to checkout, payments, infrastructure, and post-purchase workflows.
Commerce has traditionally been built around people navigating websites. Search engines added another layer, requiring stores to make pages crawlable and understandable by machines. Generative AI expanded that further, allowing customers to research products, compare options, and receive recommendations through conversational interfaces.
AI agents take this one step further. They do not only need to find and understand a product. They may need to check availability, compare variants, understand shipping and return policies, interact with checkout, use supported payment infrastructure, and retrieve order information after a purchase.
"A storefront can work perfectly for a human while still being difficult for an AI agent to understand or transact with."
Product pages may lack structured information, crawlers may be blocked, checkout may depend entirely on browser interactions, or APIs may not expose the capabilities an agent needs.
Agent readiness therefore goes beyond SEO or product schema. It depends on whether the complete commerce stack can support discovery, understanding, transactions, payments, and fulfillment through machine-readable interfaces. Agent Ready Scanner is designed to measure that readiness.
The scanner evaluates a store using 80 checks across eight scoring dimensions. It examines publicly accessible pages, headers, structured data, manifests, product feeds, APIs, checkout signals, payment infrastructure, and post-purchase capabilities. The scan does not require store credentials and does not make changes to the merchant's environment.
In Phase A, a shared context builder makes a fixed set of concurrent HTTP requests to the target and stores all results in a single ScanContext object. The homepage, robots.txt, sitemap, UCP manifest, ACP feed, TLS handshake, product pages, and checkout page are fetched here so the target is not requested again for every individual check.
| Resource | Request | What is captured |
|---|---|---|
| Homepage | GET https://{target}/ | HTML, headers, status, negotiated HTTP version |
| robots.txt | GET https://{domain}/robots.txt | Bot rules and content validation |
| Sitemap | /sitemap.xml, /sitemap_index.xml, /sitemap-index.xml | Product URLs and sitemap structure |
| UCP manifest | GET https://{domain}/.well-known/ucp | JSON, latency, headers, redirects |
| ACP feed | Known ACP feed paths | Feed availability and JSON structure |
| TLS info | Raw TLS socket to {domain}:443 | TLS version and cipher |
| Product pages | Discovered product URLs | HTML, headers, structured data |
| Checkout page | Checkout, cart, or basket URL | Checkout accessibility and redirects |
If a sitemap index is detected, the scanner can fetch a limited number of child sitemaps and combine their product URLs. Product URLs are identified from the sitemap and homepage links, then sampled rather than crawling the entire catalog.
In Phase B, each of the 80 checks reads from this shared context. Most checks do not make another HTTP request. They inspect the HTML, headers, JSON, structured data, or network information already collected. A smaller group of checks makes additional requests where live validation is necessary.
| Check | Validation |
|---|---|
| UCP - 07 | OPTIONS or HEAD against declared endpoints |
| UCP - 12 | OAuth metadata discovery |
| UCP - 14 | Capability schema URI validation |
| IR - 03 | Product page TTFB measurement |
| IR - 04 | Timed UCP manifest request |
| ACP - 04/05/06 | Checkout endpoint POST validation |
| ACP - 08 | Webhook path validation |
| PP - 01 | Order tracking endpoint validation |
This architecture separates data collection from evaluation. It reduces unnecessary traffic while ensuring that multiple checks evaluate the same underlying response.
All requests use the same HTTP client with a custom User-Agent, redirect following, HTTP/2 support, and an SSRF guard that validates every destination and redirect hop.
Each check returns pass, warning, fail, or skip. Severity levels of critical, high, medium, and low determine how heavily each result affects the final score.
Skipped checks reduce coverage confidence rather than automatically lowering the readiness score.
Emerging protocol checks such as UCP and ACP may also return warnings instead of hard failures where a missing storefront signal does not conclusively prove that a capability is unavailable.
This dimension evaluates whether the store exposes the technical capabilities required by the Universal Commerce Protocol. Checks cover manifest reachability and JSON validity, version format, declared services and capabilities, transport validation, endpoint liveness, latency, CORS, TLS 1.3, payment handlers, OAuth metadata, capability versioning, and schema URI resolution.
ACP checks evaluate whether the store exposes machine-readable product and transaction capabilities for agentic commerce. The scanner looks at ACP feed structure, required field coverage across sampled products, feed freshness, checkout responsiveness, API-Version and Idempotency-Key support, Stripe detection, webhook reachability, Stripe SPT, product data richness, pagination, compression, and ChatGPT shopping presence.
AI agents need reliable product information before they can make a recommendation or transaction. The scanner evaluates Product JSON-LD, including @graph structures, required product fields, offers, price, currency, availability, ratings, variants, BreadcrumbList, Open Graph product tags, image quality, alt text, merchant feed signals, and canonical URLs.
The goal is not only to detect whether structured data exists, but whether it contains enough information for an agent to understand and compare the product accurately.
Agent interactions can involve multiple dependent requests, so infrastructure quality directly affects the experience. Checks cover HTTPS enforcement, TLS 1.3, product page TTFB, API latency, content-type correctness, error response quality, HTTP/2 or HTTP/3 negotiation, cache headers, response compression, and HSTS configuration.
A store may expose the correct APIs but still provide a poor agent experience if those APIs are slow, inconsistent, or return responses that machines cannot reliably interpret.
Agent Ready Scanner evaluates robots.txt rules individually for GPTBot, Googlebot, Google-Extended, ClaudeBot, CCBot, Amazonbot, PerplexityBot, and Applebot-Extended. It also checks sitemap availability, product URL detection, sitemap freshness, WAF or CDN bot blocking, and rate-limit headers.
The scanner also validates whether machine-readable resources are genuine. For example, a request for robots.txt may return a 200 status while actually serving an HTML security or login page. That response is not treated as a valid robots.txt file.
A product can be discovered and selected successfully but still fail at the transaction stage. Payment readiness checks include Stripe integration, Google Pay, Apple Pay, PayPal, payment tokenization, raw card input detection, UCP payment handler declarations, and multi-currency support.
This dimension focuses on whether the store's payment layer can support secure machine-assisted transactions rather than only browser-based checkout.
Agentic commerce continues after checkout. Customers may expect an AI assistant to answer questions about shipment status, returns, delivery estimates, or order tracking.
The scanner evaluates order tracking endpoints, MerchantReturnPolicy, OfferShippingDetails, delivery time declarations, and UCP fulfillment and order capabilities.
Tracking paths are validated to confirm that they expose genuine order functionality or an appropriate authentication boundary rather than simply matching a common URL pattern.
Commerce platforms expose different capabilities and require different implementation paths. Agent Ready Scanner detects platform signals and evaluates relevant capabilities for systems such as Shopify, WooCommerce, Magento, BigCommerce, Salesforce Commerce Cloud, and headless or composable implementations.
Platform-specific checks include agent applications, payment capabilities, commerce plugins, structured data modules, merchant feed connectors, platform version requirements, and headless architecture signals.
Every external dependency sits behind a factory with interchangeable providers. Prompts live in plain text files outside the code, so behavior is tuned by editing prompt text rather than shipping a release.
80 checks across 8 scoring dimensions. No store credentials required, and no changes made to your environment.
