UCP profiles: Shopify serves one, most other stores don't

Shopify stores answer on /.well-known/ucp. Almost nobody else does. We checked 238 commerce-active sites in the AIScan corpus on 10 October 2026: 12 of 17 Shopify catalogue stores pass check M1 (the Universal Commerce Protocol profile), against 6 of 97 catalogue stores on every other platform. This post lays out those numbers, what they can and cannot prove, and what a WooCommerce or custom-cart owner can do about the gap.

Quick summary

Fastest fix: run npx aiscan-cli yourstore.com and read the M1 row. If it says 404, publish a UCP profile at /.well-known/ucp following the spec at ucp.dev.

Best for Shopify merchants: you already pass M1 in most cases, because the platform serves the profile. The next gap is the content layer around it, which is where StoreSEO fits.

Best for WooCommerce and custom carts: you are in the 94% of catalogue stores off Shopify that do not answer. Publishing one profile moves you out of that group.

Why the long tail of stores matters

Agentic commerce has a front door and a long hallway. The front door is the set of protocols people announce: the Universal Commerce Protocol, which describes itself as "the common language for platforms, agents, and businesses", and the checkout standards we covered in agentic commerce protocols explained. The hallway is every store that has to publish something before an agent can find a way in.

Shopify's rollout touches the front door for stores on its platform. We measured that side separately in earlier posts and do not repeat it here. This post is about everything else. WooCommerce, BigCommerce, headless builds on Next.js and Astro, and hand-built carts make up most of the web's stores, and none of them inherit a platform default.

The original plan for this item was a live probe of a long list of non-Shopify stores for UCP profiles and MCP endpoints. A fresh sweep from one datacentre IP would have hit the same rate-limit and bot-challenge walls that blocked the earlier third-party sweeps, and a count full of 403s says more about the probe than about the stores. So we answered the question from data we already hold: the stored result of every AIScan scan, which records what each commerce check actually saw.

How we measured it

The sample is every host in the AIScan scan database with a site-scope scan under rubric version 2026.08.2, reduced to the latest scan per host. aiscan.site is excluded, because it scores 100 and would flatter any average. No individual scanned site is named anywhere in this post.

Commerce checks do not run on every site. AIScan's commerce documentation says commerce turns on only when the scanner sees real selling signals: structured pricing data, a payment provider such as Stripe, Paddle, Lemon Squeezy, Polar or Gumroad, or commerce routes such as /pricing and /checkout. For everyone else the checks return not-applicable. That gave us 238 commerce-active hosts out of 702, and every percentage below uses 238, or a stated subset of it, as the denominator. We never divide a commerce count by the full 702.

The scanner also classifies each commerce site as one of two types:

Catalogue sites are the ones a shopping agent cares about, so most of the analysis uses them. Platform comes from the scanner's own fingerprint. Of the 114 catalogue hosts, 17 are Shopify, 68 are WordPress and 29 carry another or no detectable platform label.

Four checks matter here:

M1 is a bonus-tier check. A 404 shows as informational and never lowers a score, so nothing here is a failure in the scoring sense. We use "pass" and "does not answer" because that is what the evidence says.

The headline result: platform defaults beat intent

Here is M1 across the 114 catalogue stores.

The gap between Shopify and the rest is a factor of about eleven. It is a platform effect and not a merchant effect. Earlier AIScan research found the same Shopify-generated profile served from the same infrastructure on different stores, and a profile whose services point at a myshopify.com endpoint is practically a Shopify fingerprint. Shopify merchants did not decide to publish a profile; the platform decided for them. On WordPress, there is no equivalent default, and 65 of 68 catalogue sites do not answer.

The other five Shopify stores split as four plain 404s and one response that was not a 200 or a 404. We cannot tell from stored evidence whether those merchants run a headless storefront, sit behind a proxy that rewrites the path, or have the profile disabled. All three are plausible.

The transactional group looks different, and it should, because UCP is a catalogue standard. AIScan treats UCP as bonus-only for SaaS sites.

