AI Schema Checker

A generic validator answers a syntax question: is this JSON-LD well formed and does it satisfy the schema.org vocabulary. That is useful and several free tools do it well, including Google's own Rich Results Test. This tool answers a different question: does your markup carry what an engine needs to attribute an answer to you. It checks seven types and five properties chosen for that purpose, and ignores everything else. A page can pass every syntax check and still leave an engine unable to say who wrote the content, when, or on whose authority, which is the gap this tool is looking for.

Five carry the weight: author, datePublished, dateModified, publisher and sameAs. The first three establish provenance, which is what an engine needs to decide whether your page is current and who stands behind it. Publisher ties the content to an organisation rather than leaving it orphaned. sameAs is the one most often missing and the most underestimated. It links your entity to its other public identities, which is how an engine resolves that the company on your site and the company mentioned elsewhere are the same thing. Without it, your brand can be cited as several distinct entities, or not recognised as an entity at all.

The honest answer is that none of them has published a complete account of how they use it, and anyone who tells you otherwise is extrapolating. What is documented is that Google AI Overviews are built on the same infrastructure as Google Search, which does read structured data extensively, and that several assistants ground answers in search indexes that use it. The defensible position is that structured data is cheap, it is unambiguous where prose is not, and it is already read by the search layer that most assistants sit on top of. It is not a lever that produces citations by itself, it is a way of removing ambiguity about who you are.

The score is a coverage measure rather than a quality grade, so read it as a checklist rather than a target. It weights the presence of key types at sixty-five percent and attribution properties at thirty-five. Not every type applies to every page. A blog article has no reason to carry Product markup, and the tool marks it as not applicable rather than missing. What genuinely matters is that Organization and WebSite exist somewhere on your site, that content pages carry Article with an author and dates, and that pages answering questions carry FAQPage. A score in the eighties with a deliberate gap is better than a hundred obtained by declaring types your page does not really contain.

It means a script tag declares itself as application/ld+json but the content inside is not valid JSON, so no consumer can read it. The usual causes are a trailing comma, an unescaped quote inside a string, or a template that injected a value without encoding it. This failure is silent. The page renders normally, nothing appears in your logs, and the markup looks present when you view the source. Every machine reading the page skips the block entirely, which means you carry the maintenance cost of structured data while receiving none of the benefit. It is worth fixing first, before adding any new markup.

No. Structured data should describe what is genuinely on the page, and adding markup that overstates the content is a real risk rather than a shortcut. Declaring FAQPage on a page with no questions, or Product on a page that sells nothing, is the kind of thing search engines penalise and assistants learn to distrust. The useful approach is layered. Organization and WebSite belong site-wide, usually in your layout. BreadcrumbList belongs on any page inside a hierarchy. Article with author and dates belongs on editorial content. FAQPage belongs where real questions are answered. Anything beyond that should earn its place.