Methodology

What AUR measures

The Agent Usability Rating is a 0–100 score of how usable a website is for an AI shopping agent: can an agent acting for a shopper find the store and its products, read them reliably, trust who is selling and on what terms, and buy through a published protocol rather than by driving a browser. Higher is better; the levels below translate the number into words.

It is a passive HTTP scan. We fetch a handful of public pages and well-known documents and look at what comes back. We do not run a browser, execute JavaScript, log in, add anything to a cart, or attempt a purchase. A high AUR means the store is legible and transactable to agents in principle; it says nothing about whether a given agent will choose to recommend it.

The score

Every check is worth a fixed number of points and scores between zero and that weight (many checks award partial credit). The points add up to a raw score out of 100 across four pillars. Gates then cap the result, and a curve maps the raw score to the final AUR.

Pillars

Gates

A gate names the one thing a site must fix to rise above a ceiling. When a gate triggers, the final AUR cannot exceed its cap, whatever the raw score. Gates are shown on the report with the reason they triggered.

The curve

The raw score is passed through a convex curve, AUR = 100 × (raw / 100)^1.5, rounded to the nearest whole number. The last points are the hardest to earn: being open and legible gets a store into the sixties, but the nineties require an agent-native way to buy.

Levels

Every check

28 checks, grouped by pillar. The description says what earns full credit. Check titles on a report link back here.

User agents we send

Access checks request the same pages with each of these user-agent strings and classify the response as content, a block, a challenge page, or an empty JavaScript shell. Shopping agents are the ones that fetch pages on behalf of a live user, as opposed to crawlers that build an index or a training set; they matter most.

Blocked us vs. blocks agents

The scanner runs from datacenter IP addresses, like every AI agent does. Before probing with agent names, we fetch the homepage and product page with a plain Chrome user agent. If even that is blocked or challenged, the site is rejecting cloud traffic wholesale, and the report carries a scanner blocked flag so readers know that the per-agent results reflect network-level blocking rather than rules aimed at specific agents.

The score still counts. What blocked us blocks the agents too: ChatGPT, Claude, Perplexity, and Meta all fetch from the same kind of infrastructure, and a store that challenges every non-residential visitor is, in practice, closed to them. The flag is there so the store can tell the difference between “we block AI” and “our bot manager is too aggressive”, which have different fixes.

Platform-granted capabilities

Some capabilities come from the commerce platform rather than from anything the store built. When Shopify provides a store’s UCP profile, UCP MCP endpoint, or Storefront MCP server, the check is marked (via Shopify). The points count the same, because an agent does not care who built the endpoint; the label is there so that stores on other platforms understand what they are comparing against, and so that a Shopify store knows the fix is a setting rather than a build.

What we can’t see

• ACP. The Agentic Commerce Protocol (OpenAI and Stripe) has no public discovery document, so a passive scan cannot tell whether a store accepts ACP checkouts. The ACP check is self-reported by the merchant and labelled as such on the report.
• x402 and MPP. Pay-per-request protocols are not evaluated in version 1.
• Checkout itself. We never place an order, so we cannot see whether the checkout works for an agent once it gets there. That is what the Agent Walk is for.

Scanner policy

• A scan makes roughly 25–40 requests: GET and HEAD requests for the homepage, one product page, one listing or search page, robots.txt, the sitemap, the policy pages, and a set of well-known documents, plus two documented JSON-RPC tools/list POSTs to the MCP endpoints.
• Access probes repeat the homepage and product page with the agent user agents listed above. Everything else is sent as Mozilla/5.0 (compatible; AURbot/1.0; +https://opentools.com/aur).
• No logins, no cart mutations, no form submissions, no purchases.
• No crawling: we never follow links beyond the handful of pages above, and we read at most the first few kilobytes of a sitemap.
• Scans of the same domain are cached and rate-limited, so a store is not re-fetched on every page view.
• To opt out, disallow AURbot in robots.txt. We honour it: the domain is shown as “opted out” instead of being scored.

  User-agent: AURbot
  Disallow: /

• Questions, corrections, or a request to remove a domain: team@opentools.com.

Changelog

• v1.0.0 — initial rubric.
• v1.0.1 — a single HTTP 429 is retried once after the server’s Retry-After (as an agent would), and user-agent probes are paced instead of sent as a burst, so a site’s rate limiter no longer counts as blocking.

Scores are stored with the engine version that produced them, so a rubric change never silently moves a published score.