StoreKnows resources

An AI assistant says your product is out of stock. It isn't. Here is why, and how to check

2026-09-12T00:00:00Z

Short answer: an assistant that calls your product sold out while it is in stock has read an availability signal that does not match your inventory. There are three places that signal can come from: the Product/Offer schema in your page source, the availability field Shopify syndicates to AI channels, and the single variant a storefront tool returns when nobody asked for a specific one. Check them in that order.

Why this happens now

On 6 September 2026 a merchant posted in the Shopify Community that assistants kept calling her product out of stock when “there is no variant that is out of stock”. Her theory was that the assistant had found the words “out of stock” somewhere in the theme code. Four people replied within a day, and none of them thought the template text was the cause. They pointed at the same thing: structured availability data.

That instinct matches what we see in simulated checks. In a batch we ran on 4 September 2026 across 34 public specialist storefronts (340 questions, one shopper model, OpenAI’s GPT-5.4 mini via the API), 119 of the 186 answers that were not fully right failed on a single fact about a single product: a price, a stock state, one spec. Availability is the most common of those facts, because it is the one shoppers ask about most and the one that changes most often.

The three signals an assistant can read

1. The Product schema in your page source

Most retrievers that fetch a product page read the JSON-LD Product block and its Offer. The availability property is either https://schema.org/InStock or https://schema.org/OutOfStock. Two things go wrong here:

A stale or wrong value. The theme, or an SEO or review app, writes OutOfStock from a variable that does not track inventory the way you expect (for example, it reads the first variant, or a variant that was archived).
More than one Product block. Theme plus SEO app plus review app can each emit a Product. If one says InStock and another OutOfStock, the assistant picks one, and you do not control which.

Look at the raw source, not the browser inspector. The inspector shows the page after JavaScript has run; most retrievers see the HTML as served. Search the source for "@type": "Product" and count the blocks.

2. The availability Shopify syndicates to AI channels

Agentic Storefronts is active by default for eligible stores, and it sends each product’s “title, description, options, images, price, availability, and other key attributes” to ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta (help.shopify.com, read 11 September 2026). If a product is marked unavailable in that feed, an assistant using the channel will say so, whatever the page says.

You can see what is sent under Sales channels → Agentic in the admin. Products that are unpublished from the Online Store channel, priced at zero, or hidden from search engines are excluded from the catalog entirely, which an assistant may also describe as “not available”.

3. One variant standing in for the product

This is the one nobody in that forum thread mentioned, and in our checks it is the most common cause. Every Liquid storefront now exposes a set of storefront tools to browser-based agents (Shopify’s WebMCP tools, announced 5 August 2026 and on every Liquid storefront from 21 August 2026, currently limited to Chromium browsers through an origin trial). The get_product tool returns a price range and a single variant, the product’s default, unless the agent asks for a specific option. In a check on a 1,055-product accessories store in September 2026, six of nine partial answers came from exactly this: the agent read that one variant’s price or stock and reported it as the product’s. If your default variant is sold out and the rest are fine, the product is “sold out”.

The same shape shows up in our batch: fit questions (“which colour of this camera is actually available right now?”) were fully right 81% of the time, but the misses were almost all attribute-shaped, the variant the shopper wanted was never looked up.

How to check, in ten minutes

Pick one product the assistant got wrong and one it got right.
View source on both. Count Product blocks. Read every availability value. If the wrong product carries OutOfStock anywhere, you have found it.
Check the default variant. In the admin, open the product and look at the variant listed first (Shopify treats it as the default). If it is sold out, reorder variants so an available one comes first.
Check the Agentic channel view. Sales channels → Agentic → review how product data is sent. Confirm the product is included and shows as available.
Ask the question in fresh sessions. Open ChatGPT, Gemini and Copilot with no history and ask, “Is [product] in stock at [store]?” Note which variant each one describes and the date. Assistants change; keep the record.
Re-check after the fix. Caches on the AI side can lag by days. The Shopify help page says changes to Catalog access can take up to seven days to apply.

What fixes it

One correct schema block. Remove duplicate Product markup from apps you no longer need; make the remaining one derive availability from the selected variant’s inventory.
An available default variant. Cheap, and it fixes the storefront-tool case immediately.
Variant-level data agents can ask for. The deeper fix is letting an agent ask “is the 5-roll bundle in stock?” and get that variant’s answer. That is what StoreKnows’ captured-variant tool does: it publishes read-only price and stock per variant from a saved catalog copy you approve, beside Shopify’s own tools. It does not replace the schema fix; it covers the questions the schema cannot.

What this does not tell you

A simulated check runs models through their developer APIs, not the consumer apps, so it tells you what the tools return and how a model reads them, not what ChatGPT will say to a particular shopper this afternoon. And a wrong “out of stock” is a diagnosis, not yet a cost: whether it is losing orders shows up only when AI-referred sessions on that product start converting again.

Results in this article come from simulated checks run by StoreKnows on 2 and 4 September 2026 against public storefronts. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6 and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

How to check what ChatGPT, Gemini and Copilot say about your store (manually, and with a simulated check)

2026-09-12T00:00:00Z

Short answer: open ChatGPT with no history, ask the questions a buyer would ask about one specific product, and write down the variant, price and stock state it describes and the date. Repeat in Gemini, Copilot and Perplexity, and again next week. Then run the same questions as a simulated check against your store’s own tools, so you can see which fact the assistant lacked and re-test after you fix it.

Why one screenshot is not a check

On 9 June 2026 a merchant opened a thread in the Shopify Community titled “Is your store actually showing up in ChatGPT shopping results? Here’s how I checked mine”. The method was simple: ask “the kind of question a real buyer would” and see which stores come back. Over the following weeks the replies added the caveats that matter. One person logged a single product across four assistants and found it in three of them. Another pointed out that the same query asked twice can return two different answers, and that traffic from these answers often lands in analytics as direct, so the order that came from an assistant looks like any other.

Two lessons follow. First, an assistant answer is a sample, not a fact about your store; you need several samples before you can say anything. Second, there are two different things you can check. One is whether your store appears at all when a shopper asks a generic question (“best rain jacket for cycling”). The other is whether the assistant describes your product correctly once it has found it: the right variant, the right price, in stock or not, will it fit. This article is mostly about the second, because that is the part you control from your product data, and because it is where the errors sit. In a simulated check we ran on 4 September 2026 across 34 specialist storefronts (340 questions, one shopper model, OpenAI’s GPT-5.4 mini via the API), the assistant almost always found the product; 119 of the 186 answers that were not fully right had missed one fact about it. The full breakdown by question type is in What AI shoppers get wrong about specialist products.

How do you check by hand?

The fresh-session method takes twenty minutes the first time and ten each week after.

Start clean. Use a chat that does not carry your history: a temporary chat, a signed-out window, or a private browser window, whichever the app offers. Your own account has months of context about your store, and the assistant will use it. A shopper’s does not.
Pick three products. One bestseller, one with several variants at different prices, and one whose deciding detail sits in a spec table or a size chart. The last two are where answers go wrong.
Ask as a buyer, in two forms. Once without naming your store (“which 35 mm black-and-white film under $10 is in stock?”) and once naming it (“is the 5-roll bundle in stock at [store]?”). The first tells you about discovery, the second about accuracy.
Write down what it described. Not “it got it right” but the variant it named, the price it quoted, the stock state it gave, and any spec or compatibility claim. Add the app, the date and whether the answer linked to your product page.
Repeat in the other apps. ChatGPT, Gemini, Microsoft Copilot and Perplexity retrieve differently (more below), so a product that reads fine in one can be described wrongly in another. Four apps, three products, two forms each: 24 rows in a spreadsheet.
Ask again in a week. The answers will move. What you are looking for is the fact that is wrong every time, across apps. That one is yours to fix.

Keep the log. When you change a product’s data, the log is the only way to tell whether the change reached the assistants.

Which questions should you ask?

Generic “best X” questions are easy to ask and hard to learn from; the answer depends on the whole market and on the assistant’s mood. Questions about your own products are the ones that show a fixable gap. Use these templates, with the brackets filled from a real product.

Type	Template	What to record
Fit	“Does the [product] come in [colour or option], and is that one available now?”	The option it names; available or not
Size	“My [measurement] is [value]. Which size of [product] should I order?”	The size it recommends; whether it cites your chart
Compatibility	“I have [thing they own]. Will [product] work with it?”	Yes, no or unsure; what it based that on
Comparison	“What is actually different between [product A] and [product B]?”	The differences it lists; the ones it misses
Stock and price filter	“Show me in-stock [category] under [price] with [property].”	Which products it returns; any that are sold out or over budget
Policy	“If [product] does not fit, can I return it, and who pays shipping?”	The window and the cost it states

The types are not equally hard. In our September batch, fit questions were fully right 81% of the time; comparisons 24%, filtered searches 28%. If you only have time for two questions per product, ask a comparison and a filter.

Why do answers differ between sessions and apps?

Four reasons, and all four are ordinary.

The model samples. Ask the same question twice and you get different wording, sometimes a different product, because the answer is generated fresh each time. This is why single results mean little.

Each app retrieves differently. An assistant can know your product from a syndicated catalog entry, from a crawl it made days ago, or from fetching the page while you wait. Shopify’s Agentic Storefronts, on by default for eligible stores and managed under Sales channels > Agentic, syndicates each product’s title, description, options, images, price, availability “and other key attributes” to ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta (help.shopify.com, read 12 September 2026). Perplexity is not in that list and reads your pages the way a search engine does. Two apps looking at two copies of your product, taken at two different times, will not agree.

The copy may be stale. A syndicated entry or a cached crawl lags your admin. If you changed a price or a variant sold out this morning, an assistant can carry the old value for days. Shopify’s own note that changes to Catalog access take up to seven days to apply gives a sense of the scale.

Context leaks in. Your history, your location and the session’s earlier turns all shape the answer. The ChatGPT channel, for instance, applies to stores that sell to customers in the United States; a shopper elsewhere may be served from a crawl instead of the catalog. Hence the fresh session.

None of this is a fault in the assistants or in the catalog. It is the reason a check has to be repeated and logged rather than done once.

What does “discovery-only” mean for the ChatGPT channel?

Shopify’s help page for the channel describes it as “a discovery-focused referrer platform”, and says ChatGPT users “complete their purchase on your online store checkout” (help.shopify.com, read 12 September 2026). Your store must sell to customers in the United States, though it can be based anywhere, and there are no fees beyond your usual payment processing.

For a check, this matters in two ways. First, the answer a shopper sees in ChatGPT is a referral: it describes your product, then sends the shopper to your product page and your checkout. If the description said $69.99 and the variant they wanted is $74.99, they find out on your page, not in the chat, and the mismatch is yours to absorb. So the accuracy of the description is worth checking even though the sale happens on your storefront. Second, the same page says that if you turn the channel off, your products “might still be displayed or referenced” through web crawling and indexing. Opting out removes the catalog copy, not the crawl, so a manual check is still worth running on a store that has opted out.

What does a simulated check add?

A manual check tells you what an app said today. It cannot tell you why, and it cannot be re-run exactly after a fix. A simulated check is built for those two things.

Same questions, generated from your data. The questions are the ones in the table above, drawn from your own products, each with a reference answer built from the store’s public product data before the assistant is asked.
Tools only. The simulated shopper uses the storefront tools every Liquid store has served since 21 August 2026 (search, browse, get product, show variant, cart, policies) and your public pages. Nothing else. So an answer reflects what your store makes readable, not what a model remembered from a crawl.
Graded against the store. A separate judge model marks each answer fully right, partly right or wrong against the reference, and records which fact was missing. That is how you get from “it was wrong” to “it quoted the first variant’s price instead of the one the shopper asked for”, which is the most common shape we see and the subject of An AI assistant says your product is out of stock. It isn’t.
Repeatable. Every tool call and every answer is stored. Change the product, run again, compare. On a 144-product dev store on 5 September 2026, the same 14 questions went from 7 to 13 fully right with Google’s Gemini 3.8 Flash via the API and from 4 to 8 with OpenAI’s GPT-5.4 mini via the API, one run each, after the deciding specs were made readable to the tools. Runs vary; treat that as a direction, not a score.

The manual log and the simulated check answer different questions. Keep both.

What a simulated check cannot tell you

It runs models through their developer APIs, not the consumer apps. So it does not tell you what ChatGPT, Gemini, Copilot or Perplexity will say to a particular shopper this afternoon, whether your store appears for a generic “best X” question, or how each app’s own retrieval and caching will treat your product. One model, one run, ten or fourteen questions: the percentages describe a shape, not a benchmark. And a right answer in a simulated check is a necessary condition, not a sufficient one; the fresh-session log is still how you confirm that the fix reached the apps.

A routine that fits in a week

Monday, ten minutes: the fresh-session log, four apps, the same three products. Once a month, a simulated check on the whole catalog to find the products whose one deciding fact is unreadable. After any change to variants, prices, size charts or compatibility data, both. StoreKnows runs the simulated check on your own store for free, shows every answer beside the product data behind it, and lets you try a fix with your own question before anything is published.

Results in this article come from simulated checks run by StoreKnows on 4 September 2026 against 34 public storefronts and on 5 September 2026 against a development store. Questions were answered by OpenAI’s GPT-5.4 mini and Google’s Gemini 3.8 Flash, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

What AI shoppers get wrong about specialist products: 34 stores, 340 questions

2026-09-12T00:00:00Z

Short answer: across 340 shopper questions on 34 specialist Shopify storefronts, a simulated AI shopper using only the store’s native tools got 45% fully right, 42% partly right and 12% wrong. The assistant almost always found the product. What it missed was one fact about it: the variant’s price, whether it was in stock, a spec, a compatibility note. Of the 143 misses our judge could classify, 119 were that shape.

Why we ran this

Shoppers now ask assistants the questions specialist merchants field all day: will this fit, which size, what is actually different between these two. Shopify has done the plumbing: its catalog is syndicated to ChatGPT, Google, Copilot and Meta by default, and since 21 August 2026 every Liquid storefront exposes storefront tools that browser-based agents can call. What nobody had published is what an agent actually answers when it uses those tools on a store where the deciding facts are specs, options and charts.

So we measured it, on stores chosen because they are hard: bike parts, tool makers, camera and film shops, outdoor gear, 3D-printer parts, espresso equipment, phone accessories. This is not a random sample of Shopify stores and it supports no claim about stores in general. It is a picture of where the details decide the sale.

Method, in full

Stores: 40 public storefronts listed; 34 scanned. Three could not be scanned because their pages exposed no storefront tools (headless or custom builds); three failed at question generation. Six control stores selling food, drink and basics apparel ran alongside.
Questions: 10 per store, generated from the store’s own public catalog with a recorded reference answer for each, in six types: fit, compatibility, spec filter, comparison, policy, and open-ended “help me choose”.
Shopper: OpenAI’s GPT-5.4 mini via the API, at most six tool calls per question, using only Shopify’s native storefront tools and public pages. No StoreKnows tools were present. One model; not ChatGPT, not Gemini, not Claude.
Judge: a separate model (OpenAI’s GPT-5.6 Sol) graded each answer against its reference as fully right, partly right or wrong, and where it could, classified the gap as attribute-shaped (a fact about one product) or relationship-shaped (a link between two).
Identity and cost: every request identified as StoreKnowsBot, one store at a time, public pages only. Total model spend: $9.63. Run on 4 September 2026.

