Ten days after UCP launched on January 11th, we started monitoring manifests. Not a one-time crawl — a continuous, automated check of every domain in our pool, every 24 hours. We wanted to answer a question that a single scan can't: what happens to these manifests over time?

A month later, our crawler has run over 24,000 checks across 2,008 domains. Here's what the data shows — and what it means for anyone building on UCP.

#The monitoring pool

Our crawler currently tracks 2,008 domains. That number has grown steadily since January, with new domains entering the pool from four sources:

• Browser extension: 1,480 domains — our Chrome extension probes /.well-known/ucp on every storefront visited and feeds new domains back into the monitoring pool automatically. It's become the single largest discovery channel, with a 98.4% verified rate — the stores it finds are overwhelmingly real merchants with live manifests.
• Crawler: 407 domains — a proprietary crawl engine that continuously discovers new UCP-enabled stores.
• Web: 120 domains — manual checks submitted through ucpchecker.com by developers and store owners testing their own implementations.
• Bulk check: 1 unique domain — batch submissions where users paste lists of domains for checking. The count here only reflects net-new domains that weren't already in the pool — most bulk submissions are domains we're already tracking.

No single source covers the full picture. The crawler finds known stores systematically. The extension picks up storefronts that don't appear in any directory — niche brands, regional retailers, development endpoints. Web submissions surface stores from developers actively building on UCP. Together, the four channels give us broader coverage than any one approach could achieve alone.

On any given day in the last two weeks, we're checking between 1,500 and 2,000 domains across all sources.

Of those 2,008 domains, here's where they stand as of February 27th:

• 1,669 verified — live, valid UCP manifest at /.well-known/ucp
• 124 not detected — endpoint exists but no valid manifest
• 95 blocked — domain is actively blocking our crawler
• 65 unreachable — endpoint times out or DNS fails
• 55 invalid — manifest exists but fails validation

83% of the domains we monitor have a working UCP manifest. That's a strong baseline — but the interesting story is in the other 17%, and in what happens to manifests that were verified yesterday.

#Manifests break. More often than you'd think.

Over the monitoring period, our crawler detected 457 status changes across the pool. 95 of those were breakages: a domain that was verified on one check came back invalid, unreachable, or blocked on the next.

The breakdown:

• 68 verified → invalid — manifest still exists but fails validation. This is the most common failure mode. A deployment pushes bad JSON, a field goes missing, or a version string gets malformed.
• 14 verified → unreachable — endpoint times out entirely. Infrastructure issue, DNS change, or CDN misconfiguration.
• 7 verified → blocked — domain starts rejecting the crawler. Usually a WAF rule change or overzealous bot protection.
• 6 verified → not detected — manifest disappears. The endpoint returns 404 or redirects.

88 unique domains experienced at least one breakage during the month. That's roughly 5% of verified stores going down at some point — and then, in many cases, coming back.

#The recovery cycle

The good news: most breakages are temporary. We observed 96 recoveries — domains that were broken or missing and then came back.

• 69 invalid → verified — bad deployment gets rolled back or fixed
• 13 unreachable → verified — infrastructure recovers
• 10 not detected → verified — new manifest published
• 4 blocked → verified — bot rules relaxed

This creates a pattern we're calling the "manifest recovery cycle." A store's UCP endpoint breaks — usually through an invalid manifest — and typically recovers within 24–48 hours. A caveat: we're running a free service with a 24-hour crawl cycle, so the actual recovery time could be shorter than what we can measure. A store that breaks and fixes within a few hours between our checks wouldn't show up as a transition at all — meaning the true breakage rate is likely higher than what we're reporting here.

The implication for agent developers: just because a store worked yesterday doesn't mean it works today. And just because it's broken now doesn't mean it's gone.

#The flappers

32 domains showed signs of persistent instability — oscillating between working and broken states multiple times over the month. We're calling these "flappers."

