Schema Markup Mistakes That Still Pass Validation

Key takeaways

A validator checks whether your markup is well formed. It cannot check whether it is true, and untrue markup is the most common serious error.
The rule most sites break: Google structured data guidelines require markup to describe content visible on the page. FAQ schema for answers nobody can read is the classic violation.
We shipped that violation ourselves. Four of our six tool pages declared FAQPage schema for answers that appeared nowhere on the page, until we made the FAQ visible in October 2026.
The second most common error is duplication: the same type emitted twice, once by a template and once by a component, which gives a crawler two competing descriptions of one page.
Marking up the wrong thing is quieter. A LocalBusiness on every page of a site, or an Organization on a blog post, describes the site rather than the page.
Schema does not cause rankings. It helps an engine read the page correctly, which is a precondition for other things working rather than a lever on its own.

Structured data has a validator, which creates the impression that correct markup is a solved problem. The validator checks syntax and says nothing about whether the markup describes reality.

Almost every serious structured data error passes validation. That is what makes this category of mistake persistent: nothing fails, nothing warns, and the markup quietly misrepresents the page.

We include one of our own in the list below, because it was live on four pages and a validator reported no problem with any of them.

What is the most common schema markup mistake?

Short answer: Markup that describes content the page does not contain. Google structured data guidelines require that markup represent content visible to a user, and FAQ schema listing questions and answers that appear nowhere on the page is the most widespread breach of it.

It happens because the markup and the page are generated separately. A template emits an FAQ block from a content record while the rendered page shows something else.

The reason it matters is that it is a policy violation rather than a technical error. Google documentation treats markup that misrepresents a page as a reason to disregard the markup or take manual action.

We had this exact defect. Four of our six free tool pages declared FAQPage schema for answers that were not rendered anywhere on the page, which we fixed in October 2026 by making the FAQ visible and generating the schema from it.

A validator had reported all four as valid.

Why does duplicate markup matter?

Short answer: Because it gives a crawler two competing descriptions of the same page. The usual cause is a template emitting a type while a component emits it again, so the page declares two Articles or two Organizations with slightly different values.

This happens most often on sites that added structured data twice, in different years, through different mechanisms. Nobody removed the first implementation because nobody knew it was there.

The symptom is hard to spot by reading the page source, because the two blocks are usually far apart in the document. Checking with a browser console query for every script of type application/ld+json is faster.

Our own site injects page-level markup from an edge function, and the React components check for it and skip their own rather than emitting a second copy. That guard exists because the first version did emit everything twice.

What does marking up the wrong thing look like?

Short answer: Markup that describes the site rather than the individual page. A LocalBusiness block on every URL including blog posts, or an Organization on an article where an Article type plainly belongs, tells an engine the wrong thing about that specific page.

LocalBusiness everywhere. It belongs on pages about the business location, not on a blog post about a technical topic.
Product on a category page. A category lists products; it is not one. This one generates genuine errors as well as wrong meaning.
Review markup for reviews you collected. Self-serving review markup has specific restrictions, and the general rule about visible content applies to it too.
Breadcrumbs that do not match the navigation. Markup describing a hierarchy the page does not show is the visible-content rule again.
Every available property filled in. Schema.org defines far more properties than any engine consumes, and filling them all adds weight rather than meaning.

The last item is the mistake that comes from enthusiasm rather than carelessness. The vocabulary is large and most of it is not read by anyone.

Does schema markup improve rankings?

Short answer: Not directly. It helps an engine understand what a page is, which can qualify the page for particular result presentations, but Google documentation is clear that structured data is not a ranking factor in the way content and links are.

The honest framing is that schema is plumbing. It belongs in the same category as crawlability and rendering: required for other things to work, insufficient on its own.

This matters commercially because schema is frequently sold as a lever. An agency proposing structured data as a primary growth initiative is proposing a hygiene task as a strategy.

Where it does earn its keep is in presentation and in machine readability. Both are real benefits and neither is a ranking improvement.

How should you check your own markup?

Short answer: Three checks a validator will not do for you: confirm every marked-up claim appears on the rendered page, count how many blocks of each type the page emits, and confirm the type actually describes this page rather than the site.

View the rendered page and find each marked-up question, answer, price and rating in the visible text. Anything you cannot find is a policy problem.
Count the blocks. One of each type per page, except where nesting is intended. Two Articles is a defect.
Ask what this page is, in one word, and check the primary type matches. A blog post is an Article; it is not an Organization.
Then run the validator, to catch syntax. It is the last check rather than the first.
Then watch Search Console enhancement reports, which will show you what Google actually parsed rather than what you intended.

Step five is the only one that tells you what Google did with your markup rather than what it thinks of your syntax. It is also free and routinely ignored.

Frequently asked questions

Will a validator catch my schema errors?

It catches syntax errors and missing required properties. It cannot tell whether the markup is true, which means the most serious category of error, markup describing content that is not on the page, passes validation cleanly.

Can I use FAQ schema if the answers are in an accordion?

Yes. Content inside a collapsed accordion is still in the page and still visible to a user who expands it, which satisfies the visible-content requirement. Content that exists only in the markup does not.

How many schema types should one page have?

As many as genuinely describe it, which is usually one primary type plus breadcrumbs, and sometimes a nested FAQ. More than that is normally a sign that two implementations are both running.

Does JSON-LD or microdata matter?

JSON-LD is what Google recommends and it is easier to maintain because it sits apart from the markup. Microdata works and couples your structured data to your HTML, which is how it drifts out of step with the page.

Should I mark up every page?

Mark up pages where a type genuinely describes the content. A page with no natural type is better left alone than given a loose one, because loose markup is wrong markup and wrong markup is a policy risk.

Sources and further reading

Generate it, then check it against the page

Our schema generator will produce valid markup for free. The three checks above are what a validator will not do for you, and they are the ones that catch the errors that actually matter.