UCP Checker evaluates merchant domains in two parts:

1. Static Analysis — Does a valid UCP manifest exist? Is the JSON well-formed? Are the required fields present? Does robots.txt allow agents? This is the foundation: a published, valid, agent-reachable manifest.
2. UCP Score — A 0–100 composite that summarises agent-readiness across three weighted categories: Agent Discovery, UCP Conformance, and Capability Coverage. Static analysis feeds the score; opt-in functional probes refine it.

Static analysis tells you whether a merchant publishes a UCP manifest. The UCP Score tells you how well agents can find, parse, and use it. Both layers are documented below. For full end-to-end agent shopping simulations against live infrastructure, see UCP Playground — a complementary product.

Static analysis crawls the public manifest file and evaluates it against the UCP specification. This data powers the Merchant Directory and individual status pages.

Each audit runs a two-step sequence to capture both policy and technical readiness:

1. Policy Audit: Fetch https://{domain}/robots.txt and parse directives for wildcard * plus the major AI agents (GPTBot, Google-Extended, ClaudeBot, Applebot-Extended, CCBot). This determines if agents are legally allowed to index the manifest.
2. Manifest Validation: Request https://{domain}/.well-known/ucp with User-Agent: UCPCheckerBot/1.0 (+https://ucpchecker.com/methodology) and Accept: application/json to gather the commerce capabilities.

All requests enforce HTTPS, follow up to 5 redirects, and timeout after 2 seconds to match agentic latency budgets.

We measure how fast the static manifest file downloads (connection + SSL + transfer). Latency feeds into the UCP Score's Discovery component. Agents typically abandon a request after ~2 seconds.

• 🚀 Excellent: < 200ms – ideal for real-time agent workflows.
• ⚠️ Fair: 200–800ms – acceptable but may slow multi-step reasoning.
• 🐌 Slow: > 800ms – high risk of agent timeout.
• Unreachable: > 2000ms – we abort and mark the domain unreachable.

In addition to our own crawler, we audit robots.txt access for the foundational model bots powering the agentic economy:

• GPTBot (OpenAI / ChatGPT)
• Google-Extended (Gemini / Vertex AI)
• ClaudeBot (Anthropic)
• Applebot-Extended (Apple Intelligence)
• CCBot (Common Crawl)

If a bot isn’t explicitly mentioned, we inherit the wildcard * policy.

Based on the HTTP response, we classify merchants into one of the following statuses:

Error Semantics & Evidence

Every status is backed by the HTTP response we received:

• 404 Not Detected: We store the 404 code and mark the crawl as evidence that no manifest is present.
• 401/403 Blocked: If a bot wall blocks the request we record the error body so merchants can see what needs to be allowed.
• 5xx / Connection Issues: We classify them as Unreachable and log whether it was a timeout, DNS failure, SSL mismatch, or server error.
• Invalid JSON: We keep the response payload (when safe) so teams can diff malformed manifests.

This evidence appears on each status page so LLMs and humans can cite exactly why a readiness decision was made.

For HTTP 200 responses, we validate the JSON structure against the spec version declared in the manifest. Validation is version-aware — we apply the rules for the declared version, falling back to the latest known rules for unrecognised versions. You can run this same validation yourself using the UCP Validator.

Currently supported spec versions: 2026-01-11, 2026-01-23, 2026-04-08, 2026-08-25 (current).

Required Fields

• ucp.version - The UCP specification version (YYYY-MM-DD format)
• ucp.services - Service definitions with transport and endpoint details
• ucp.payment_handlers - Payment handler configuration

Optional Fields

• ucp.capabilities - Supported capabilities (optional per spec; generates a warning if absent)
• keys - JWK Set of public keys for signature verification, at the manifest root. v2026-08-25 removed signing_keys[] and promoted keys[] as the canonical field; we accept either at every version, so older manifests keep validating (optional but recommended)
• ucp.supported_versions - Map of older protocol versions to their profile URIs (v2026-04-08+)
• ucp.capabilities under dev.ucp.common.* - v2026-08-25 split the spec into shopping/, payment/ and common/ domains; payment, location, loyalty and identity capabilities now live under dev.ucp.common.* and validate the same way

Version-Aware Validation (v2026-04-08+)

The v2026-04-08 spec introduced a distinction between platform profiles and business profiles. Business profiles (served at /.well-known/ucp) are what individual stores publish. Platform profiles are what platforms like Shopify publish upstream.

For business profiles, spec and schema URLs on services, capabilities, and payment handlers are not required — stores inherit these from their platform. UCPChecker validates accordingly: stores declaring v2026-04-08 or later will not receive warnings about missing spec or schema fields.

Example Valid Manifest

{
  "ucp": {
    "version": "2026-08-25",
    "services": {
      "dev.ucp.shopping": [{
        "version": "2026-08-25",
        "spec": "https://ucp.dev/specification/shopping/",
        "transport": "rest",
        "endpoint": "https://api.example.com/ucp/v1",
        "schema": "https://example.com/openapi.json"
      }]
    },
    "payment_handlers": {
      "com.example.processor": [{
        "id": "processor-1",
        "version": "2026-08-25",
        "spec": "https://example.com/ucp/handler",
        "schema": "https://example.com/ucp/handler/schema.json"
      }]
    }
  },
  "keys": [{
    "kid": "key-1",
    "kty": "EC",
    "crv": "P-256",
    "x": "example-x-coordinate",
    "y": "example-y-coordinate"
  }]
}

