Articles · SEO
Shopify schema markup, end to end
Published
Most stores already have schema markup. Almost none of them know what they have, which is why the usual advice, add structured data, is the wrong first move. The first move is finding out what your theme and your apps are already telling Google, because on a Shopify store they are usually telling it two different things.
Everything below uses one worked example: a fictional coffee roaster called Northbound Coffee. Fictional deliberately: the field names are real and the prices are not anybody's.
Schema markup in plain English
A product page tells a person the price by putting it next to a button. Schema markup tells a machine the price by declaring it in a labelled field, in the head of the document, where no visitor ever sees it. It changes nothing about how the page looks. It changes what a search engine is willing to say about the page in its results, and, the newer half of the story, what an AI assistant is willing to quote.
The format is JSON-LD: a block of JSON in a script tag, describing the page in Schema.org's shared vocabulary. Google has recommended it over the older inline formats for years, and on Shopify it is the only format worth writing new markup in.
It is not the same thing as Liquid section schema
Worth clearing up before anything else, because the name collision causes real confusion on real projects. A Liquid section file contains a schema block, and that block defines the settings a merchant sees in the theme editor: headings, colour pickers, block limits. It has nothing to do with search engines.
Schema.org structured data is a different thing that happens to share a word. When a developer says the theme "has schema", find out which one they mean before you conclude anything, because the two answers point in opposite directions.
The types that matter, and the ones that do not
There are hundreds of Schema.org types. About a dozen are relevant to a store, and they are not equally worth your afternoon. The ordering below is ours, and the reason it is worth stating as an ordering is that most schema advice presents a list of twelve types as though they were twelve equal jobs.
Product schema, line by line
This is the one that pays. A complete Product block is what produces the price, the stock status and the star rating in a search result, and it is also the block most themes get almost right.
The trap in that block is availability. It takes a
schema.org URL, not a description. It wants https://schema.org/InStock,
not the words "In stock". Themes get this wrong constantly, and because
the block still validates as a Product, nothing tells you the stock line
is silently not rendering.
Organization and breadcrumbs, the cheap wins
Organization is one block, added once, sitewide. Name, logo, URL, and a
sameAs array pointing at the social profiles you actually
run. It is what a knowledge panel is assembled from, and it takes about
twenty minutes on a store that has never had it.
BreadcrumbList is nearly as cheap and does one visible job: it replaces
the raw URL under a result with a readable trail. On a store with deep
collection nesting that is the difference between a result showing
/collections/whole-bean/products/house-blend-1kg and one
showing Home › Coffee › Whole Bean.
Reviews and AggregateRating, and the one rule with teeth
Star ratings in a search result come from aggregateRating,
and this is the only part of schema markup where getting it wrong is
treated as a policy problem rather than a technical one.
The rule: the ratings have to be from reviews collected on your own site, from real customers, and a person looking at the page has to be able to see them. Importing a supplier's average, marking up reviews of the brand rather than the product, or inventing the numbers outright are all the same offence with the same outcome. If you run a review app, it is almost certainly emitting this block already, which brings us to the audit further down.
Collections, articles and FAQs
Collection pages are the most under-marked-up surface on a typical store.
A CollectionPage containing an ItemList of the
products on it tells a shopping assistant what the page is a list of,
which is exactly the question those tools are trying to answer.
On the blog, Article with a real author does
two jobs: the blog rich result, and an authorship signal that matters
more now than it did, because generative engines lean on identifiable
authorship when deciding what to cite.
FAQPage is the interesting one. The visible FAQ rich result
is rare in 2026 and if the SERP appearance were the only prize it would
not be worth the markup. It is worth it because AI answers quote question
and answer pairs more or less verbatim, and this is one of very few ways
to hand a machine a fact in a form it will reproduce accurately.
Actually adding it to a Shopify theme
Three routes, and the right one depends less on the store's size than on who is going to maintain it.
Theme code. A snippet rendered into
theme.liquid, built from Liquid objects so the values track
the product rather than being typed once and forgotten. Full control, no
monthly cost, and it needs somebody who will remember it exists at the
next theme upgrade.
A schema app. Faster, maintained by somebody else, and the good ones handle the duplicate problem for you with a microdata filter. The cost is a monthly fee and a layer you do not control.
Built as part of the theme, by a developer. What we do on Plus builds, because at that size the markup has to handle Markets, B2B pricing and multiple currencies, and no app models that well.
The duplicate-schema audit, which is where to start
If you read one section of this, read this one. The most common schema fault we find on a Shopify store is not missing markup. It is two sources of the same markup, disagreeing.
It happens because markup accumulates. The theme has always emitted
Product microdata. Someone installed an SEO app in 2023 that adds its
own JSON-LD. The review app adds an aggregateRating. None of
the three knows about the others, and nothing in Shopify warns you.
The audit is short: view source on a product page, search for
itemtype and for application/ld+json, and count
the Product entities. More than one is the job. The fix is always the
same: choose which source owns it, and suppress the rest.
Validating it, and what a clean run looks like
Google's Rich Results Test takes a URL and tells you what it found. Run it on one product page and one collection page before you change anything, and again after.
After that, Search Console's Enhancements reports are where problems turn up at scale, because they read your whole catalogue rather than the one URL you thought to test. Worth a look once a quarter, and worth a look immediately after any theme update.
Schema as an AI-search signal
This is the part that has changed since most schema advice was written. Structured data used to be a way to get a nicer-looking search result. It is now also the most reliable way to hand a generative engine a fact it will repeat correctly.
The practical consequence is that completeness matters more than it used to. A partial Product block still produced a decent rich result, because Google filled the gaps from the page. An assistant asked for a recommendation under twenty-five pounds either has your price as a declared number or it does not. This is the same argument our GEO work and AI SEO work rest on, approached from the plumbing rather than the strategy.
Plus, B2B and Markets
Three complications that only appear at the larger end, and all three break naive markup.
Markets. A store selling in several currencies needs the
priceCurrency in the markup to match the currency the page
is actually rendering, per locale. Hardcode GBP and every localised page
declares the wrong currency.
B2B. Catalogue-specific pricing means the price a logged in wholesale customer sees is not the price to declare publicly. The markup should carry the retail price, or none.
Headless. If the storefront is Hydrogen or custom, the markup is your application's job entirely and no theme is emitting anything. That is more freedom and one more thing to remember at launch.
The errors we find most often
priceCurrencymissing, so the price never renders.availabilityset to the words "In stock" rather than a schema.org URL.- Two Product entities on one page, from the theme and an app.
- Images below 1600px on the long edge, or pointing at a 404.
priceValidUntilleft at a date that has passed.- Review markup for reviews that are not visible on the page.
- Organization declared on every page with a different logo URL.
What we would actually do first
- Run the Rich Results Test on one product page and one collection page. Read what is already there before adding anything.
- Find every source of Product markup: the theme, the SEO app, the review app. Pick one. Suppress the rest.
- Complete the Product block: price, priceCurrency and availability together, image at 1600px or more.
- Add Organization once, sitewide, with logo and sameAs. It is the cheapest thing on this list.
- Add BreadcrumbList sitewide, then stop and re-validate before going near anything else.
That is a morning on most stores, and it covers the majority of what schema markup can do for a Shopify catalogue. Everything past it has real but smaller returns. If it turns into a development job rather than an editing job, or the catalogue is large enough that the decisions have to be structural, that is where our Shopify SEO work earns its cost. The on-page half of the same subject is in product page SEO.
Common questions
- Does Shopify add schema markup automatically?
- Partly, and the partly is the problem. Nearly every modern theme emits some Product markup, and most emit Organization and Breadcrumb too. What themes tend to miss are the fields that actually produce the visible result: priceCurrency, a schema.org availability URL rather than the word "In stock", and review data. So the honest starting position is not "we have none", it is "we have some, and nobody has checked what".
- How do I get Shopify Google rich snippets to show?
- Three things have to be true at once. The markup has to be valid, which the Rich Results Test will tell you in about ten seconds. It has to be complete for the result you want, which for a price snippet means price, priceCurrency and availability all present together. And it has to be the only markup of its type on the page, because two Product blocks disagreeing about the price is the most common reason a technically valid page renders as a plain blue link. Even then Google chooses whether to show a rich result; eligibility is not a guarantee.
- Schema, Shopify themes and apps: which one should own the markup?
- One of them, and which one matters less than that it is only one. If you already pay for a schema app, the usual answer is to let it own everything and turn on its microdata filtering so it suppresses the theme output. If you do not, strip the app and let the theme own it, filling the gaps in the theme code. The failure mode is not having too much markup, it is having two sources that drift apart the first time a price changes.
- Is FAQ schema still worth adding in 2026?
- For most stores the visible FAQ rich result is rare now, so if the only reason to add it is the SERP appearance then no. The reason to add it anyway is that AI answers quote it. A well-formed question and answer pair is the easiest thing in the world for a generative engine to lift and cite, and it is one of the few places you can put a fact on a page in a form a machine will reproduce verbatim.
- Can marking up reviews get a store penalised?
- Marking up reviews you have not earned can, yes. The rule with actual teeth is that aggregateRating has to come from reviews collected on your own site, from real customers, and that the ratings are visible to a person on the same page. Inventing a 4.9 across 300 reviews, or importing a supplier average, is the one error in this whole area that is treated as a manual-action problem rather than a warning.
- Is Liquid section schema the same thing?
- No, and the name collision causes real confusion. The schema block inside a Liquid section file defines the settings a merchant sees in the theme editor. Schema.org structured data is JSON-LD in the document head and is aimed at search engines. Same word, no relationship. If a developer tells you the theme "has schema", establish which one they mean before drawing any conclusion.
Get in touch
Tell us about your store or your business and we'll reply personally. No wizard, no ten questions.
Stores we build and grow