Product Schema
Structured data describing a product's name, price, availability, and attributes.
Product schema should mirror facts shoppers can verify, not create a second catalog. If markup and the page disagree, fix the data or omit the property.
Use one markup owner, exact mappings, stable identifiers, and validation of initial and rendered HTML. Valid code creates eligibility, not guaranteed rich results, rankings, citations, recommendations, visits, or sales.
What is Product schema?
Product schema is machine-readable Schema.org markup that identifies a real product and describes supported facts already available to shoppers. In Shopify, it commonly connects product identity with one or more offers. The markup can support platform understanding and eligibility, but it cannot force a rich result, ranking, citation, recommendation, visit, or sale.
Schema.org Product defines vocabulary; Google’s product structured data documentation defines supported experiences. A property can exist in Schema.org without being required or used by Google.
The structured data definition adds context. Markup does not replace visible specifications, policies, inventory, checkout, or claim evidence.
How do Product, Offer, ratings, and Organization differ?
Use Product for the item, Offer for a purchasable price-and-availability proposition, and Organization for the business entity. Review describes an individual review; AggregateRating summarizes eligible rating data. Variants represent selectable product differences, while merchant listings are Google experiences—not a separate Schema.org replacement for accurate Product and Offer data.
| Type | Role | Boundary |
|---|---|---|
| Product | Item identity | Not seller or price |
| Offer | Purchase proposition | Current facts only |
| Variant | Selectable difference | Exact attributes and offer |
| Review | One attributable review | Never invent |
| AggregateRating | Rating summary | Supported real data |
| Organization | Brand, seller, publisher | No fictional Person |
| Merchant listing | Google experience | Platform-controlled eligibility |
Follow Google’s Organization markup guidance. Brand, seller, publisher, product, offer, and review remain distinct even when linked.
Which Shopify values should map to Product schema?
Map only current values that the selected product or variant actually exposes. Identity, SKU, GTIN, brand, image, URL, variant attributes, price, currency, availability, seller, condition, shipping, and returns must remain internally consistent. Omit unknown values; never manufacture identifiers, reviews, ratings, stock, prices, people, or claims.
| Store facts | Schema destination | Rule |
|---|---|---|
Title, URL, @id | Product identity | Visible and stable |
| Images, brand | image, brand | Actual and accessible |
| SKU, GTIN | sku, gtin | Assigned identifiers only |
| Variant options | Variant properties | Exact selected values |
| Price, currency | Offer properties | Current visible offer |
| Stock, seller, condition | Offer properties | Current proposition |
| Shipping, returns | Policy properties | Maintained support only |
Omit unknowns. A missing GTIN or rating is safer than false precision; never default stock, price, reviewer, or claims.
How should variants and offers be modeled?
Model variants according to what shoppers can select and what the page consistently identifies. Each variant needs a stable relationship to its product group and an offer that reflects its current purchasable state. Do not collapse conflicting variant prices or availability into one misleading value merely to make validation pass.
Follow Google’s product variant guidance. Each Offer must match the selected variant’s price, currency, availability, seller, and condition; never copy a default across differing options.
Test canonical and rendered selection together. The graph must not claim one variant while the page displays another.
Who should own Product markup in Shopify?
Assign one implementation owner across the Shopify theme, apps, tag manager, and custom scripts. Multiple producers can emit duplicate or conflicting Product graphs after rendering, even when the initial HTML appears clean. Keep a stable @id, document the source, and inspect both server output and the browser-rendered document after changes.
Inventory emitters, choose a theme, app, or custom owner, and disable overlap through supported settings. Apps may inject markup after rendering, so do not delete unfamiliar snippets blindly.
Shopify’s json filter safely serializes values. Hand-built quoting can break JSON; stable @id references should identify the same entity across page states.
What is a safe Product schema implementation workflow?
A safe implementation starts with page truth, maps it to the correct vocabulary, serializes it without hand-built escaping, and verifies the final rendered graph. Add only properties the store can maintain. Launch one template or product type first, observe output, then expand after duplicate and variant checks pass.
- Inventory theme, app, extension, and script emitters.
- Choose one owner and record how to disable it safely.
- Map visible Shopify fields to Product, Offer, and related entities.
- Create stable
@idvalues and omit unknown properties. - Generate JSON-LD with safe serialization and no manual escaping.
- Test initial HTML, rendered HTML, variants, inventory, and currencies.
- Pilot a small product set before expanding templates.
Use the StoreCited guide to adding Product schema in Shopify for implementation detail. The Product schema generator can draft markup, but generated output still requires store-specific mapping, ownership, and validation.
How should Product schema be validated and monitored?
Validate Product schema at three levels: JSON-LD syntax, Schema.org vocabulary, and correspondence with visible page truth. A clean parser result cannot prove accurate commerce facts or Google eligibility. Test initial and rendered HTML, review warnings in context, and monitor Search Console after deployment for changing errors and impressions.
Use this validation checklist:
- JSON parses and the graph uses intended
@idreferences. - Product and Offer properties use the correct vocabulary.
- Visible identity, variant, price, currency, and stock match.
- No duplicate app, theme, or rendered graph conflicts.
- Reviews, ratings, shipping, and returns have real support.
- Search Console changes are reviewed after deployment.
The Schema.org validator checks vocabulary, and JSON-LD 1.1 defines the syntax model. Google’s structured data introduction and content policies add platform requirements. The StoreCited schema checker inspects public output, not private configuration.
Monitor Search Console enhancement reports and impressions after release, but avoid attributing every change to markup. Eligibility, presentation, ranking, clicks, and conversions are separate stages with other influences.
What can StoreCited truthfully check?
StoreCited checks observable Product markup and related public storefront conditions at one point in time. It cannot edit Shopify, inspect private app configuration, identify which app owns hidden output, monitor live citations, access proprietary indexes, or guarantee rich results, rankings, recommendations, traffic, or revenue. Findings describe tested public output only.
The scan can flag missing or conflicting public fields, markup mismatches, observable duplicates, and validation issues in the response it receives. It cannot prove a private app setting, historical rendering, Google eligibility, or what a crawler, model, or shopping surface will select later.
Run the free StoreCited readiness scan to inspect public storefront output. Confirm ownership inside Shopify, test important variants yourself, and use platform reporting for downstream outcomes.