Shopify product data
an agent can act on.

There are two jobs a machine can do with a product page. It can describe the product — summarise the copy, name the category, repeat a claim. Or it can act on it: tell a shopper the exact price in their currency, say whether the 14-inch is in stock, match this item to the same item sold elsewhere, hand a cart to a checkout. Description tolerates gaps. Action does not: each of those steps needs a specific field, and a field that is missing or ambiguous stops it.

The feed specifications that AI shopping surfaces publish make the fields explicit, and they converge. OpenAI’s product feed specification requires id, title, description, link, image_link, availability, price, brand, and a gtin or an mpn. Google Merchant Center’s product data specification requires id, title, description, link, image_link, price with an ISO 4217 currency, and availability; it calls gtin “Strongly Recommended”, requires brand for new products other than media, and requires mpn where there is no GTIN. Different documents, one skeleton: identity, price, availability, the variant, the brand.

Rank Sniper measures the same skeleton from the storefront side. Its AIO pillar carries a named transactability sub-score made of exactly these checks — the fields that decide whether an agent can complete a purchase rather than merely understand the listing:

SKU — your identifier

Shopify defines the SKU as “a case-sensitive identifier for the product variant in the shop”. It is optional, and becomes required only when you connect a fulfillment service. That optionality is why so many catalogues have gaps: nothing forces a SKU onto a variant created by hand or by an import. For an agent, the SKU is the stable handle on one specific variant inside your store — the thing a cart line or a support ticket refers to.

The scan’s SKU coverage check is strict on purpose: a product passes only when every variant has one. A product with twelve sizes and eleven SKUs fails, because the twelfth size is exactly the one nobody can refer to.

Barcode — a field, not a guarantee

The variant’s barcode field holds, in the Admin API’s words, “the value of the barcode associated with the product”. Shopify’s Help Center lists the barcode types it accepts: custom barcodes, GTINs of 8, 12, 13 or 14 digits, UPC, EAN, ISBN and ASIN. So a barcode is not automatically a GTIN. An internal code in that field is a good warehouse label and a false global identifier.

GTIN — the product in the world

A GTIN is what lets a system match your listing to the same product sold elsewhere. Merchant Center’s specification calls it strongly recommended rather than required and says to omit it if you are unsure, with brand plus mpn required where no GTIN exists. OpenAI’s feed specification accepts either a gtin or an mpn. Neither asks you to invent one, and nobody should: for handmade, made-to-order or private-label goods with no GTIN, the honest record is brand plus a manufacturer part number, not a fabricated barcode.

Rank Sniper’s public scan detects gtin and mpn in product JSON-LD but does not score them in rubric v1.0, and the variant barcode itself is not visible to a public scan. Reading identifiers per variant needs the Admin API — the connected scan, which is Planned.

Handle — identity for URLs only

The handle is “a unique, human-readable string of the product's title”, made of letters, hyphens and numbers — unique in your store and stable in your URLs, meaningless outside it. Keep it readable; do not mistake it for a product identifier.

Shopify allows up to three options per product and, since 2025-10-15, up to 2,048 variants per product. Options are the axes — size, colour, material — and variants are the combinations. Everything an agent needs to transact lives on the variant: its price, SKU, barcode, weight and inventory. When markup or a feed states those facts once for the product, it is not summarising; it is picking one variant and presenting it as all of them. Merchant Center requires item_group_id to tie variants together in some regions, which is the feed-side form of the same rule.

Option names

An option’s name is the only thing that tells a machine what the variants differ by. The rubric puts it in one line:

Default Title tells an agent nothing about size, colour or configuration.Rubric v1.0 — Real variant options

The check passes a product whose options include a real name, and any product with a single variant — one variant has nothing to distinguish. It fails a product with several variants hung off an option still named Title, which leaves an agent unable to say what the choices are. Renaming it is a one-field change per product in the admin; the variants keep their values.

Where variants meet structured data

The same structure belongs in the markup: a ProductGroup with an Offer per variant. The structured-data guide has the Liquid, and our journal’s variant-collapse audit shows the failure from the machine’s side.

Vendor consistency is identity too

Three spellings of one brand — Northfield, Northfield Linen, NORTHFIELD LINEN CO. — are three brands to a parser. The scan’s entity-consistency check compares each product’s vendor, trimmed and lower-cased, against the catalogue’s most common vendors, and fails the outliers. Normalising the field is tedious and worth it: the vendor is what a feed sends as brand, and what a model has to attribute a claim to.

Type and tags that say something

A blank product type leaves a product outside every comparison set built on your own categories. Tags carry what the type cannot: gift, machine-washable, queen. The rubric’s test is three or more per product, and its reason is short: Three or more per product. How use-case and occasion queries find you. Collections are not scored, but each has its own URL in your sitemap, which makes them the natural entries for a catalogue list in an llms.txt.

Most Shopify catalogues keep attributes in the description, as prose. That is readable, and Rank Sniper’s attribute checks read it there: the Structured attributes check passes a description containing a measurement with a unit, a list, or the words dimension, material or composition. It is also fragile — the same width typed into the description, a size chart and an app’s specification tab will eventually disagree.

Shopify’s own answer for structured facts is custom data. Metafields are, in Shopify’s words, “key-value pairs” that “add custom data to any Shopify resource”, each defined by a namespace and key, a value and a type. Metaobjects go further: “an instance of structured data with multiple related field values”, shaped by a definition that sets out its fields and rules — a material or a care instruction shared by many products.

The durable pattern is to keep each fact once, in a typed metafield, and render it everywhere from there: the specification table, the description’s key facts, the product markup. A sketch of the table:

{%- assign spec = product.metafields.specs -%}
{%- if spec.material != blank or spec.width_cm != blank -%}
<table>
  <caption>Specifications</caption>
  {%- if spec.material != blank %}
  <tr><th scope="row">Material</th><td>{{ spec.material.value }}</td></tr>
  {%- endif %}
  {%- if spec.width_cm != blank %}
  <tr><th scope="row">Width</th><td>{{ spec.width_cm.value }} cm</td></tr>
  {%- endif %}
</table>
{%- endif -%}

Facts only you hold

Rank Sniper does not invent attributes. In the fix design, the structured attributes check is automatic only because it republishes what you already wrote: material, dimensions and composition extracted from your own copy. A measurement that is not in your copy is asked of you, never guessed. That design is Planned; today the scan names the products that fail and stops there. The reasoning is in our journal’s case against generated product facts.

Read the middle column as the honest division of labour. A SKU, a shipping weight and product photography are facts only you hold, and no tool should fill them in for you. A product type or a set of tags can often be derived from the catalogue itself. Where Rank Sniper would draft something, you approve it before it is written: Planned assisted batch rewrites, applied on merchant approval. See the full tables on the AIO pillar, the GEO pillar and the methodology page, and — for how this data meets AI shopping programmes — the agentic-commerce guide.