Free tool
The validator does not grade you against the full schema.org vocabulary. It looks at the handful of fields that change whether an answer engine can do something with your markup, which is a much shorter list than most audit tools imply.
For Organization: name, url, logo, and sameAs. The first two are table stakes. sameAs is the one that matters and the one most sites omit. For FAQPage: whether mainEntity is actually populated, because a page declaring itself an FAQ and listing no questions is surprisingly common and does nothing. For Product: whether there is an offers block with a price, since assistants answering “what does this cost” need a number. For Article: headline, author, datePublished, which are what let a page be attributed and aged against competitors.
A JSON-LD block with a trailing comma or an unescaped quote is invisible. Not degraded, invisible — the parser gives up on that block and moves on, and no error appears anywhere you would normally look. Sites ship broken markup for months this way, usually after a template change put a raw value where a quoted string should be.
Most validators quietly skip the blocks they cannot parse. This one reports them with the parse error, because if you have a broken block that is almost certainly the thing you came here to find.
There is a persistent idea that adding more schema types increases your chances of being cited. It does not. Structured data is a labelling exercise: it tells engines what a page is so they do not have to guess. Once the guessing is eliminated, more markup adds nothing, and markup describing things that are not on the page actively costs you.
The work that actually moves AI visibility happens off your own domain, in the comparison articles, directories and threads the engines assemble answers from. That is a slower and less satisfying job than editing a script tag, which is probably why so much AEO advice stops at the script tag.
Next
Google’s tool checks conformance against its own rich-result requirements, and it is stricter and more complete than this. This checks a narrower thing: whether the markup gives an answer engine what it needs to identify you and quote you. Different question, so use both. If you only have time for one and you are chasing rich snippets in Google, use theirs.
It fetches the page, pulls out every application/ld+json script tag, and reports each one separately: the types it declares, whether it parses as JSON at all, and which of the fields that matter are missing. Broken blocks are reported rather than skipped, because a block that fails to parse is the finding.
No. Engines read both. JSON-LD is easier to maintain because it sits in one block instead of being threaded through your markup, and it is what most tooling assumes, but microdata is not wrong. The tool reports when it sees microdata so a page using it does not get told it has no structured data.
Because it is the field that does the most work and the one most often left out. sameAs points at other profiles that are unambiguously you, which is how an engine joins your homepage to records it already holds. Without it, your company name is a string that might refer to several things, and disambiguation is exactly what you want the engine to get right.
Some sites refuse unfamiliar user agents, some sit behind a bot wall, and some render everything client-side so the HTML we get back is nearly empty. All three are worth knowing about, because a crawler that cannot read your page also cannot read your markup. If it is the third one, that is the more serious finding.
No, and this is worth being blunt about. Schema removes ambiguity about what a page is. It does not create the independent coverage that makes an engine recommend you. A site with perfect markup that nobody writes about stays invisible. Markup is the cheap half; the other half is being in the pages the answers get built from.