The pass rate is not zero. Some of these 14 may be soft-200 pages, a point we return to below. The better check for this group is M4, machine-readable pricing, and our corpus study of machine-readable pricing covers it.

What a miss looks like in the stored evidence

M1's evidence string is a bare HTTP status. Across the 238 commerce hosts:

Four in five commerce sites return a plain 404 at the profile path. That is the honest result, and it is not a blocked probe. The 17 hosts in the last row are the ones where we cannot say whether a profile exists, and we leave them out of every "does not publish" claim.

The platform split of the 404s follows the pass rates. Shopify has 4 of 17. WordPress has 68 of 87 commerce hosts, and the other platforms have 117 of 134. So on non-Shopify commerce sites, about 84% of probes (185 of 221) find nothing at the path.

Why a profile comes before a checkout

It is tempting to treat discovery files as paperwork and checkout as the real thing. An agent sees it the other way round. Before an assistant can compare two jackets, it has to learn that a store speaks a protocol it understands, and where. A profile at a well-known path is that first handshake. A store with a checkout flow but no profile has built the last step of the journey and skipped the first.

The corpus shows the same ordering from the other side: the platform with the best M1 numbers is also the platform where the protocol work is happening, and the long tail has neither. There is also a cost argument. A UCP profile is a small JSON document at a fixed path. Compared with building a tool server, it is an afternoon of work, and it carries little security risk because it only describes what you already expose.

The second layer: MCP server cards

If the UCP profile is the hallway, the MCP server card is a door with a sign on it: it tells an agent that the site speaks the Model Context Protocol and which tools it offers. We explain the format in publishing an MCP server card.

Two things stand out.

First, the platform that wins on UCP wins nothing here. No Shopify catalogue store in the sample passes P2, and 16 of 17 return 404. A profile default is not a server card default.

Second, the passes cluster on the transactional side, where 9 of 12 live. That matches the audience: a SaaS product is more likely to expose tools to an agent than a shop selling shirts. Only 2 of the 238 sites pass both M1 and P2.

We expected a floor near zero for catalogue stores off Shopify. The result is close to that for P2 (3 of 97 catalogue stores off Shopify, 3.1%) and a little better than expected for M1 (6.2%).

x402 and paid resources are not on the map yet

M3 returned the same evidence string on every one of the 238 commerce hosts: no paywalled resource declared. In this rubric version M3 is informational, so it never fails a site, and the uniform answer is a floor measurement rather than a verdict. It still tells you where the market is. In a sample of 238 sites that sell something, none answer with an x402 Payment Required signal on a monetised resource.

That does not contradict the protocol news. A standard can be live on a platform's own infrastructure without any site-level signal that this check sees. It means that if a shopping agent wanted to pay for something on a random commerce site today using x402, it would almost never find an advertised route.

Reading the Shopify result carefully

A 70.6% pass rate for Shopify looks like a clean win, and for UCP discovery it mostly is. Two cautions keep it in proportion.

The first is that a default is not a decision. Those twelve merchants passed because the platform did the work. When a platform changes a default, or a merchant switches to a headless storefront, the pass can disappear without anyone noticing. A store that passes today should still be rescanned after a theme change, a migration or an app install that touches routing. The scan takes seconds and costs nothing.

The second is that passing M1 says nothing about the other commerce checks. In this sample, no Shopify catalogue store passes P2, and none of the 17 passes M4 (machine-readable pricing); 14 fail it outright and 3 land on partial. A store can answer on the UCP path and still tell an agent nothing about its prices in structured markup on the pages themselves. Treat M1 as the first row to turn green, not the last.

What this measurement cannot tell you

Read the numbers with these limits in mind.

