Guides · Structured data

Schema Validation Errors: What Each Validator Message Means

Last verified: October 2026 · About 9 minutes of reading

A validator gives you one sentence and a line number. This guide maps the sentences you will actually see to the mistake behind them, starting with the ones that are not really errors at all.

Why valid JSON can still fail validation

Three different checks share one output box: JSON syntax, schema.org vocabulary, and Google's requirements for a specific feature.

Only the first is about whether your code parses. A block can be perfect JSON and still be rejected because a property does not exist, a value has the wrong type, or a field that Google requires for that feature is absent. The message rarely says which layer you are in, so the first job is to identify it.

A syntax failure is the expensive one. Google's Unparsable structured data report warns that fixing a parse error can reveal further errors that were hidden while the block could not be read, so one clean test is not always the end of the job.

The error messages you will actually see

Nine messages cover the common cases; each names the property at fault, and the fix is usually local.

Three parse messages are worth memorising: Parsing error: Missing ',' or '}', Parsing error: Missing '}' or object member name, and Invalid JSON document. In practice they mean a trailing comma, an unescaped quotation mark inside a string, or two objects placed side by side without an array or an @graph wrapper. Smart quotes pasted from a document editor produce the same family of errors and are almost invisible in a code editor.

The two validators disagree — here is why

The Schema Markup Validator checks the whole vocabulary; Google's Rich Results Test checks only features Google may display.

They are not two opinions about one question. The Schema Markup Validator at validator.schema.org confirms that the markup is well formed and uses real schema.org terms, and it has no view on whether Google will do anything with it. The Rich Results Test at search.google.com/test/rich-results checks eligibility for a specific Google feature, applies Google's own extra requirements, and renders JavaScript before reading the page. It also only knows the types Google supports.

So "no items detected" is not a failure. It means the type on the page has no Google feature attached. The reverse also happens: a page can be ineligible in the Rich Results Test while the validator reports nothing at all, because the missing piece is a Google requirement rather than a schema.org rule.

Missing required properties

Required is defined per feature by Google, not by schema.org, so the same property can be optional on one type and mandatory on another.

Google's message names the property and, since March 2022, its parent: Missing field "name" (in "author") tells you the author object exists but has no name. That context matters because a bare Missing field "name" could point at the page, the author or the publisher. An empty string counts as missing, which is why a template that renders "name": "" fails exactly like one that omits the key.

The fix is not always "add the field". If the property describes something the page does not show, the honest fix is to remove the object or change the type. Marking up a value that a reader cannot see is a guidelines problem, not a formatting one.

Date, URL and value formatting

Dates must be ISO 8601, URLs absolute, and numbers free of symbols; each of the three has its own message and its own fix.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A title that also appears on the page",
  "datePublished": "2026-10-25",
  "dateModified": "2026-10-25T09:30:00+00:00",
  "author": { "@type": "Person", "name": "Martin Cao", "url": "https://example.com/about" },
  "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/guide" },
  "image": "https://example.com/cover.png"
}

Three details in that block are deliberate. datePublished uses a date without a time, which ISO 8601 permits; dateModified keeps a full timestamp with an offset, so no timezone is assumed. author is an object with a name and a URL, not a string. And mainEntityOfPage uses @id to point at the page rather than repeating its URL as a bare string.

One more: if a time is present without an offset, Google may fall back to the timezone its crawler uses, which is not yours. Add Z or an offset wherever the time matters.

@type typos and @graph nesting mistakes

A mistyped @type produces no error at all; it simply stops matching the feature you were targeting.

Google's error list has no entry for a misspelled type, because nothing failed to parse. The Rich Results Test reports no detected items, and the validator marks the term as undefined. If you expected a feature and see nothing, check the spelling of every @type before you change anything else.

The structural mistake is more common. Two top-level objects in one script tag are not valid JSON:

// Invalid: two objects, no wrapper
{ "@context": "https://schema.org", "@type": "Article", "headline": "A" }
{ "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [] }

Use one object with an @graph array, or two separate script tags. Both are valid; the graph form keeps one @context and lets nodes reference each other by @id.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Article", "@id": "https://example.com/guide#article", "headline": "A" },
    { "@type": "BreadcrumbList", "@id": "https://example.com/guide#crumbs", "itemListElement": [] }
  ]
}

How to use a JSON-LD tester in 30 seconds

Look at the raw source first, then run the same markup through both tools and read which layer failed.

1. Confirm the block ships in the HTML. View source and search for application/ld+json. If it only appears in the inspector, a script injected it and a non-rendering consumer will never see it.
2. Paste the block into the Schema Markup Validator. Fix syntax and vocabulary there first, before reading anything about eligibility.
3. Run the live URL through the Rich Results Test. This is the only check that reflects Google's requirements and JavaScript rendering.
4. Compare with Search Console after deploy. The enhancement reports show the same messages at site scale, and a template error will appear on every page built from it.

One current limit is worth knowing before you chase a warning. Since August 2023, Google shows FAQ rich results only for well-known, authoritative government and health sites. FAQPage markup on any other site remains valid but no longer produces the expandable result, and no validator will tell you that. If you want the basics of the format rather than the error list, they are in the JSON-LD guide.

Frequently asked questions

Four questions cover the cases where the report looks wrong but the markup is fine.

Last verified: October 2026. Messages were checked against Google's published error list on 2026-10-25; Google changes feature requirements without notice, so confirm the type you use in its own documentation.