v2026-08-25 removed signing_keys[] and made keys[] — a JWK Set per RFC 7517 — the canonical root field every UCP verifier reads. Manifests still publishing signing_keys at the root keep validating here; we read either.

We mark a merchant as UCP ready when:

• A manifest exists at /.well-known/ucp.
• The manifest includes all required fields for its declared spec version (version, services, payment_handlers).
• Endpoints referenced in the manifest resolve to HTTPS URLs.

Merchants missing one of these requirements are labeled as Not Detected (no manifest), Invalid (manifest present but incomplete), or Blocked/Unreachable (infrastructure issues). This creates a transparent readiness scale for agentic commerce teams.

For each check, we store:

• Domain name (normalized, lowercase, no www)
• Status classification
• HTTP status code received
• UCP version (if detected)
• Capabilities summary and individual capability flags (checkout, identity linking, cart management, order, payment token, catalog)
• Transport types detected (REST, MCP, A2A, Embedded)
• Raw JSON response (if valid)
• Error message and validation warnings (if applicable)
• Timestamp of check (UTC)
• Response latency (ms)
• Robots policy verdict
• Per-bot policy matrix for GPTBot, Google-Extended, ClaudeBot, Applebot-Extended, CCBot
• Detected e-commerce platform (Shopify, WooCommerce, Magento, etc.)

We periodically re-check all domains in our index:

• Default interval: Every 24 hours
• Priority domains: More frequently for verified merchants
• On-demand: Users can trigger immediate checks via our checker tool

Observed vs. attempted. Not every attempt observes the store: a store's edge may rate-limit our crawler, or a host may not answer in time. An attempt that observes nothing is recorded, but it never changes a store's status, score, latency or any other measurement — those always describe the last observation, and every page and API response says when that was (observed) and, if later, when we last attempted. A store we have never managed to observe is shown as pending, not unreachable: unreachable is a verdict, and we do not issue verdicts we have not observed.

To be respectful to merchant servers:

• We space out requests across our batch crawls
• We cache results for 10 minutes to avoid duplicate requests
• We identify ourselves clearly via User-Agent
• We respect robots.txt where applicable

When processing domain input, we normalize as follows:

• Remove https:// or http:// prefix.
• Strip www. (but store it if a manifest only exists there).
• Remove trailing slashes, query strings, and paths.
• Convert to lowercase and trim whitespace.
• Support internationalized domains by preserving punycode.
• Deduplicate so shop.example.com and https://SHOP.example.com/ map to one canonical merchant record.

Example: https://www.Example.COM/path becomes example.com. This ensures every status page has a clean slug like /status/example.com.

The UCP Score is a 0–100 rating that summarises how agent-ready a store is. It is computed from the static analysis above plus a handful of public surface signals (and, when the user opts in, lightweight functional probes). Every store with a completed check has a score; the score appears on the store's /score/{domain} page and on the leaderboard.

The score is a weighted average of three category sub-scores, each independently rated 0–100:

Composite formula: Discovery × 0.30 + Conformance × 0.40 + Capabilities × 0.30, rounded to the nearest integer.

The composite score maps to a single-letter grade for quick comparison. Bands are tuned so a passing grade requires a complete, valid manifest plus working discovery — not just a published file:

By default the score is computed from static signals only — fast, cheap, safe for daily-cron-scale checking. When a user manually triggers a check (via the /score/{domain} page or the live checker), we additionally run two probe families:

• Transport probes — Each declared transport endpoint (MCP, REST, A2A) gets a benign request: MCP receives a JSON-RPC tools/list, REST/A2A receive a GET. Connection refused, DNS failure, TLS errors, and 5xx responses count as failures. A manifest that declares transports without working endpoints is the worst kind of broken — looks perfect to static validators, fails the moment an agent tries to use it.
• URL resolution probes — Every spec and schema URL declared in the manifest is fetched. Broken spec links suggest the manifest was copy-pasted without verification.

Probe failures are surfaced as recommendations on the score page and feed into the Capability Coverage sub-score. Probes are deliberately read-only and rate-limited — they do not exercise checkout or write any state.

Surface signals are public files and meta tags an agent (or LLM) reads alongside the manifest to understand the store. We capture all of them on every reachable domain:

• /llms.txt — An emerging convention (analogous to robots.txt) for hand-written briefs aimed at LLM agents. We capture the body for change-detection but do not score on its content.
• /sitemap.xml — Tells agents which pages are canonical and how often they change.
• Open Graph tags — Give agents and link unfurlers a clean title, description, and image.
• Organization JSON-LD — Structured brand identity (name, logo, social profiles, contact info) so agents can verify who you are.
• Mobile viewport — Mobile-originating agents render the page in a sandbox and use this tag for layout.

The presence of each signal is a Discovery sub-component. Missing signals are surfaced as low-effort recommendations on the score page.

Scores update on every check:

1. The 24-hour cron sweep refreshes static signals across the directory and recomputes scores. Probes do not run on the cron — that would be excessive load on merchants.
2. User-triggered checks (live checker, /score/{domain} "Run a fresh check", claimed-domain weekly rescan) include functional probes and platform detection.
3. Saved reports include a sparkline of your UCP Score across recent checks, so you can see your readiness trend at a glance.

If you have questions about our methodology or believe your domain has been incorrectly classified, please run a fresh check or contact us.

Check a Domain View Directory API & MCP docs