Schema Drift: Why Your Structured Data Breaks Silently, And Nobody Ever Notices

Schema Drift: Why Your Structured Data Breaks Silently, And Nobody Ever Notices

Here’s a job I’ve done more times than I’d like. A store gets a structured data audit. Everything’s wrong — missing GTINs, availability out of sync, review markup pointing at nothing. We fix it properly, validate it, everyone’s pleased. Nine months later someone runs the audit again and it’s broken in a completely different way.

Nobody did anything careless. That’s the thing. The theme got updated, two apps got installed, one got removed, a developer added a section, and the structured data quietly degraded across four thousand product pages while every dashboard reported normal.

I’ve started calling it schema drift, and I think it’s the single most under-discussed problem in ecommerce technical SEO — because unlike almost every other failure mode, **it produces no symptom you would ever notice**.

Why structured data fails silently

Think about what happens when your product images break. Customers complain. Conversion drops. Someone spots it within a day.

Now think about what happens when your `availability` property starts emitting `InStock` for every product regardless of actual stock. The page looks perfect. Customers see the correct sold-out badge, because that’s rendered from a different part of the template. Conversion is unaffected. Nothing in your analytics changes.

The only parties who see the broken data are the crawlers, and they don’t file tickets. They just quietly downgrade how much they trust what your site says — and trust, once lost, is not a per-property setting. A source that has been wrong about availability is a source to be careful with generally.

That’s why drift is expensive out of proportion to how boring it is.

The five ways it happens

Having pulled these apart on a lot of stores, the causes are consistent enough to list.

**Theme updates.** Your theme emits JSON-LD from Liquid templates. Update the theme and those templates are replaced with the vendor’s current version — which may structure things differently, may drop a property you were relying on, and will certainly discard any customisation applied directly to the old files.

**App installs.** Review apps, SEO apps, rich snippet apps and structured data apps all inject their own markup. Install two and you can end up with two `Product` objects on one page, disagreeing about price. Crawlers handle duplicate conflicting markup badly, and “badly” here means “by ignoring some of it.”

**App removals.** Worse than installs. Remove a review app and its script tags frequently stay in the theme — but the data source is gone, so you emit `AggregateRating` markup pointing at reviews that no longer render. That’s markup for content not visible on the page, which is a policy violation, not just an error.

**Catalogue changes.** You start selling a new category with different attributes. Your schema template was written for the old category. Products enter the catalogue with structurally incomplete markup from day one, and nobody re-audits because the code didn’t change.

**Third-party template edits.** A developer adds a section, a freelancer fixes a layout bug, an agency ships a landing page. Any of them can break a Liquid loop that was populating a schema property, and none of them will think to validate structured data afterwards.

Notice the pattern: **four of those five involve no change to any file anyone thinks of as “the SEO setup.”**

Why one-off validation doesn’t solve it

The standard advice is to validate in Google’s Rich Results Test. Good advice. Necessary. Completely insufficient, for three reasons.

**It’s a snapshot.** It tells you about one URL at one moment. The whole problem is change over time.

**It’s one URL.** You have thousands, across at least three or four templates, with categories that differ in which attributes exist. A clean result on your best-maintained product page tells you nothing about the 400 SKUs imported in a hurry last spring.

**It tests validity, not accuracy.** This is the one people miss. Schema can be perfectly valid and completely wrong. `”availability”: “https://schema.org/InStock”` is valid markup. If the product is sold out, it’s a lie, and the validator has no way to know.

Which is why the useful unit of work here isn’t validation. It’s **monitoring** — the same shift that happened in web performance a decade ago, from “we ran Lighthouse once” to “we track field data continuously.”

What to actually monitor

Six checks, run on a schedule across your catalogue rather than once on a URL:

**1. Presence.** Does every product page emit `Product` schema at all? Templates diverge; new categories get missed.

**2. Completeness.** Which properties are populated? Track the fill rate for `gtin`, `brand`, `sku`, `offers.price`, `offers.availability`, `image`, `description` as percentages across the catalogue. A fill rate is a number you can watch trend.

**3. Accuracy against the live page.** Does schema price match displayed price? Does schema availability match actual stock? This is the check almost nobody runs and it’s where the real damage sits.

**4. Duplication.** More than one `Product` object per page, or conflicting objects from competing apps.

**5. Orphaned markup.** `AggregateRating` or `Review` markup where no reviews render on the page.

**6. Change detection.** Alerting when any of the above moves. This is the whole point — you want to know that fill rate dropped from 94% to 61% the week the theme updated, not nine months later.

Doing this at catalogue scale

Now the honest part about why this is hard, and it’s the same reason most stores never fix it.

Running those six checks on one product page takes about ten minutes with a validator and a careful eye. Running them across 2,000 products is not 20,000 minutes of the same work — it’s a different kind of work entirely. It needs to be automated, or it doesn’t happen.

This is precisely the gap GEOptimisation exists to fill, and I’ll describe the split plainly. The free tier gives you the audit output for up to 25 audits — you can see exactly what’s broken, on which pages, against which checks. That’s genuinely enough to diagnose a store and to prove to yourself whether you have a problem.

Implementing the fixes from those audits by hand is entirely possible. It’s also, on a real catalogue, days of work: editing templates, populating fields, reconciling app conflicts, product by product. The paid tiers exist because that implementation step is where every good intention dies. One-click bulk application across schema, breadcrumbs, meta descriptions and product content is the difference between an audit you read and an audit you act on.

You do not need my tool to run the checks. You need *something* that runs them on a schedule, because the failure mode here is time, not knowledge.

The 20-minute version, if you do nothing else

Pick five products across your different categories and templates. For each, validate the schema, then manually compare the schema’s price and availability against the live page. Then check for duplicate `Product` objects, and check whether any review markup corresponds to reviews actually visible.

Write down what you find with today’s date.

Then put a recurring calendar entry for ninety days’ time to do it again — and specifically, do it after any theme update or app change, because that’s when drift happens.

If nothing has moved in ninety days, you’re in better shape than most stores. If something has, you’ve just discovered the thing that would otherwise have been quietly costing you for a year.

*Sources: Google structured data documentation and Rich Results Test; Shopify Help Centre. Verify current structured data requirements at developers.google.com before implementing.*