Structured Data Testing: How to Validate Your JSON-LD Before You Publish

Structured data fails closed, not gracefully. A schema.org JSON-LD block with one invalid property, a missing required field, or a type mismatch doesn't produce a degraded rich result — it usually produces no rich result at all, and the failure is silent: the page still renders fine, the script tag still loads, and nothing in the browser console necessarily flags the problem. Validating before publishing is the only reliable way to catch this.

The two tools that actually matter

Schema.org's own validator (validator.schema.org) checks whether your JSON-LD conforms to the schema.org vocabulary itself — correct types, correct property names, correct nesting. It's the strictest check and the right first stop, because it validates against the specification rather than against what Google specifically chooses to support.

Google's Rich Results Test (search.google.com/test/rich-results) checks something narrower but more practically important: whether Google will actually generate a rich result from your markup. Schema.org defines hundreds of types and properties; Google's rich results only support a subset of them, with their own additional requirements layered on top (for example, FAQPage rich results require the questions to be visibly present on the page, not just in the JSON-LD). Passing schema.org validation does not guarantee passing Google's Rich Results Test, and you need both — the first confirms your markup is valid, the second confirms Google will do anything with it.

Common failure patterns, in order of frequency

• Wrong property nesting — putting a property at the top level of the object when it belongs nested inside another property (for example, author needs to be a nested Person or Organization object with its own name property, not a plain string in most contexts).
• Missing required properties — each type has a baseline set Google requires for a rich result to appear at all (Article requires headline, image, and datePublished, for instance); missing any one of them disqualifies the whole block even if everything else is correct.
• Markup that doesn't match visible page content — marking up an FAQPage with questions that aren't actually shown anywhere on the rendered page is treated as a quality violation, not just a missing field, and can result in markup being ignored sitewide if it happens repeatedly.
• Multiple conflicting schema blocks on one page — two separate Article blocks, or an Article and a BlogPosting both describing the same content, create ambiguity about which one is authoritative.
• Stale data — a price, availability status, or rating that hasn't been updated since the underlying page content changed; the JSON-LD and the visible page should never disagree.

A practical pre-publish checklist

1. Generate or write the JSON-LD block.
2. Run it through validator.schema.org first — fix any structural errors it reports.
3. Run the live (or staged) URL through Google's Rich Results Test — confirm it detects the intended rich result type with no errors or warnings.
4. Manually cross-check that every fact in the JSON-LD — price, date, author name, FAQ text — matches what's visibly on the page.
5. Re-test after any future content edit that touches a marked-up field; structured data drifts out of sync with page content more often than it's deliberately broken.

If you're generating markup rather than hand-writing it, the Schema Generator produces correctly nested JSON-LD for the most common types (Article, FAQPage, Product, LocalBusiness, HowTo, BreadcrumbList) — but running the output through both validators above before publishing is still worth the two minutes, since no generator can verify that your specific page's visible content matches what you typed into the form.