What a schema markup error actually means

Error, warning and recommended: who decides each

A finding means nothing until you know which authority it comes from — and there are only four, in descending order of how much they can cost you.

Google’s documentation is the only basis that can affect a search feature, because only Google decides what Google shows. When its page for a type lists a property as required, leaving it out has a stated consequence.

schema.org is the shared vocabulary. It says a price is a number and a date is a date. Breaking that does not make you ineligible for anything at Google, but it does mean a machine reading your page gets a value it cannot use.

Mechanical findings are facts about the file rather than anybody’s rule: the JSON did not parse, or a question in your FAQ markup has no answer text anywhere on the page. There is no authority to appeal to, which is what makes these the ones to fix first.

House preference is the tool’s own taste. Ours are labelled as ours. A tool that dresses its preferences as errors is training you to ignore its errors.

Why a clean check is not a promise of anything

Valid markup is a precondition for a rich result, never a cause of one.

Google’s structured data policies put the negative case plainly: items missing required properties are not eligible for rich results. Eligibility is not the same as appearance. Google decides what to show per query, and it has removed whole result types from sites whose markup never changed — which is exactly what happened to FAQ snippets.

So the honest reading of a clean result is narrow and still worth having: nothing in this file is stopping you. Any tool that converts that into a forecast of traffic is selling you a feeling.

Which types actually have required properties

Fewer than most people expect, and the two most commonly marked-up types have none at all.

Checked against Google’s own documentation on 2026-10-19:

This is why a checker that reports “missing required property” on an Article or an Organization block is telling you about its own preferences. There is no Google list behind it to be missing from.

The block that did not parse

This is the only finding that is unambiguously fatal, and it is usually a comma.

If the JSON in a <script type=”application/ld+json”> block does not parse, nothing in it exists as far as any consumer is concerned. Not partially — entirely. A trailing comma after the last property, a smart quote pasted from a word processor, an unescaped quotation mark inside a description: each one voids the whole block while the page looks perfectly normal to you.

It is also the finding least likely to be your fault in an obvious way, because content management systems and page builders routinely inject their own markup alongside yours.

A missing required property

Read the basis before you read the property.

Where the basis is Google’s documentation and the type is one that has required properties, the consequence is stated: the item is not eligible for that rich result. That is worth fixing the same day, and the fix is usually a field somebody left blank rather than anything structural.

Where the basis is schema.org or the tool’s own list, “required” is doing different work: it means the node carries nothing useful to read. An Organization with only a name is valid and almost pointless. Nothing is blocked; nothing is gained either.

A value of the wrong shape

A date written as “last Tuesday” is not a date.

schema.org gives each property an expected type: a number, a date in ISO 8601, a URL, a nested node. Prices arrive as “$49.00” when a number is expected; dates arrive in local formats; a URL arrives as the word “website”. The markup still parses, so many tools stay silent.

It matters because the whole point of structured data is that a machine does not have to guess. A value of the wrong shape puts the guessing back.

Two blocks saying the same thing

Duplicate nodes of one type are usually a plugin and a theme both doing you a favour.

An SEO plugin emits an Organization block; a theme emits another; someone pastes a third from a generator. They disagree about the logo, or the name, or the social profiles. Nothing is invalid, and a consumer now has to pick which version of you is true.

Our checker reports this as a warning on a house basis, because no published rule forbids it — but it is worth resolving, and the resolution is nearly always “delete two of them”.

Why recommended properties sit in their own list

Because mixing them into an error count makes the count meaningless.

Google’s policies say the more recommended properties you provide, the higher the quality of the result — a genuine reason to add them, and not a failure if you do not. A tool that adds them to a red number produces a page that can never reach zero, and a score you learn to ignore.

In our checker they appear per node, each labelled with who recommends it, and never counted as errors.

FAQ markup, after Google removed the documentation

FAQ rich results are gone for almost every site, and your FAQ markup can still be worth keeping.

Google announced the removal of the FAQ rich result in 2026; today the old documentation URL redirects to that announcement rather than to a property list (checked 2026-10-19). There is now no Google list for a checker to measure your FAQPage against, so any tool reporting “missing required property” there is inventing the rule.

What can still be checked is mechanical and still useful: that each mainEntity entry is typed as a Question, that each carries an acceptedAnswer, and that the answer text actually exists on the page rather than only in the markup. That last one is the common defect, and it matters beyond Google: assistants quote what they can corroborate on the page.

Where the markup on your page came from

On most sites, nobody wrote it on purpose and nobody owns it.

A typical page carries blocks from three or four places at once. The SEO plugin emits Organization and WebSite markup from its settings. The theme emits Article or BreadcrumbList from its templates. A page builder adds its own. Somebody once pasted a block from a generator into a custom HTML widget and forgot. Each is invisible in the editor, and together they are what a checker reports on.

That matters for how you read the results. An error on a property you have never heard of is usually a plugin default, not something you typed. Before editing anything by hand, find out which component emits the block — the fix is nearly always a settings field or switching one emitter off, and a block you hand-edit today is a block the plugin rewrites on its next update.

The quickest way to see what is actually on the page is to look at the served HTML rather than the editor: every application/ld+json block, in the order a consumer meets them. That is also where you discover you have three Organization blocks disagreeing about your logo.

How much time each class is worth

Spend the afternoon on the first two rows of this table and ignore the rest until they are done.

The ordering is not about effort. It is about whether anybody has published a consequence for ignoring it — which, for most of the rows a checker shows you in red, nobody has.

What no validator can tell you

Three things, and a tool that implies otherwise is overselling.

• Whether you will get a rich result. Only Google’s own Rich Results Test speaks for Google’s rendering, and even it reports eligibility, not appearance.
• What markup your page has after JavaScript runs. A checker reading the served HTML sees what a non-rendering crawler sees. If a script injects your schema later, it is absent here — the render check shows that split directly.
• Whether the content is true. Markup claiming a five-star rating on a page with no reviews is perfectly valid, and it is the kind of thing that earns a manual action rather than a star.

Fixing them in order

Work down the bases, not down the list.

1. Blocks that do not parse. Everything else is theoretical until this is clear.
2. Google-documented required properties, on types that actually have them — LocalBusiness and Product before anything else.
3. Mechanical mismatches, such as an FAQ answer that exists only in the markup.
4. Wrong-shaped values, cheapest of all to fix and the most ignored.
5. Duplicates, by deleting rather than reconciling.
6. Recommended properties, when there is nothing above them left.

Generators keep most of this from arising: the LocalBusiness and Product generators ask for the properties Google lists, and nothing they write is invented.

FAQs