Contents
The short answerThe priority stackA worked exampleImplementationQuestionsRelated service
Shopify SEO →The short answer
A Shopify store needs five schema types, in this priority order: Product markup complete enough to qualify for merchant listing treatment, Organization markup that defines the brand as an entity, BreadcrumbList on products and collections, FAQPage wherever a visible FAQ exists, and Article on editorial content. Everything else is situational, and several popular types are now a waste of effort.
Schema serves two readers at once in 2026. Search engines use it to understand pages and to build the rich results and merchant listings that dominate product search, and AI models lean on it when they resolve which entities they are looking at and which facts they can repeat with confidence. One implementation feeds both, which is why the work has moved up the priority list rather than down it.
The catch on Shopify is that markup arrives with the theme, and theme-generated schema is built for the general case: usually incomplete, occasionally wrong, and always ignorant of what your specific catalogue needs. The work is an audit against what the store sells, then a gap-fill in order of commercial return.
What a Shopify theme gives you by default
Most themes, including Shopify's own free themes, output a basic Product schema with name, price, currency and availability. Brand, SKU, GTIN, aggregate ratings and the richer offer details that qualify a page for merchant listing treatment depend on the theme, and often on custom work.
Collection pages get BreadcrumbList schema in some themes but not others, and Organization schema usually exists at the homepage level but is rarely complete. None of this is a criticism of theme developers, who build for the general case. It means the markup needs auditing against what the store sells.
When we audit Shopify Plus stores, the same two gaps appear on nearly every one: no aggregate rating markup despite thousands of collected reviews sitting in a review app, and no return policy or shipping markup despite both being merchant listing fields Google explicitly supports. Neither gap is visible to anyone browsing the store, which is why they survive redesign after redesign.
The priority stack
| Type | Where it lives | What it earns | Typical state on a Shopify store |
|---|---|---|---|
| Product + Offer | Every product page | Rich results and merchant listing treatment: price, stock, ratings, shipping and returns in the result | Present but thin, with identifiers and policy fields missing |
| Organization | Site-wide, once | Entity recognition: who the brand is, connected to its verified profiles | Present but skeletal, missing sameAs and logo, often duplicated per page |
| BreadcrumbList | Products and collections | Hierarchy in the result, catalogue structure for crawlers | Theme-dependent, and often absent on collections |
| FAQPage | Pages with a visible FAQ | Machine-readable Q&A for AI surfaces | Absent, or worse, present without visible FAQs |
| Article | Editorial content | Authorship and publish data connected to the brand entity | Absent or generic |
Two once-popular types have left the list. Google restricted FAQ rich results to authoritative government and health sites in August 2023 and retired HowTo rich results for most devices at the same time, so neither earns visible search treatment for a store any more. FAQPage markup keeps a different job, covered below. HowTo markup on ecommerce content is now effort with no payoff.
Product schema done properly
Google's documentation is direct: the more valid properties a product page carries, the more result enhancements it is eligible for. The gap between minimum markup and complete markup is the gap between a blue link and a merchant listing carrying price, availability, ratings, shipping cost and return window directly in the result.
Complete, for a Shopify product, means the offer data (price, currency, availability, condition), the identifiers (brand, SKU, and GTIN where products carry barcodes), the review layer (aggregateRating and review, fed from whichever review app holds the data), and the policy layer (OfferShippingDetails and MerchantReturnPolicy, stating the same terms the policy pages state). Variants deserve care: a page selling six colourways should describe them as variants of one product, and the theme decides whether that happens.
The review layer is the one worth escalating internally, because it is usually a plumbing problem. The reviews exist, the app displays them, and nothing connects them to the Product markup, so the store shows star ratings to humans and none to machines. Whichever review platform the store uses, the integration that writes ratings into the page markup is the single highest-return schema fix on most established stores.
A worked example: one product, fully described
For an illustrative pair of leather walking boots at £189, this is what complete markup states and where each value comes from. Every field maps to data Shopify already holds, so complete schema is rarely a content problem, it is a wiring problem.
| Field | Value for this product | Where it lives in Shopify |
|---|---|---|
| name, description, image | The product title, a trimmed description, the featured image set | The product record |
| brand | The brand name as the Organization states it | Vendor field, or hardcoded for own-brand stores |
| sku / gtin | The variant SKU and barcode | Variant fields, populated at product setup |
| offers: price, currency, availability | £189, GBP, InStock, per variant | Live variant data via Liquid, never hardcoded |
| aggregateRating | 4.7 from 312 reviews | The review app, wired into the markup |
| shippingDetails | UK £4.95, free over £150, 2 to 3 working days | Stated to match the shipping policy page |
| hasMerchantReturnPolicy | 30 days, free returns, refund to original method | Stated to match the returns policy page |
Read the last two rows again, because they are where merchant listings earn their keep: the return window and delivery cost appear directly under the product in search results, answered before the click. They are also where consistency bites, since the values must match the policy pages and every other machine-readable surface word for word.
Organization schema and the entity layer
Organization markup is where the brand tells machines what it is, and one discipline matters more than any individual field: state it once, completely, and reference it everywhere else. One Organization entity with a stable identifier, carrying the legal name, logo, founding facts, contact points and a sameAs array pointing at the brand's verified profiles and listings, gives every other piece of markup on the site something authoritative to point at.
The sameAs array does more work than its size suggests, because it is how machines connect the store to the brand's social profiles, directory entries and knowledge-panel sources, and every URL in it must be byte-identical to the canonical profile URL it references. We treat inconsistent sameAs URLs as a defect for the same reason a misspelled brand name would be: entity resolution runs on exact matches, and near-misses fragment the entity you are trying to consolidate.
This is also where schema meets the wider machine-readable layer. The facts the Organization markup states, and the policies the Product markup states, must agree with the policy pages, the Knowledge Base feed and the agents.md file, because every one of those surfaces is read by systems that compare. The one-fact-everywhere discipline in our discovery-ready standard starts with schema, and it is the reason schema work and agentic readiness are one budget rather than two.
FAQPage after the 2023 change
Google announced in August 2023 that FAQ rich results would only be shown for well-known, authoritative government and health sites, so the visible accordion in search results is gone for ecommerce, and any agency still selling FAQ markup as a rich-result play is selling 2022.
The markup itself still earns its place, for a different reader. AI models consume FAQPage markup as clean question-and-answer pairs, exactly the format they reach for when answering a buyer's question, and collection-page FAQs marked up properly become citable answers rather than paragraphs to parse. Go in knowing the payoff is in AI answers, and hold one rule as hard: FAQPage markup only where a visible FAQ exists on the page. Markup describing content the page does not show is the kind of mismatch that costs trust with every machine reader at once.
Implementation on Shopify, and validation
Custom JSON-LD in the theme is the cleanest route. The markup goes in through Liquid snippets, draws live values from the product and shop objects so it never drifts from the catalogue, and stays under version control with the rest of the theme. Schema apps work adequately for standard product markup, but they inherit whatever inconsistencies exist in the product data, add script weight, and put a subscription between the store and its own structured data.
- Audit what exists: run the homepage, one collection and two products through Google's Rich Results Test, recording what validates, what errors, and what is missing against the priority stack.
- Fix Product markup first, on the templates, so every product inherits the fix: identifiers, review integration, shipping and returns fields.
- Consolidate Organization markup to a single complete entity, and remove duplicate or conflicting versions that apps and theme sections have scattered.
- Add BreadcrumbList where the theme omits it, and FAQPage wherever visible FAQ content already exists.
- Re-validate, then re-test quarterly and after every theme update, because theme updates overwrite Liquid customisations silently.
Validation is not optional at either end. Markup that throws errors delivers nothing, and structured data that misrepresents the page, invented reviews, prices that disagree with the visible price, policies the store does not honour, is the one area where Google's documentation warns of manual actions. The rule that keeps a store safe is the same one that makes the markup useful: schema states what the page already shows, and nothing else.
The rules that keep markup trustworthy
Schema fails in two directions: too little, which wastes eligibility, and too loose, which costs trust. Four rules keep an implementation on the right side, and they are the ones we hold every store to.
- One primary entity per type per page. A product page describes one Product, the site describes one Organization, and duplicates from apps or theme sections get removed.
- Markup states only what the page shows. No FAQPage without a visible FAQ, no ratings the visitor cannot see, no policies the store does not honour.
- Live values over hardcoded ones. Price, availability and variant data come from Liquid objects so the markup cannot drift from the catalogue.
- No aspirational types. SearchAction without a site search, HowTo on product content, and video markup for pages without video all describe a site that does not exist.
The common thread is that structured data is a claim, and machines increasingly cross-check claims against the visible page, the policy pages and the agentic feeds. A store whose claims agree everywhere compounds trust with every reader, and a store whose claims disagree teaches every reader to discount it.
Questions we hear about Shopify schema
No. Google's documentation does not list structured data as a ranking factor. It changes how results display and how confidently machines understand the page, which changes click-through and citation, and those are worth having on different grounds.
Usually not. Theme markup covers the general case, and the commercial gaps, review integration, identifiers, shipping and returns fields, complete Organization data, are exactly the parts a theme cannot know about your store. Audit rather than assume.
Theme-level JSON-LD if you have developer access, because it stays accurate to live data and adds no script weight. An app is a reasonable interim for standard product markup, and it will faithfully reproduce whatever gaps your product data has.
Yes, where visible FAQ content exists, because AI surfaces read the markup even though the search results page no longer rewards it. Adding FAQPage markup to pages without visible FAQs is not worth doing and never was.
The Rich Results Test confirms validity page by page, Search Console's enhancement reports track eligible pages at scale, and merchant listing treatments appearing under your products in search are the visible payoff. For the AI side, watch how accurately assistants describe your products and terms.
Sources & references
- Google Search Central, Product structured data(developers.google.com)
- Google Search Central, Merchant listing structured data(developers.google.com)
- Google Search Central, Organization structured data(developers.google.com)
- Google Search Central, Introduction to structured data(developers.google.com)
- Google Search Central blog, Changes to HowTo and FAQ rich results(developers.google.com)
- Google Search Central, Page experience in Google Search results(developers.google.com)



