A page starts with one block of structured data. Then someone adds an FAQ block, then a How-To block, then breadcrumbs, then an Organization block that repeats what the site-wide one already says. Nobody removes anything, because removing markup feels like removing an advantage.
The question that never gets asked is what any of it is supposed to produce. Volume is not the risk on its own — contradiction is, and volume is how contradiction arrives.
Is there a limit on how many schema types one page can declare?
Google publishes no numeric cap, and there is no threshold at which a page is penalised for having too many types. The limits that exist are practical: every claim must match the page, only some types can produce anything visible, and all of it has to stay true as the page changes.
That means the honest answer to "how much is too much" is "more than you can keep accurate", which is a different number for every team. A page with three blocks generated from the same database as the visible content is in better shape than a page with one block a developer hand-wrote in 2023 and nobody has looked at since.
What actually breaks when a page has too much markup?
Contradiction between blocks. A single page that declares two different prices, two different ratings or two different entity names is not giving a search engine more information — it is giving it a reason to trust none of it.
The usual causes are dull and repeatable:
- A plugin adds schema markup while the theme adds its own, so both fire on the same template.
- A category page carries a full product schema block for every item plus a summary block describing the collection.
- Organization details are repeated on every page and drift out of sync with the version in the site footer.
- A review schema aggregate is left in place after the review widget it described was removed.
The fourth one is the most damaging, because it is markup describing content that is no longer on the page. That is not a volume problem dressed as an accuracy problem — it is straightforwardly a page making a claim its own HTML disproves.
Structured data is a set of claims about the page, and claims can conflict. The cost of an extra block is not weight or crawl budget — it is the chance that it disagrees with a block already there, and the odds of that rise with every block nobody owns.
Which markup earns its place on a page?
Markup earns its place when it either produces something in the results or describes an entity you want understood. Everything else is inert, and inert markup still has to be maintained.
| Question to ask | Keep it | Cut it |
|---|---|---|
| Does it map to visible page content? | Yes, exactly | No, or only partly |
| Is it generated from the same source as that content? | Yes | Hand-written and static |
| Does it describe this page or the whole site? | This page | Repeated site-wide detail |
| Would anyone notice if it were wrong? | Yes, it is checked | No, nobody owns it |
| Does another block on the page already say it? | No | Yes, duplicated |
Note that "does it produce a rich result" is deliberately not the first row. Eligibility changes over time and is documented by Google rather than inferred, so a rule built on today's list of supported types ages badly. Accuracy and ownership do not age.
Does extra structured data slow the page down?
Rarely enough to matter, with one exception. A few kilobytes of JSON-LD is trivial next to the images and scripts on a typical page, and it does not block rendering, so it has almost no bearing on Core Web Vitals.
The exception is a listing template that emits a complete markup block for every item on the page. Forty products with full descriptions and offer details can add tens of kilobytes to every category page on the site, repeated for every paginated variant. That is worth measuring rather than assuming, and the fix is to describe the list rather than restate every item in it.
How do you consolidate instead of deleting?
Declare each entity once and reference it, rather than repeating it. Nesting related types inside a single graph lets a page describe an article, its author and the organization behind it without three independent blocks that can each drift.
Practically, that means one block per page containing the connected types, with identifiers used to point at entities defined elsewhere rather than re-declaring them. It also makes the audit tractable: one place to look when something is wrong, instead of hunting through a template, a plugin and a hard-coded snippet in the footer.
Marking up content that is not visible to a visitor — a rating, an FAQ or a price that exists only in the markup. It is the one structured data error that can cost a site eligibility rather than simply doing nothing.
What is the test for markup worth keeping?
Change something on the page and see whether the markup changes with it. Update a price, edit a heading, remove a review, and check the JSON-LD. Markup that updated itself is an asset; markup that did not is a statement that will eventually be false.
Run that test on your highest-traffic template rather than on a page you already suspect. The blocks that survive it are the ones to invest in, and every block that fails is a decision waiting to be made: wire it to the real data, or take it out.
Not sure which of your markup is doing anything?
We will audit what your pages declare, what contradicts what, and which blocks can be removed without losing a thing.
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.