How to Test and Validate Structured Data

Structured data only helps you if it is valid — broken or incomplete markup is silently ignored, so testing it is a required step, not an optional polish. The three tools you need are Google's Rich Results Test (does this page qualify for a Google rich result?), the Schema Markup Validator at validator.schema.org (is the markup syntactically correct against the schema.org vocabulary?), and Google Search Console's Enhancements reports (is my live site's markup valid at scale?). This guide walks through testing structured data with each, explains the crucial difference between errors and warnings, makes clear that eligibility is not a guarantee, and shows how to debug the mistakes that catch people out.

It assumes you already know the basics; if not, start with what is schema markup and which types you need.

Why validating structured data matters

When you add structured data — usually as JSON-LD in the page's head — you are making a machine-readable claim about what the page contains: this is an article by this author published on this date, this is a product with this price and these reviews, these are the answers to these questions. Search engines and AI systems read those claims to understand the page and, in Google's case, to decide whether to show an enhanced "rich result" such as review stars, FAQ accordions or recipe cards.

But there is a catch that surprises people: if the markup is invalid, it is simply ignored. Google does not guess at your intent or repair broken JSON. A missing required field, a typo in a property name, or a stray bracket can mean the entire block is discarded and the rich result you were hoping for never appears — with no warning unless you go looking. That is why testing is not a nice-to-have. Structured data you have not validated is structured data you cannot rely on, and the cost of a five-minute check is far lower than the cost of months of invisible, non-functioning markup.

There is a GEO dimension too. Clean, valid structured data helps AI answer engines parse and attribute your content, which feeds into being cited — a theme explored in how to get cited by AI search engines. Whatever the destination, valid markup is the entry ticket.

The three tools you need

Each tool answers a different question, and you want all three in your workflow.

Tool	What it answers	When to use it
Rich Results Test (Google)	Is this page eligible for a Google rich result?	Before and after adding markup for a Google feature
Schema Markup Validator (schema.org)	Is my markup valid against the full schema.org vocabulary?	To check any schema type, including ones Google does not render
Search Console Enhancements (Google)	Is my live site's markup valid at scale, over time?	Ongoing monitoring of indexed pages

The Rich Results Test and the Schema Markup Validator overlap but are not interchangeable. The Rich Results Test is Google-specific: it only checks the types Google can turn into rich results, and it tells you about Google eligibility. The Schema Markup Validator is vocabulary-wide: it checks any schema.org type for structural correctness, including types Google does not currently display, which makes it the better tool when you are using schema for general semantic clarity or for AI engines rather than a specific Google feature.

Testing with Google's Rich Results Test

The Rich Results Test is the place to start when your goal is a Google rich result. It works in two modes.

Test a live URL. Paste the page's URL and the tool fetches it as Googlebot would, runs your markup, and reports which rich-result types it detected and whether each is valid. Testing the live URL is the truest check because it sees the page exactly as Google does, including markup injected by JavaScript.

Test a code snippet. Paste raw HTML or JSON-LD directly to validate markup before you deploy it. This is ideal during development, when the page is not live yet or you are iterating on the code.

After running it, read the result in three parts:

• Detected items — the rich-result types the tool found (for example "FAQ" or "Article"). If a type you added is missing here, the tool did not recognise it, which usually means a syntax or property problem.
• Errors — problems that make an item invalid or ineligible. These are listed per item with the specific property at fault.
• Warnings — recommended properties that are missing but do not block eligibility.

The tool also offers a rendered view of the page and the raw HTML Google received, which is invaluable for diagnosing JavaScript and rendering issues — if your markup is injected by script and Google did not get it, you will see that here.

Testing with the Schema Markup Validator

The Schema Markup Validator (validator.schema.org), maintained by the schema.org community, is the general-purpose checker. Like the Rich Results Test, it accepts either a URL or pasted code. It parses your structured data and shows you the full object tree it understood — every type, every property and its value — which is the clearest way to confirm the markup actually says what you intended.

Use it when:

• You are using a schema type Google does not render as a rich result, but you still want it correct for semantic clarity or AI consumption.
• You want to see the complete parsed structure, not just the Google-eligible subset.
• You are debugging nesting — confirming, say, that your author is correctly attached to your Article, or your Offer to your Product.

It will flag invalid properties and structural problems against the schema.org vocabulary. Note that it does not judge Google rich-result eligibility — for that you still need the Rich Results Test. The two are complementary: validate the vocabulary with one, confirm Google eligibility with the other.

Errors versus warnings: the distinction that matters

This is the single most important concept in structured-data testing, because it tells you where to spend effort.

An error means the markup is invalid or a rich result is blocked. The usual causes are a missing required property (the type demands a field you did not supply) or invalid syntax. Errors must be fixed — until you do, the affected item will not produce a rich result, and may be ignored entirely.

A warning means a recommended but optional property is missing. The markup is still valid and may still be eligible. Adding the field improves the quality and completeness of your structured data and can unlock a richer presentation, but its absence is not fatal. For example, an Article might be valid with required fields present but warn that an optional image or dateModified is missing.

The practical rule: fix every error, then address warnings selectively. A page with zero errors and a few warnings is in good shape; chasing every warning to zero has diminishing returns. Errors are the blockers; warnings are the upgrades.

Eligibility is not a guarantee

Here is the expectation-setting that saves a lot of confusion: passing the Rich Results Test makes you eligible for a rich result — it does not guarantee one will appear. Google decides whether to actually show a rich result based on its own assessment of quality, relevance, trust and context, and it can withhold one even for perfectly valid markup. A page can be 100% valid and still show a plain blue-link result.

So if your markup validates but you do not see a rich result in the wild, that is not necessarily a bug. Common explanations include: Google simply chose not to show one; the page has not been recrawled since you added the markup; the site or page does not yet meet Google's quality bar for that feature; or the content violates a policy. The fix is rarely "add more schema" — it is to confirm validity, ensure the page is indexed and crawled, meet the quality and content guidelines, and then accept that display is Google's call. Validation removes the technical blockers and is entirely within your control; display is probabilistic and is not.

Monitoring at scale with Search Console

The Rich Results Test and Schema Markup Validator check one page at a time, which is perfect for development and spot checks but does not scale to a whole site. That is what Google Search Console's Enhancements reports are for. As Google indexes your pages, it groups detected structured-data types into reports — "FAQ", "Breadcrumbs", "Products", "Merchant listings" and so on — each showing how many of your pages are valid, valid with warnings, or have errors, with the specific issues listed and example URLs.

This is the tool for ongoing health monitoring:

• See aggregate validity across all indexed pages, not just the one you are testing.
• Catch regressions — for instance, a template change that introduces an error across thousands of pages at once.
• Use the "Validate fix" workflow: after correcting an issue, ask Google to recheck the affected pages and track whether the fix propagates.

Pair this with the URL Inspection tool, which shows the structured data Google detected on a specific live URL and the Google-selected state, so you can confirm what Google actually sees versus what you intended. Together, the per-page tools and the site-wide reports give you both depth and breadth.

Debugging JSON-LD: a practical walkthrough

Most structured data today is JSON-LD, a script block in the page head. When it fails, the cause is usually one of a handful of things. Here is a debugging order that resolves most problems.

1. Confirm the block is present and reaches Google. Use the Rich Results Test on the live URL and check the rendered HTML. If your JSON-LD is injected by JavaScript and Google did not receive it, that is your problem — server-render or statically include it.
2. Validate the JSON syntax. A single missing comma, unbalanced bracket or unescaped quote breaks the entire block. The tools will flag a parse error; a strict JSON linter helps pinpoint the character.
3. Check the type and required properties. Confirm @type is spelled correctly and matches a real schema.org type, and that every required property for that type is present with a sensible value.
4. Check property names and nesting. Misspelled properties (datePublish instead of datePublished) are ignored; incorrect nesting (an author not actually inside the article) produces a structure that does not say what you meant. The Schema Markup Validator's object tree makes this visible.
5. Confirm the markup matches the visible content. This is a policy requirement, not just a syntax one — covered next.
6. Re-test, then request reindexing so Google picks up the corrected markup.

Working through that list in order turns "it does not work" into a specific, fixable cause almost every time.

The most common mistakes

A few errors recur constantly. Knowing them lets you avoid most failures before you test.

• Missing required properties. Every type has required fields; omit one and you get an error. Always check the requirements for the type you are using.
• Markup that does not match visible content. Google's guidelines are explicit that structured data must describe content that is actually visible on the page. Marking up reviews, FAQs or prices that users cannot see is a violation that can trigger a manual action and lose you rich results entirely. This is the most serious mistake because it is a policy breach, not just a technical slip. If you add FAQ schema, the questions and answers must appear on the page — see how to add FAQ schema for doing it correctly.
• Invalid JSON-LD syntax. Missing commas, brackets or quotes break the whole block. A linter catches these instantly.
• Wrong or misspelled types and properties. @type values and property names must match schema.org exactly, or they are ignored.
• Marking up the wrong page type. Using Article schema on a category page, or Product schema where there is no single product, confuses rather than clarifies.
• Forgetting to update markup when content changes. Stale schema — a price or date in the markup that no longer matches the page — drifts out of sync and can mislead or violate guidelines.

A testing and validation checklist

• Test new markup as a code snippet in the Rich Results Test before you deploy.
• Test the live URL after deploying, so you see what Google actually receives.
• Run the Schema Markup Validator for any type Google does not render, or to inspect the parsed object tree.
• Fix every error; address warnings where they add real value.
• Confirm the markup matches the visible content on the page.
• For JavaScript-injected schema, verify Google receives it in the rendered HTML.
• Monitor the Enhancements reports in Search Console for site-wide validity and regressions.
• After fixing an issue, use "Validate fix" and request reindexing.
• Re-test whenever you change a template or the underlying content.

Where to start

If you have never validated your structured data, start with your most important page types — your articles, products or FAQs — and run each through the Rich Results Test on its live URL. Note every error and fix it; these are the blockers actively costing you rich results. Then open Search Console's Enhancements reports to see whether the same errors repeat across many pages, which usually points to a template fix that resolves them in bulk. Finally, confirm your markup matches what users actually see, because that policy check is the one most likely to cause real trouble down the line. That sequence — validate key pages, fix errors, check for template-wide patterns, confirm content match — gets a site from "unknown" to "reliable" quickly, and from then on testing becomes a quick step in every content change rather than a rescue mission.

Go deeper

• The foundation: what is schema markup and which types you need.
• The highest-leverage type: how to add FAQ schema.
• Make valid markup earn citations: how to get cited by AI search engines.
• The on-page basics alongside it: how to write a title tag and meta description.

Want structured-data and technical-SEO issues flagged automatically? Analyse any URL with StackOptic — one report covering schema, SEO, performance and more, free, no sign-up.