How to Add Product Schema to Shopify Without Lying to Google

How should Shopify fields map to Product and Offer?

Map every JSON-LD property to a verified Shopify source and visible page fact. Product fields describe the item; Offer fields describe the purchasable transaction. The offer URL, selected variant, price, ISO priceCurrency, availability URL, seller, identifiers, and variant name must refer to the same state. Never mix default-product facts with a selected-variant offer.

Use Shopify’s product object and variant object as inputs, then compare outputs with Schema.org Product and Offer.

How should variants and market URLs be represented?

Variant modeling has no universal Shopify pattern. A ProductGroup with hasVariant can represent a family when product-group relationships, shared identity, and variant URLs are implemented correctly; a selected-variant Product and Offer can be appropriate when the page exposes one purchasable state. Markets, currencies, localized URLs, and theme behavior determine which model stays truthful.

Schema.org ProductGroup documents hasVariant, while Product and Offer define item and transaction entities.

Variant checklist:

• Decide between a family graph and selected-variant offer.
• Preserve the variant-specific URL and identity.
• Map market price, currency, and localized URL together.
• Map available state to the full InStock or OutOfStock URL.
• Output verified SKU or GTIN values, or omit them.
• Test in-stock, sale, out-of-stock, and multi-variant states.

What Liquid and JSON-LD pattern is safe to adapt?

Use Liquid’s json filter for strings and Liquid-derived values that must become valid JSON; manual quoting can break on apostrophes, quotes, or Unicode. Map availability deliberately to full Schema.org URLs and output an ISO currency code. The pattern below is illustrative: adapt it to existing markup ownership, selected-variant logic, markets, and visible storefront facts.

Shopify documents the Liquid json filter, product, and variant objects; theme-specific market mapping still needs verification.

{% assign v = product.selected_or_first_available_variant %}
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": {{ product.title | json }},
  "url": {{ selected_variant_url | json }},
  "offers": {
    "@type": "Offer",
    "url": {{ selected_variant_url | json }},
    "price": {{ selected_variant_price_decimal | json }},
    "priceCurrency": {{ market_currency_iso | json }},
    "availability": "https://schema.org/{% if v.available %}InStock{% else %}OutOfStock{% endif %}",
    "seller": {
      "@type": "Organization",
      "name": {{ shop.name | json }}
    }
  }
}
</script>

Define the custom variables from audited, market-aware data. Modify the existing graph owner instead of appending this illustrative pattern.

How should reviews, ratings, shipping, and returns be handled?

Add Review or AggregateRating only when real, eligible evidence is visible on the page and meets the applicable policies. Never synthesize ratings, counts, testimonials, Person credentials, GTINs, SKUs, shipping terms, or returns. If an app owns review markup, reconcile its Product identity and variant scope with the primary graph instead of copying values into a second block.

Google’s structured data policies, review guidance, product snippets, and merchant listings define feature requirements; Schema.org AggregateRating defines vocabulary. Shipping and returns must reflect real visible policies.

How should markup be validated and monitored?

Validate representative storefront states, not one convenient product. Test in-stock, sale, out-of-stock, multi-variant, and market or localized URLs with Google’s Rich Results Test, then inspect rendered source and compare every extracted value with the page. Passing validation establishes technical eligibility for supported features; it does not guarantee display, ranking, citation, traffic, or sales.

1. Inspect initial and rendered source; list every graph owner.
2. Test representative URLs in the Rich Results Test.
3. Resolve errors and warnings; compare extracted values with visible facts.
4. Deploy a controlled change, then recrawl every affected template.
5. Monitor Search Console merchant listings and product reports.

Revisit Google’s product snippet and merchant listing guidance when fields or eligibility change. A clean test on one URL does not validate every variant, market, theme template, or app-controlled response.

Where does StoreCited fit?

StoreCited can flag observable schema and storefront-readiness issues in a point-in-time public scan. It does not generate guaranteed publish-ready schema, edit Shopify themes, choose a universal variant model, monitor live citations, access proprietary indexes, or guarantee results. Use its findings to inspect the markup owner and representative templates, then validate changes with official tools.

Use the product schema generator as a starting aid, the schema checker for observable issues, and the product-page guide for visible content alignment. StoreCited remains the Organization entity. Run the free StoreCited readiness scan before assigning fixes.