Shopify structured data: Product, Article and FAQ limits

On Shopify, structured-data work begins with inspection, not installation. Current supported themes already include structured data, and apps or custom snippets can add a second version. Your goal is one coherent description of the visible page: the same product, price, availability, variant, author, dates and images a shopper sees. Validation can confirm syntax and eligibility; it cannot promise a rich result, ranking or AI citation.

Download the structured-data audit CSV and the Product, Article and FAQ review checklist. The worked examples are fictional and are not copied from or tested on a live merchant theme.

For products with different sizes, colors, prices or stock, use the variant-level data audit to reconcile the selected page, matching offer and feed record.

Inspect the published page before changing it

Shopify says current Shopify-supported themes and themes from the Theme Store include structured data by default, including product information such as price, availability and reviews where applicable (Shopify Help Center, sitemap and search display, read 10 September 2026). A heavily customized or older theme can differ, and an app can inject additional markup.

Choose representative public URLs:

• one simple product;
• one product with variants;
• one unavailable product or variant;
• one article with a named human author;
• one article updated after publication;
• one page with visible questions and answers, if you use that format.

View source and search for application/ld+json, schema.org, Product, ProductGroup, Article, BlogPosting and FAQPage. Also run the live URL through Google's Rich Results Test. Record every emitter you can identify: theme, app, tag manager or custom snippet. Do not delete a block until you know which layer owns it and what other pages depend on that layer.

The risk is not “having too much schema” in the abstract. The risk is contradictory facts. Two Product objects that disagree about price or availability leave both crawlers and auditors with an avoidable ambiguity.

Product markup belongs on a purchasable product page

Google distinguishes product snippets from merchant listings. A Shopify product detail page where the merchant sells the item is normally the merchant-listing case. Google says merchant listing eligibility applies to pages where a shopper can purchase the product, and recommends product markup on pages focused on one product or variants of that same product rather than a category list (Google Search Central, merchant listings, read 10 September 2026).

At minimum, audit the properties required for the Google experience you target, then add recommended properties only when they apply. Common checks include:

Property area	What to compare with the page
Identity	Product name, preferred URL, brand and stable identifiers
Offer	Current price, currency, availability, offer URL and seller context
Images	Representative, crawlable product images rather than logos
Variants	Selected colour, size, material or other variation and its identifier
Reviews	Ratings and review counts visibly supported by the page
Policies	Shipping and return information consistent with current policy

Do not manufacture a SKU, GTIN, rating, review count, price-valid-until date or return promise to silence a validator warning. Google separates required properties, which determine eligibility, from recommended properties that can enrich a result. An inapplicable recommended field can remain absent.

Product structured data and a Merchant Center feed can be used together. Google says providing both maximizes eligibility and helps it understand and verify product data (Google Search Central, Product structured data, read 10 September 2026). That is still eligibility, not guaranteed display. When feed and page facts disagree, fix the underlying catalog or synchronization path rather than choosing whichever version looks better.

Treat variants as a data-model decision

Variant markup depends on storefront behavior. Google documents two patterns: variants selected on one page, often through query parameters, and variants with distinct pages or URLs. It supports ProductGroup with hasVariant, variesBy and productGroupID, alongside Product data for the variants. Each variant and product group needs a unique identifier, and a single-page group needs one distinct canonical URL for the group (Google Search Central, product variants, read 10 September 2026).

Before editing markup, write down:

1. Does selecting a variant change the URL?
2. Does the selected price, availability, image and identifier change on the visible page?
3. Which URL is canonical for the group?
4. Can a crawler reach every variant that you intend it to understand?
5. Does the emitted data describe the default product, the selected variant or the whole group?

Do not label every product in a collection as variants of one group. Colour or size versions of one product can be variants; different jackets merely displayed together are separate products.

Article and BlogPosting markup should match the byline

For Shopify blog posts, Article or the more specific BlogPosting can describe the page. Google says Article markup can help it understand title, images, dates and authors, while noting that there are no required Article properties; publishers should add the recommended properties that apply (Google Search Central, Article structured data, read 10 September 2026).

Compare the markup with the visible article:

• headline matches the article's actual title;
• each image represents the article and is crawlable;
• datePublished is the original publication date;
• dateModified changes only for meaningful, visible updates;
• every visible author appears separately in author;
• a human uses Person, an entity uses Organization;
• author URLs resolve to pages that identify those authors;
• publisher details describe the publisher, not the author.

Google recommends timezone information in published and modified timestamps and recommends multiple high-resolution representative images in 16:9, 4:3 and 1:1 aspect ratios when available. These are recommendations, not an instruction to invent crops or dates. The Shopify blog SEO guide covers visible dates, headings and image context around the markup.

