Validators

Schema Markup Validator

JSON-LD parsed, expanded to real schema.org IRIs, and checked

Structured data fails quietly. A misspelled `@type`, a context that resolves to nothing, a property on an entity that does not define it - the JSON parses, the page renders, and the rich result never appears. Nothing tells you why.

Try:

Free, no signupNo account, no card
No AI in the score986 deterministic rules
Nothing publishedYour scans stay yours
Answers in secondsQuick scan, no browser

Rather than string-matching your markup, this expands it: every term is resolved to its fully-qualified schema.org IRI against its `@context`, and every value normalised to the specification's array form. That is what lets it answer 'is there an Organization here' correctly whether you wrote a bare string, an array, an alias or a custom vocabulary prefix.

120 rules cover the entity types and properties that search engines actually consume, checked against the schema.org vocabulary rather than a hand-copied list. Detection rules - 'this page declares a Recipe' - are reported and deliberately excluded from your score, because a law firm is not defective for not being a recipe.

Why this matters

I added the markup. The rich result never appeared.

You pasted the JSON-LD into your theme, or a plugin generated it for you. The page renders, the browser reports nothing, and weeks later there are still no stars, no FAQ dropdown, no product panel. Structured data has no visible failure state: broken markup and correct markup look identical in a browser, so the only way to find out is to have something read it the way a machine does.

What it costs you when this is wrong

One stray comma, the whole block gone
A trailing comma or an unescaped quote in an address makes that script block fail to parse, and the browser simply ignores it. Your other blocks still work and still validate, so nothing points at the one that died.
Only a browser can see it
Structured data injected after load by a tag manager or a client-side framework does not exist in the raw HTML response. Anything that fetches your URL without executing JavaScript reports the page as having none at all, so you either chase a problem you do not have or ship a fix to the wrong place.
Valid JSON that means nothing
With no resolvable @context, a block still parses cleanly, but only @type survives expansion - name, address, price and everything else are silently dropped. A check that asks 'did this parse' passes it, and the entity you thought you published is empty.

Why run it here

Read from the page a browser renders
In a full scan the markup is taken from the page after JavaScript has run, so structured data injected by a tag manager or a client-side framework is checked like any other. The pre-JavaScript response body is kept separately rather than discarded.
Expanded before any rule reads it
Every block is resolved against its @context before a single rule looks at it, so @type matching survives aliases, custom vocabulary prefixes and @graph wrappers instead of matching raw script text. If a block cannot expand, the rules fall back to what you literally wrote, so broken markup is still checked rather than reported as absent.
Catches blocks that expand to nothing
The validity check counts how many properties survive expansion against how many you actually declared, and fails the block when they all disappear. That is the unresolvable-@context case: syntactically perfect JSON carrying no meaning, which a syntax check reports as fine.

This check runs on its own here, and as part of the full audit alongside the other 985 rules. Either way the findings carry their evidence and their citation, and the report is never published or kept.

How to fix structured data errors

Structured data fails in two distinct ways: markup that does not parse, and markup that parses but describes the page incorrectly. The second is more common and more damaging.

Make sure the JSON-LD parses. A trailing comma or unescaped quote invalidates the entire block, and search engines treat an unparseable block as absent.
Declare an @context of https://schema.org and a valid @type on every entity.
Fill in the required properties for your type — an Article needs headline, author and datePublished; a Product needs name and offers.
Make the markup match the visible page. Marking up a rating or a price that a visitor cannot see is a policy violation and grounds for a manual action.
Use one accurate type rather than several speculative ones. An accurate Article beats Article plus NewsArticle plus BlogPosting.

What happens when you run it

Enter your address
Just the domain is enough — example.com, with or without the https. No account, no card, no crawl of your whole site.
We render it like a visitor
Your page opens in a real browser and JavaScript runs to completion, so what gets audited is the page a person actually sees — not the raw HTML your server sent. A screenshot comes back with the report as evidence of exactly what we measured.
You get findings you can act on
Up to 986 checks run against that rendered page. Each finding names the rule, quotes the evidence found on your page, cites the public specification behind it, and says what to change. Nothing is a judgement call — run it twice on an unchanged page and the score is identical.

