Is your store ready for Universal Cart?

What is Universal Cart?

Google announced Universal Cart in May: "a truly intelligent shopping cart that works across retailers," holding items from different stores at once, across Search, Gemini and more.¹ A shopper can check out right there with Google Pay, or get sent on to the store's own site to finish. Either way, Google says, "the retailer always remains the merchant of record."

It runs on the Universal Commerce Protocol, Google's standard for buying on its AI surfaces, which Google itself calls "an evolving standard." Taking part isn't automatic. A store sets up its feed, shipping and returns in Merchant Center, joins a waitlist, and has to be approved by Google before it goes live in AI Mode and Gemini.²

The part that interests us is quieter. Everything a shopper used to work out by reading a page now has to be stated for a system to act on: the price, whether the size is in stock, what delivery costs and how long it takes, and whether it can go back. Google gets those facts from the feed and from the page's structured data, and it checks one against the other. A store that states them plainly, and the same way in both places, gives Google's systems far more to work with than one that leaves them on the page as prose.

What a cart reads

Google lists the fields it wants for a product in its merchant listing docs.³ Two are required and the rest are recommended, but for an agent trying to buy something, the recommended ones are the whole point:

Here's what that looks like in practice. This is the kind of block many themes write today, for a sample product:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Linen shirt",
  "image": "//cdn.shop.example/linen-shirt.jpg",
  "offers": {
    "price": "$68",
    "priceCurrency": "Dollars",
    "availability": "in stock"
  }
}