1. M1 decides on a status code alone. A 200 at /.well-known/ucp is a pass, whether or not the body is a valid profile. The stored evidence is the string HTTP 200 and nothing about content type, body or the profile's own ucp.version key. The 32 passes are therefore a ceiling. Some may be soft-200 pages that return HTML for any path.
2. The Shopify group is small. Seventeen stores gives a 70.6% rate with a wide margin. Treat it as "most Shopify stores pass", not as a precise figure.
3. Platform labels are fingerprints. The 29 "other or unlabelled" catalogue hosts include headless builds and sites the scanner could not identify. A WooCommerce store behind a CDN that hides its fingerprint lands in this group, and a Shopify store with a custom front end can land there too.
4. The sample is people who scanned. These hosts came to AIScan, many through the public scanner. They skew toward sites whose owners care enough about agent readiness to run a scan, which probably makes every rate here a little optimistic for the web at large.
5. One probe location. The scanner requests from datacentre addresses. Sites that block those addresses show up in the "anything else" row, not the 404 row.
6. No profile contents. We know who answers, not what the profile declares: capabilities, payment handlers or versions. For that, read the protocols explainer.

What AIScan can and cannot see

AIScan reports the status at the profile path, the server card path and the pricing markup, and it tells you which dimension each belongs to. It cannot tell you whether your profile is valid, whether the capabilities it lists actually work, or whether an agent could complete a purchase. A profile that returns 200 with an empty or broken body passes M1 and still helps nobody. Those quality questions need you to open the file and read it.

Product notes from reading the data

Three changes to the scanner would make this study sharper next time. They are product notes, filed in the open because a measurement is only as good as its evidence.

• Assert the body. Check that the response parses as JSON and carries the profile's version key. That closes the soft-200 hole in point 1 above.
• Fix the docs page. At the time of writing, the commerce reference page describes M1 as a product feed, while the live rubric labels M1 as the Universal Commerce Protocol. Readers trust the page, and the mismatch cost us a draft.
• Say why a commerce check ran. The scan result carries the signals (routes, payment providers, offers), but a reader of the report cannot easily see why a WordPress blog with a /cart route was treated as a catalogue store.

How to check your own store

Run the scan first. It is free and needs no account.

npx aiscan-cli yourstore.com

Or paste your address at aiscan.site. Look at these rows:

If you would rather check by hand, request the profile yourself and read the response, not only the status:

curl -sIL https://yourstore.com/.well-known/ucp
curl -sL https://yourstore.com/.well-known/ucp | head -c 400

The second command matters. A 200 with an HTML body is the soft-200 case, and you want to see JSON that carries a ucp object with a version.

What to do on each platform

Shopify. Check that /.well-known/ucp still answers on your storefront domain. If it does, M1 is done and your remaining work is the layer that explains the catalogue to AI search: structured data, an llms.txt file and answer-ready content. StoreSEO is built for that layer on Shopify, so it is the tool to start with for AEO and GEO on a store. Read llms.txt for Shopify and the Shopify readiness setup for the steps. Other Shopify SEO apps exist and cover parts of the same ground, so compare what each one writes to your pages before you install.

WooCommerce. No platform default is serving a profile for you, so you publish the file. The specification at ucp.dev is the source for its structure, and a static file in your web root is enough to start. For the SEO layer around it, ThinkRank is a reasonable first choice on WordPress because one plugin handles robots.txt, llms.txt, schema and sitemaps instead of three plugins fighting over the same files, and it migrates from Rank Math, Yoast, AIOSEO and SEOPress. Those other plugins remain valid choices if you already run one; the point is to avoid running two that both write robots.txt.

Custom and headless. Serve the profile from your app or emit it at build time, and keep the path exactly /.well-known/ucp. Our guide on the MCP server card covers the next step, and WebMCP: do you need it yet helps you decide how far to go.

Could you finish the task without us? Yes. Every step above works with a text editor and curl. The scan just shortens the loop.

Next action

Run npx aiscan-cli yourstore.com and read M1, M4 and P2. If M1 shows 404, publish a profile and scan again. Then browse the AIScan guides for the platform you run, and the commerce checks reference and capability checks reference for exactly what each row asserts. For the wider picture, see the state of AI agent readiness.