How to Validate JSON-LD

You added a JSON-LD block, published the page, and moved on. Weeks later, Search Console flags a structured data error, or the rich result you expected never shows up. Nothing on the page looks broken, so it's easy to assume the schema is fine. It usually isn't, and the only way to know for sure is to actually validate it.

Validating JSON-LD isn't a one-time formality you run before hitting publish. It's a check that confirms your code parses correctly, matches the schema type's requirements, and still reflects what's actually on the page — three separate things that can each quietly fail on their own.

What does "validating JSON-LD" actually mean?

Validation is really three separate checks stacked on top of each other, and passing one doesn't mean you've passed the others.

• Syntax validity. The JSON itself has to parse — matching brackets, correct commas, properly quoted strings. This is the lowest bar, and the easiest to pass with a generator.
• Schema compliance. The block has to include the fields a given schema.org type actually requires, and use them the way the type expects. Valid JSON with the wrong fields still fails here.
• Content accuracy. Every value in the markup should match something a visitor can actually see on the page. No validator can fully catch this on its own — it's the one check that still needs a human eye.
• Rich result eligibility. Even schema that clears all three checks above only makes a page eligible for a rich result; Google still decides whether to actually show one.

A page can sail through a basic syntax check and still get flagged in Search Console weeks later, because syntax was never the part that was broken.

Why validation matters, even for correct-looking code

Skipping validation, or treating a syntax pass as the finish line, creates problems that surface later and cost more to fix:

• Errors are invisible on the page. A broken JSON-LD block doesn't change how the page looks to a visitor, so nothing alerts you until a search feature quietly fails to appear.
• Search Console reports lag behind reality. By the time a structured data error shows up in Search Console, it may have been broken for days or weeks — validating before and after publishing catches it immediately instead.
• Small edits break schema more often than big ones. A content tweak, theme update, or plugin change can silently corrupt a JSON-LD block that worked fine before, with no visible symptom on the page itself.
• Rich results are a competitive edge. Star ratings, FAQ dropdowns, and other rich results affect click-through rate directly, so an unnoticed schema error has a real, ongoing cost.

Step-by-step: validating your JSON-LD

1. Grab the live URL or the raw code. Validators can test either a published page or a pasted code snippet — use the live URL whenever the page is already public, since that's what search engines actually see.
2. Run it through Google's Rich Results Test. This checks not just syntax, but whether the markup meets Google's specific requirements for the rich result it's targeting.
3. Cross-check with the Schema Markup Validator. This tool checks compliance against the broader schema.org specification, which is useful for types or fields Google's tool doesn't specifically test for.
4. Read every error and warning, not just the pass/fail result. Errors usually block a rich result outright; warnings flag optional-but-recommended fields worth reviewing.
5. Fix issues at the source. Correct the generator settings or the CMS field the schema came from, rather than patching the output snippet directly, so the fix survives the next regeneration.
6. Re-test the live page after publishing. A snippet that validates in isolation can still fail once it's placed on the real page, so the final check should always be against the published URL.
7. Recheck periodically, especially after site changes. Revalidate key templates after theme updates, plugin changes, or major content edits, since these are the most common causes of schema quietly breaking after launch.

Common mistakes that slip past a quick glance

1. Trusting a syntax pass as proof the schema works

Well-formed JSON can still be missing every field a schema type requires. Syntax validity and schema compliance are different checks, and passing one says nothing about the other.

2. Validating the snippet instead of the live page

A block that validates perfectly on its own can still fail once it's actually placed on the page, especially if it ends up duplicated, nested incorrectly, or dropped in the wrong location by the CMS.

3. Ignoring warnings because the test technically "passed"

A warning for a missing recommended field, like an image or review count, often determines whether a rich result actually renders, even though it doesn't count as a hard error.

4. Never revisiting schema after the initial launch

Structured data isn't a set-it-and-forget-it feature. A theme change, a content edit, or a plugin update can each quietly invalidate a block that worked fine the day it was added.

Real-world examples

How different validation issues actually show up in practice, and what fixing them looks like:

In each case, the code looked fine at a glance — the issue only surfaced once it was actually run through a validator.

Validation tools compared

A look at the main ways to validate JSON-LD, and what each one is actually good for.

Validate your JSON-LD right now — free

The Rebrixe JSON-LD Validator checks syntax and schema compliance for the most common schema types — Article, Product, FAQPage, Recipe, and more. Paste a URL or raw code, no account needed, and get a clear list of errors and warnings in seconds.

Frequently asked questions