The most unstable endpoint in the pool flipped status 22 times in a month. Others in the top 10 include major retailers and well-known tech companies — names you'd expect to have stable infrastructure. Some of these are running custom UCP implementations outside Shopify, which may explain the instability. Others appear to be testing or iterating in production.

Flapping is a signal. It tells you the endpoint exists and someone is actively working on it — but it's not yet reliable enough for an agent to depend on. For agent developers building production flows against specific stores, flapping domains need a different strategy than stable ones: retry logic, fallback handling, or simply waiting until the implementation stabilises.

#Who's blocking agents — and how

95 domains in our current dataset are actively blocking our crawler. The blocking breaks down into two categories:

• Firewall blocks (1,179 check instances) — the domain's WAF or CDN rejects the request before it reaches the UCP endpoint. This is the dominant pattern and includes major retailers like Kohl's, Macy's, Sears, REI, Neiman Marcus, and Tiffany.
• Robots.txt blocks (108 instances) — the domain explicitly disallows crawlers in their robots.txt file.

Here's the paradox we flagged in our first audit and it persists: some of these blocked domains have fully deployed UCP manifests. They've built the infrastructure for agentic commerce and then locked the front door. This is almost certainly an operational gap — the security team updating firewall rules without coordinating with the product team that shipped UCP — but for agents, the result is a hard bounce.

#Robots.txt: who's letting agents in?

Among the 1,669 verified domains, we check robots.txt for six major AI bot user agents. The access picture is overwhelmingly permissive — but not universal.

Per-bot breakdown across verified domains:

• UCPCheckerBot: 100% allowed (1,660 of 1,660 with data) — no verified store blocks us
• Applebot-Extended: 99.2% allowed, 13 domains block
• ClaudeBot: 99.2% allowed, 14 domains block
• CCBot (Common Crawl): 99.2% allowed, 14 domains block
• GPTBot: 99.1% allowed, 15 domains block
• Google-Extended: 99.1% allowed, 15 domains block

18 verified domains block at least one AI bot while maintaining a live UCP manifest. The pattern splits into two groups: stores that block everything (all five non-UCPChecker bots) and stores that selectively block one or two. The selective blockers are the more interesting case — a store that blocks GPTBot but allows ClaudeBot is making a deliberate choice about which agents can discover them.

The most common selective block is Google-Extended, which controls whether Google can use your content for AI training — a different concern than agent shopping access. Some stores appear to be conflating AI training crawlers with AI shopping agents in their robots.txt rules.

The broader signal is clear: stores that have committed to UCP have also committed to being discoverable by agents. The 1% that block specific bots are edge cases — and most of them look like they haven't updated their robots.txt since deploying UCP rather than making a conscious decision to exclude specific agents.

#Response times: fast, but with a long tail

Across 19,035 verified checks, the median manifest response time is 130ms. That's fast — well within the range needed for real-time agent interactions.

But the distribution has a meaningful tail:

• p50: 130ms
• p90: 185ms
• p95: 234ms
• p99: 748ms

1.5% of verified checks returned in over 500ms. A handful of domains are consistently slow — typically above 500ms — which points to infrastructure placement, CDN configuration, or an overloaded origin server rather than transient issues.

For agents making multiple tool calls per shopping session — search, details, cart, checkout — a slow manifest endpoint compounds. A 130ms response adds barely any latency to a session. A 750ms response, hit three or four times, adds 2–3 seconds of dead time that the user feels.

#The version story

The UCP spec uses date-based versioning — the official launch version is 2026-01-11. In practice, nearly every manifest in our dataset declares 2026-01-23, which is the version Shopify shipped when they deployed UCP across their platform. A smaller set of early adopters and custom implementations still reference the original 2026-01-11.

No new official spec version has been published since launch. That's a signal of stability — the schema, capabilities, and transport declarations from January are holding up in production across thousands of stores. As more platforms ship native UCP support — Salesforce, BigCommerce, and the WooCommerce ecosystem — we expect version diversity to increase, and monitoring for it will matter.

