Validate your JSON-LD structured data against schema.org's required fields — paste the markup or fetch it live from a URL. Pairs with our Schema generator.
In August 2026 we ran a duplicate check across our own site:
414 pages carrying structured data,
11 of them declaring FAQPage twice. Every single block was valid on its own. The conflict was
born at build time, when two components each injected their own script
tag into the same page.
That is the shape of the problem: a validator reading one block at a time reports "valid" for both, and the page still tells Google two different things about the same entity. One of ours was the page ranking for the only query that had ever earned us a click.
How to reproduce it on your own site. Fetch the rendered HTML,
collect the @type of every node across all
JSON-LD blocks, and count. Types that legitimately repeat —
ListItem, Question, Offer,
Person — are graph contents, not page declarations;
ignore those. What is left is either intentional or a conflict, and
usually nobody chose it.
Markup assembled by a framework, a CMS plugin or a template partial
does not exist as such in your repository. Duplicates, missing
@id targets and script-injected blocks appear only after
the build — so a clean report on source files says nothing about what
Googlebot receives.
The practical rule: whatever you validate must be the same bytes the crawler gets. Paste the rendered output, or fetch the live URL above and let the tool do it.
JSON-LD can parse perfectly and still earn nothing. Schema.org defines what is valid; each search feature defines what is required — and the second list is shorter and stricter.
A Product without offers is valid schema and an ineligible
rich result. That gap is where most markup quietly fails, and it is why
a validator and the rich-result test
answer two different questions.
@id pointing at a node that does not exist in the graph.Rich results are earned, not owed. Valid markup makes a page eligible; Google still decides per query whether the feature helps. Thin or low-quality pages stay plain no matter how complete the JSON-LD is.
So treat validation as a floor to clear rather than a lever to pull. The lever is the page itself — the markup only makes sure engines read it the way you meant.
The same structured data decides whether an AI engine attributes a fact to you by name or paraphrases it anonymously. Author, organisation and date fields are what turn a sentence into a citation with your domain attached.
This is why validation stopped being cosmetic: rich results are one surface, and citation in an answer is another that reads the same markup. Check whether engines quote you with the AI Overview checker.
Paste your JSON-LD or fetch it from a URL above. The validator checks structure and the required fields for each declared type.
It can, and that is a conflict rather than a doubling of strength. When two components each inject their own script tag, a page ends up declaring FAQPage twice — both blocks valid in isolation. We found exactly that on 11 of our own pages in August 2026. A validator that reads one block at a time cannot report it; the check has to be made against the whole rendered page.
Valid means eligible, not guaranteed. Google decides per query whether to show the feature, and page quality is part of that decision.
Not directly. It affects how a result is displayed and how confidently engines understand the entity — which influences clicks and citation, not the ranking algorithm itself.
The rendered page. Markup assembled by a framework, a CMS plugin or a template partial does not exist as such in your source files — duplicates, missing @id targets and JavaScript-injected blocks only appear after the build. Validating source code alone gives a clean report on a page that conflicts in production.
A JSON-LD checker answers whether the markup is well-formed and complete for its type. The Rich Results Test answers which Google features that markup qualifies for. The first is a superset: markup can be perfectly valid and eligible for nothing, because eligibility has its own shorter, stricter list of required fields.
A JSON-LD validator checks whether your structured data parses correctly and includes the properties schema.org marks as required or recommended for each type — Article, Product, FAQPage, Organization, and the rest. Missing or malformed fields silently disqualify a page from rich results in Google and make your facts harder for AI engines like ChatGPT and Perplexity to parse and cite. Validating before you publish catches the errors that quietly cost you eligibility.
Required properties are the minimum a type needs to be eligible for a rich result — omit one and Google won't render the enhanced snippet. Recommended properties are optional extras that improve the snippet and give AI engines more to cite, but their absence won't disqualify the page.
No. Valid, complete markup makes a page eligible, but Google decides whether to actually show a rich result based on content quality, page policy, and query context. Validation removes the technical blockers; it doesn't force the enhancement.
JSON-LD is the format Google explicitly recommends because it lives in one script block, separate from your visible HTML, making it easier to add, maintain, and validate. Microdata and RDFa are still supported but interleave markup with content, which is more error-prone.
Yes — paste the raw JSON-LD directly instead of fetching a URL, and the validator checks the markup on its own. The URL fetch is for auditing pages that are already published.
Free tools show you WHAT to fix. The full audit + the autonomous team of 20 AI agents fix it end-to-end — strategy, content, GEO, internal links, publishing and day-2 upkeep.
All free tools →cookies
The Matrix already knows everything about you — cookies are small change by comparison. The choice, as always, is yours: