Schema Drift Fixes: Catch and Reverse Silent Structured Data Changes
Structured data rarely breaks on the day someone works on it. It breaks weeks later, when a plugin updates, a theme is swapped, a template is tidied up or a content editor changes a field, and nothing on the visible page looks different.
The Schema Drift Detector takes regular snapshots of your markup and reports what changed: types added or removed, properties dropped, validation errors that were not there before, and shifts in rich result coverage. This page explains where drift comes from, how to trace a change back to its cause and how to stop it recurring.
Where drift comes from
Drift is a change nobody meant to make. It almost always has one of a handful of causes, and each leaves a recognisable pattern in the detector's findings.
| What changed | Typical pattern in the findings |
|---|---|
| Plugin or app update | A whole type disappears or changes across every page of one template on the same day |
| New plugin or app installed | A second copy of an existing type appears, often with slightly different values |
| Theme change or redesign | Markup that lived in the old theme's templates is gone site-wide |
| CMS core or platform update | Output format changes, for example dates or image values, across many types at once |
| Content edits | One or a few pages lose a property, such as a price, rating or author, because a field was emptied |
| Migration or new URL structure | URLs and @id values in the markup still point
at old addresses, or markup is missing on moved pages |
| Tag manager changes | Markup injected by script appears and disappears depending on consent or container versions |
The date of the first snapshot that shows the change is the most useful clue you have. Match it against your update history, deployment log or plugin changelog before looking anywhere else.
The fix guides
Each guide covers one kind of change the detector reports: how to confirm it, how to restore the markup and how to stop it happening again.
Markup that went missing or changed
Fixing entirely deleted schema covers restoring markup that vanished after an update, through plugin settings, a theme override or your own template code. Fixing changed schema types covers downgrades such as NewsArticle becoming Article or Product becoming a generic type, which quietly remove eligibility. Fixing lost schema properties covers markup that is still there but has lost ratings, offers, authors or images.
New problems and their effect
Fixing new validation errors is a checklist for markup that passed last week and fails now. Fixing rich result coverage drops helps separate a change on your site from a change in how Google shows a feature, using Search Console alongside the detector's snapshots.
Causes to deal with at source
Fixing CMS update regressions covers testing updates on a staging copy, rolling back and reapplying safely. Fixing plugin and app schema conflicts covers deciding which source owns each type and switching off the rest. Fixing a stale dateModified covers dates that stop updating when content changes, or that change when nothing meaningful did.
Prevention by platform
WordPress covers automatic updates, staging sites and where to keep custom markup so updates do not overwrite it. Shopify covers reviewing theme updates and the apps that change product markup. Custom builds covers keeping markup in one source of truth and testing it on every commit.
Build a baseline you can compare against
Drift is only visible against a known good state. Before relying on alerts, take the time to record what correct markup looks like for each part of the site.
- Pick representative pages. One or two per template: home, product, category, article, event, location, contact. Monitoring every URL is rarely needed, because drift usually happens at template level.
- Confirm each page is correct now. Fix any existing errors first. A baseline full of problems makes every later comparison harder to read.
- Record the expected types and key properties. For a product template that might be Product with name, image, offers, price, currency and availability; for an article, the type, headline, author reference, dates and image.
- Note the source of each type. Theme, SEO plugin, review app, custom code or tag manager. When something changes, this tells you where to look.
- Keep the baseline with your site documentation. Update it deliberately whenever you change markup on purpose, so intended changes are not mistaken for drift.
Snapshots taken by the detector give you the history; the baseline tells you which version was the one you wanted.
Catch drift before it reaches the live site
Monitoring tells you after the fact. The cheaper option is to check markup as part of every change, so problems never go live.
- Update on staging first. Apply plugin, theme and platform updates to a staging copy, then compare the markup on your representative pages with the baseline before updating the live site.
- Turn off blind automatic updates for the plugins and apps that produce structured data, or at least schedule them for a time when someone will check the result.
- Test markup in your build. On custom sites, a simple automated test can fetch or render key templates, parse each JSON-LD block and assert that the expected types and properties are present. A failing test blocks the release.
- Keep one owner per type. When a new plugin or app is installed, check whether it adds markup for a type something else already handles, and switch one off.
- Protect key fields in the CMS. If a rating, price or author comes from a content field, make that field required so an editor cannot empty it by mistake.
Tracing one change back to its cause
A worked example shows how the pieces fit together. Suppose the detector reports that product pages
no longer contain aggregateRating, starting with Tuesday's snapshot, while the rest of the
Product markup is unchanged.
- Check the scope. Is the rating missing on every product page, or only some? Every page points to a template, app or plugin; a few pages point to content or to those products losing their reviews.
- Check the source. Your baseline says ratings come from the review app, not the theme. That narrows the search to one place.
- Check the date. The app's changelog shows an update on Monday night that moved rich snippet output behind a new setting.
- Restore and confirm. Turn the setting on, test a live product page, and confirm the next snapshot shows the rating back.
- Close the gap. Add that app to the list of updates that are checked on staging before going live.
The same routine, scope, source, date, restore, prevent, works for almost every drift finding. It turns a vague worry that rich results have gone into a specific change with a specific owner.
Which findings to fix first
- Markup deleted across a template. The biggest loss and usually one cause, so one fix restores many pages.
- New validation errors on revenue pages. Product, event and job markup that newly fails loses eligibility until fixed.
- Type downgrades. A specific type replaced by a generic one looks valid but no longer qualifies for its rich result.
- Lost key properties. Missing offers, ratings or images reduce or remove enhancements.
- Duplicate sources. Resolve conflicts before they produce contradictory values.
- Stale or jumpy dates. Fix templates so dates reflect real content changes.
A sensible order of work
- Set up the Schema Drift Detector on representative pages from each template.
- Fix any existing errors and record the result as your baseline.
- When the detector reports a change, note the date of the first snapshot that shows it.
- Match that date against updates, deployments, installed apps and content edits.
- Restore the markup at its source: plugin settings, child theme, app configuration or template code.
- Confirm the fix on the live page, then check Search Console's enhancement reports as Google recrawls.
- Add the check that would have caught it: a staging review, a build test or a required CMS field.
- Update the baseline whenever you change markup on purpose.
For debugging a single page's markup in detail, see the Schema Debugger Guide. To rebuild lost markup correctly, see the Schema Builder Guide or the AI Schema Guide, and for what the markup should earn in search, the Rich Snippets Guide.
1. What is schema drift?
Schema drift is any unintended change to a site's structured data over time. Markup can be deleted, change type, lose properties or start failing validation because of an update, a redesign, a new plugin or an ordinary content edit. The visible page usually looks exactly the same, so nobody notices until rich results disappear or someone happens to test the page. Monitoring compares snapshots over time so these changes are caught when they happen.
2. How would I know if my structured data broke?
Without monitoring, most people find out from a drop in rich results or from Search Console's enhancement reports, and by then the problem may be weeks old. Search Console only reports what Google found on its last crawl of each page, so it lags behind the change. Regular snapshots of your own pages show the change within the monitoring interval and tell you exactly which types and properties changed, which makes the cause much easier to find.
3. Why did a plugin update remove my schema?
Plugins change how they build markup between versions: they rename settings, reset options, move a feature to a paid tier or change which types they output by default. Custom markup attached through a plugin's filters can also stop working if those hooks change. Check the plugin's changelog for the version you updated to, review its schema settings, and test the update on a staging site first next time so you see the effect before visitors do.
4. Should dateModified change every time I edit a page?
It should change when the content meaningfully changes, such as updated facts, prices, advice or sections. Fixing a typo or changing a sidebar does not need a new date. Setting the date to today on every page load, or bumping it without real changes, misrepresents the page, and Google has said it does not want dates changed just to look fresh. The goal is a date that honestly reflects when the main content was last updated.
5. Is a coverage drop in Search Console always a schema problem?
No. Valid items can fall because your markup changed, but impressions with a rich result can also fall because Google changed how often it shows a feature, restricted it, or retired it altogether, as happened with FAQ and HowTo results in 2023. Compare the detector's snapshots with the dates in Search Console. If your markup did not change on the date the drop started, the cause is more likely on Google's side.
6. How often should structured data be checked?
It depends on how often your site changes. A site with automatic plugin updates, frequent deployments or many editors benefits from daily or weekly snapshots of key templates. A small static site that rarely changes can be checked less often. Whatever the interval, always run a check straight after any update, redesign, migration or new plugin, because those are the moments drift is most likely to begin and the easiest times to trace it.
7. How do I stop two plugins fighting over my schema?
Decide which one should own each type, then switch the type off in the other. Most SEO plugins, review apps and schema plugins let you disable specific types, and some let you disable their markup entirely. If a plugin offers no switch, a small code filter or a theme setting may remove its output. Once one source owns each type, record that in your baseline so a later update that turns the other back on is spotted quickly.
The Schema Drift Detector snapshots your schema regularly and reports changes: types added or removed, properties dropped, validation errors that newly appear and shifts in rich result coverage in Search Console.
Run the Schema Drift Detector →