Structured data validator

What is checked

Every script[type="application/ld+json"] block on the pages read is parsed and inspected. The audit reports per page rather than averaging away a single broken block.

• The block parses as JSON; malformed blocks are counted separately.
• An @context resolves to schema.org, directly or through @graph.
• Declared @type values are recognised, and unknown types are reported rather than ignored.
• Entity declarations carry a name and URL that match information visible on the page.
• Product or article declarations describe something the page actually presents.
• Duplicate or conflicting declarations on the same page are reported together.

What this validator is not

It is not the Google Rich Results Test and it does not preview rich results. It cannot tell you whether Google will grant a rich result, because eligibility depends on Google policies, competition and the query. It also does not recommend adding markup your content does not support: structured data must describe what the page already says.

Failures it commonly reports

These are the cases where the evidence is unambiguous and the fix is local to the page.

• Invalid JSON inside a JSON-LD block, usually from an unescaped quote or a trailing comma.
• A missing or non-schema.org @context.
• A recognisable @type with no name, or a name that does not appear in the visible content.
• Organization or Product markup repeated in two blocks with different values.
• A declaration for a page type the page does not actually represent, such as Product markup on a blog post.

A record that matches the page

This is the shape the audit expects: a real name, a real URL and fields that the visitor can also see on the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your product name",
  "url": "https://your-domain.com/",
  "email": "support@your-domain.com"
}
</script>

How the result is reported

Each declaration becomes a finding with the page URL, the parsed types, the observed problem and the expected result. The report separates parse failures from content mismatches so you can fix the syntax first and the facts second.

After you fix it

Use Recheck after fixes at the same entry URL. The recheck repeats the same parse and entity checks and reports resolved, remaining, newly found and unverified items. A declaration that was removed rather than corrected is reported as a change, not a fix.