What runs this check

JSON-LD expansion
schema.org vocabulary

Named because provenance is the product. Every finding in your report says which of these produced it, so you can check the reasoning rather than take a score on faith.

Questions

Does it check Microdata and RDFa too?: It detects them and reports their presence. The deep validation is JSON-LD, which is what Google recommends and what every current rich-result format is documented in.
Why is a missing Recipe schema not lowering my score?: Because most pages are not recipes. Rules that detect an entity type are informational: they run, they appear in the report, and they never penalise. Only genuine requirements - valid JSON, a resolvable context, required properties on entities you actually declare - affect the number.
Is this the same as Google's Rich Results Test?: No, and they answer different questions. This checks whether your structured data is valid and complete. Rich-result eligibility - whether a given page qualifies for a specific search feature - is a separate question, covered on the Rich Results page.

Also checks

This page answers these searches too — they are the same job, so they share one page rather than being split across near-identical ones:

schema validator
json-ld validator
structured data validator
structured data testing tool

Other checkers

Run the schema markup validator now

No signup, no credit card. Quick answers in seconds; a full audit takes about a minute.

Run a free scan

No signup. No credit card. Nothing stored but the result.

I added the markup. The rich result never appeared.

What it costs you when this is wrong

One stray comma, the whole block gone

A trailing comma or an unescaped quote in an address makes that script block fail to parse, and the browser simply ignores it. Your other blocks still work and still validate, so nothing points at the one that died.

Only a browser can see it

Structured data injected after load by a tag manager or a client-side framework does not exist in the raw HTML response. Anything that fetches your URL without executing JavaScript reports the page as having none at all, so you either chase a problem you do not have or ship a fix to the wrong place.

Valid JSON that means nothing

With no resolvable @context, a block still parses cleanly, but only @type survives expansion - name, address, price and everything else are silently dropped. A check that asks 'did this parse' passes it, and the entity you thought you published is empty.

Why run it here

Read from the page a browser renders

In a full scan the markup is taken from the page after JavaScript has run, so structured data injected by a tag manager or a client-side framework is checked like any other. The pre-JavaScript response body is kept separately rather than discarded.

Expanded before any rule reads it

Every block is resolved against its @context before a single rule looks at it, so @type matching survives aliases, custom vocabulary prefixes and @graph wrappers instead of matching raw script text. If a block cannot expand, the rules fall back to what you literally wrote, so broken markup is still checked rather than reported as absent.

Catches blocks that expand to nothing

The validity check counts how many properties survive expansion against how many you actually declared, and fails the block when they all disappear. That is the unresolvable-@context case: syntactically perfect JSON carrying no meaning, which a syntax check reports as fine.

Questions

Does it check Microdata and RDFa too?

It detects them and reports their presence. The deep validation is JSON-LD, which is what Google recommends and what every current rich-result format is documented in.

Why is a missing Recipe schema not lowering my score?

Because most pages are not recipes. Rules that detect an entity type are informational: they run, they appear in the report, and they never penalise. Only genuine requirements - valid JSON, a resolvable context, required properties on entities you actually declare - affect the number.

Is this the same as Google's Rich Results Test?

No, and they answer different questions. This checks whether your structured data is valid and complete. Rich-result eligibility - whether a given page qualifies for a specific search feature - is a separate question, covered on the Rich Results page.

Schema Markup Validator

I added the markup. The rich result never appeared.

What it costs you when this is wrong

One stray comma, the whole block gone

Only a browser can see it

Valid JSON that means nothing

Why run it here

Read from the page a browser renders

Expanded before any rule reads it

Catches blocks that expand to nothing

How to fix structured data errors

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the schema markup validator now

Schema Markup Validator

I added the markup. The rich result never appeared.

What it costs you when this is wrong

One stray comma, the whole block gone

Only a browser can see it

Valid JSON that means nothing

Why run it here

Read from the page a browser renders

Expanded before any rule reads it

Catches blocks that expand to nothing

How to fix structured data errors

What happens when you run it

Enter your address

We render it like a visitor

You get findings you can act on

What runs this check

Questions

Also checks

Other checkers

Run the schema markup validator now