Shopify product
structured data, end to end.

On a Shopify product page the markup is a JSON-LD block — a script element of type application/ld+json — holding a Product node in schema.org vocabulary, usually with an Offer inside it. None of the facts in it are new. The title, the variant prices, the SKUs, the barcodes and the stock state already live in your Shopify admin; the markup is a translation of them into a form that does not depend on how your theme lays the page out.

That framing explains most of what goes wrong. Structured data is rarely wrong about the product; it is wrong about the translation. A template that writes InStock as a literal string, an Offer that only ever describes the first variant, a price with no currency, two apps each writing their own Product node — every one of those is a faithful copy of the wrong thing.

What it does not do

Google is explicit that none of this is a ticket into its generative AI features:

“Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add.”Google Search Central — Optimizing your website for generative AI features on Google Search

The same guidance says structured data stays useful for rich-result eligibility, and Google’s AI features page makes the point from the other side: there is “no special schema.org structured data that you need to add” to appear in AI Overviews or AI Mode. So the case for getting Product markup right is not a promised placement. It is that JSON-LD is the one place on the page where price, currency and availability are stated as fields rather than as styled text. That is what Rank Sniper measures — whether a machine can read the record without guessing, its machine readability — not whether any engine rewards it.

Written by the theme

If your theme writes product JSON-LD, it does so in its Liquid templates, so the block is part of the HTML the storefront returns for the product URL. That is the most robust place for it: every reader that fetches the page gets the same bytes, whether or not it runs scripts. It is also where markup goes stale, because a template is a snapshot of what its author thought the specification asked for on the day it shipped — the story our journal’s theme audit tells in detail.

Added by an app

An app can add product markup in two ways that look identical in a browser. It can render it into the page’s HTML — for example through an app block the theme outputs with the rest of the template — or it can run a script that inserts a JSON-LD block after the page has loaded. The first is in the response; the second exists only in the rendered page. Your browser’s inspector shows the rendered page, after every script has run. View-source shows the response. Only the response reaches a reader that does not execute JavaScript, and Rank Sniper’s scanner is such a reader: it fetches raw HTML and runs no scripts.

Both

The common failure on a mature store is not missing markup but doubled markup: the theme’s Product node and an app’s Product node on the same page. They rarely agree. One formats the price as 25.0, the other as 25.00; one hard-codes availability, the other reads inventory; one describes the first variant, the other the selected one. A parser that finds two records for one product has no rule for choosing between them. This is the case the scan’s schema-conflict check exists for.

To see which sources your page carries, list every @type in the raw response:

curl -s https://yourstore.example/products/your-handle \
  | grep -o '"@type": *"[A-Za-z]*"' \
  | sort | uniq -c

Two Product lines and no ProductGroup on a single product usually means two sources. A ProductGroup with several nested Product lines is the variant pattern described below, and is expected. No output at all, while an app reports structured data as installed, means the markup is injected by script and is absent from the response. Declared versus delivered covers that gap on its own.

A validator’s green result does not settle provenance. It tells you the markup is valid, not where it came from. Google’s Rich Results Test runs as Google-InspectionTool, which Google lists among its crawlers with “no effect on Google Search” — useful for syntax, silent about which source wrote the block. Check the raw response as well.

Note what is not in the required set: availability is recommended, not required, for a merchant listing. Rank Sniper scores it anyway, for a reason that has nothing to do with Google’s eligibility rules — a record that states a price but not whether the item can be bought is one an agent cannot act on — and says so, rather than presenting it as a Google requirement. Ratings are the opposite case: recommended on a ProductGroup, and worth marking up only where real reviews render on the page. A rating the page does not show is a claim nobody can check.

Shopify’s model maps onto the vocabulary almost one to one. A product can carry up to three options and — since the change Shopify announced on 2025-10-15 — up to 2,048 variants, where the limit used to be 100. Each variant has its own price, its own SKU (which Shopify defines as “a case-sensitive identifier for the product variant in the shop”), its own barcode and its own inventory. The product is the ProductGroup; each variant is a Product node nested under hasVariant, with its own Offer. A single Offer on the product node, describing whichever variant loads first, turns every other variant into a question the markup cannot answer.

The sketch below is Liquid for a product template. It is written for a product whose first option is size; map each option to the schema.org property that actually describes it, and leave out any dimension you cannot map rather than guessing one.

{%- comment -%} Assumes option1 is size. Map each option to its own property. {%- endcomment -%}
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": {{ product.title | json }},
  "description": {{ product.description | strip_html | strip | json }},
  "url": {{ request.origin | append: product.url | json }},
  "brand": { "@type": "Brand", "name": {{ product.vendor | json }} },
  "productGroupID": {{ product.id | append: '' | json }},
  "variesBy": ["https://schema.org/size"],
  "hasVariant": [
    {%- for variant in product.variants %}
    {
      "@type": "Product",
      "name": {{ product.title | append: ' - ' | append: variant.title | json }},
      "sku": {{ variant.sku | json }},
      "size": {{ variant.option1 | json }},
      "image": {{ variant.image | default: product.featured_image | image_url: width: 1200 | prepend: 'https:' | json }},
      "offers": {
        "@type": "Offer",
        "url": {{ request.origin | append: variant.url | json }},
        "price": {{ variant.price | divided_by: 100.0 | json }},
        "priceCurrency": {{ cart.currency.iso_code | json }},
        "availability": "https://schema.org/{% if variant.available %}InStock{% else %}OutOfStock{% endif %}"
      }
    }{% unless forloop.last %},{% endunless %}
    {%- endfor %}
  ]
}
</script>

• Currency. cart.currency.iso_code writes the ISO 4217 code of the currency the cart is in. Check it matches the currency the page displays; a price with no currency fails the Offer’s required set.
• Availability. Bound to variant.available, never typed. A literal InStock stays true after the variant sells out.
• Identifiers. Add gtin from variant.barcode only for variants whose barcode is a real GTIN; Shopify’s barcode field also accepts custom values. The product-data guide covers identity in full.
• Formatting. Write each price one way, everywhere. The scan compares price values as written, so 25.0 in one block and 25.00 in another are two prices.
• Images. A product with no media at all needs a guard around the image line; the sketch assumes at least one image.

1. Inventory the sources. Run the @type listing on a single-variant product, a multi-variant product and a sold-out product. Switch an app’s structured-data option off on a copy of your theme to see which block is its.
2. Choose one owner. One Product or ProductGroup per page, written by one source. Remove or disable the other; two partial records are worse than one complete one.
3. Bind every value to data. Price and currency from the variant and the cart, availability from variant.available, identifiers from the variant. No literals.
4. Group the variants. Move from one Offer to a ProductGroup with an Offer per variant.
5. Add shipping and returns from your real policies. shippingDetails and hasMerchantReturnPolicy should describe what your store actually does; a policy the markup invents is a promise made to a customer.
6. Re-read the raw response, then re-scan. The response is the only version a non-rendering reader gets. The free scan reads it the same way.

How these checks sit among the rest: the AIO pillar, the SEO pillar and every weight on the methodology page. For markup that targets features Google has retired, see our journal’s graveyard tour.