Structured data: markup errors live in templates, not pages

Why one broken component costs four hundred pages their rich results, and how to validate schema.org across a whole site in one pass.

SEO · Published: 26 August 2026 · 3 min read · Дмитрий Орлов

Structured data is the one part of SEO where a machine tells you plainly whether you got it right. Either the page qualifies for a rich result or it does not, and the reason is always specific: a missing property, a wrong type, a price without a currency.

What it buys you

Rich results are not a ranking boost. They are screen real estate: a review row, a price, a stock status, an FAQ accordion, a recipe time. On a crowded results page that is the difference between one line and four.

The types that repay the effort on most sites:

• Product — price, availability, and reviews if you actually have them.
• BreadcrumbList — replaces the raw URL in the snippet with a readable path.
• Article — headline, date, author; the entry ticket to news surfaces.
• Organization — logo, social profiles, contact points; feeds knowledge panels.
• FAQPage — only where a real question and answer exist on the page.

The errors that recur

Markup describing something the page does not show. A price in JSON-LD that the visitor never sees is the fastest way to lose the rich result entirely.

Wrong nesting. offers outside Product, author as a string instead of a Person. Valid JSON, invalid schema.

Dates in the wrong format. datePublished must be ISO 8601. "12 March 2026" is not.

Copy-pasted IDs. Every product carrying @id: "product-1" because the template hard-codes it.

One fix, four hundred pages

Here is the part teams miss: structured data is emitted by a template, so an error is never on one page — it is on every page that renders that component. That cuts both ways. A report that lists two thousand invalid pages is really listing three broken components, and fixing three components turns two thousand pages green in one deploy.

So group findings by template before you plan the work:

findings
  .groupBy(f => f.template ?? inferTemplate(f.url))
  .sortBy(group => -group.pages)

Fix the group with the most pages first. The list collapses fast.

Validate in the pipeline, not by hand

Testing tools check one URL at a time, which is fine for a spot check and useless as a guarantee. What you want on every release is a crawl that parses every application/ld+json block, validates it against the type, and fails the build on new errors. That way markup breaks in review, not in the search results a week later.

A note on AI answers

Assistants that summarise pages lean on the same explicit markup, for the same reason search engines do: it removes guesswork about what a number on the page means. Clean structured data is no longer only about the blue links — it is about being quotable.