#Transports: MCP dominates, but the edges are interesting

UCP is transport-agnostic by design — a manifest can declare MCP, REST, Embedded, or A2A endpoints, and an agent picks the one it supports. Across our 1,669 verified domains, the transport landscape is heavily concentrated:

• MCP: 99.9% (1,668 domains) — the default Shopify transport. JSON-RPC connection, tool discovery via schema introspection, real-time tool calls.
• Embedded: 99.8% (1,665 domains) — declared alongside MCP on nearly every Shopify store. Embedded is designed to solve the payment wall: the agent builds the cart, and the merchant's checkout UI handles payment in a secure iframe. In practice, most agent experiences today still hand over a checkout URL that opens in a new window — the in-chat embedded checkout experience isn't widely implemented yet. But the transport is declared and ready in the manifest, which means the infrastructure is in place for when agent surfaces support it.
• REST: 0.5% (8 domains) — the familiar HTTP API pattern. Found exclusively on non-Shopify implementations: WooCommerce stores via UCPReady, custom builds, and a handful of development endpoints.
• A2A: 1 domain — Google's Agent-to-Agent protocol. Only one endpoint in the pool declares it so far — notable as the first A2A declaration we've seen in a UCP manifest in the wild, even if it looks like early experimentation rather than production deployment.

The dominant combination is ["mcp", "embedded"] — what Shopify ships by default. But the 8 REST-declaring stores are where the transport diversity lives. These include the WooCommerce implementations we profiled in our Playground deep dive, which expose REST alongside MCP and Embedded — giving agents three paths to the same store. One endpoint declares MCP, A2A, and REST together — the widest transport coverage in the dataset.

For agent developers, this matters because transport availability determines what your agent can do. An agent that only speaks MCP can reach 99.9% of the current ecosystem — but as non-Shopify platforms ship UCP with REST-first architectures, that percentage will shift. The agents that handle multiple transports will have the widest reach.

#Extensions: the capability layer beyond core UCP

UCP's capability system uses a reverse-domain namespace convention — dev.ucp.* for protocol-defined capabilities, com.* for vendor-specific extensions. In our benchmarks, we're seeing the first signs of this extensibility in the wild:

• dev.ucp.shopping.checkout: 150 stores — a structured checkout capability that goes beyond Shopify's default cart-to-checkout-URL flow. Found primarily on WooCommerce and custom implementations that manage the full checkout lifecycle (create, update, complete, cancel).
• dev.ucp.shopping.fulfillment: 149 stores — shipping and fulfillment capabilities declared as their own standalone service, separate from the core cart operations. Where Shopify bundles shipping into the cart flow, these implementations break it out so an agent can query fulfillment options independently.
• dev.ucp.shopping.catalog: 1 store — an alternative catalog interface distinct from the standard search_shop_catalog tool.

These capabilities are being tested in production by independent developers and may evolve as the spec matures. But they point to where UCP is heading: a modular capability system where different stores expose different operational surfaces, and agents negotiate what's available at discovery time.

This is fundamentally different from Shopify's current model, where every store gets an identical capability set. As the ecosystem diversifies, an agent will need to read the manifest, check which capabilities are declared, and adapt its flow accordingly. A WooCommerce store with dev.ucp.shopping.checkout offers a different agent experience than a Shopify store with the standard five tools — and both are valid UCP implementations.

#The benchmark picture

We've now benchmarked 1,183 domains on our scoring system (methodology at ucpchecker.com/methodology). The grades tell a clear story about where the ecosystem is:

• 9 A-grade stores — fast, complete, agent-ready from search to checkout
• 422 B+ stores — solid implementations with minor gaps
• 222 B stores — good but with checkout or data quality issues
• 84 C+ stores — functional but with significant reliability or speed gaps
• 141 C stores — partial implementations
• 16 D stores — major gaps in implementation
• 289 F stores — no working manifest or completely non-functional

