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

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

1. 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.
2. 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.
3. 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.
4. Ask the follow-up. “Which rotor size?” or “Which laptop model exactly?” This is where the attribute-shaped misses show.
5. 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.