The fields are there, but most of them can't be used as written. The image address starts with //, so it isn't a full URL. The price is a string with a currency symbol in it. The currency is a word, not an ISO 4217 code, and the availability is free text, not a schema.org value. The same product, written from the platform's own fields:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Linen shirt",
  "description": "A relaxed shirt in washed European linen.",
  "image": ["https://cdn.shop.example/linen-shirt-1200.jpg"],
  "sku": "LS-NAT-M",
  "gtin13": "4006381333931",
  "brand": { "@type": "Brand", "name": "Field and Loom" },
  "offers": {
    "@type": "Offer",
    "url": "https://shop.example/products/linen-shirt",
    "price": 68.00,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

One more thing matters as much as any field: the data has to agree with the page, and with the feed. Google checks the feed against what the page shows and can disapprove a product that disagrees.³ A sale price in the theme but not in the data, or a sold-out variant marked in stock, is exactly the kind of mismatch that gets a product dropped.

What stores leave out

mttr reads sites the way search engines and assistants do. It has graded 828 Shopify stores in the US and Canada so far, out of 2,687 there it has found. On the whole they're in better shape than most of the web: they average 82 out of 100, against 74 for every site we've graded there. But almost all of them miss the basics somewhere:

A couple of honest notes on those numbers. They're mttr's own rules, counted per store, so one page failing is enough to count. And the structured-data rule covers more than products, so "91%" doesn't mean 91% have broken product data. It means nine in ten have pages where the data an agent reads is missing or wrong somewhere, and the last column says how much: 17% of their pages. The fix for product pages is narrower, and that's what the skill does.

How mttr grades a store

Every number above comes from one engine. mttr reads up to the first 100 pages of a store and checks each against 44 rules. Code decides 42 of them: whether the structured data parses, whether the title fits, whether the image has words. A model reads the other two, whether a page answers its own question and whether its claims are backed, and anything it is unsure of goes to a person rather than passing or failing the page.

The rules fall into four stages, weighted by how much a reader depends on them. A stage's score is the share of its rules' weight a store passes, across every page each rule applies to, and the four together make the score out of 100. A store closed to crawlers is capped at 20, because the rest describes pages nobody can reach. Here is where the 828 Shopify stores stand:

Product data sits almost entirely in the second stage, which counts for 30 points and where stores average 69, against 94 for being reachable at all. Structured data carries 4 points of weight there, as much as any rule in the stage, and whether that data matches the page carries 3 more. Act is lower still, at 61, and nearly all of that is one rule: 86% of store pages give no number a shopper can tap to call. The full rulebook, every rule with its weight and its fix, is public.⁶

A grade says a store's pages are well formed for machines to read. It doesn't say an assistant cites the store, or that Google will show its products. Those are decided elsewhere, and the last section comes back to that.

How Shop Ready fixes it

Shop Ready is a skill for coding agents like Claude Code. It works in the store's own repository, on the templates that write every product page, so one change fixes every product at once. mttr checks the live pages before and after, field by field. It runs in seven steps:

1. Find the platform from the repository's own files: a Shopify theme, Hydrogen, Next.js commerce, WooCommerce, BigCommerce or Magento.
2. List every product template, and every place that already writes product data. Apps and tag managers often write a second copy, and two answers for one product is worse than one.
3. Check one live page per template with mttr, including a product with variants, one on sale and one sold out, since that's where data and page disagree most.
4. Fix the template so every field comes from the platform's own product data, never typed in by hand.
5. Make the data match the page: price, sale price, currency, stock, images, variant, shipping and returns, all checked against what a shopper actually sees.
6. Ship it the way the store owner allows: as a proposal they approve, straight to the store if they've said so, or as a pull request.
7. Check again and report against the first read, with anything still missing and why.

Two rules are built into it. It never invents anything: a GTIN, a rating, a return window or a shipping time that the store can't back up stays missing, and gets reported as missing. And it never changes a price, stock, a policy or a product to make the data pass. It fixes how the store describes itself, not what the store sells.

The skill is five plain files an agent reads as it works, each one open to read on its own:

• SKILL.mdThe seven steps from finding the platform to checking again, the four ways a change ships, the fields to fix in order, and the report.
• platforms.mdWhere Shopify themes, Hydrogen, Next.js commerce, WooCommerce, BigCommerce and Magento write their product data, which field each value comes from, and a worked replacement for each.
• markup.mdBefore and after JSON-LD for a plain product, a product with variants, a sale price, and the shop's shipping and returns, with the rules for each field and which source wins.
• merchant-center.mdThe Merchant Center feed's fields beside the page's, why they must agree, prices and tax by country, and the feed apps on Shopify and WooCommerce.
• verify.mdA command that prints the JSON-LD the server sends, what the check's answer means, Google's own tools, and a table of symptom, cause and fix.

Fix the product schema in our Shopify theme so every product page passes Google's merchant listing fields.

Making it automatic on Shopify

The skill needs a person with a coding agent and access to the theme. For most Shopify stores that's one step too many, so we're building it into Shopify itself. mttr for Shopify is in beta, and it works the same way, without the repository:

1. Install it from the Shopify admin and let it read the theme and the products. Nothing in the store changes yet.
2. mttr reads the store, its first 100 pages the way a search engine and an assistant do, with each product's own data beside its page.
3. The fixes show up ranked in the admin, each with the pages it touches and exactly what it would change, the most valuable first.
4. Approve one and it's written to the theme or the product fields. mttr reads those pages again and shows what moved.

It never touches a price, a product's name, its stock or an order, every change waits for a yes, and each one can be undone from the admin. Some of the work still stays with the merchant, because only they can do it: the Merchant Center feed, the shipping and return settings there, and joining Google's waitlist for checkout.

What it gives an assistant

Think about what someone actually asks an assistant: "a linen shirt in medium, under $80, that gets here by Friday and I can return." To answer that, the assistant needs the price, the size in stock, the delivery time and the return window, stated plainly and in agreement with the page. A store that states all of it gives the assistant everything it needs to answer, and to help the shopper buy. One that doesn't leaves the shopper to go and check for themselves.

That's the value, plainly: every detail an agent needs to buy the thing, in the form it reads, for every product, kept true as the catalog changes. It doesn't need new copy or a redesign. Most stores already have every one of these facts in Shopify. They just aren't saying them where an agent looks.

Checking it with Google's own tools

mttr's check is a fast way to see every field on every template, but the last word is always Google's. Three of its tools are worth using on any store, and the skill points the store owner to each one: the Rich Results Test, for Google's own read of a single product page; the Merchant listings report in Search Console, for how Google sees the store's products across the whole site once it has crawled them again; and the diagnostics in Merchant Center, for where the feed and the pages disagree.⁵

What it doesn't do

None of this makes a product eligible for anything. Merchant Center and Google's own review decide whether a product shows in merchant listings, in Universal Cart, in AI Mode or in Gemini. mttr reads what the pages publish and says, field by field, whether it's there and right. It can't promise a store a placement, and neither can anyone else outside Google.

And the data only helps if it stays true. A sale that ends, a variant that sells out, a return window that changes: the template keeps the data in step with the product automatically, because every value comes from the product itself. That's why the skill fixes templates and never individual pages.

References

1. Google, "How we're helping retailers thrive with new Universal Commerce Protocol features and AI tools on Google," May 20, 2026. blog.google
2. Google for Developers, "Universal Commerce Protocol (UCP) guide." developers.google.com
3. Google Search Central, "Merchant listing (Product, Offer) structured data," and "Product variant structured data." merchant listing, product variants
4. mttr, the Shop Ready skill (mttr-shop-ready 1.2.0), and mttr's catalog of Shopify stores graded in the US and Canada, counted October 20, 2026. mttr.si/skills/shop-ready
5. Google, the Rich Results Test, the Merchant listings report in Search Console, and Merchant Center. Rich Results Test, Merchant Center
6. mttr, the rulebook: every rule, its stage, its weight and its fix. mttr.si/rulebook