The A-grade stores — Allbirds, Emma Bridgewater, Bodybuilding.com, and six others — represent the current ceiling. Average TTFB of 188ms, total scores of 90, and full capability coverage. These are the reference implementations that other stores should benchmark against.

The F-grade stores are almost entirely non-Shopify domains (285 out of 289). Most don't have a manifest at all — they're domains that have been submitted for checking but haven't deployed UCP. The 4 Shopify F-grades are edge cases: expired trials, development stores, or domains with DNS issues.

#Capability coverage

Among the 741 stores with verified manifests and benchmarked capabilities, the coverage is near-universal:

• Search, cart, product details, policies, shipping, discounts: 100%
• Cart notes, gift cards, buyer identity, delivery address: 100%
• OAuth: effectively 0%

This uniformity reflects Shopify's platform-wide deployment. Every store gets the same capability set. OAuth — which would allow agents to authenticate on behalf of a user — isn't part of any production manifest we've seen. That's a significant gap: without OAuth, every agent interaction is anonymous. No saved addresses, no order history, no loyalty discounts. It's a gap the spec acknowledges but the ecosystem hasn't addressed yet. The interesting divergence comes from non-Shopify implementations — like the WooCommerce stores exposing dev.ucp.shopping.checkout and dev.ucp.shopping.fulfillment capabilities that Shopify stores don't declare.

As the ecosystem diversifies beyond Shopify, capability coverage will become a more meaningful differentiator. An agent trying to complete a full checkout needs to know not just whether a manifest exists, but whether that specific store supports the operations the agent needs.

#What this means for the ecosystem

A month of continuous monitoring surfaces patterns that a one-time audit misses:

Manifests are not static. They break, recover, flap, and evolve. Any system that depends on UCP endpoints needs to account for this — whether that's an agent framework, a store aggregator, or a developer's integration test suite.

The reliability gap between Shopify and everyone else is significant. The vast majority of consistently stable domains are Shopify stores. The non-Shopify implementations are where the instability lives — and where the most interesting development is happening.

Blocking is an operational problem, not a strategic one. The stores blocking AI crawlers aren't rejecting agentic commerce. They're running standard bot protection that wasn't updated when UCP went live. As awareness grows, we expect these firewall rules to be relaxed for legitimate agent traffic.

Speed matters at the manifest level. A slow /.well-known/ucp response adds latency to every agent interaction. The best stores respond in under 200ms. The worst take over 2 seconds. This is infrastructure-level optimisation that stores can fix independently of their UCP implementation.

#Why we built alerts

This is exactly why we shipped UCP Alerts this week. Continuous monitoring generates signals. Alerts turn those signals into action.

Track any domain and get emailed the moment its UCP status changes. A store goes live with a manifest — you know immediately. A verified endpoint breaks — you know before your agents hit the error. A blocked domain recovers — you know when to retry.

Alerts run on the same 24-hour crawl cycle that powers the data in this post. Sign in, add up to 3 domains, and you're covered. If you need more domains or higher-frequency checks, get in touch.

Set up alerts at ucpchecker.com/alerts.

#Methodology

Our crawler checks each domain in the pool every 24 hours. A check hits /.well-known/ucp, validates the response against the UCP spec, and evaluates HTTP status, response time, manifest structure, AI bot policies, and any errors or warnings. When a domain's status changes, our alerting system flags it.

All data in this post is from real automated checks recorded between January 21 and February 27, 2026.

#What's next

We'll continue publishing deep dives like this as the ecosystem evolves — tracking how manifests change, which platforms ship native UCP support, and how reliability trends across the stack.

If you want the data weekly, subscribe to our Monday report — free adoption stats, bot access trends, and verified merchant growth.

We'll keep scanning. Every day.