Skip to content

Free Schema Markup Checker

Paste a page URL and get per-rung verdicts on its JSON-LD, judged the way the schema audit playbook walks it: is the markup delivered to non-rendering crawlers, does it parse, does the entity graph join, and does the page agree with what the markup asserts. Every negative verdict quotes its evidence. There is no 0–100 score, and that is the point.

Free, no account needed — 8 checks a day. Sign in for 25. Sign in with Google

One fetch of the raw HTML, no JavaScript executed — this is the response body a non-rendering AI crawler receives, which is the delivery question devtools cannot answer. The two Google validators check vocabulary and feature eligibility; this tool checks the rungs they cannot see: delivery, graph integrity, and the machine-checkable slice of truth.

The four rungs

How to read the verdicts

  • The rung holds for what the machine can measure.
  • ⚠️ Something needs your judgment or your hand — the finding says which.
  • A failure shape was found — the evidence is quoted next to it.
  • N/A Nothing of this kind on the page to judge. That is not a failure.

1 · Delivery

Does a non-rendering crawler receive the markup at all?

How this is measured

Measured: JSON-LD blocks present in the raw response body — the exact bytes GPTBot or ClaudeBot receives, no JavaScript executed. Markup that only exists in the rendered DOM is delivered to nobody that matters here. Microdata and RDFa are noted but not audited. the playbook section · how to fix it

2 · Validity

Does every block parse, in the schema.org vocabulary?

How this is measured

Measured: JSON syntax per block and the @context declaration. A block that fails here is discarded by parsers but still read as page text by live-fetch models — which is why broken blocks are quoted, not just counted. Full vocabulary conformance stays with the Schema Markup Validator. the playbook section · how to fix it

3 · Integrity

Does the entity graph join?

How this is measured

Measured: @id uniqueness, references that resolve within the page, duplicate entity nodes, and the Organization/Person entity spine. Every one of these is green in every validator ever written — a graph that quietly merges or splits entities errors nowhere. the playbook section · how to fix it

4 · Truth

Do the page and the outside world agree with what the markup asserts?

How this is measured

Measured: the machine-checkable slice — asserted headline vs the visible H1, author shape and visibility, date sanity, and one liveness probe per sameAs/logo target (up to 10). Liveness is not identity, and the full parity read stays human — see the row below. the playbook section · how to fix it

The manual parity read

Human judgment

Is every fact the markup asserts visible on the page — prices, ratings, addresses, descriptions?

Not machine-judged, ever. This is the one check with a documented penalty behind it, and no tool runs it: put the emitted block beside the rendered page and confirm every asserted fact is visible. Two minutes per template. When a block cannot be made to agree with the page, remove the block, never the fact. the playbook section

Why there is no score

The schema audit playbook closes its severity section with the rule this tool obeys: do not compress findings into a score. A composite 0–100 grade with an unpublished formula is a rumour rather than a measurement — the same provenance discipline the citability checker applies to citability scores.

What ships instead is the playbook's actual deliverable: per-finding verdicts with the evidence quoted — the @id defined as two different things, the sameAs target that answers 404, the date asserted in the future. Every verdict can be re-checked against your own page in seconds.

How the check works

  1. Fetch the page once, raw HTML only, no JavaScript executed — deliberately: it is the response body non-rendering AI crawlers ingest. Every JSON-LD script block in it is collected.
  2. Parse each block and check its @context. Unparsable blocks are quoted rather than just counted, because live-fetch models read them as page text even after parsers discard them.
  3. Read the graph: @id values defined twice as different things, references that resolve to nothing on the page, entities defined more than once, and whether an Organization or Person spine exists at all.
  4. Check the assertions a machine can check — headline against the visible title, author shape and visibility, date sanity — and probe each sameAs and logo URL once for liveness, up to ten targets.
  5. Report four-state verdicts per rung — ✅ / ⚠️ / ❌ / N/A — quoting the exact evidence behind every negative one.

What this check can and cannot judge

Frequently asked questions

Why does this tool refuse to give a 0–100 schema score?
Because the schema audit playbook it operationalizes forbids exactly that: per-finding severity is the deliverable, and a composite grade with an unpublished formula is a rumour rather than a measurement. Two tools compute such scores differently and neither can be checked. Every verdict here quotes its evidence, so you can verify each one against your own page — a number would add nothing but false authority.
The Schema Markup Validator says my page is fine. Why does this tool still find problems?
Because validators check vocabulary conformance, which is rung 2 of a four-rung ladder. An @id defined as two different things, a reference that resolves nowhere, an author no external source can corroborate, a sameAs target that has been dead for a year — all of these are green in every validator ever written, because none of them is a vocabulary error. The audit playbook's rule of thumb: rungs 3 and 4 are exactly the findings your validator cannot show you.
My markup shows up in devtools, but this tool says there is none. Which is right?
Both — and that is the finding. Devtools shows the rendered DOM, after JavaScript ran. This tool reads the raw response body, which is what GPTBot, ClaudeBot and PerplexityBot receive, since none of them is observed to execute JavaScript. Markup injected by a tag manager or client-side framework exists in the first and not the second: it is shipped, and delivered to nobody. The fix is emitting it server-side.
Is broken JSON-LD harmless, since parsers just ignore it?
No — and this is the audit's most counterintuitive point. The parser discards an invalid block, so nothing good happens. But live-fetch models reading your page (ChatGPT with browsing, Perplexity) ingest the block as more text on the page. Mark Williams-Cook demonstrated this by publishing a fictional company whose address existed only inside deliberately broken JSON-LD — ChatGPT and Perplexity returned the address anyway. Whatever a broken block asserts is still being served to the consumers that matter.
Should I remove my FAQPage or HowTo markup now that Google dropped rich results for them?
No. Deprecated-but-accurate markup is not a finding: it is still valid Schema.org, carries no penalty, and removing it buys nothing — a deprecation sweep is a large ticket with a payoff of zero, which is where audit budgets go to die. This tool surfaces the type as a note precisely so nobody files it as work. Markup earns removal only when it asserts something the page contradicts.
If I fix everything this tool finds, will AI engines cite me more?
The evidence says no — Ahrefs tracked 1,885 pages adding JSON-LD against matched controls and found no meaningful citation movement, and Google states structured data is not required for generative AI search. What a clean audit buys is narrower and still worth having: no markup asserting things your page contradicts (the one class with a documented penalty), and an entity graph that resolves to one identity instead of contradicting itself. Treat schema as identity infrastructure, not a citation lever.