Schema markup audit: what is on your site and what is wrong

Almost every schema audit starts in the wrong place: someone pastes a product URL into a validator, reads a list of warnings, and starts fixing them. That finds property-level faults and misses the structural one, which on a Shopify store is nearly always the same. Something is emitting a second copy of the same entity.

Work out what is producing markup before you read any of it. On a typical store, the candidates are the theme (product, collection, breadcrumb and organisation markup written into the Liquid templates), an SEO app that offers "one-click structured data", a reviews app that adds aggregateRating and review, and occasionally a third-party search or merchandising app that renders its own product cards. Each is doing a reasonable thing in isolation. Together, they publish two or three answers to the question "what is this page about", and you do not control which one is believed.

The mechanical version of the check: fetch the rendered HTML of one product page, one collection page, one blog post and the home page, and count the application/ld+json blocks. Then read each one far enough to identify its @type and where it came from. Half an hour of this is worth more than any report, because it tells you which switch to turn off — and turning one off is almost always the fix, rather than reconciling two sources of truth.

Both are free, both are worth running, and treating them as interchangeable is how audits reach a false conclusion.

The Rich Results Test answers "can Google use this for a feature it supports?" It only knows about the types Google has a search feature for, so valid, useful markup can produce the message that no rich results were detected. That is not an error.

The Schema Markup Validator answers "is this valid schema.org?" It does not care whether Google has a feature for it, which makes it the right tool for anything you are publishing for extraction rather than for a rich result — and for machine readers that are not Google at all.

Search Console is the third input and the only one that reports at site scale rather than per URL. Its enhancement reports are the place a fault that affects four thousand pages becomes visible; a spot check on one URL will never find the one template variant that is broken.

Google's merchant listing documentation is short on requirements and long on recommendations, which is the opposite of how most stores treat it. The required properties are name, image, offers, and within the offer either offers.price or offers.priceSpecification.price plus offers.priceCurrency or offers.priceSpecification.priceCurrency. That is the whole list.

The recommended set is where the work is, and it is the part that a theme rarely fills in: aggregateRating, brand.name, category, color, description, gtin (or gtin8/gtin12/gtin13/gtin14/isbn), material, mpn, pattern, review, size, sku, audience, hasCertification, and the two that matter most for stores with variants — isVariantOf and inProductGroupWithID.

Two practical readings of that list. First, identifiers are the highest-value gap: gtin, mpn and sku are the properties that let a machine reconcile your product with the same product elsewhere, and they are usually already in Shopify as barcode and SKU fields, unmapped. Second, if you sell variants, the variant properties decide whether Google sees one product or forty unrelated ones. Most themes emit a single Product for the default variant and stop.

On shipping and returns, Google's own guidance is to publish the policy once rather than everywhere: provide "a global shipping policy for your business under Organization markup instead", and override it on an individual Offer only where a specific product genuinely differs. Stores that inject a shipping policy into every product page have taken on maintenance they were not asked for.

This is the part of the audit that saves money, because it removes work rather than adding it.

How-to markup does not produce a rich result. Google removed the documentation on 14 September 2023 with the note that the rich result "is no longer shown in search results, on both desktop and mobile devices". If a HowTo block is on your site because someone promised a stepped rich result in the SERP, that promise expired.

FAQ rich results are effectively closed. Google's own guidance is that "the feature is only shown for well-known, authoritative government and health websites". A commerce site will not get FAQ rich results, and an app subscription sold on the basis that it will is being mis-sold.

Neither of those is an argument for deleting the markup, and this is where honest advice diverges from the usual audit. A FAQPage or HowTo block is a machine-readable statement that this page contains a question with a direct answer, and the readers that matter have multiplied since 2023. Keeping it costs nothing if the content exists anyway. What has to change is the justification: it is structure for extraction, not a route to a bigger search result, and nobody should be buying an app or building a template around it on the old basis.

The rule that follows is the one worth enforcing: the answer must exist in the visible page, not only in the markup. Structured data that describes content a reader cannot see is a policy breach — "don't mark up content that is not visible to readers of the page" — and it is also useless to any reader arriving from an answer engine, who wants the paragraph, not the JSON.

Worth knowing before anyone proposes an emergency sprint: a structured data manual action, in Google's own words, "means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search."

That is a meaningful cost and a bounded one. It also means the failure mode of bad markup is losing an enhancement, not losing the page — so the rational response to a messy schema estate is a deliberate clean-up, not stripping every block out of the theme on a Friday afternoon. The teams that do the latter usually remove working Product markup along with the broken aggregateRating that caused the problem.

Schema estates do not decay randomly. They decay when someone builds a new page type — a landing page, a campaign template, a new collection layout — and the markup is not part of the template. The audit finds the mess; template ownership is what stops it coming back.

That is the practical argument for composing pages from a small set of maintained blocks rather than hand-building each new layout: the structured data is written once, in the block, and every page built from it inherits the correct markup without anyone remembering. It is the same reason a [Shopify section library](/services/build/shopify-section-library) keeps a marketing team fast — the thing that scales is not the page, it is the component behind it.

And keep one rule above all the others. If the markup says something, the page should say it too, in words a person can read. Everything else in this audit is maintenance; that one is the difference between structured data and a liability.

• Shopify section libraries for content-heavy brands
• Review platforms and the schema that makes them count
• Answer engine optimisation for a product catalogue