Results

Question type	Questions	Fully right	Partly	Wrong
Fit: does this option exist, is it available	68	55 (81%)	9	4
Compatibility: does A work with B	66	42 (64%)	21	3
Policy: shipping and returns	39	14 (36%)	15	10
Spec filter: in stock, under a price, with a property	60	17 (28%)	30	13
Open-ended: help me choose	39	10 (26%)	26	3
Comparison: what is different between A and B	68	16 (24%)	43	9
All	340	154 (45%)	144 (42%)	42 (12%)

Three things stand out.

Finding the product is solved. Fit questions, “which colour is actually available”, “does the 5-roll bundle exist”, were right four times in five. The search and browse tools work.

Comparing and filtering is not. “What is actually different between the 4-person tent and its vestibule?” was fully right one time in four; 43 of 68 comparisons came back partly right, typically listing the two products without the fact that separates them. Filtered searches (“in-stock black-and-white 35 mm film under $10”) were fully right 28% of the time and wrong 22%.

The misses are single facts. Of the 143 gaps the judge could classify, 119 (83%) were attribute-shaped: a spec, a variant price, a stock state that the tools never returned. Only 24 were relationship-shaped, the “does A fit B” kind that fitment apps exist to solve. The comparison misses alone account for 48 attribute gaps: the assistant had both products and lacked the one number that told them apart.

The six control stores, small text-rich catalogs, scored 25 of 60 fully right (42%), with 22 attribute gaps and one relationship gap. Even where the catalog is simple, the missing piece is a fact about one product.

Why a fact goes missing

Three mechanisms, each seen directly in the tool responses:

One variant stands in for the product. The get_product storefront tool returns a price range and a single variant unless the agent asks for a specific option. On a 1,055-product accessories store we checked separately on 2 September, six of nine partial answers were this: the agent quoted the product’s $69.99 minimum when the chosen variant costs $74.99.
Specs live where no tool looks. Metafields were invisible from outside on 41 of 41 storefronts we crawled: not in /products.json, not in the WebMCP tools, not in the UCP catalog endpoint. If the weight, the thread pitch or the compatible model is a metafield rendered by the theme, an agent reading through the tools cannot see it.
Filters live in tags and options the search tool does not return. Free-text search returns ten summary cards; “MagSafe, kickstand, navy, under $30” is a set intersection the agent has to reconstruct by opening products one at a time, and it runs out of tool calls.

What this is not

It is not evidence that Shopify’s tools are weak. On a 150-product coffee store, run two days earlier with the same setup, Anthropic’s Claude Opus 5 answered 10 of 10 and OpenAI’s GPT-5.6 9 of 10 using native tools alone. The tools read what the catalog holds; specialist catalogs hold their deciding facts somewhere the tools do not reach.

It is not a prediction of what ChatGPT or Gemini will say to a real shopper. Simulated checks call developer APIs and are graded against a reference we built from the store’s own public data; consumer assistants add their own retrieval and caching. One model, one run per store, ten questions each: treat the percentages as a shape, not a benchmark.

What to do with it

If your catalog looks like these (options with dozens of values, specs in metafields, size charts, compatibility tables), the fix is not rewriting descriptions. It is making the one fact per product readable where agents look: a correct first variant, a complete schema block, and, where the facts sit in metafields, a read-only tool that answers “which variant, what price, in stock or not, does it fit”. StoreKnows runs this check on your own store for free, shows you every answer with the product data behind it, and lets you try a fix with your own question before publishing anything.

Results come from a simulated check run by StoreKnows on 4 September 2026 against 34 public storefronts (and on 2 September against two further stores). Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6 and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

Agentic Storefronts, explained for merchants: what Shopify sends to ChatGPT, Gemini, Copilot and Meta, and what it doesn't

2026-09-12T00:00:00Z

Short answer: Agentic Storefronts is Shopify’s name for the set of AI channels it connects your products to. It is active by default for eligible stores. Through Shopify Catalog it sends each product’s title, description, options, images, price and availability to ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta. It does not send your metafields, size charts or compatibility tables, unless you map them into one of five listing fields. Everything below was read on Shopify’s own pages on 12 September 2026 and carries its link.

What Agentic Storefronts is

Shopify describes it in one sentence on the Agentic Storefronts help page (read 12 September 2026): “Agentic storefronts is active by default for eligible stores.” Your products reach the AI channels “through Shopify Catalog or through the Google & YouTube sales channel”, and you “manage which AI channels you want to sell your products on in Sales channels > Agentic”. Using it means agreeing to the Shopify Agentic Storefronts Supplemental Terms of Service.

Default-on dates from the week of 24 March 2026. Shopify’s news post of that day, Millions of merchants can sell in AI chats, put it this way: “Products become discoverable in ChatGPT by default via Agentic Storefronts, with no separate integrations, no apps, and no transaction fees beyond standard processing rates.”

The default is implemented by a single switch. On the Managing agentic storefronts page (read 12 September 2026), “Allow Shopify to manage for me is the default behavior”, and while it is on “you’re automatically enrolled in all future agentic storefronts channels”. Turn it off and you configure each channel by hand.

So if you have not looked, the honest assumption is that your catalog is already in front of these assistants. That is not a problem to fix. It is a reason to know what they were given.

The channels, and which ones can take the order

There are four channels today. They differ in one way that matters commercially: whether the shopper buys inside the assistant or on your checkout.

Channel	How the shopper buys	Who sees it	Extra requirements	Source, read 12 Sep 2026
ChatGPT	On your online store checkout, in a ChatGPT in-app browser (mobile) or a new tab (web). Discovery only.	Customers in the US; your store can be based elsewhere	None beyond Catalog eligibility	Selling on ChatGPT
Google AI Mode and Gemini	“Buy” in the Google interface, Shopify-powered direct checkout; or sent to your store if you turn direct checkout off	Direct checkout only for US customers; store must be US-based	Google Merchant Center account with products synced	Selling on Google AI Mode and Gemini
Microsoft Copilot	Shopify-powered direct checkout “without having to leave their chat conversation”	Direct checkout displays only to US customers	Store policies completed in Settings → Policies	Selling on Microsoft Copilot
Meta	Shopify-powered direct checkout “on Meta surfaces”; falls back to your store with the cart preserved	Direct checkout displays only to US customers	Facebook & Instagram by Meta channel installed with syncing on	Selling on Meta

Three notes on the table.

ChatGPT is a referrer, not a checkout. The main help page calls ChatGPT “a discovery-focused referrer platform”. The ChatGPT page says “ChatGPT users complete their purchase on your online store checkout in a ChatGPT in-app browser, or in a new tab when customers use ChatGPT web.” If you have read older coverage of an in-chat “Instant Checkout” for Shopify merchants, that is stale; since March 2026 the purchase happens with you. There are “no fees associated with selling in ChatGPT. You pay only your standard payment processing fees.”

Direct checkout is US-only on every channel that has it. All three direct-checkout pages use the same wording: the checkout “displays only to customers based in the United States”. Google adds that “your store must be based in the United States”. Copilot and Meta require only that you sell to US customers. Shoppers elsewhere can still see your products in those assistants; they land on your store to buy.

The order still reaches you. Direct checkout is Shopify’s checkout rendered inside the channel. It is not the assistant’s own payment system. No channel charges a fee beyond payment processing (each page states this in the same sentence).

What Shopify Catalog sends

Shopify Catalog is the feed behind all four channels. The Shopify Catalog and product discovery page (read 12 September 2026) lists what it carries: “title, description, options, images, price, availability, and other key attributes”. The data sharing page says the same in slightly different words, “titles, descriptions, images, pricing, and availability information”, and adds what stays private: “AI channels don’t have access to your full order history, orders from other sales channels, or your general customer database.”

Two sentences on the Shopify Catalog overview (read 12 September 2026) set expectations on both sides:

“You can’t opt out of Shopify Catalog itself.” You can remove a channel’s access to it (more on that below), but the catalog exists regardless.
Being included in Shopify Catalog, in Shopify’s words, “doesn’t guarantee” that a product “will appear in a specific AI answer, be ranked in a specific position, or be displayed by every channel that’s connected to Shopify Catalog.”

Which products get in is spelled out on the requirements page (read 12 September 2026). A product needs a title and at least one image, “a price greater than zero”, publication to the Online Store, Hydrogen or Headless channel with an identifiable URL, an active (not Unlisted) status, and it “can’t be hidden from search engines”. The store must be on Starter or above and not in private mode. The products page adds that B2B-only products are excluded automatically.

That is a clean, sensible list. Notice what is on it: the fields every product has. Notice what is not: anything you added.

What Catalog Mapping can map, and what it cannot

If your product title or description lives somewhere unusual, Shopify offers Catalog Mapping. The products page says: “If your product data, such as title, description, and category, are stored in custom fields, then you can use Shopify Catalog Mapping to ensure that the product data is correctly sourced for agentic storefronts.”

The mapping page (read 12 September 2026) names the fields you can remap:

product title
product description
product category
product variant options
variant grouping (which products count as one listing)

Each of those can be pointed at a product attribute, a product metafield, a metaobject reference, a tag prefix, or a delimiter in the product title; grouping can also follow your Combined Listings setup. It is configured under Sales channels → Agentic, then “Review how your product data is sent to the Shopify Catalog for Agentic Channels”.

This is useful when, for example, your marketing description is a metafield and the default description field holds boilerplate. It is a way to choose the source for five fields. It is not a way to add a sixth. A weight_grams metafield, a compatible_with list, a helmet size chart stored as a metaobject: none of those is a title, a description, a category, an option or a grouping. There is no field on the mapping page for them, and the page does not describe one. As of 12 September 2026, the mapping page also carries no note about how unmapped metafields are treated, which we read as: they are not part of the syndicated record.

The fields Shopify infers for you

Developers who read the catalog from the other side see something merchants do not. Shopify’s Global Catalog extension (version 2026-08-25, read 12 September 2026) documents extra fields on each catalog record: metadata.tech_specs (“Technical specifications”), metadata.top_features (“Top product features”) and metadata.attributes (“Product attributes such as material, style, and occasion”). The page says these are “inferred or enriched by Shopify” and should be “treated as discovery and merchandising signals, not as merchant-authored source text”. There are also inventory signals such as availability.running_low, inferred descriptions and options, and a similarity search.

Read that carefully, because it is the closest thing to a spec field in the whole system. Shopify generates a tech_specs block from what it can see of your product. The extension page does not mention merchant metafields as an input, and the field is labelled as not merchant-authored. If your product’s deciding specification lives in a metafield the theme renders into a table, the inferred specs are a model’s summary of your page, not your data. Often good enough. Not the same thing as the number you maintain.

What the Knowledge Base app covers

Shopify also ships a free app, Shopify Knowledge Base, that sits beside the catalog. Its help page (read 12 September 2026) describes “automatically generated facts about your store” and FAQs that “aren’t displayed directly on your storefront - instead, they serve as a trusted data source for AI platforms to generate accurate responses about your store.” The FAQ management page shows the scope: shipping and delivery settings, return rules, payment options, account features, languages, plus FAQs you write yourself, which are “saved as metaobjects and can be edited”.

A note on the main page is worth quoting because it is the kind of honesty we like: the app “improves the accuracy of AI responses about your store but doesn’t affect how often your store appears in AI platform results.”

So the Knowledge Base answers store-level questions: do you ship to Norway, what is the returns window. Neither page describes product-level facts. “Does the 700c version fit a 28 mm tyre” is not a store FAQ, and the app is not built to hold one per product.

What this means when a shopper asks whether it fits

Put the pieces together and a shape appears. Shopify’s channel knows your products: which exist, what they are called, what they cost, whether they are available, what the options are. That is the majority of what a shopper needs, and on a text-rich catalog it is nearly all of it.

The questions that decide a specialist sale are different. “Which of these pads fits a C2 caliper?” “Is the 15.4-inch sleeve the same as the 15?” “What is the thread pitch?” “I have a 56 cm head, which helmet size?” The data that answers those is a metafield, a metaobject, an option with hundreds of values, or a table in the description. Of the syndicated fields, only description and options can carry it, and only if you have written it there in prose.

We measured how that plays out. In a simulated check on 4 September 2026 across 34 public specialist storefronts (340 questions, ten per store, one shopper model, OpenAI’s GPT-5.4 mini via the API, using only Shopify’s native storefront tools and public pages), 154 answers were fully right (45%), 144 partly right and 42 wrong. Of the 186 answers that were not fully right, 119 failed on a single attribute of a single product: a spec, a variant price, a stock state. The stores were chosen because their catalogs are option-heavy and spec-heavy, so the numbers describe that kind of store, not Shopify stores in general. On a 150-product coffee store two days earlier, the same native tools were enough: Anthropic’s Claude Opus 5 answered 10 of 10.

The related finding is where the missing facts sit. Across 41 storefronts we crawled on 5 September 2026, metafields were invisible from outside on all 41: not in /products.json, not in the storefront tools, not in the catalog endpoint. On one 1,055-product accessories store, a 15-inch versus 15.4-inch fitment comparison stayed partial for every model we tried, because the difference lives in a metafield. That is not a bug in the channel. It is the channel doing exactly what its field list says.

The same limit applies to the ten storefront tools Shopify added to every Liquid theme on 21 August 2026 (changelog, read 12 September 2026). get_product and show_variant read the product record; the tools do not expose metafields, and “agent support is currently limited to Chromium-based browsers through an origin trial.”

Should you turn it off?

Briefly, because a separate article on this site covers the decision (turn-off-agentic-storefronts). The mechanics are on the Managing agentic storefronts page and each channel page, read 12 September 2026:

Under Sales channels → Agentic, turn off Allow Shopify to manage for me, open a channel, and deactivate Shopify Catalog access (or only Direct checkout, which keeps discovery and sends buyers to your store).
“It can take up to 7 days before your product data is no longer being shared through Shopify Catalog.”
“When access is deactivated, your products can still be discovered through web crawling”, in the same way they are listed in Google.
To hide a single product from AI channels you set it to Unlisted, which the products page notes “also hides the product from sitemaps, search engines such as Google, and your online store search”.

In other words, opting out removes the structured feed and leaves the crawl. It does not make the assistant forget your store, and it does not improve what it says. If the concern is wrong answers about fit or specs, the fix is making that data readable, not removing the data that is already right.

How to see what is being sent

You do not have to guess. From the admin:

Go to Sales channels → Agentic. Each channel shows whether Catalog access and direct checkout are on.
Open “Review how your product data is sent to the Shopify Catalog for Agentic Channels”. This is where Catalog Mapping lives; it shows the source for title, description, category, options and grouping.
The Managing page also describes a search preview tool, “listing quality indicators”, a list of top-ranking products and a list of “products that didn’t rank” (read 12 September 2026). Run a query a shopper would type and see which products come back.
For the raw feed, open https://your-store.com/.well-known/ucp and the catalog endpoint at /api/ucp/mcp, which every storefront serves and which has advertised catalog version 2026-08-25 since 4 September 2026 (our reads). That is what an agent reading the catalog receives. Metafields are not in it.