If an article was merely republished by a scheduler without a material editorial change, do not reset the original publication date to make it look new. Markup should describe the content history a reader can verify.

Google FAQ rich results have been retired

An FAQ section can still help a shopper. That editorial usefulness is separate from Google rich-result eligibility.

Google's current changelog says FAQ rich results stopped appearing on May 7, 2026; the documentation was removed in June (Google Search Central updates, checked 17 September 2026). This supersedes the earlier government/health restriction. Useful visible questions and answers remain editorial content, but FAQPage markup is not a route to the retired Google feature. Use the customer-question workflow to choose and maintain answers for readers.

If you retain FAQPage markup for a valid non-Google consumer or future portability, keep the basics honest:

• every marked question and answer is visible on the page;
• the site supplies one authoritative answer to each question;
• user-submitted competing answers use a Q&A model rather than FAQPage;
• promotional copy is not disguised as an answer;
• the markup updates when the visible answer changes.

Do not add FAQs solely to repeat target phrases. A concise shipping or product-care answer can help a buyer even when it produces no special search treatment.

There is no special AI schema layer

Google says pages appearing in AI Overviews or AI Mode have no additional technical requirements beyond normal Search eligibility. It specifically says no new machine-readable files, AI text files or special schema.org structured data are required (Google Search Central, AI features and your site, read 10 September 2026).

Use Product markup because the page sells a product, and Article markup because the page is an article. Do not create AIOptimized, GEOPage, “LLM schema,” or hidden answer objects and present them as a supported standard. The generative-engine optimization guide explains why visible, sourced answers matter more than an invented markup label.

Structured data also does not fix weak visible facts. Before marking up product details, use a fact sheet and the process in keeping AI-written product content true. The product-description scorer checks pasted text with deterministic rules; it does not validate JSON-LD, query Shopify or verify factual accuracy.

Worked example: conflicting product objects

Illustrative example — Harbor Thread and Tidal Shell are fictional. No live theme or rich result was tested.

The Tidal Shell page visibly shows the blue, medium variant at USD 148 and says it is in stock. The audit finds two Product objects:

Source	Name	Price	Availability	URL
Theme	Tidal Shell	148 USD	InStock	canonical product URL
Review app	Tidal Waterproof Jacket	129 USD	OutOfStock	URL with an old variant parameter

Both blocks can be syntactically valid. Together they contradict the visible page. The audit action is:

1. Confirm which app or snippet owns each block.
2. Confirm the selected variant and canonical behavior in the storefront.
3. Decide which owner should emit Product and which should emit only its supported review data, if appropriate.
4. Remove or reconfigure the stale duplicate in a theme copy.
5. Validate simple, variant and unavailable-product samples.
6. Publish through the store's normal theme-review process and test public URLs again.

The result should be reported as “one coherent Product description on the sampled pages.” Do not report “rich results fixed” until Search Console or live search evidence supports that separate outcome.

Validate in three passes

First, use Google's Rich Results Test on the public URL and, while developing, on the exact code under review. Fix critical errors for the intended rich-result type. Recommended-property warnings require judgment: add the field only when the page truly supports it.

Second, use the Schema Markup Validator for broader schema.org syntax. Google describes these tools as different: the Rich Results Test evaluates Google rich-result possibilities, while the Schema Markup Validator checks schema.org markup without Google-specific feature warnings (Google Search Central, structured-data tools, read 10 September 2026).

Third, compare every important value with the rendered page, catalog and policy source. A validator cannot know that a syntactically valid price is yesterday's price or that an author URL identifies someone else.

After release, inspect representative URLs in Search Console. Google recommends deploying a few pages, using URL Inspection to see how it reads them, and submitting a sitemap for ongoing discovery. Allow time for recrawling and reindexing.

If a URL is still missing, work through the Shopify indexing diagnosis before requesting another crawl.

Record limits with the result

Google says valid markup does not guarantee a rich result. Eligibility can also be lost through content or technical-policy violations, and a manual structured-data action affects rich-result eligibility rather than ordinary web ranking (Google Search Central, structured-data guidelines, read 10 September 2026).

Record the exact URLs, template version, validator, date and result. List untested markets, variants, app states and logged-in experiences. Keep these outcomes separate:

• markup exists;
• markup parses;
• markup is eligible for a Google feature;
• Google crawled the updated page;
• a rich result appeared;
• impressions, clicks or sales changed.

That separation turns a schema audit into evidence instead of decoration.

When several template systems may be involved, carry the result into the storewide Shopify SEO checklist so canonical, robots, title, visible content and performance evidence are reviewed alongside the markup.