Schema markup validator

Test a page’s structured data against the requirements Google documents for each Search feature — and against what a visitor can actually see. Every finding shows both values, where we looked, and how confident we are.

What this validator checks that others do not

Whether the values match the page

A syntax validator tells you the JSON parses and the properties exist. That is a low bar, and it is not what gets markup ignored. The requirement that matters is that marked-up values reflect what visitors see, and it is the one nothing else routinely tests. We locate every value with a content requirement in the page itself, and report the ones that are missing, hidden, or disagree with the markup.

Each Google feature separately

One schema.org type maps to several Search features with different requirements. Product alone spans product snippets, merchant listings, variants and return policy. Checking “Product” as a single ruleset means telling a review page it is missing shipping details it was never expected to provide. We assess each feature on its own, and only when your markup shows you are attempting it.

All three formats

JSON-LD, microdata and RDFa are parsed into one internal graph before any rule runs — so multiple script blocks, @graph wrappers, nested entities and bare @id references are read the way a consumer reads them, not the way a simplified parser wishes they were written.

Whether the feature still exists

Features get removed. FAQ rich results were withdrawn on 7 May 2026, and plenty of pages still carry FAQPage markup expecting something from it. A validator that silently finds nothing wrong is not telling you that. We keep removed features in the registry permanently, so the report can say what the markup now does — and, just as importantly, never asks you to add properties for a feature that no longer produces anything.

Validator, checker, tester — and Google’s own tools

These names all describe the same job, and it is worth being clear about which tool does what, because they are not substitutes for each other.

Google’s Rich Results Test is the authoritative answer to “does Google think this page is eligible for a rich result”. It is Google’s own index and Google’s own parser. Nothing else can answer that question, this tool included, and you should use it before you ship anything you care about.

The Schema.org validator answers “is this valid schema.org”. It is vocabulary-level and says nothing about Google’s requirements or about your page content.

This validator answers the question neither of those does: whether your markup describes the page it sits on, whether the values are visible, which features it is attempting, and whether the requirements it is being judged against are current. Run it before Google’s tools, to fix the things Google’s tools will not point out.

How we read the page

You give us a URL and we work out the rest. The request goes out over HTTP, follows redirects, and reads the source. If the response comes back nearly empty with a JavaScript framework signature — a Next.js or Nuxt app that builds its markup in the browser — we load the page in a real browser and read it again, because reporting “no structured data found” on that page would be a false negative dressed up as a result.

Rendering is not just a rescue. It is the only way visibility is measured from the real layout rather than inferred from the HTML, so a rendered check can tell a collapsed accordion from genuinely hidden content with confidence rather than a guess.

If a site answers with a bot wall, we retry from a different source address, then try the browser. None of this defeats bot protection and it is not meant to: a site that declines all of that has made a decision, and we report it plainly. The report always states which of these actually happened, so you know whether you are reading the HTML response or the rendered DOM.

Common errors this finds

A price with a currency symbol in it

offers.price takes a bare number. Writing $1,299.00 into it is the single most common Product error, and a plain schema.org validator will not object, because schema.org itself does not constrain the format that tightly.

Ratings that exist only in the markup

An aggregateRating with a review count and nothing corresponding on the page fails the visible-content requirement. It is also the easiest mismatch in the world to detect, which makes it a poor thing to chance.

Two entities describing one thing

A theme that outputs Product markup and a plugin that also outputs Product markup give consumers two descriptions of one product, often with different prices. On established WordPress and Shopify sites this is the most common finding of all, and the fix is to turn one of them off rather than to reconcile them.

Values that drifted

Markup written by hand a year ago and page content edited since. Opening hours, prices and author names are the usual casualties, and nothing surfaces it until something checks the two against each other.

What it does not do

It does not tell you whether a rich result will appear. Nothing can, and any tool claiming otherwise is describing something it cannot know. It does not tell you what Google sees — only what our crawler observed, or what was in the HTML you pasted. And it does not report a possible mismatch as a violation unless the evidence is high-confidence, because a validator that flags correct markup as broken gets abandoned faster than one that misses a problem.

Checking more than one page? Crawl the whole site — the same defect usually lives in a template, and seeing it once with a page count is more useful than seeing it four thousand times.