A site audit turns up eleven types of structured data across the templates. Some of it was added by a plugin, some by an agency three years ago, and some by a developer who is no longer there. Two types throw warnings. The instinct is to fix the warnings.
The better first question is whether those types should be on the site at all. Markup is not free once it ships — it is a set of machine-readable claims that somebody has to keep true.
Why would you delete markup that mostly works?
Because schema markup asserts facts, and an assertion nobody maintains becomes false on its own schedule. A price, a rating, an availability status, an event date: each of those decays without anyone touching it.
The asymmetry matters. Correct markup on a page that earns no enhanced result gives you very little. Incorrect markup on the same page gives you a claim that contradicts your own page, in a format built to be parsed literally. The upside is capped and the downside is not.
Which markup earns nothing and still costs upkeep?
Types that describe your page accurately but have no corresponding treatment in search results for pages like yours. They are the bulk of what accumulates.
| Situation | Verdict | Reasoning |
|---|---|---|
| Drives a result you can see in Search Console | Keep and fix | Measurable return justifies the upkeep |
| Generated automatically from live page data | Keep | Cannot drift, because there is one source |
| Hand-written values duplicating visible content | Fix or remove | Two copies of one fact will disagree eventually |
| No enhancement, no impressions, still maintained | Remove | Pure cost |
| Contradicts what the page shows | Remove today | A policy problem, not a formatting one |
| Describes a page or entity that no longer exists | Remove | Stale claims about deleted things |
The second row is the one to design toward. Markup built from the same data the page renders cannot fall out of step with the page, because there is nothing for it to fall out of step with.
Structured data is a maintenance contract, not a tag. Before adding a type, name the person who will notice when it becomes untrue. If there is no answer, the honest options are to generate it from live data or not to ship it.
What is the risk of markup that disagrees with the page?
Google's structured data guidelines require markup to represent content visible to the user, and markup that misrepresents the page is grounds for a manual action against the site's rich result eligibility.
That risk is rarely deliberate. It arrives through drift: a template ships a hard-coded rating, a price is updated in the CMS but not the JSON-LD block, a product goes out of stock while the markup still says in stock. Nobody decided to misrepresent anything, and the outcome is the same. If you cannot keep product schema synchronized with the catalog, removing it is a defensible engineering decision rather than a retreat.
Review markup is where this bites hardest
Google does not show review snippets for reviews a business writes about itself, so self-serving review schema on your own service pages earns nothing while carrying the highest accuracy burden on the site.
Two failure modes recur. The first is an aggregate rating hard-coded when the page was built, still reading 4.9 from 127 reviews years later, with no system anywhere that could update it. The second is markup covering reviews that are not visible on the page at all, which fails the visible-content requirement outright. Both are safer deleted than patched.
Treating a validator's green tick as proof the markup is right. Validators check syntax and required properties. They cannot tell that your rating is three years stale or that the review it describes was never published on the page.
How do you remove it safely?
One type at a time, with a before-and-after measurement, so that a drop in organic search performance can be attributed to something specific rather than argued about.
- Inventory what is on each template, not each page — the duplication lives in templates.
- Check the enhancement reports in Search Console for impressions and clicks tied to each type. A type with no enhanced results has nothing to lose.
- Remove one type, deploy, and note the date somewhere the next person will find it.
- Watch four to six weeks of clicks and impressions for the affected templates before removing the next one.
Removal is a template edit, not a redirect or a content change, so it is quick to reverse. That reversibility is what makes sequential removal the sensible approach — you are running cheap experiments, not making an irreversible cut.
What should survive the cut?
Types that identify what a page is and who published it tend to keep earning without much upkeep, because they describe things that change rarely. Article and breadcrumb markup on editorial pages, organization details on a site that has not moved offices, and anything generated from the same fields the page renders.
The types worth scrutinizing are the ones making quantitative claims — ratings, prices, counts, dates, stock levels. Those are the numbers that go stale, and they are also the ones a machine reads most literally.
Open your Search Console enhancement reports and list every markup type that has produced zero enhanced impressions in the last quarter. That list is your removal queue, and working through it makes the markup that remains easier to trust.
Inherited a pile of schema nobody can explain?
We will audit what your markup claims, what it earns you, and what it quietly puts at risk — then cut it back to the parts that pay.
Get in Touch →Does this apply to your site?
Reading about it is one thing. Point the scan at your own site and see whether this applies to you, and what it is worth fixing.
Free and unlimited. No account, no card, and you get every finding rather than a teaser.