How to validate JSON-LD structured data

How to validate JSON-LD structured data

1. Enter the URL of the page, not the homepage. Structured data is per page: a product page carries Product, an article carries Article. The validator fetches the page exactly as your server serves it, so it also sees blocks added by a plugin, a theme or a tag manager that are not in your source files.
2. Or paste the JSON-LD. Switch to the Paste tab and drop in the contents of a <script type="application/ld+json"> block. Use this before the markup is live, and for output from a generator or a language model before you trust it.
3. Read the score and the issue list. Every block on the page gets its own section. Each issue names the field, says whether it is a parse error, a schema.org error or a Google requirement, and gives the fix. Errors block eligibility; warnings are recommended properties you can add.
4. Fix, re-scan, confirm. The report reads the live page, so once the fix is deployed a second scan confirms it. Signed in, a URL scan is saved to your dashboard so you can compare before and after.

How to read the report

The 0–100 score

The score is the share of checks the page passes across every JSON-LD block it carries. A page with one clean Organization block and one Product block missing its offers scores in the middle: valid, but not eligible for the product rich result it is clearly trying to earn.

Errors, warnings and information

• Error — the JSON does not parse, the type or property does not exist on schema.org, or a property Google lists as required for that type is missing or malformed. Any one of these stops the rich result.
• Warning — a property Google lists as recommended is missing, or a value is of an unexpected shape. The page is eligible; the result may be poorer.
• Information — something worth knowing that is not a fault: a deprecated type (FAQPage no longer earns a rich result), Microdata detected alongside JSON-LD, a block with no Google rich result behind it.

Required versus recommended

Google states that a page must “include all the required properties for an object to be eligible for appearance in Google Search with enhanced display”. The required and recommended lists differ by type and change over time, so the report says which side of that line each missing field is on. That is the difference between a real blocker and a nice-to-have.

Unresolved @id references

Referencing another node by @id is correct JSON-LD — as long as that node is defined somewhere on the same page. A reference to an @id that exists nowhere reads to Search as an empty object, and everything the type required behind it goes missing. These are reported on their own because the fix is different: define the node, do not add the missing fields to the reference.

How to find the JSON-LD on a page yourself

If you want to see what the validator sees, or check a page by hand:

1. Open the page, then view the page source (Ctrl+U or Cmd+Option+U). Search for application/ld+json. Each match is one block; a page often has two or three.
2. In Chrome DevTools, the Elements panel shows the DOM after JavaScript ran, so a block injected by a tag manager appears there but not in the source. The validator reads the served HTML, which is what search engines index first.
3. Copy the contents of one block (everything between the <script> tags) and paste it into the Paste tab above to validate that block alone.

Google recommends JSON-LD over Microdata and RDFa (“In general, Google recommends using JSON-LD for structured data if your site's setup allows it”), and the block may sit in the <head> or the <body>.

What Greadme Schema Validator checks

Structured data fails in three different places, and a validator that only checks the first one will tell you a broken page is fine. This runs all three.

1. Does the JSON parse? A trailing comma or a smart quote from a CMS editor breaks the whole block. Parse errors come back with the line number.
2. Is it valid schema.org? Correct @context and @type, properties that exist on that type, and the nesting each type expects.
3. Does it meet Google's requirements for rich results? This is where most markup actually fails — the JSON is valid, the type is real, and a required property Google asks for is missing.

You get the score, every issue with the field name and a suggested fix, and a Copy As Prompt button that hands the whole report to your AI coding agent.

Types with dedicated validation

Generic validators check that a property exists. These 21 types get their own rules — the required fields, the value formats and the nesting each one actually needs:

Anything else is still parsed and checked against schema.org; it simply does not get a type-specific rule set.

Schema Validator vs. Rich Results Test vs. Schema Markup Validator

Three tools, three questions. Use the one that answers yours — they are not substitutes.

A sensible order: validate here first (it catches the parse and requirement errors with a fix), then confirm with Google's test that the rich result type is detected.

The mistakes that come up most, and how to fix them

A required property that is only recommended in your head

Markup that earned a rich result two years ago can quietly stop qualifying when Google moves a property from recommended to required. Fix: add the property the report names; the issue text says which list it is on and what shape the value takes.

Miscased property names

mainentity is not mainEntity. JSON-LD property names are case-sensitive and a miscased one is silently ignored — the block validates as well-formed JSON and the property simply does not exist as far as Search is concerned. Fix: copy the property name from the report, which uses schema.org's spelling.

Markup describing something the page does not show

Google's structured data policies require markup to be a true representation of the page content and forbid marking up content that is not visible to readers. A review count in the markup with no reviews on the page is a policy problem, not a formatting one. Fix: remove the claim from the markup, or put the content on the page.

@id references that point at nothing

Reported separately from ordinary missing fields, because the fix is different: define the node the @id points to — usually an Organization or WebSite block that was meant to be on every page and is missing from this one.

Two blocks describing the same thing differently

A theme adds an Organization, a plugin adds another with a different name and logo. Search picks one, and not necessarily yours. Fix: keep one, or link them with the same @id.

Questions people ask

Written by the Greadme team, who build the validator. Last updated 2026-09-03; the type rules are re-checked against schema.org and Google's structured data documentation whenever either changes.