Schema Markup Validator: How to Read the Results

The Schema Markup Validator is the free tool at validator.schema.org that checks whether your structured data is valid schema.org: it parses JSON-LD, Microdata and RDFa from a URL or pasted code, lists every item it extracted, and flags syntax and vocabulary problems. It does not check Google’s rich result rules; that is the job of the Rich Results Test. Knowing which question each tool answers is most of the skill.

This guide is for marketers and developers who already have markup on a site and want to know whether it says what they think it says. It covers where the tool came from, how to run a test, how to read the output, and what a clean result still doesn’t prove.

On this page

• What the Schema Markup Validator checks
• Schema Markup Validator vs Rich Results Test: which one do you need?
• How to run a test
• How to read the results panel
• What do errors and warnings mean?
• Checking a JSON-LD graph with @id
• What a clean result does not prove
• Making the schema markup validator part of every release

What the Schema Markup Validator checks

The validator checks one thing well: whether your markup is well-formed and uses schema.org types and properties in ways the vocabulary expects. According to schema.org’s own description of the service, it processes JSON-LD 1.0, RDFa 1.1 and Microdata, retrieves pages by URL or accepts markup directly, handles data injected by JavaScript widgets, and displays a summary of the extracted structured data graph along with syntax errors. JSON-LD is the format you will check most often: the HTTP Archive’s 2024 Web Almanac found it on 41% of pages, up from 34% in 2022.

It also has a documented blind spot. For JSON-LD it does not fetch or interpret any @context URL other than schema.org’s. If your markup mixes in a custom vocabulary, the validator won’t expand it.

The tool has a longer history than most people realize. The diagram below shows how Google’s original testing tool became a schema.org service.

Scroll the diagram sideways to see all of it.

Google’s December 2020 announcement said the refocused tool’s main purpose would be to “check syntax and compliance of markup with schema.org standards”, and that it would no longer check for Google Search rich result types. Schema.org’s launch post adds that the validator is powered by Google’s general structured data infrastructure and is provided to the project as a Google-hosted tool. The vocabulary it checks against is everywhere: schema.org says that as of 2024, over 45 million web domains mark up their pages with over 450 billion schema.org objects.

Schema Markup Validator vs Rich Results Test: which one do you need?

You usually need both, in a set order. Google’s structured data testing page recommends starting with the Rich Results Test to see which Google rich results a page can generate, and using the Schema Markup Validator “for generic schema validation” of any schema.org type without Google-specific checks. The Rich Results Test is worth the minute it takes when a rich result is on the table. In the case studies on Google’s introduction to structured data, Rotten Tomatoes measured a 25% higher click-through rate on pages with structured data, and Nestlé an 82% higher click-through rate on pages shown as rich results.

The practical rule: if the type you’re marking up appears in Google’s rich result gallery, run the Rich Results Test first. For everything else, the validator is the only official check you have. That includes most of the entity markup covered in structured data for AI search. Service markup is a common example: it produces no Google rich result, so the Rich Results Test returns nothing useful for it, as the Service schema guide explains.

How to run a test

Running a test takes under a minute. The choice that matters is URL or code.

1. Open validator.schema.org.
2. Choose Fetch URL to test a live page, or Code snippet to paste markup.
3. Run the test and wait for the panel on the right to fill.

Use URL mode for anything that ships. It tests what the server and browser actually produce, including markup injected by JavaScript. Pasting code is for drafts: it skips your templates, your CMS plugins and your scripts, so it can pass markup that never reaches the live page. If your schema is built client-side, read how JavaScript rendering affects AI crawlers as well. Google can render it, but many AI crawlers read only the initial HTML.

How to read the results panel

The results panel opens with a Detected summary (total errors, warnings and items), then one row per top-level type with its own counts. A separate Uncategorized Errors row collects problems that stopped a block from parsing at all. Click a type to expand it into a tree of properties and nested items, with each problem marked on the line where it occurs.

Read it in this order:

• Count the items. Three Organization items on one page usually means a theme, a plugin and a hand-written block are all describing your company. Pick one source and remove the others.
• Check the types. The validator won’t flag a deprecated type for you. When we tested a ProfessionalService item on September 22, 2026, it came back with zero errors and zero warnings, even though schema.org’s definition of ProfessionalService says the type was deprecated because it was confused with Service. You have to catch that by eye.
• Open the nested items. An author that shows as plain text rather than a Person item tells you the markup gives a name, not an entity. The validator also applies heuristics: in our test, a location given as plain text was shown as a Place with that text as its name.
• Read the values. The validator shows what it parsed, so a wrong phone number or an outdated price is visible here even when nothing is flagged.

What do errors and warnings mean?

An error means the validator couldn’t parse something or couldn’t accept a value. A warning means the markup parses but uses the vocabulary in an unusual combination. Fix every error. Read every warning and decide.

We ran five deliberate mistakes through the validator on September 22, 2026 to see how each is classified. The diagram below shows what came back.

Scroll the diagram sideways to see all of it.

Three patterns fall out of that test:

• Syntax errors are fatal to the whole block. A stray trailing comma put the block under Uncategorized Errors, and the Product inside it wasn’t detected at all. One typo can hide every item in a script.
• Unknown words are errors; misplaced words are warnings. A property that exists nowhere in schema.org is an error. A real property used on a type that doesn’t expect it is only a warning, which is easy to ignore and usually a sign you nested something in the wrong place.
• Bad values are errors. Dates in plain English and enumeration values without their proper names fail. The eventStatus error even lists the accepted values.

What the validator won’t tell you matters as much. It doesn’t know Google’s required properties, so a Product without an offers, review or aggregateRating can pass cleanly here and still be ineligible for a product snippet.

Checking a JSON-LD graph with @id

The validator is the best free way to check that the pieces of a JSON-LD graph point at each other correctly. In JSON-LD, @id gives a node a stable identifier, and any other node that references that identifier is talking about the same thing. The JSON-LD 1.1 specification defines @id as the keyword “used to uniquely identify node objects”.

The diagram below shows the pattern to look for: three scripts on one page, all resolving to one organization.

Scroll the diagram sideways to see all of it.

The validator follows these references. In our test, a WebSite whose publisher pointed at https://example.com/#org was displayed with the organization’s name nested inside it, pulled from the node declared elsewhere in the graph. So when you expand the WebSite and BlogPosting items, check that each publisher shows the organization’s details, not a bare @id. If one says https://example.com/#org and another says https://www.example.com/#organization, you’ve described two organizations, and one of them has no name, logo or sameAs. Our guide to Organization schema for AI search covers the stable @id pattern in full, and the JSON-LD guide explains nesting versus referencing.

What a clean result does not prove

A result with zero errors and zero warnings proves your markup parses and uses real schema.org terms. It proves nothing about whether the content is true, visible or eligible.

Three gaps are worth naming:

• Visibility. Google’s general structured data guidelines say not to mark up content that isn’t visible to readers of the page. The validator can’t see your rendered page the way a reader does, so it can’t check this.
• Accuracy. A wrong phone number, an old address or a rating you made up all validate perfectly. Structured data that contradicts the page can lead to a manual action, which removes rich result eligibility.
• Eligibility. Google says plainly that it does not guarantee your structured data will show up in search results, even when it is marked up correctly according to the Rich Results Test. The validator makes an even smaller promise.

AI search has the same limit. No AI assistant publishes how it weighs schema, so a clean validator result is a hygiene check, not a visibility guarantee. It removes one reason for an engine to misread you. It doesn’t add a reason to cite you.

Making the schema markup validator part of every release

The validator earns its keep when you run it on a schedule, not once. Templates change, plugins update and a redesign can drop a script tag without anyone noticing.

A routine that works:

1. Keep a short URL list of one page per template: home, a service page, a blog post, a product, a location.
2. Run each URL through the validator after every deploy and note the item count per type. A change in count is the fastest signal something moved.
3. Run the same URLs through the Rich Results Test for the types Google supports, and fix critical issues first.
4. Spot-check values against the visible page once a month, especially prices, hours, dates and authors.

If you use a schema markup generator to draft markup, run its output through the validator in URL mode after it’s live, not just in the generator’s preview. Add the whole routine to your technical SEO checklist for AI search so it survives staff changes.

If your graph has grown past what a spot-check can cover, or you’re not sure which of three Organization blocks is the real one, our schema markup service audits the rendered output page by page and rebuilds it as one connected graph.