Then ask the real question. Pick a product whose sale depends on one detail, and ask a fresh ChatGPT, Gemini or Copilot session about that detail. Note the answer and the date. If the answer is right, the syndicated fields carried it. If it is vague or generic, you have found the boundary of the feed.

Where StoreKnows fits

Shopify’s channel knows your products. StoreKnows adds what your product data knows: the metafields, metaobjects and option tables that decide the answer. It runs a simulated check on your store with buyer-intent questions, shows you every answer next to the product data behind it, and lets you publish read-only tools that answer “which variant, what price, in stock, does it fit” beside Shopify’s own. Nothing in Agentic Storefronts changes; the assistant simply has a second, merchant-authored place to look. The check is free.

Results in this article come from simulated checks run by StoreKnows on 2, 4 and 5 September 2026 against public storefronts. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6 and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. Platform facts were read on the linked Shopify pages on 12 September 2026. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

Which product data AI shopping agents can actually read from your store (and which they can't)

2026-09-12T00:00:00Z

Short answer: an AI shopping agent can read your Shopify store through five surfaces, and each returns a different slice of the product record. Title, description, options, price, images and availability travel on all of them. Tags and variant SKUs travel on some. Metafields travel on none: on 5 September 2026 they were invisible from outside on 41 of 41 storefronts we crawled. If the fact that decides the sale lives in a metafield, no agent using these surfaces can see it.

Why this is the question to ask

Specialist catalogs keep their deciding facts in metafields. Thread pitch, compatible models, sensor size, the 15-inch versus 15.4-inch laptop fitment: a well-run store puts these in typed fields so the theme can render a spec table. It is the right way to run a store, and today the one place agents do not look.

On 4 July 2025 a Shopify Partner opened a feature request on the Shopify Community titled “Improve Shopify MCP Agent to Use Metafields for Structured Product Data”. His stores sell model locomotives, and his complaint was precise: the agent “seems to overlook structured data from product metafields—even when I explicitly prompted it”. The thread has two posts, both from partners, the last on the day it opened. As of 12 September 2026 nobody from Shopify has replied (community.shopify.com/t/422280, read 12 September 2026).

Fourteen months later the answer is the same, and it explains most of what we measure. In our batch of 340 shopper questions across 34 specialist storefronts on 4 September 2026 (one shopper model, OpenAI’s GPT-5.4 mini via the API, native storefront tools only), 119 of the 186 answers that were not fully right failed on a single fact about a single product. The agent found the product. It could not read the number.

Surface 1: the public product page

The oldest surface, and the only one where a metafield can appear at all. A crawler or a browsing agent fetches the page and reads the JSON-LD Product and Offer blocks in the source, then the rendered HTML.

The schema block carries the product name, description, image, brand, one offer price and an availability value for one variant. Which variant depends on the theme, and on any SEO app that also writes a Product block.

The rendered HTML carries whatever your theme puts on the page. Metafields reach it only if you have connected them: “You can connect metafields to your theme by adding sections or blocks that support dynamic sources”, or reference them in Liquid (help.shopify.com, Displaying metafields on your online store, read 12 September 2026). A metafield that is defined but not rendered is not on the page. A rendered one arrives as prose or a table cell, not a typed field, often behind a tab or an accordion, and the agent has to find it in the page text.

So the page can carry a spec; whether an agent reads it depends on the theme, the page length and the model’s patience. Every surface below is easier to use, and none of them carry it.

Surface 2: /products.json

Every Online Store storefront answers https://your-store.com/products.json, and agents that fetch pages know it. We opened it on two public storefronts on 12 September 2026. Each product carries id, title, handle, body_html, vendor, product_type, tags, options (name and values), images and variants; each variant carries title, option1 to option3, price, compare_at_price, available, sku, grams, requires_shipping and taxable. No metafields key exists anywhere in the response and no parameter adds one. We found no shopify.dev page documenting the endpoint (searched 12 September 2026); treat it as a public, undocumented read of the data the theme uses.

It is the richest surface for tags and per-variant price and stock, and a plain dump: no search, no filter, 250 products a page. Most agents use a tool surface instead.

Surface 3: the Shopify Catalog and the Shopify-inferred fields

Agentic Storefronts “lets customers discover and purchase your products in AI channels, such as ChatGPT, Google AI Mode and Gemini, Microsoft Copilot, and Meta”, and “is active by default for eligible stores” (help.shopify.com, Shopify agentic storefronts, read 12 September 2026). The data those channels receive comes from Shopify Catalog: products “are listed by default with their title, description, options, images, price, availability, and other key attributes” (help.shopify.com, Shopify Catalog and product discovery, read 12 September 2026). Products set as Unlisted are hidden from AI channels; you can remove Catalog access for ChatGPT or Copilot, though your products “might still be displayed through other external discovery and listing methods”.

“Other key attributes” is where the metafield question lives, and the help page answers it in the next breath: “If your product data, such as title, description, and category, are stored in custom fields, then you can use Shopify Catalog Mapping”. The mapping tool is exact about its scope: “You can map different data sources to your product title, description, and category fields. Choose from product attributes, product metafields, or metaobject references.” With custom variant grouping on, “you can select your product variant options and set the option names that are displayed to customers through Shopify Catalog” (help.shopify.com, Mapping your product data sources for Shopify Catalog, read 12 September 2026). That is five things: title, description, category, variant grouping, option names. There is no row for specs, compatibility or a size chart. A metafield reaches the Catalog only by becoming the title, the description or the category.

There is a second set of attributes in the Catalog, and merchants do not write them. The Global Catalog extension (version 2026-08-25) returns metadata.tech_specs, metadata.top_features, metadata.attributes and metadata.unique_selling_points, each tagged as inferred. Shopify’s guidance: they “might not always be present or might vary in accuracy depending on available product data”, and consumers should “Treat them as discovery and merchandising signals, not as merchant-authored source text” (shopify.dev, Global Catalog extension, read 12 September 2026). An agent reading the Catalog may see a tech_specs block for your product; it is Shopify’s inference from the title, description and images it was given, not your spec table.

Surface 4: the UCP catalog endpoint, /api/ucp/mcp

Every storefront now advertises the Universal Commerce Protocol at /.well-known/ucp (version 2026-08-25 on the storefront we read on 12 September 2026) and serves an MCP endpoint at /api/ucp/mcp. Shopify documents the Storefront Catalog at https://{storeDomain}/api/ucp/mcp with three catalog tools, search_catalog, lookup_catalog and get_product (shopify.dev, About Catalogs, read 12 September 2026). A tools/list call on two public storefronts on 12 September 2026 returned thirteen tools: those three plus cart, checkout and order tools.

The tool descriptions say what they return. get_product returns “a singular product with a relevant set of variants, exact pricing, and real-time availability” and supports “interactive option selection via selected and preferences parameters”. lookup_catalog resolves product and variant IDs in one request. search_catalog accepts “natural language queries, specific filter criteria, or both”. When we ran these tools on 2 September 2026, search_catalog took category, price and availability filters, a shopper context (country, language, currency) and pagination up to 250, and its results carried description.html, variants with price and availability, media, taxonomy categories and tags. Nothing in any response was a metafield.

Two notes for anyone repeating the check. The older /api/mcp endpoint still answers but marks itself deprecated and points to the UCP path. And on 12 September 2026 a bare tools/call on /api/ucp/mcp was refused with “UCP discovery failed” until the request carried a reachable agent profile URL in meta.ucp-agent.profile; on 2 September it had answered unauthenticated. This is the richest of the tool surfaces and the one merchants most often assume carries everything.

Surface 5: the WebMCP storefront tools

Since 21 August 2026 every Liquid storefront registers ten tools with the browser, “live today on every Liquid storefront and on the Hydrogen developer preview”, with “nothing to install or configure” (shopify.dev changelog, WebMCP support for Liquid and Hydrogen storefronts, read 12 September 2026). The ten are search_catalog, browse_store, get_product, show_variant, get_cart, update_cart, cancel_cart, proceed_to_checkout, manage_orders and search_shop_policies_and_faqs (shopify.dev, WebMCP tools, read 12 September 2026). On 32 of 32 live third-party storefronts we read on 5 September 2026 the set was exactly these ten; none of 30 third-party apps we detected registered another.

These are the tools an in-browser agent calls, and they are thinner than the UCP endpoint. When we drove them on four public storefronts on 2 September 2026, search_catalog took a free-text query and a limit of at most ten, with no price, category or availability filter, and returned summary cards: id, title, handle, URL, a single price figure, image, available, variant count, option names, product type and vendor. get_product returned the description, tags, available_options, images and a variants list with each variant’s options, price, list price, availability and SKU.

The documentation describes get_product as returning “full details for a product, including variants, prices, and which option combinations are in stock”. In practice the response leads with a price range and one variant unless the agent names an option, and agents that do not ask a second time answer from that one. On a 1,055-product accessories store on 2 September 2026, six of nine partial answers were exactly this: “$69.99–$79.99”, or the $69.99 minimum, when the variant asked about costs $74.99. Metafields did not appear in any get_product response on any store.

One limit, stated once: “agent support for WebMCP is currently limited to Chromium-based browsers through an origin trial” (same changelog). The trial token Shopify serves expires on 17 November 2026 by our decode of 5 September 2026; we re-check it monthly and will edit this page the day it changes.

The table

Surface	What it returns	Metafields?
Product page (schema + rendered HTML)	Name, description, images, brand, one offer price and availability in schema; whatever the theme renders in HTML	Only if the theme renders them, as page text
`/products.json`	id, title, handle, body_html, vendor, product_type, tags, options, images; per variant: title, options, price, compare_at_price, available, sku, grams	No
Shopify Catalog (Agentic Storefronts)	Title, description, options, images, price, availability, “other key attributes”; Catalog Mapping sets the source of title, description, category and option names; Shopify-inferred `tech_specs`, `top_features`, `attributes`	Only by mapping one into title, description or category
`/api/ucp/mcp` (search_catalog, lookup_catalog, get_product)	Description, variants with exact price and real-time availability, media, taxonomy categories, tags; filters on category, price, availability	No
WebMCP tools (ten, in-browser)	Search: summary cards, free text only, ten at most. `get_product`: description, tags, options, images, variants with price, list price, availability, SKU; price range and one variant unless an option is named	No

Dates: help.shopify.com and shopify.dev pages read 12 September 2026; /products.json and /api/ucp/mcp tools/list read on public storefronts 12 September 2026; tool responses from our runs of 2 September 2026; the 41-store crawl on 5 September 2026.

Metafields: invisible on 41 of 41

On 5 September 2026 we crawled 41 public storefronts and read every surface above that can be read from outside: /products.json, the WebMCP tools, /api/mcp and /api/ucp/mcp. On every store, every surface omitted metafields. Not “usually”: 41 of 41, four surfaces each. The stores were specialist catalogs chosen because their facts live in metafields, so the finding says nothing about how many Shopify stores are affected. It says that if yours is, no surface will carry the field for you.

This is not a defect in the tools. A metafield is by design a merchant-defined field with no fixed meaning; a tool that returned all of them would hand the agent a bag of keys nobody has explained. The Community request from July 2025 was asking for that explanation. It has not come, and the mapping tool that has shipped since maps three fields.

What to do, cheapest first

From a free admin edit to a tool you publish. Most stores need only the first two for their top products.

1. Move the deciding fact into a field every surface reads

Three fields travel on all five surfaces: option values, the title and the description. If the deciding fact is one of a small set of values, make it an option. “Fits: 15-inch / 15.4-inch” as an option value shows up in /products.json, in every get_product response, in the Catalog’s option list and on the page. An agent asking “the 15.4 one, is it in stock” then gets a variant, a price and an availability, which is the answer.

If it is a single number or a short phrase, put it in the title or the first line of the description: “Brake pad set, fits C2 calipers, sintered”. The description is body_html on /products.json, description.html on both tool surfaces, and the text the Catalog syndicates and infers tech_specs from. It is the widest pipe you have. Our six control stores, text-rich with few options, scored no better overall than the specialist ones (25 of 60 fully right on 4 September 2026), so this is not “write more”; it is “put the one fact where the tools return it”.

Costs: editing time. Limits: three options per product, and a description that becomes a spec dump reads badly on the page.

2. Point Catalog Mapping at the metafield

If your real title, description or category already lives in a metafield or a metaobject, tell the Catalog so. Catalog Mapping takes “product attributes, product metafields, or metaobject references” as the source for each of the three fields, and lets you set the option names customers see. For a store whose real description is a metaobject, this is the difference between the AI channels seeing boilerplate and seeing the product.

Costs: an hour in the admin. Limits: three fields plus grouping and option names. It fixes the Catalog surface (ChatGPT, Google AI Mode and Gemini, Copilot, Meta) and nothing else; /products.json and the storefront tools still read the base fields. It cannot carry a spec table, a size chart or a compatibility list.

3. Keep specs in metafields, and publish them through a read-only tool

For everything that should stay a typed field, a chain-line width, a helmet size chart, a “compatible with” list, the theme keeps rendering the metafield and the agent needs a way to ask for it. That is a tool that sits beside Shopify’s ten, reads a saved copy of the store’s metafields and metaobjects the merchant has approved, and answers “which variant, what price, in stock or not, does it fit”. It is what StoreKnows publishes through a theme app embed: read-only, no cart or checkout access.

We have measured what that does on a prepared store. On 5 September 2026, on a dev store of 144 bicycle products whose deciding specs live in metafields, the same 14 questions went from 7 of 14 to 13 of 14 fully right for Google’s Gemini 3.8 Flash via the API and from 4 of 14 to 8 of 14 for OpenAI’s GPT-5.4 mini via the API, one run each, tools served by the embed. On the 1,055-product accessories store on 2 September, Anthropic’s Claude Opus 5 went from 9 of 12 to 12 of 12 with the metafield-backed tools present, in fewer tool calls. Single runs on two stores, not a benchmark.

Costs: the free check shows every answer and the product data behind it; publishing is a one-off charge. Limits: the tool is reachable by agents that call storefront tools, today Chromium-based browsers under the origin trial above, and by any agent that reads the page where it is registered. It is a bridge to the fields, not a change to the Catalog.

What could change this guide

Shopify could expose metafields to agents: Catalog Mapping could gain rows beyond title, description and category; the Global Catalog extension could add merchant-authored attributes beside the inferred ones; the storefront tools could grow a specs tool. Our scanner records the exact tool set on every store it visits, and we re-read the pages linked above each quarter; this page becomes “how to map” the day the gap closes. Until then: five surfaces, three fields that travel everywhere, and a set of typed fields that only a tool can carry.

Results in this article come from simulated checks run by StoreKnows on 2, 4 and 5 September 2026 against public storefronts and one prepared dev store. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6, Google’s Gemini 3.8 Flash and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

Why AI quotes the wrong price for your variant (and how to make the right one readable)

2026-09-12T00:00:00Z

Short answer: an assistant that quotes the wrong price for a variant has read the product, not the variant. The storefront get_product tool returns a price range and one variant unless the agent asks for a specific option; agents often don’t, and quote the range or the minimum. Fix the first variant, then let agents ask for the rest.

Why does an assistant quote $69.99 when the variant costs $74.99?

Every Liquid storefront on Shopify has exposed ten storefront tools to browser-based agents on every Liquid storefront since 21 August 2026 (announced 5 August), currently limited to Chromium browsers through an origin trial whose token expires on 17 November 2026. One of those tools, get_product, is how an agent reads a product once search has found it. Its response carries a price range for the whole product and a single variant. In the responses we captured, a product with four variants reported variant_count of 4 and returned one of them.

To get the price of a specific option, the agent has to call again with that option selected (or call show_variant). That is one more call, per product, and agents run on a budget of a handful of calls per question. When the budget runs short, or the model decides it already has enough, it answers from what it holds: the range, or the low end of it.

We saw this directly in a simulated check on 2 September 2026 against a public 1,055-product phone and device accessories store. Twelve shopper questions, each with a verified answer set; three models, Anthropic’s Claude Opus 5 and OpenAI’s GPT-5.6 and GPT-5.5, called through their developer APIs; at most six tool calls per question; a judge pinned to Claude Opus 5. With the store’s native tools alone, Claude resolved 9 of 12 and both GPT models 8 of 12. No answer scored zero; every miss was a partial. Six of the nine native partials were variant-level price or stock: the agent answered “$69.99–$79.99” or quoted the $69.99 minimum when the variant the question named costs $74.99. The judge’s note on the missing capability, verbatim: “variant-level price lookup for selected options”.

The agent found the right product every time. It just described the wrong version of it.

Why option-heavy catalogs get hit hardest

On a catalog where every product has one variant, none of this matters: the one variant returned is the product. The problem scales with the number of options a shopper has to name before a price means anything.

The accessories store in that check has a “Device” option with 474 values. One phone model alone appears on 45 products. A shopper never asks “how much is this case”; they ask “how much is this case for my phone”, and the answer is a variant, not a product. Every such question costs the agent a second call per candidate product, and a comparison across three cases costs six, which is the whole budget.

Descriptions do not rescue it. On that store, 891 of the 1,055 products carry boilerplate descriptions; the real specs are theme-rendered metafields no storefront tool reads. So the model has nowhere else to look up the price and reaches for the range.

Contrast a 150-product coffee store we checked with the same setup the same day: native tools were enough, Claude Opus 5 answered 10 of 10 and GPT-5.6 9 of 10. The tools are not weak; they return one variant, and text-rich catalogs rarely need more than that. Option-heavy ones do, on almost every question. The wider batch of 34 specialist stores shows the same pattern from the other side: 119 of 186 imperfect answers were a single missing fact about a single product.

What the same shape looks like for stock

The one variant get_product returns carries its own availability. An agent that never asks for the shopper’s option reports that variant’s stock state as the product’s.

Two outcomes follow. If the first variant is sold out and the one the shopper wants is available, the shopper hears “out of stock” for a product you could ship today. If the first variant is in stock and the requested one is not, the shopper hears “in stock”, tries to buy, and finds out at the cart. The first case is the one merchants notice, because it surfaces in forums as “an assistant says my product is sold out”. If that is your symptom, that article walks through the other availability signals too (page schema and the syndicated catalog); this one stays with the variant.

How to check, in ten minutes

Pick a product with three or more variants whose price differs by option. Note the price and stock state of the variant most shoppers buy, and of the product’s default variant (the one listed first) in the admin.
Ask for a specific option, in a fresh session. Open an assistant with no history and ask, in your own words, “How much is [product] for [option] at [store]?” Record the answer verbatim, with the assistant and the date.
Compare it to the variant. A range, or the product’s lowest price, when the option you named costs more, is the mechanism above. The exact price of the first variant, rather than the one you asked for, is the same mechanism.
Repeat with stock. “Is [product] in [option] in stock?” Compare the answer to that variant’s inventory, then to the first variant’s.
Look at your first variant. For your top twenty products, is the product’s default variant (the one listed first) the one most shoppers want, and is it in stock? If not, that is where an agent starts reading.

Consumer assistants add their own retrieval and caching on top of the storefront tools, so a manual check tells you what a shopper heard on that day, not what every agent will read. A simulated check through the developer APIs shows the tool responses themselves, which is where the fix has to land.

The fixes, cheapest first

1. Make the first variant the one most shoppers want, and keep it in stock

This costs nothing and works immediately. In the admin, order each product’s variants so the best-selling option comes first, and watch its inventory: if the first variant sells out, the product reads as sold out to any agent that does not ask further. For products where one option dominates, this alone removes most wrong-variant answers. For products where the mix is even, it only moves the error to a different shopper, which is why the next two fixes exist.

2. Name option values the way shoppers ask

Variant titles on Shopify are built from option values, and they are what an agent sees when it does ask for a specific option. “iPhone 17 Pro Max” matches a shopper’s question; “17PM” or “Model C” does not, and an agent that cannot match the shopper’s words to an option value will not select it, even when it tries. Write option values in the words a shopper would type, keep them consistent across products, and avoid encoding two facts in one value (“Black / MagSafe”) when they are separate options. Free, but tedious on a large catalog; do the top sellers first.

3. Publish a per-variant price and stock tool

The two fixes above make the right variant easier to hit. They do not let an agent ask “what does the version for my phone cost, and is it in stock?” and get that variant’s answer in one call. That is what StoreKnows’ captured-variant tool does. It publishes, read-only, the price and availability of every variant of every product, beside Shopify’s own tools, from a saved copy of your catalog that you review and approve before anything goes live. It is not live inventory: the tool answers from the copy you approved, and you refresh it when you choose. We say so to shoppers’ agents in the tool description and to you in the app, because a stale “in stock” is worse than a range.

The reason we built it is what happened in that same check when we added tools with full variant data. A compare-products tool that returns every variant’s price and availability for the products named, in a single call, was what fixed the variant partials: Claude Opus 5 went from 9 of 12 to 12 of 12 while making 40% fewer tool calls (a mean of 4.4 per question down to 2.7), because it stopped looping through get_product per product. GPT-5.5 went from 8 to 10. GPT-5.6 went from 8 to 9; its traces show it often ignored the added tools and kept searching and reading one product at a time, then quoted the minimum. Tool adoption is model-dependent, which is why the app shows you the result per assistant rather than one number.

What this does not tell you

Twelve questions, three models, one run each, on one store chosen because it is hard. The counts describe a mechanism, not a rate you should expect on your own catalog. The check ran through developer APIs, not the consumer apps, so it shows what the tools return and how a model reads them, not what ChatGPT or Gemini will say to a shopper this afternoon.

It also does not cover every miss. One comparison in that check, between a 15" and a 15.4" screen protector, stayed partial in every model with native tools alone, because the difference lives in a metafield no tool exposes. Variant tools fix variant questions; spec questions need spec data made readable, which is a separate fix.

The variant problem is the most common one we see on specialist stores, and the cheapest to test. Reorder your first variants this week, rename the option values that shoppers would not recognise, and if your catalog looks like the one above, run the free check: you will see every answer by assistant, the variant the agent actually read, and what changes when it can ask for the right one.

Results in this article come from a simulated check run by StoreKnows on 2 September 2026 against a public 1,055-product accessories storefront and a public 150-product coffee storefront. Questions were answered by Anthropic’s Claude Opus 5 and OpenAI’s GPT-5.6 and GPT-5.5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

The AI shopping tools every Liquid storefront got in August 2026: the ten tools, what they read, what they can't

2026-09-12T00:00:00Z

Short answer: since August 2026 every Liquid storefront on Shopify declares ten tools that an AI agent running in the shopper’s browser can call. They search and browse the catalog, fetch a product’s variants and prices, manage the cart, hand off to checkout and orders, and answer policy questions. They read what the catalog holds. A spec in a metafield, a filter across tags, or the price of one particular variant is where they stop.

What WebMCP is, in one paragraph

WebMCP is “a proposed web standard to help you build and expose structured tools for AI agents” (developer.chrome.com, published 18 May 2026, last updated 7 August 2026). A page registers tools with the browser, each with a name, a description and a JSON schema for its inputs. An agent running in that browser reads the list and calls the tool it needs, getting structured data back instead of scraping the page and simulating clicks. Shopify’s own description is the same shape: “your storefront registers tools with the browser, and the agent calls them with structured inputs and gets structured data back” (shopify.dev/docs/api/web-mcp, read 12 September 2026). The standard covers the declaring side. Which agents call the tools is a separate question, and we come back to it.

When it arrived, and where

Shopify’s changelog entry “WebMCP support for Liquid and Hydrogen storefronts” is dated 5 August 2026 and says the tools “are live today on every Liquid storefront and on the Hydrogen developer preview. There’s nothing to install or configure” (shopify.dev/changelog/webmcp-liquid-hydrogen, read 12 September 2026). If your store runs a Liquid theme, you have these tools now, and you did nothing to get them.

One design point from the docs matters for what follows: the catalog tools “read product, collection, and search data through the Storefront API”, so they see what the Storefront API sees. Everything happens in the tab the shopper is looking at.

The ten tools

Names and descriptions below are from Shopify’s documentation (read 12 September 2026), lightly shortened.

Tool	Group	What it reads or does
`search_catalog`	Catalog	Searches products, collections, articles and pages. Returns matching products with prices and availability, plus a link to the full search results page.
`browse_store`	Catalog	Lists the store’s collections, or the products in one collection. Can take the shopper to the collection page.
`get_product`	Catalog	Full details for one product: variants, prices, and which option combinations are in stock. Can take the shopper to the product page.
`show_variant`	Catalog	Opens a product page with a specific variant selected; accepts an exact variant or a partial option such as a colour.
`get_cart`	Cart	Reads the cart: line items with product and variant details, quantities and totals.
`update_cart`	Cart	Adds items, changes quantities or removes items. If a request is ambiguous it returns options to clarify without changing the cart.
`cancel_cart`	Cart	Empties the cart.
`proceed_to_checkout`	Checkout and orders	Takes the shopper to checkout with the current cart, after checking it is not empty.
`manage_orders`	Checkout and orders	Takes the shopper to their order history; asks them to log in first if needed.
`search_shop_policies_and_faqs`	Store information	Answers questions about the store’s policies and services, such as returns, shipping and opening hours, from the store’s own content.

Four of the ten read data, five act on the session, one answers from policy content. An agent’s knowledge of your products comes almost entirely from the first three: search_catalog, browse_store and get_product.

Who can call them today

Shopify’s changelog is direct about this: “WebMCP is still an emerging standard, and agent support is currently limited to Chromium-based browsers through an origin trial.” The docs page says the same without the last clause: “agent support for WebMCP is currently limited to Chromium-based browsers.”

An origin trial is Chrome’s way of letting a site turn on an experimental API for its own visitors before the browser ships it to everyone. The API is not on by default in any Chrome channel; it works on Shopify storefronts because Shopify serves a trial token. We decoded that token on 5 September 2026 and re-checked it on 12 September: it expires on 17 November 2026. By then either Chrome ships the API by default, Google extends the trial and Shopify renews its token, or the tools stop appearing until one of those happens. We will update this line the day the date changes.

The other half deserves the same precision. Chrome ships the page-side API; it does not yet ship a built-in agent that calls page tools, and Google’s documentation names no such consumer. Today the callers are extensions, site-loaded agents, automation frameworks and the ChatGPT desktop app’s browsing mode, which we have driven against these tools by hand. That is a small share of shopper sessions. None of this is a defect in Shopify’s implementation; it is the state of the browsers.

What is not documented

Two things merchants ask us about have no published answer, as of 12 September 2026.

There is no documented way to turn the tools off on a Liquid theme. Neither the changelog nor the docs page describes an opt-out, a theme setting or an admin toggle. Chrome’s side has a tools Permissions Policy, but it “defaults to self, which allows tool registration in top-level and same-origin contexts” (developer.chrome.com, 7 August 2026), so it does not stop a script the storefront itself loads. If you want the tools gone, the honest answer is that nobody has written down how.

Nothing is published about apps registering additional tools. The WebMCP specification permits any script with document access to register a tool, subject to that same policy. Shopify has not said whether apps may do so on a storefront, or under what rules. StoreKnows does register tools this way, through a theme app embed the merchant enables, and will follow Shopify’s guidance when it arrives. On 32 live third-party storefronts we read on 5 September 2026, the tool set was the same ten on every one, and none of the 30 third-party apps we detected had added a tool.

What the tools return, in practice

The descriptions above are what the tools are for. What matters for a shopper question is what comes back. Three observations from our own checks:

get_product returns a price range and one variant unless the agent names an option. The docs say it returns “variants, prices, and which option combinations are in stock”, and it does: the response carries the product’s price range and the details of one variant, and the agent has to ask again with a specific option to get another. On a 1,055-product phone-accessories store we checked on 2 September 2026 (12 questions; Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6 and GPT-5.5 via their APIs; a separate judge model), six of the nine partial answers were exactly this: the agent answered “$69.99–$79.99”, or the $69.99 minimum, when the variant the shopper chose costs $74.99. Our fix article on AI assistants calling in-stock products sold out covers the availability version of the same trap.

search_catalog returns ten summary cards. Title, price, availability, a link. It is a good search. It is not a filter: “in-stock black-and-white 35 mm film under $10” is an intersection the agent has to rebuild by opening products one at a time, and it runs out of tool calls. In the same 2 September check, the three remaining partials were attribute-filter recall across near-identical products, where the deciding property lived in tags or options that the search result does not carry.

Metafields are not in any of it. On 41 of 41 storefronts we crawled on 5 September 2026, product metafields were invisible from outside: not in the WebMCP tools, not in /products.json, not in the UCP catalog endpoint. If your thread pitch, your helmet size chart or your “fits models X, Y, Z” note is a metafield the theme renders on the page, an agent calling get_product does not see it. A 15-inch versus 15.4-inch fitment comparison in that accessories check stayed partial in every model for this reason.

Which shopper questions this covers, and which it doesn’t

Put the tool list and the return shapes together and the map is fairly clear.

Answered well by the native tools:

Do you sell a 4-person tent? Is it available in green? Search, then get_product, then a variant lookup. In our batch of 340 questions across 34 specialist storefronts on 4 September 2026 (OpenAI’s GPT-5.4 mini via the API, native tools only), fit questions of this kind were fully right 55 times out of 68.
What is your returns window? Do you ship to Ireland? search_shop_policies_and_faqs reads the store’s own policy pages and FAQs, which is precisely what those pages are for. Keep them complete and current and the tool has what it needs.
Add the medium to my cart and take me to checkout. The cart and checkout tools were built for this, and they trigger your theme’s own behaviour.

Not answered by the native tools alone:

What is the max load of this rack? A spec in a metafield, or in an image, or in a size chart. Not returned.
How much is the 256 GB one? A variant’s price, when the agent did not name the option. It gets the range or the minimum.
Show me the in-stock MagSafe cases under $30 with a kickstand. A filter across tags and options. Search returns ten cards; the agent cannot intersect what it cannot see.
What is actually different between these two? Comparisons were fully right 16 times out of 68 in the same batch, because the fact that separates two near-identical products is usually one of the three above.

The pattern in our data is not “the tools fail”. It is that the agent almost always finds the product and then lacks one fact about it. On a small text-rich coffee store, checked the same week with the same setup, native tools alone answered 10 of 10 (Claude Opus 5) and 9 of 10 (GPT-5.6). The tools read what the catalog holds; specialist catalogs hold their deciding facts where the tools do not reach. The full numbers, method and limits are in What AI shoppers get wrong about specialist products.

How to see the tools on your own store

You can read the list yourself in about a minute. Open your storefront in Chrome (or another Chromium browser: Edge, Brave, Arc), open the developer console, and run:

await document.modelContext.getTools()

You get back an array of ten tool objects, each with its name, description and input schema. This is the check Slobodan “Sani” Manic of No Hacks ran on 6 August 2026, the day after the changelog, on three live Liquid storefronts in a stock Chrome 150 with no flags (nohacks.co, published 6 August 2026). Two of his details are useful here: the older name from the draft spec, navigator.modelContext, now returns a deprecation warning pointing at document.modelContext; and the descriptions the tools ship with are the text an agent uses to decide which tool to call. Read yours. It is your store as an agent will see it.

If document.modelContext is undefined, you are either not in a Chromium browser, or the origin-trial token is not being served to your page, or the trial has ended. That last case is what the 17 November date is about.

What StoreKnows adds beside them

StoreKnows does not replace any of the ten tools and does not put a chat widget on your store. It registers a small set of extra read-only tools beside Shopify’s, through a theme app embed you enable, built from a saved copy of your catalog that you review and approve. They answer the questions the native set does not: the price and stock of a named variant, a spec or chart from a metafield or metaobject, a “fits with” relationship. An agent that can call get_product can call them too, unchanged. On our dev store, with 144 seeded bicycle products whose deciding specs live in metafields, that took Google’s Gemini 3.8 Flash via the API from 7 of 14 fully right to 13 of 14 on one run each, and OpenAI’s GPT-5.4 mini from 4 of 14 to 8 of 14 (5 September 2026; runs vary).

The honest limits are the same as Shopify’s. The added tools run under the same origin trial and the same expiry date. They are read-only. They serve a saved catalog copy, not live inventory, so stock answers are as fresh as the last sync you approved. And a simulated check tells you what the tools return and how a model reads them, not what a consumer assistant will say to a given shopper this afternoon.

What to do this week

Run the console line above on one product page and read the ten descriptions.
Take the five hardest questions your customers actually send you and check where each answer lives: title, description, option or variant (the tools see it), or metafield, chart, image or tag (they do not).
Make sure the first variant of every product is one you would be happy to have quoted as “the” price and stock.
Keep your policy pages complete; the policy tool is only as good as they are.
Run a simulated check to see the answers agents actually give on your store, with the product data behind each one. StoreKnows does that for free, and lets you try a fix against your own question before publishing anything.

Results in this article come from simulated checks run by StoreKnows on 2, 4 and 5 September 2026 against public storefronts and our own development store. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6, Google’s Gemini 3.8 Flash and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

Should you turn off Agentic Storefronts? What opting out does, and what fixing does instead

2026-09-12T00:00:00Z

Short answer: you can switch off each AI channel’s access to your products under Sales channels → Agentic, but you cannot opt out of Shopify Catalog itself, the change takes up to seven days, and assistants can still find your products by crawling. If the worry is wrong recommendations, opting out removes the correct facts and leaves the gaps. Fixing the data is the other option.

Why merchants search for this

Type “shopify agentic storefronts” into Google and the suggestions, as of 11 September 2026, are launch, reddit, supplemental terms of service, turn off agentic storefronts, and chatgpt. Two of the five are merchants who have just found the feature is on and want to know what they agreed to and how to leave.

The clearest version of the worry is a thread on the Shopify Community from 5 June 2026 titled “Why Can’t We Opt Out of Agentic Storefronts?” The merchant sells parts to what they call “a niche within a niche”, where customers are sometimes unsure what they need even with a human to ask. Their fear is specific: an assistant confidently connecting a buyer with the wrong part, an uptick in orders that have to be amended or returned, and products shown in contexts the merchant never gets to correct. They had already turned the channels off and were angry that the Shop app could not be switched off the same way.

That is a reasonable worry for a fitment-heavy catalog, and it deserves a precise answer about what the switch does rather than reassurance. What follows was read from Shopify’s own help pages on 12 September 2026.

What exactly can you switch off?

Agentic Storefronts is the umbrella for four AI channels: ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta. The main help page (read 12 September 2026) says it “is active by default for eligible stores”, that you “manage which AI channels you want to sell your products on” under Sales channels → Agentic, and that using it means you “read and agree to the Shopify Agentic Storefronts Supplemental Terms of Service”. What each channel receives and does is covered in Agentic Storefronts, explained for merchants; this article is only about the off switch.

The switch has three layers, per the Managing agentic storefronts page (read 12 September 2026):

Allow Shopify to manage for me. The default. While it is on, every current channel is active and you are enrolled in future ones. Turning it off is the first step; nothing else is editable until you do.
Shopify Catalog access, per channel. This is the opt-out most people mean. The ChatGPT channel page (read 12 September 2026) gives the path as Sales channels → Agentic → ChatGPT, then deactivate “Shopify Catalog access”. Copilot, Google and Meta work the same way.
Direct checkout, per channel. On the channels that have it (Google, Copilot, Meta), you can leave discovery on and turn off the in-chat checkout, so the shopper is sent to your store to buy.

Two caveats travel with layer 2, in Shopify’s own words. On timing: “If you turn off Shopify Catalog access, then it can take up to 7 days before your product data is no longer being shared through Shopify Catalog.” On reach: after access is removed, “your products might still be displayed or referenced by the AI channel through other external discovery and listing methods, such as web crawling and indexing.”

What can you not switch off?

The Shopify Catalog page (read 12 September 2026) is plain about it: “You can’t opt out of Shopify Catalog itself.” The catalog is the structured product record Shopify builds from every eligible product on the platform; the channel switches decide who may read it, not whether it exists. The same page says you can “stop individual agentic storefronts from having access to your products through Shopify Catalog”, which is layer 2 above, and that inclusion does not promise a place in any answer or any position.

Two more things sit outside the switch.

The Shop app. The Managing page notes that Shop does not offer the option to deactivate Catalog access in the Agentic section; Shop is managed through its own sales channel. This is what the June thread was ultimately about. The only way Shopify documents to hide a product from every agentic storefront including Shop is the Unlisted product status or the seo.hidden metafield, and the products page (read 12 September 2026) spells out the cost: setting a product to Unlisted “also hides the product from sitemaps, search engines such as Google, and your online store search”. That is a per-product decision, and it is a decision to leave Google as well.

The open web. The products page lists three ways an AI channel can find your products: Shopify Catalog, “web crawling and indexing”, and “product feeds that you own and share”. The switch touches the first. Your robots.txt rules, the page adds, are “directional and advisory”. A full opt-out plus a crawler block is not silence; it is a request.

What stays true after you opt out?

Removing Catalog access changes one input to the assistants and leaves every other input where it was.

	Opting out of Catalog access changes it	Opting out leaves it as it was
Structured catalog record (title, description, options, images, price, availability) sent to that channel	Yes, after up to 7 days
Direct checkout inside Google, Copilot or Meta	Yes, if you turn it off
Your product pages on the open web		Still public, still crawled and fetched
Your schema markup (Product, Offer, availability)		Still there, still read
The ten storefront tools on every Liquid theme (search, product, variant, cart, policies)		Still served, still callable by a browser agent
`/products.json`, `/llms.txt`, `/agents.md`, the UCP catalog endpoint		Still served
The Shop app’s use of the catalog		Unchanged unless the product is Unlisted
Whether an assistant mentions your products at all		Still possible, from the sources above
What the assistant knows about fit, specs, compatibility		Whatever was in the description; the rest was never sent

The row that matters is the last one. Shopify Catalog syndicates “title, description, options, images, price, availability, and other key attributes” (products page, read 12 September 2026). Metafields, size charts and compatibility tables are not on that list, and Catalog Mapping only lets you choose the source for five listing fields. The fitment data that would have prevented a wrong recommendation was not in the feed before you opted out, and it is not in the crawl after.

So after opting out, assistants still answer questions about your products, from a cached crawl or a live page fetch instead of a fresh structured record: the same data with less precision and more lag. The wrong-part risk does not go down. It can go up, because the price and availability the catalog kept current are now whatever the crawler last saw.

The honest trade-off for a specialist merchant

We have some numbers on where wrong answers come from, and they bear on the decision.

In a simulated check on 4 September 2026 across 34 public specialist storefronts (parts, tools, cameras, outdoor, 3D-printing; 340 questions, ten per store; one shopper model, OpenAI’s GPT-5.4 mini via the API; only the store’s public pages and Shopify’s native storefront tools), 154 answers were fully right (45%), 144 partly right and 42 wrong. Of the 186 that were not fully right, 119 had missed or misread one fact about one product, and 24 had missed a link between two products. The stores were chosen because their catalogs are option-heavy and spec-heavy; the figures describe that kind of store, not Shopify stores in general. The full breakdown is in What AI shoppers get wrong about specialist products.

Two days earlier, on a 1,055-product phone-accessories store, a 15-inch versus 15.4-inch fitment comparison stayed partial for every model tried (Claude Opus 5, GPT-5.6, GPT-5.5), because the difference sits in a metafield no tool or feed exposes. On a 150-product coffee store the same day, the native tools alone were enough: 10 of 10 for Claude Opus 5.

The shape is consistent. On a text-rich store the assistant does fine with what Shopify sends. On a specialist store it finds the right product almost every time and then guesses at the one fact that decides the sale, because that fact was never readable. The channel is not the cause of the wrong answer; the missing fact is. Opting out removes the channel’s correct contribution (which product, what it costs, whether it is available) and does nothing about the missing fact. For the merchant in the June thread that is a poor trade: the returns they fear come from an assistant that cannot see what fits what, and the switch does not make it see more.

One reply in that thread said as much: the problem for a fitment-sensitive catalog is not the agent existing but the agent working from descriptions that do not say what fits what. We would add one thing. If the compatibility rules live in a metafield, today’s feed and tools still cannot see them either. They have to be published somewhere an agent can read.

When is opting out the right call?

There are cases where turning a channel off is simply correct, and the mechanics above serve them well. This is our reading, not Shopify’s guidance.

You only sell B2B. B2B-only products are excluded from the channels anyway (the ChatGPT page says they are not supported), so there is nothing to lose by turning them off.
You cannot serve the channel’s shoppers. The ChatGPT channel and every direct checkout are for customers in the United States. If you do not ship there, or a product carries regional restrictions an assistant elsewhere should not be offering, turning that channel off matches reality.
Pre-launch or a catalog you are rebuilding. If titles, prices and availability are about to change wholesale, a seven-day lag on a structured feed can put stale records in front of shoppers. Turn it off, finish, turn it back on. The crawl will see the interim state either way.
You need a product invisible everywhere. Then Unlisted is the tool, and it is a decision about search engines too.

What does not belong on the list is “assistants sometimes get my products wrong”. That is a reason to look, not a reason to leave.

The alternative: check, fix, re-check

If the worry is wrong recommendations, the useful question is not “how do I opt out” but “what are assistants getting wrong about my products, and which fact is missing when they do”. There is a method for that.

Check. Open a fresh session in ChatGPT, Gemini and Copilot and ask three buyer questions about one product whose sale depends on a detail: does the 700c version fit a 28 mm tyre, which of these pads fits a C2 caliper, is the 5-roll bundle in stock. Record the variant, price, stock state and any fit claim, with the date. The method, the question templates and why answers move between sessions are in How to check what ChatGPT, Gemini and Copilot say about your store. A simulated check does the same thing repeatably, through the models’ APIs and your store’s own tools, and shows which fact was missing behind each miss.

Fix. Most misses we see have one of three causes. The first variant is quoted as “the” price and stock, so make it one you are happy to have quoted. A deciding spec sits in a metafield or an image, so write it into the description in a sentence a model can parse, or publish it through a read-only tool the agent can call. A compatibility rule lives in prose, so give it a structure: this part, these models, not those.

Re-check. Run the same questions again. On a 144-product development store on 5 September 2026, the same 14 questions went from 7 to 13 fully right with Google’s Gemini 3.8 Flash via the API and from 4 to 8 with OpenAI’s GPT-5.4 mini via the API, one run each, after the deciding specs were made readable to the storefront tools. Runs vary; the direction is the point. Then confirm in the consumer apps with the fresh-session log, because a simulated check tells you what the tools return, not what ChatGPT will say to a shopper this afternoon.

None of this touches Sales channels → Agentic. The channels keep sending the facts they already have right. You add the ones they were missing.

Where StoreKnows fits

StoreKnows runs the simulated check on your store for free: buyer questions generated from your own products, answered by several models through their APIs using only your storefront’s tools and pages, each answer graded and shown beside the product data behind it. If a fact is missing, you can try a fix against your own question before publishing anything. Agentic Storefronts stays as it is; the assistant simply gets a second, merchant-authored place to look.

Results in this article come from simulated checks run by StoreKnows on 2, 4 and 5 September 2026 against public storefronts and a development store. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6, Google’s Gemini 3.8 Flash and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. Platform facts were read on the linked Shopify pages on 12 September 2026. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

Size charts AI shoppers can read: data, not images

2026-09-12T00:00:00Z

Short answer: an assistant can only turn “my head measures 56 cm” into “order the M” if it can read your chart as rows, and no storefront surface returns a chart that is an image, a PDF, a pop-up page or a metafield. Store the chart as structured rows (size, minimum, maximum, unit), link it from each product, and give agents a tool that reads it.

The question your staff answer every day

“I measure 56 cm around the head, which size?” “My foot is 27.5 cm, is that a 43 or a 44?” “Chest 98 cm, medium or large?” A shop assistant answers with the chart. A shopper on your site finds the chart, reads the row, and checks that size is in stock.

An AI shopper has to do the same three things, and the second is where it fails. In our batch of 340 shopper questions across 34 specialist Shopify storefronts on 4 September 2026 (one shopper model, OpenAI’s GPT-5.4 mini via the API, native storefront tools only, in a simulated check), 119 of the 186 answers that were not fully right failed on a single fact about a single product. A size chart is that kind of fact, once per product type, usually stored where agents cannot see it. The wider pattern is in what AI shoppers get wrong about specialist products; this guide is about the chart.

Why does an assistant answer the sizing question badly?

Since 21 August 2026 every Liquid storefront exposes ten storefront tools to browser-based agents, and every store also serves a catalog endpoint at /api/ucp/mcp and the older /products.json. Across those surfaces an agent can read a product’s title, description, options and option values, images, price and availability, and per-variant price and stock. It reads “S / M / L” as option values. It does not read what S means in centimetres, because that fact is in no field those surfaces return. On 5 September 2026 we crawled 41 public storefronts and read /products.json, the WebMCP tools, /api/mcp and /api/ucp/mcp on each: metafields were invisible from outside on 41 of 41. The surface-by-surface account is in which product data AI agents can actually read.

That leaves the product page, which a browsing agent can fetch. What it finds depends on how you built the chart:

An image. The most common format, because a designer made it once. To an agent it is pixels: text recognition, then a guess whether the row that says “M” belongs to the column that says “55–58” or the one that says “21.7–22.8”. The storefront tools never return the image’s contents at all.
A PDF. A link to a file on another URL. An agent reading get_product sees a link in the description at best; opening it is another fetch, another parse, the same column-guessing problem.
A theme-rendered table. Better: the rows are text. But they sit inside a tab, an accordion or a pop-up, as HTML the agent has to find, and only an agent that reads pages rather than calling tools will see them.
A metafield. If you have done the disciplined thing and stored the chart as a metafield or a metaobject, you have rows an agent could use perfectly, and no surface carries them.

None of this is a defect in the tools; they read the product record the way the storefront does, and a size chart has no fixed place in that record. The result is the same in every case: the assistant knows the product comes in S, M and L and cannot say which one a 56 cm head needs. It lists the options, tells the shopper to check the chart, or guesses. Guessing produces returns.

What does Shopify offer for size charts?

Shopify’s own guidance treats a size chart as a metafield: “If you sell clothing and you want to display a size chart for your products, then you might add a Product metafield called Size chart”, and “You can then display the size chart as a pop-up on your product pages” (help.shopify.com, Metafields, read 12 September 2026). The linked tutorial builds a page reference metafield and connects it to a pop-up block: “With metafields, you can add a page reference to a pop-up block that displays a link on your product pages”, and the chart is a page where “You can add images and other media using the rich text editor” (help.shopify.com, Adding a pop-up size chart to your product pages, read 12 September 2026). It needs a theme that supports dynamic sources.

That is a good design for people. For an agent it is two hops (a metafield the tools do not return, pointing at a page the tools do not return) ending in whatever you pasted into the rich text editor, which is very often the image again.

Metaobjects are the other half of the toolkit, for “when your data is best represented by multiple fields”, with a definition and entries, and “Your metaobject can be referenced by metafields or used stand-alone” (help.shopify.com, Metaobjects, read 12 September 2026). A size chart is exactly that shape.

On the syndication side, Agentic Storefronts sends products to ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and Meta through Shopify Catalog, and Catalog Mapping steers what goes. Its scope is exact: “You can map different data sources to your product title, description, and category fields” (help.shopify.com, Mapping your product data sources for Shopify Catalog, read 12 September 2026). There is no size chart row. The only way a chart’s numbers reach the Catalog is as sentences in the description.

Most guides about size charts on Shopify, and most apps in the category, are about showing the chart to a person: a pop-up, a tab, a recommender on the page. They do that well, and they are not the problem here. The problem is that whatever they render, an agent cannot read it as data.

Chart formats, and whether an assistant can read them

How the chart is stored	Returned by the storefront tools or catalog endpoints?	Readable by an agent that fetches the page?	Usable as rows?
Image (PNG/JPG) in the description or gallery	No (the URL travels; the contents do not)	Only with text recognition; column matching is a guess	No
PDF link	No	Only with a second fetch and a parse	Rarely
HTML table rendered by the theme (tab, accordion, section)	No	Yes, as page text, if the agent finds it	Sometimes
Pop-up page via a page reference metafield	No (neither the metafield nor the page)	Only by following the link, and only as whatever the page holds	Depends on the page
Option values (S, M, L)	Yes, on every surface	Yes	Labels only; no measurements
Structured rows (metaobject or JSON metafield: size, min, max, unit)	No (metafields invisible on 41 of 41 stores, 5 September 2026)	No, unless the theme also renders them	Yes, through a tool that reads them

Dates: help.shopify.com pages read 12 September 2026; surface behaviour from our reads of 2, 5 and 12 September 2026, set out in the product data guide.

The last row is the interesting one. Structured rows are the only format an agent could use without guessing, and the only format that today reaches no surface at all. The fix is not to abandon the format. It is to keep it and add the tool.

The data model that works

A size chart an agent can use is a table with one row per size and, for each row, the measurement range that maps to it:

One chart per product type, not per product. Helmets share a head-circumference chart; a jacket line shares a chest chart; shoes share a foot-length chart. Each chart is a metaobject entry (or a JSON metafield holding the same rows).
One row per size: a label that matches your option value exactly (“M”, not “Medium” if the variant says “M”), a minimum, a maximum, and the unit in the column name (head_circumference_cm, chest_cm, foot_length_mm). Store numbers as numbers, not as “55–58 cm” text, though a tool can parse the text form if that is what you have.
A link from every product that uses the chart: a metaobject reference metafield on the product (custom.size_chart, say) pointing at the chart entry.
Keep the rendered chart for people. Point the theme’s table or pop-up at the same metaobject, so the visible chart and the rows cannot drift apart.

Here is our demo store’s version, and it is demo data, not a real product: the Cedar Road Helmet on our development store carries a chart with three rows, S 51–54 cm, M 55–58 cm, L 59–62 cm, keyed on head circumference. “My head measures 56 cm, which size?” resolves to one row, M, by arithmetic. Nothing to interpret. A tool that has the rows can answer with the row, then check whether the M variant is available in the saved catalog copy, and at what price.

Two things this model deliberately does not do. It does not predict fit between rows (a 58.5 cm head sits between M and L; the honest answer names both and says so), and it does not replace the brand’s fit advice (“runs small, size up”). Put that advice in the description, where every surface reads it; keep the rows in the chart.

How to check your own store

Start with the manual version, in fresh sessions, so no earlier chat teaches the assistant your chart:

Pick one sized product and note two rows: one for a measurement in the middle of a size, one on a boundary.
Ask a consumer assistant, in a new conversation each time, in a shopper’s words: “My head measures 56 cm. Which size of the [product] at [store] should I order?” Record the answer verbatim, with the assistant and the date. Repeat with the boundary measurement.
Compare to the chart. “Here are the sizes, check the chart”, a size with no reasoning, or a size that contradicts the row: each says the assistant did not read the rows.
Ask which size is in stock. An assistant that names the right size may still report the product’s stock rather than that variant’s; that is a separate mechanism with its own fix.

Consumer assistants add their own retrieval and caching, so this tells you what a shopper heard that day, not what every agent reads. A simulated check goes one layer down: it calls the models through their developer APIs against the storefront tools and shows the tool responses each answer was built from, so an unreadable chart shows up in the trace (the agent called get_product, received option values, and had nowhere to get centimetres from). Both routines are in how to check what AI says about your store.

What StoreKnows’ “Recommend a size” tool does

StoreKnows reads the store’s catalog into a saved copy: products, variants, prices, availability, options, metafields, and the metaobjects those metafields reference, which is where size charts live. When it finds a chart with numeric ranges and products that reference it, it proposes a fix called “Recommend a size”. The tool’s job is narrow: given a product and a measurement, find the row the measurement falls in and return it.

The answer is the row, not an opinion: the recommended size label, the matched row as stored (so the agent can quote “M, 55–58 cm”), whether the measurement fell inside a row, between rows or beyond the chart’s ends, any second row that overlaps at that measurement, and the matching variant’s captured availability and price when the label matches an option value. A product with no chart gets “no chart” and the sizes it comes in, not a guess.

The boundaries, stated once:

Read-only. It answers questions. No cart, checkout or order access; nothing on your store changes.
Saved catalog copy, not live stock. Availability is from the copy you approved, refreshed when you choose. The tool description says so to the agent; the app says so to you.
Needs numeric ranges. A chart that is an image or free text has nothing to match; the app says so and lists the chart under what to add.
Not a fit predictor. Between-row and off-chart measurements are labelled as such.
You approve what becomes public. Nothing is served until you include a fix and publish; excluding it withdraws it.

Before any of that there is a preview. Open the proposed fix and type your own question (“My head measures 56 cm. Which size does the Cedar Road Helmet chart recommend?” is the one we use on the demo store). You see the answer and the rows it used, on saved data, before paying anything. If it picks a row you would not have picked, you have found a chart problem to fix, not a tool to publish.

Published fixes are served by a theme app embed beside Shopify’s own ten tools, so an agent that calls storefront tools finds “recommend a size” in the same list as get_product. Today that means Chromium-based browsers under an origin trial whose token expires on 17 November 2026 by our decode of 5 September 2026; we re-check it monthly. We have measured what metafield-backed tools do on a prepared store, though not on sizing questions specifically: on 5 September 2026, on a dev store of 144 bicycle products with specs in metafields, 14 questions went from 7 to 13 fully right for Google’s Gemini 3.8 Flash via the API and from 4 to 8 for OpenAI’s GPT-5.4 mini via the API, one run each, in a simulated check. Runs vary; treat it as a shape.

What to do this week

If your charts are images, the first move costs nothing but time: write the rows out as a metaobject, one entry per product type, reference it from each product, and point the theme’s pop-up or table at it so people keep seeing a chart. Put the brand’s fit advice in the description. Then ask the sizing question in a fresh session.

For the surfaces that read tools, which is where in-browser agents start, the rows need a tool. StoreKnows runs the simulated check on your own store for free, shows every answer beside the product data behind it, and lets you try “Recommend a size” with your own measurement before anything is published.

Results in this article come from simulated checks run by StoreKnows on 4 September 2026 against 34 public storefronts, a crawl of 41 public storefronts on 5 September 2026, and a run on 5 September 2026 against a development store. Questions were answered by OpenAI’s GPT-5.4 mini and Google’s Gemini 3.8 Flash, called through their developer APIs, not the consumer apps, and graded by a separate judge model. The Cedar Road Helmet and its chart are fictional demo-store data. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

"Will it fit?" Compatibility data that AI assistants can use

2026-09-12T00:00:00Z

Short answer: in our simulated check, “does this fit?” was fully right 64% of the time, better than most question types. The misses split almost evenly between a missing link (pads to calipers) and a missing fact (one spec), and both live in fields the storefront tools do not return. A compatible_with list on the part, named consistently, fixes both.

What a compatibility question looks like from the shopper’s side

A bike-parts shopper asks, “Will these pads fit my C2 calipers?” A truck owner asks, “Does this rotor fit a 2019 F-150?” A laptop owner asks, “Is this the 15-inch or the 15.4-inch protector?” A phone owner asks, “Do you have this case for the 17 Pro Max?”

Three of the four share a shape: the shopper names a thing they own, and the answer is a link between a product in your catalog and that thing. The fourth is a variant question in disguise and belongs to the variant article. This guide is about the first three, and the one fact that often hides inside them.

You have already done the hard work: somebody decided which pads fit which calipers and wrote it down. The question is where, and whether an assistant can read it from there.

What our checks found

On 4 September 2026 we ran 340 shopper questions across 34 public specialist storefronts on Shopify, ten per store, with one shopper model (OpenAI’s GPT-5.4 mini via the API) using only the store’s native storefront tools and public pages. The stores sell parts, tools, cameras, outdoor gear and 3D-printer components, chosen because compatibility is their hardest question; the sample says nothing about Shopify stores in general. The full dataset is in What AI shoppers get wrong.

Sixty-six of the 340 were compatibility questions, “does A work with B”. The result: 42 fully right (64%), 21 partly right, 3 wrong. That is the second-best question type in the batch, behind only “does this option exist” (81%) and well ahead of comparisons (24%) and filtered searches (28%).

The 24 imperfect answers are the interesting part. Our judge classified 13 as relationship-shaped: the assistant could not establish that A fits B, because the link lives somewhere it could not read. It classified 10 as attribute-shaped: the assistant found both products but missed one fact that changes the answer, a mount standard, a rotor diameter, a thread pitch. One it could not shape.

So on this sample, four in ten compatibility misses were not a missing relationship. They were a missing spec. That matches the batch overall, where 119 of 186 imperfect answers were a single fact about a single product and only 24 were links between two. If you sell parts, the first thing to fix is often not the fitment table but the one number on the part that the table depends on.

We saw the comparison version on 2 September 2026, in a separate check on a public 1,055-product phone and device accessories store (twelve questions; Anthropic’s Claude Opus 5, OpenAI’s GPT-5.6 and GPT-5.5 via their developer APIs; judge pinned to Claude Opus 5). One question asked what separates the 15-inch protector from the 15.4-inch one. With native tools alone it stayed partial in every model: the agents found both products and could not say which laptop each fits, because the difference sits in a theme-rendered metafield. With metafield-backed tools added, Claude Opus 5 resolved 12 of 12 and GPT-5.5 10 of 12, one run each.

Why assistants miss it: the data is in the one place they do not look

The fit relationship is stored in one of three places on almost every specialist store, and the storefront tools an agent calls return none of them.

A metafield on the product. custom.compatible_with, specs.fits_models, fitment.vehicles: the right way to store it, rendered by the theme as a “Compatibility” row or tab. On 5 September 2026 we crawled 41 public storefronts and read every machine surface an agent uses: /products.json, the ten WebMCP storefront tools, /api/mcp and the UCP catalog endpoint. Metafields were absent from all four on 41 of 41 stores. Which product data AI agents can actually read walks through each surface; the short version is that a metafield reaches an agent only if the theme prints it on the page and the agent reads the page.

A table in the description or an image. An HTML fitment chart does travel with the description, so an agent can sometimes find the row, if the description is not boilerplate. On that accessories store, 891 of 1,055 products carried boilerplate descriptions and the real specs were in metafields. A PNG of a chart travels nowhere.

A fitment app’s own database. Year/make/model apps keep the vehicle-to-part table on their servers and render it as a widget. On the 34 stores in our batch, two ran a fitment app and two more had hand-built a year/make/model bar into the theme. In every case the table was invisible to an agent: on 32 of 32 live storefronts we read on 5 September 2026 the tool set was exactly Shopify’s ten, and none of the 30 third-party apps we detected registered a tool of its own.

None of this is a fault in the storefront tools. They read the product record the way the storefront does, and a compatibility metafield is a merchant-defined field with no fixed meaning that a generic tool could safely return. The gap is that fitment is real, verified data stored in the one field family no tool carries.

Ambaum, a Shopify agency, made the same argument on 5 August 2026 in a piece on fitment data as the AEO strategy for auto parts (read 12 September 2026): fitment the recommending models cannot read “may as well not exist”, so structure it in metafields rather than in a year/make/model app alone. We agree on the diagnosis. One caution on the route to the AI channels: Catalog Mapping carries a metafield only by making it the title, description or category, as the next section shows.

The data model: one field, one direction, one name

Here is the model StoreKnows reads, and the one we recommend whether or not you use the app. It is small on purpose.

One field: compatible_with, as a list. Define a product metafield with a list type (single-line text, or product references if the targets are products in the same store), under a namespace you control; custom is fine. One entry per thing the part fits. Not five targets in one comma-separated string: a list lets a tool match one entry without parsing prose.

One direction: the part lists what it fits. Cedar C2 Brake Pads list “Cedar C2 calipers”. The caliper product does not list every pad that fits it. The relationship is stored once, on the side that has the knowledge, and a tool answers “what fits my C2 calipers” by searching every product’s list for that target. Two-directional data doubles the maintenance and drifts; one-directional data cannot disagree with itself.

One name for the target. Every pad that fits the Cedar C2 calipers writes exactly “Cedar C2 calipers”. Not “C2”, not “Cedar C-2”, not “Cedar C2 caliper (2024+)”. If the target is a product in your catalog, use its title; if it is a vehicle, pick one form (“2019 Ford F-150”) and use it everywhere. Matching is forgiving about word order and extra words (“Shimano XT M8100” matches “M8100”) but treats numbers as decisive, so “C2” never matches “C3” and “11-speed” never matches “12-speed”. Consistent naming is what makes that safe.

The example is from our own demo store, not a merchant’s: a development store of 144 seeded bicycle products whose deciding specs live in metafields, where Cedar C2 Brake Pads carry custom.compatible_with = “Cedar C2 calipers” beside custom.material and custom.weight_g. On 5 September 2026 the same 14 questions on that store, with our tools live, went from 7 of 14 to 13 of 14 fully right for Google’s Gemini 3.8 Flash via the API and from 4 of 14 to 8 of 14 for OpenAI’s GPT-5.4 mini via the API, one run each. Runs vary; it is a prepared store, not yours.

And the fact beside the link. Remember the 10 attribute-shaped misses. Put the spec that qualifies the fit on the part too, as its own typed metafield: rotor_diameter_mm, mount_standard, thread_pitch, screen_size_in. “Fits Cedar C2 calipers” answers the link; “160 mm rotor, post mount” answers the follow-up that decides the sale. The 15-inch versus 15.4-inch miss was exactly this: a fact, not a relationship, and one field would have carried it.

Where each version of the fact can be read

Where the compatibility fact lives	Product page	`/products.json` and storefront tools	Shopify Catalog (AI channels)	StoreKnows fit tool
Fitment app database (year/make/model widget)	As a widget, for humans	No	No	No
Theme-rendered `compatible_with` metafield	As page text, if rendered	No	No	Yes
“Fits: Cedar C2 calipers” line in the description	Yes	Yes	Yes	Yes (from the metafield)
Option value (“Fits: 15-inch / 15.4-inch”)	Yes	Yes, as a variant	Yes	Yes
Spec metafield beside the link (`rotor_diameter_mm`)	As page text, if rendered	No	No	Yes

Surfaces as read on 5 and 12 September 2026; the Catalog column follows the help page below.

What Catalog Mapping can and cannot do for fitment

Shopify Catalog is what the AI channels (ChatGPT, Google AI Mode and Gemini, Microsoft Copilot, Meta) receive, and Catalog Mapping chooses where its fields come from. We read the help page on 12 September 2026 (Mapping your product data sources for Shopify Catalog). It lets you set a different source for three fields, product title, product description and product category, and for each you “choose from product attributes, product metafields, or metaobject references”. With custom variant grouping on, you can group by product title, a product metafield or a product tag, and set the option names shoppers see.

That is the whole list. There is no row for compatibility, fitment, specs or attributes. A compatible_with metafield reaches the Catalog in one way only: by becoming part of the description. That is a legitimate, cheap move: generate a first line, “Fits: Cedar C2 calipers, 160 mm rotor, post mount”, from the metafield, and the Catalog, /products.json and every storefront tool carry it. It gives an agent a sentence to find, not a field to query, which is why a comparison across twelve pads still needs the typed list.

How to check your own store

Pick three products whose sale depends on fit, one per category, and note where the compatibility fact is stored: metafield, description text, image, fitment app.
Open /products.json on your storefront and find one of them. If the compatible model is not in body_html, tags or an option value, no storefront tool will return it either.
Ask the question in a fresh session. In an assistant with no history: “Will [part] fit my [target] at [store]?” Record the answer with the date. A confident yes or no that matches your data means the fact travelled; “check the product page” is the gap.
Ask the follow-up. “Which rotor size?” or “Which laptop model exactly?” This is where the attribute-shaped misses show.
Look at your fitment widget and ask whether the same table exists anywhere in the product record. If not, it exists for humans on the page and nobody else.

A manual check tells you what one assistant said on one day, not a rate. A simulated check through the developer APIs shows the tool responses themselves, which is where a fix has to land.

Fitment apps stay. The field is added beside them

Nothing here asks you to remove a year/make/model widget. It does a job the field does not: a shopper picks their vehicle from three dropdowns and sees the parts that fit, without typing. An agent’s tool has no reason to replace that. If you run one you are ahead of most of our batch, because the data exists; the remaining step is to write it into the product record as well.

The practical path is an export: most fitment apps can produce the vehicle-to-part list as a CSV, and a metafield import turns it into one compatible_with list per product. Keep the app as the source of truth for the widget if that is how your team maintains it, and refresh the metafield when the table changes. A shopper on the page and a shopper’s agent then see the same answer.

What StoreKnows’ “does this fit?” tool does

StoreKnows reads your catalog through the app, metafields and referenced metaobjects included, into a saved copy. When it finds a field that looks like compatibility data (a key or name containing “compatible”, “fits with”, “works with”, “fitment”, “mount” or “standard”), it proposes a fix called Answer “does this fit?”, shows which products carry the field and how many of the missed questions it would have covered, and lets you ask it a question of your own before anything is published.

Published, it is one read-only tool registered beside Shopify’s ten through a theme app embed. An agent calls it with the thing the shopper owns, optionally a product type (“brake pads”) and a stock or price limit, and gets back the products whose compatible_with list contains that target: the matched entry as the source, each product’s variants, price and availability, and a flag saying whether the match was exact or family-level (same brand and series, no conflicting number), with a note to check the details before recommending a family match. If nothing matches it says so rather than guessing. It is not an engineering database; it can only say what your data says.

Three limits, stated once. It answers from the saved catalog copy you approved, not live inventory; you refresh it when you choose. It has no cart or checkout access. And it is reachable by agents that call storefront tools, today Chromium-based browsers under Shopify’s origin trial (token expiry 17 November 2026 by our decode of 5 September 2026), and by any agent that reads the page where it is registered.

If your catalog is pads and calipers, rotors and trucks, cases and phones, or protectors and laptops, the free check shows every fit question by assistant, the product data behind each answer, and which misses were a missing link versus a missing number. Fix the number first; it is usually the cheaper one.

Results in this article come from simulated checks run by StoreKnows on 2, 4 and 5 September 2026 against public storefronts and our own development store. Questions were answered by OpenAI’s GPT-5.4 mini, GPT-5.5 and GPT-5.6, Google’s Gemini 3.8 Flash and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. Platform facts were read on the linked Shopify help page on 12 September 2026. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.

Shopify's readiness scanner, free AI checkers and StoreKnows: what each one actually tests

2026-09-12T00:00:00Z

Short answer: Shopify’s readiness scanner and Craftshift’s checker test whether files, schema and endpoints are present. AI Catalog Score grades how complete your catalog fields are. Verity Score asks buyer questions across four models and logs the replies. None of them grade an assistant’s answer to “does this fit”, “which size”, “what is the spec” or “will it work with mine” against your own product record, show the data behind each answer, let you try a fix, and re-run the same questions after publishing. That is what StoreKnows does, and only that. All five have a place; this page says which.

Why five tools give five different answers

“Is my store ready for AI shoppers” sounds like one question. The tools that answer it measure different layers of the same store, and a store can pass one layer and fail the next.

Presence. Does /llms.txt exist, is the Product JSON-LD complete, is guest checkout on, does robots.txt admit GPTBot? Yes/no facts about files and markup.
Completeness. Per product, is the title clear, the category set, the metafields filled? Grades on the data you maintain.
Visibility. When a shopper asks a generic question, which brands get named? What the assistants say, aggregated across many stores.
Accuracy. Asked about one of your products, does an assistant give the right variant, price, stock state, size or spec? A grade on one answer against your own data.

Presence and completeness are necessary. They are not accuracy. In a simulated check we ran on 4 September 2026 across 34 specialist storefronts (340 questions, one shopper model, OpenAI’s GPT-5.4 mini via the API, native storefront tools only), the assistant almost always found the product; 119 of the 186 answers that were not fully right had missed a single fact about it. Every one of those stores served the standard files. The breakdown by question type is in What AI shoppers get wrong about specialist products.

So the useful comparison is not “which tool scores my store highest” but “which layer does each tool test, and which layer is my problem”.

Shopify’s agentic readiness scanner

Shopify’s own page at shopify.com/agentic-readiness (read 12 September 2026) is short. It asks for a product URL and says: “We check your product page for the structured data that AI agents read to answer shoppers’ questions.” It lists no individual checks. The detail comes from two secondary sources that opened the tool and wrote down what it does.

The first is a community thread of 26 April 2026 by Rahul of FoundGPT, who reported that the scanner “runs 31 checks on any public storefront across five categories”: AI discoverability, product schema, transaction readiness, trust signals and operational maturity. It is free, needs no login, and takes about thirty seconds per URL. His caveat: it diagnoses and “does not fix anything”.

The second is Craftshift’s guide of 12 May 2026, which lists the checks per category. Agent discovery: robots.txt, llms.txt, sitemaps, the UCP discovery endpoint. Product schema: whether the JSON-LD carries name, image, description, offers, review, aggregateRating, brand, sku, shippingDetails and itemCondition. Transaction readiness: guest checkout, current pricing and inventory, whether sign-in is required. Trust: policy pages, About, contact, FAQ depth. Operational: shipping clarity, return windows, currency, locale sitemaps. The guide also records what the scanner does not test: catalog breadth (it samples pages), client-side-rendered schema, variant image and count problems, translations, and the competitive signals that decide which product an agent recommends. Its summary line is fair: a perfect 100 “measures technical readiness, not competitive readiness”.

Two things follow. This is a thorough scanner for the presence layer, and since it is Shopify’s own, its checklist is the closest thing to a statement of what Shopify’s channels want to find. And none of the 31 checks asks a question about a product and grades the reply. It confirms the Product schema has an offers block; it does not check that the price in that block is the one for the variant a shopper asked about.

Craftshift’s AI readiness checker

Craftshift, a Shopify Partner, publishes a free checker at craftshift.com/ai-readiness-checker (read 12 September 2026). It takes a store URL, scans the homepage HTML and robots.txt, and returns a score out of 100 with pass/fail per check and suggested fixes. The nine checks: JSON-LD schema, Speakable schema, meta descriptions, and whether robots.txt admits GPTBot, PerplexityBot, ClaudeBot, OAI-SearchBot and ChatGPT-User, plus the presence of llms.txt and llms-full.txt.

Narrower than Shopify’s scanner and quicker to read, it is the tool for finding out whether you have accidentally blocked a crawler, a common problem that no answer-grading tool will diagnose. It does not open product pages and does not test answers. Craftshift’s dated guide to the native llms.txt and agents.md files is worth reading on its own.

AI Catalog Score

AI Catalog Score (aicatalogscore.com, read 12 September 2026) does two distinct things, and it helps to keep them apart.

The catalog audit grades each product on eight dimensions: title clarity, description richness, alt text completeness, JSON-LD structured data, category assignment, metafields completeness, review signals and pricing structure, rolled up to a 0–100 score with a letter grade; the public audit samples roughly 250 products per store. This is the completeness layer at scale, and its emphasis on filled metafields over prose matches what we see in our own data.

The visibility tracking is what earns the company its dataset. Its “State of AI Commerce Q2 2026” report (20 May 2026) draws on 1,047,024 captures across 17,863 brands from six agents (ChatGPT, Claude, Perplexity, Gemini, Mistral and DeepSeek) over 22 days: Gemini produced 37% of captures, Amazon was the most-mentioned merchant at 64,426 mentions, the average audit score among the top 200 brands was 59/100, and position 50 in a category typically gets under a tenth of the mentions position 1 gets. That is original, large and worth citing. It measures which brands get named, not whether what is said about them is right; the report says it runs no controlled experiments.

Pricing, from its homepage on 12 September 2026 (there is no separate pricing page; /pricing returned 404): free up to 50 SKUs; Growth USD 49 a month for 500 SKUs; Pro USD 149 a month for 3,000; Performance USD 399 a month, unlimited, with an alternative of 5% of AI-attributed revenue uplift capped at USD 5,000 a month. Yearly billing is discounted 30%. It advertises a “+10 points within 30 days or full refund” promise on paid plans.

Verity Score

Verity Score (verityscore.io, read 12 September 2026) is the closest of the four to grading answers, so it is worth being precise about where it stops.

Its audit has three layers. The source layer checks what crawlers can read: rendering, schema.org, price visibility, availability, catalog metadata. The simulation layer runs “buyer decision questions” on ChatGPT, Perplexity, Gemini and Claude and keeps each reply “verbatim with its model, timestamp and sources”. The repair layer drafts fixes from existing product content and applies them after approval, reversible for 30 days.

Its published AI Buyer Score, explained in a post of 5 March 2026 (updated 12 April 2026), is a set of criteria a shopping agent needs to see on a product page: clear structured price, credible reviews, documented shipping, returns possible, confirmed availability, identifiable brand, complete specifications, coherent claims and proofs, crawlability. The post lists nine; the homepage now says eight. Either way, these are signal-presence criteria scored per page. The logged replies sit beside them as evidence of visibility, and Verity publishes original benchmarks from them: 237 audits across 102 Shopify stores, a GEO Barometer of 475 French stores, and fifteen vertical benchmarks.

What the published material does not describe is grading a reply to a fit, size, spec or compatibility question against the store’s own record and naming the fact that was wrong. The score is about what the page exposes; the simulations show what models say.

Pricing, from verityscore.io/en/pricing on 12 September 2026: Free at USD 0 (25 products, one ChatGPT purchase simulation, 60-day history); Lite USD 39 a month (100 products, four simulations on ChatGPT and Perplexity); Essential USD 149 a month (350 products, twelve simulations on three engines); Growth USD 449 a month (5,000 products, thirty simulations on all engines, weekly scans); Scale USD 899 a month (10,000 products); Enterprise on quote. Annual billing gives two months free.

Shopify’s Knowledge Base app

The Knowledge Base app (apps.shopify.com/shopify-knowledge-base, read 12 September 2026; by Shopify, free, launched 16 May 2025, 3.6 stars from 29 reviews) is not a scanner, but merchants reach for it when a scanner flags “thin policy content”. It lets you “view and customize the FAQs that AI shopping agents use to answer questions” about your store: shipping, returns, payment and policies generated from your settings, plus FAQs you write, stored as metaobjects, with a count of how often agents request the store’s information.

It is store-level. It holds no per-product spec, size chart or compatibility list, and it tests nothing. For policy questions, fully right only 36% of the time in our September batch, it is the right first step and it is free.

StoreKnows

StoreKnows tests the accuracy layer, on your own store, inside the Shopify admin. The check reads your catalog (products, variants, metafields, metaobjects, size charts), builds up to fourteen shopper questions with a recorded reference answer each (fit, size, spec filter, comparison, compatibility, policy), and has simulated shoppers on OpenAI, Google and Anthropic models ask them through the storefront tools every Liquid store already serves. A separate judge model grades each reply against the reference as fully right, partly right or wrong, and you see the reply, the model, the product data it should have found, and the gap.

Then three things the other tools do not do. You can type your own question into a proposed read-only tool and see the answer and the product fields it used, before anything is published. If you enable, the tools are added beside Shopify’s own through a theme app embed, and StoreKnows visits the storefront daily to confirm they are still available. And the same questions run again after publishing, so the before and after is per question, per model. On a 144-product development store on 5 September 2026 that took Google’s Gemini 3.8 Flash via the API from 7 to 13 of 14 fully right and OpenAI’s GPT-5.4 mini via the API from 4 to 8, one run each; runs vary.

Its limits: it does not check files, schema or robots.txt (run Shopify’s scanner for that); it does not track which brands get named for generic questions (Verity’s and AI Catalog Score’s work); a simulated check through developer APIs does not predict what a consumer assistant says to a real shopper; the published tools use a saved catalog copy, not live inventory, and work with compatible agents on theme-based stores.

Pricing: the check is free, one per store. Enabling is a one-time charge per store through Shopify billing, with no subscription, no usage charges and no per-order fee; the current figure is on our Shopify App Store listing, so this table gives the other tools’ published prices and not ours.

What each tool tests

	Shopify scanner	Craftshift checker	AI Catalog Score	Verity Score	Knowledge Base	StoreKnows
Files and robots.txt (llms.txt, crawler access)	Yes	Yes	No	Partial (crawlability)	No	No
Product JSON-LD completeness	Yes	Partial (homepage only)	Yes	Yes	No	No
Endpoint and checkout readiness (UCP, guest checkout)	Yes	No	No	No	No	No
Per-product field completeness (metafields, category, alt text)	No	No	Yes	Partial	No	No
Brand visibility across models, generic questions	No	No	Yes	Yes	No	No
Model replies logged verbatim	No	No	No	Yes	No	Yes
Answers graded against the store’s own product data	No	No	No	No	No	Yes
Fit, size, spec, compatibility questions on your products	No	No	No	Partial (specs as a presence check)	No	Yes
Product data behind each answer shown	No	No	No	No	No	Yes
Try a fix with your own question before publishing	No	No	No	Partial (fix previews)	No	Yes
Same questions re-run after publishing	No	No	No	No	No	Yes
Store-level policy FAQs editable	No	No	No	No	Yes	No
Runs on any public store without installing	Yes	Yes	Yes	No	No	No
Price	Free	Free	Free to 50 SKUs, then USD 49–399/mo	Free tier, then USD 39–899/mo	Free	Check free, then one-time (see listing)

“Partial” means the tool touches the row without doing what the row says in full; the sections above give the specifics. Prices as read on 12 September 2026.

When the free scanner is enough

Run Shopify’s scanner first, whatever else you do. It is free, it takes thirty seconds, and it is the checklist from the company that runs the channels. It is enough on its own when:

Your products have one or two options and one price each, so the first variant in the schema is the only variant.
The facts a shopper needs are in the description, not in a spec table, a size chart or a metafield.
Your question is “have I blocked a crawler, forgotten llms.txt, or left a schema field empty”, which is exactly what it and Craftshift’s checker find.
Nothing has changed and you want a monthly confirmation that the files are still there.

On a text-rich 150-product coffee store we checked on 2 September 2026, the native tools alone answered 10 of 10 questions for Anthropic’s Claude Opus 5 and 9 of 10 for OpenAI’s GPT-5.6, in a simulated check. A store like that learns little from an answer grader that a file check has not already told it.

When to choose the others

Verity Score when you want to see what four consumer-facing engines say about your products over time, replies kept verbatim and dated, and you sell in a market it benchmarks. Its free plan gives one ChatGPT simulation on 25 products, enough to see whether the format suits you.

AI Catalog Score when you have hundreds or thousands of SKUs and want a consistent completeness grade per product so a team can work through the worst ones, plus a picture of which brands in your category the agents name. The free 50-SKU tier is a real audit.

Knowledge Base when the wrong answers are about shipping, returns or payment rather than products. Write the FAQ there before you buy anything.

Craftshift’s checker when you want a one-minute robots.txt and llms.txt check without a login, or you have just changed a theme and want to confirm nothing blocked a bot.

StoreKnows when the scanner passes and shoppers still get the wrong variant, price, size or compatibility. That is the attribute problem, four of five classifiable gaps in our September batch, and it lives below the layer the file and field tools measure. If you are not sure which layer your problem is on, the fresh-session method in How to check what ChatGPT, Gemini and Copilot say about your store takes twenty minutes and will tell you.

Use them in order

Presence, then completeness, then accuracy. Shopify’s scanner and Craftshift’s checker in the first ten minutes; Knowledge Base for the policy FAQs the scanner flags; AI Catalog Score or Verity Score if your catalog is large or you want the visibility picture; a simulated check that grades answers when the facts that decide a sale sit in variants, charts and specs. StoreKnows runs that check on your own store for free, shows every answer beside the product data behind it, and lets you try a fix with your own question before anything is published.

Results in this article come from simulated checks run by StoreKnows on 2 and 4 September 2026 against public storefronts and on 5 September 2026 against a development store. Questions were answered by OpenAI’s GPT-5.4 mini and GPT-5.6, Google’s Gemini 3.8 Flash and Anthropic’s Claude Opus 5, called through their developer APIs, not the consumer apps, and graded by a separate judge model. Third-party check lists, datasets and prices are as published on the pages named, read on 12 September 2026. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic, Shopify, Craftshift, AI Catalog Score or Verity Score.

Same store, same questions, better answers: what changed when product data became readable

2026-09-12T00:00:00Z

Short answer: on a 144-product development store where the deciding specs live in metafields, making those specs readable through five read-only tools took Google’s Gemini 3.8 Flash from 7 of 14 fully right answers to 13 of 14, and OpenAI’s GPT-5.4 mini from 4 of 14 to 8 of 14, on the same 14 questions. One store, one run each, both models called through their APIs. Here is the setup, the numbers, and what they do and do not show.

Why run the same questions twice?

Our batch of 340 questions across 34 specialist storefronts showed where simulated AI shoppers miss: almost never in finding the product, almost always in reading one fact about it. A spec, a variant price, a stock state, a compatibility note. On Shopify stores that fact usually sits in a metafield, and on 5 September 2026 metafields were invisible from outside on 41 of 41 storefronts we crawled.

A diagnosis is only useful if the fix can be measured. So the question for this article is narrow: if the same store serves the same metafield facts through tools an agent can call, and the same questions are asked again, what changes? Not “does it help in general”. Just: same store, same questions, what moved.

The setup

Store: our own development store, seeded with 144 bicycle products whose deciding specs live only in metafields. This is a synthetic catalog built so that the facts are where specialist stores keep them, which is a strength for isolating the mechanism and a limit for generalising, and we come back to it below.
Questions: 14 shopper questions generated from the store’s own catalog, each with a recorded reference answer. The same 14, word for word, in both runs.
Shoppers: Google’s Gemini 3.8 Flash via the API and OpenAI’s GPT-5.4 mini via the API, each answering through the storefront’s tools in a browser session against the live store. No consumer apps.
Judge: OpenAI’s GPT-5.6 Sol, a separate model, grading each answer against its reference as fully right, partly right or wrong. No model is judged by itself.
Before: only the ten native storefront tools every Liquid storefront has carried since 21 August 2026 (search, browse, product details, cart and checkout, orders, policies).
After: the same ten tools plus five read-only StoreKnows tools served by the theme app embed on the live storefront: answer “does this fit?”, recommend a size, filter by spec, compare products, and check a captured variant’s price and stock. The run loaded nothing itself. The storefront served the tools through the theme, the way a real agent would find them; the store’s verification listed fifteen tools, ten Shopify’s and five ours.
Runs: one before, one after, on 5 September 2026.

The results

Assistant (via the API)	Before: fully right	After: fully right	Wrong before → after
Google’s Gemini 3.8 Flash	7 / 14	13 / 14	2 → 0
OpenAI’s GPT-5.4 mini	4 / 14	8 / 14	2 → 2

The remainder in each cell is partly right: Gemini went from five partial answers to one; the mini model from eight to four.

Two things are worth saying plainly.

The gain is large and uneven. Gemini picked up six questions and lost its two wrong answers. The mini model picked up four and kept two wrong. Same store, same tools, same questions; the difference is how each model uses a tool it is offered. We saw the same spread in a separate check on a 1,055-product accessories store on 2 September, where one model adopted added tools immediately and another kept searching and reading one product at a time (that check is written up here). Tool adoption is model-dependent, which is why the app reports per assistant and not as one score.

Wrong went to zero for one model, and stayed at two for the other. The run log records the counts: two wrong answers from GPT-5.4 mini before, two after. It does not record which questions those were, or whether they were the same two, and we are not going to guess. What we can say is that a readable spec removes the reason for the most common miss we see, an answer that says the information is not available when the store holds it. It does not stop a model from misreading a fact it has been given, or from not asking for it.

What changed, and what did not

The run log records totals per model, not a per-question breakdown, so we will not claim which question types moved. What the setup does tell you is what each tool could and could not do.

The five tools each answer one shape of question from the metafield data: “which pads fit these calipers” from a compatibility field, “which of these weighs 24 g or less” from a weight field, “my head is 56 cm, which size” from a size chart, “what is different between these two” from the fields both products share, “is this variant in stock and what does it cost” from a captured copy of the variant. If the fact is in the field and the model calls the tool, the answer has the fact in it. If the model does not call the tool, nothing has changed for that question: it is still reading the same product card it read before.

Nothing else moved. The catalog was not rewritten. No description was edited, no tag added, no option renamed. The tools are read-only and serve a saved copy of the approved fields; they cannot change a price, a stock level or a product. The difference between the two runs is entirely that the facts in the metafields became callable.

One question, before and after

The clearest way to see the mechanism is a single answer pair. This one comes from the demo catalog in our listing video, not from the 144-product run above: a fictional store of eight published bicycle products on a separate development store, recorded on 9 September 2026 in a simulated check, answered by Anthropic’s Claude Sonnet 5 via OpenRouter. The pads’ product record carries a compatibility metafield, “Compatible with: Cedar C2 calipers”, and the catalog has no separate calipers product.

The question: Is Cedar C2 calipers listed as compatible with Cedar C2 Brake Pads? The recorded reference: “Yes. Cedar C2 calipers is listed as compatible with Cedar C2 Brake Pads.”

Before, with native tools only, the assistant found the product and reported, in part: “So I could not determine whether Cedar C2 Calipers are listed as compatible with Cedar C2 Brake Pads — because there is no ‘Cedar C2 Calipers’ product in the catalog, and the brake pad listing contains no compatibility/fitment information to check against.” Graded not answered correctly, with the judge’s note: “The captured product record declares Cedar C2 Brake Pads compatible with Cedar C2 calipers.”

After, with the “does this fit?” tool published: “Yes — the Cedar C2 Brake Pads (handle: cedar-c2-brake-pads) are listed in the catalog with ‘Compatible with: Cedar C2 calipers.’ So the merchant’s own data confirms compatibility between the Cedar C2 Brake Pads and Cedar C2 calipers.” Graded answered correctly. The assistant also noted that it “could not find a separate product listing for ‘Cedar C2 Calipers’” and that the compatibility “is only documented from the brake pads’ side”, which is exactly right: the link is one-directional in the data, and the tool said so rather than inventing the other direction.

The first answer is not a hallucination. It is an accurate description of what the native tools returned: a product card with no compatibility field on it. The store knew; the tools the assistant had did not carry it. That is the whole before-and-after in one exchange. Two caveats travel with it: it is listed compatibility, not a physical-fit certification, and it is one graded answer on a demo catalog, not a result we count.

The limits, stated once

One prepared store. The 144-product catalog was seeded so that its deciding facts live in metafields. That is how many specialist stores are built, and it is also the case the tools are designed for. A store whose specs already sit in titles and descriptions would show a smaller gap and a smaller gain; on a text-rich 150-product coffee store on 2 September, native tools alone answered 10 of 10 for one model.
One run each. Runs vary. A second before-run would not score exactly 7 and 4, and a second after-run would not score exactly 13 and 8. The direction is what the numbers support; the exact figures are one draw.
Fourteen questions. Enough to see a mechanism, not enough to quote a percentage with confidence. We give the counts, not the percentages, for that reason.
APIs, not consumer apps. Both models were called through developer APIs in a browser session against the storefront’s tools. What ChatGPT, Gemini or any consumer assistant says to a real shopper adds retrieval, caching and product knowledge of its own on top, and we make no claim about that.
No Claude before-and-after on this store yet. Anthropic’s Claude Sonnet 5 via OpenRouter has been part of every check since 8 September 2026, so new checks report three assistants. The 5 September run predates it, and we have not yet published a Claude before-and-after on the 144-product store. The single Cedar pair above is one question on a demo catalog, not a scored run.
Saved data, not live inventory. The tools answer from a copy of the approved fields, frozen at publication. Price and stock, where a tool returns them, are captured values; the storefront and checkout remain the source of truth, and the tools say so.

How the same loop runs on a real store

The measurement above is the loop StoreKnows runs on any Liquid storefront, with you deciding at each step.

Check. StoreKnows reads your catalog (products, variants, metafields, metaobjects, size charts) and builds up to 14 shopper questions with a recorded reference each. Simulated shoppers on Gemini, GPT and Claude models answer them through your storefront’s native tools. Free, one per store, in a simulated check.
Read the answers. Each answer is shown with the assistant that gave it, its grade, the reference, and the product data it should have found. Where a miss is a fact the store holds, the app says which field.
Try the fix with your own question. Where your data supports it, StoreKnows proposes a read-only tool and lets you ask it anything in a preview that uses saved product data. Ask a question you already know the answer to. See the answer and the rows it came from. Nothing is published by trying.
Publish what you approve. Enabling is a one-time charge per store, with no subscription. You see exactly which products, fields and charts become public, inspect the values, and approve. Your previous published version stays in place until you approve a replacement, and a catalog refresh or a change of selection asks for approval again.
Switch on the theme app embed. One click in the theme editor adds the tools beside Shopify’s own. Switching it off removes them.
Storefront verification. StoreKnows visits your storefront, confirms the published tools are served and match the approved version, and keeps checking daily. This proves the tools are available; it does not test answers.
The same questions again. A successful verification starts the comparison: the same 14 questions, the same assistants, side by side with the baseline, so you see per question and per assistant what changed, what stayed the same, and anything that got worse. Enable includes that first after-check and two more you can start yourself, for instance after refreshing your catalog.

That is the whole product: a check you can read, a fix you can try with a question you know, a publication you approve field by field, and the same questions asked again so the claim is yours to verify rather than ours to make.

If your catalog keeps its deciding facts in metafields, run the free check and read what the assistants say today. Then try one fix with a question you already know the answer to, and decide for yourself whether the after is worth publishing.

Results in this article come from a simulated check run by StoreKnows on 5 September 2026 against our own 144-product development store, and one answer pair from a fictional eight-product demo catalog on a separate development store on 9 September 2026. Questions were answered by Google’s Gemini 3.8 Flash and OpenAI’s GPT-5.4 mini, called through their developer APIs, and by Anthropic’s Claude Sonnet 5 via OpenRouter, not the consumer apps, and graded by a separate judge model. StoreKnows is independently developed and not affiliated with, endorsed by or sponsored by OpenAI, Google, Anthropic or Shopify.