Product schema on Shopify: what the theme gives you and what it hides

What the theme emits

Open view-source on a Dawn-based product page and you will find a Product JSON-LD block with the basics: name, image, description, SKU, brand from the vendor field, and an offers object carrying price, currency, availability and URL. That is genuinely useful: it is enough for a basic product snippet. What the theme does not reliably emit is everything Google added to the merchant-listing requirements afterwards: GTIN from the barcode field, aggregateRating and review data, hasMerchantReturnPolicy, shippingDetails, and proper variant structure. So the theme is both done and unfinished, depending on which surface you care about.

Snippets versus merchant listings

Google uses product markup on two distinct surfaces. Product snippets enrich ordinary search results with price, availability and ratings: the theme output is usually enough here. Merchant listings power Shopping surfaces and carousels, and they demand agreement between the page markup and the Merchant Center feed, plus the return and shipping fields. A store can have perfect snippets and still be thin on merchant listings. Know which surface you are fixing before touching code.

The five missing-field warnings, explained

• shippingDetails. The delivery cost and time Google shows beside the price. Easiest fix is not in the theme at all: set shipping in Merchant Center once and Google uses it everywhere.
• hasMerchantReturnPolicy. Same story: set the return policy in Merchant Center and the warning is covered account-wide. Page-level markup only matters for per-product exceptions.
• aggregateRating. Only valid with genuine independent reviews on the page. Self-serving review markup does not earn stars and can draw penalties. Never fabricate it.
• review. For editorial or critic reviews, not customer ratings on your own products. Most stores should simply not have it.
• priceValidUntil. Worth setting on genuine sale prices; Shopify has no native field for it, so it needs custom markup or an app.

For implementation detail, see the shipping and returns markup guide and a worked Product JSON-LD example. The pattern: set account-level truth in Merchant Center first, reserve page surgery for genuine per-product exceptions, and never invent values. Markup that misstates policy or ratings is a data-quality violation, not an optimization.

Variants and ProductGroup

A product sold in five sizes is not one product to Google, or rather, it should not be. The correct structure is a ProductGroup with each variant nested under hasVariant carrying its own offer, price and availability. Many themes emit a single flat Product for the default variant instead, which under-represents the catalogue and confuses naive validators into reporting markup as missing when it is merely nested. Any checker worth trusting parses ProductGroup and hasVariant; anything else cries wolf on modern themes.

How to validate like a crawler

1. Use view-source, not the inspector. The inspector shows the page after scripts run; crawlers read raw HTML. Markup injected client-side is invisible to them.
2. Search the source for application/ld+json and confirm a Product block exists server-side.
3. Run the URL through the Rich Results Test and clear errors first, warnings second.
4. Confirm the feed agrees with the page on price, currency and availability. Markup can be valid and still mismatch.
5. Re-validate after every theme update. Schema snippets are among the first casualties of template changes.

Questions

Keep reading