How to Validate Your Schema Markup So AI Engines Can Read It

You added schema to your pages, and now you're not sure it's doing anything. That's a normal place to be. This guide walks you through how to validate schema markup step by step, using the free tools that check syntax, vocabulary, Google eligibility, and what a crawler actually sees on your live page. By the end, you'll be able to test structured data with confidence, read the errors without guessing, and know your markup is machine-readable for ChatGPT, Perplexity, Gemini, and Claude.

You don't need a developer for most of this. You need about an hour, a browser, and access to Google Search Console for your property.

Understand the four layers you're actually checking

Here's the thing that makes validation confusing: there isn't one check. There are four, and each tool only covers part of the picture.

Schema validation is a four-layer process. Miss a layer and you get the worst outcome, markup that looks fine in a test but is invisible in production.

Layer 1: Syntax. Is the JSON-LD well-formed and parsable? This catches trailing commas, unmatched braces, missing closing script tags, and improperly escaped quotes.

Layer 2: Vocabulary. Do your terms actually exist in the Schema.org vocabulary, used in valid contexts? This catches properties that don't exist on the type you declared, or a string sitting where a URL belongs.

Layer 3: Rich result eligibility. Does the markup meet Google's specific requirements for a rich result feature? This catches an Article missing an image or author, or a Product missing a price currency.

Layer 4: Live render. Can the crawler fetch and parse the structured data on the real page? This catches JavaScript that never executes, blocked resources, and markup a CDN quietly stripped during optimization.

How you know this step is done: you can name which layer each tool in this guide covers. Layers 1 and 2 are about correctness. Layer 3 is about Google features. Layer 4 is about reality.

Where people go wrong: they run one validator, see a green check, and stop. A clean vocabulary check tells you nothing about whether your crawler can reach the markup.

Check your syntax before you check anything else

Start with the cheapest check. If your JSON won't parse, every other tool will just throw a confusing error and you'll waste twenty minutes chasing the wrong problem.

Run your JSON-LD through a JSON syntax checker first. Any JSON linter works. You're looking for parse errors, nothing more.

The usual suspects:

• Trailing comma. The JSON spec disallows a comma before a closing brace. Remove it.
• Missing comma. The parser fails immediately at that line.
• Unescaped quotes. These break the script tag. Use single quotes inside your JSON, or escape them with a backslash.
• Missing closing tag. The </script> got dropped. Always close your script tags.

While you're in there, confirm the structural basics. Your @context must be "https://schema.org", not http, and not a bare schema.org. Your @type must be a real Schema.org type.

How you know this step is done: the linter parses your block with zero errors.

Where people go wrong: they skip straight to a schema validator with broken JSON. The validator reports a vague failure, and it reads like a vocabulary problem when it's really a missing brace.

Run the Schema.org validator for vocabulary

Now check whether your terms are real and used correctly. This is what the schema.org validator at validator.schema.org is for.

It validates against the full Schema.org type system, not just the parts Google turns into rich results. It supports JSON-LD, RDFa, and Microdata, and it returns three buckets: errors, warnings, and ignored properties.

That third bucket matters more than people realize. "Ignored" means the validator didn't recognize the property at all. It's usually a typo or a property that doesn't exist on your declared type.

Paste in your code snippet or point it at a URL. Then read what comes back:

• Unrecognized property? Check the spelling against that type's documentation. recipeIngredient on a non-Recipe type will not fly.
• Wrong value type? A string where a URL is expected usually means a relative URL. Make it absolute.
• Type mismatch? A string where a number is expected means you wrapped a numeric value in quotes. 29.99, not "29.99".

This tool is your safety net for types Google doesn't surface as rich results at all, like Service or WebPage. Google's own test will happily ignore those. The schema validator won't.

How you know this step is done: zero errors, and you've reviewed every ignored property and confirmed each one is intentional.

Pro tip: the Schema Markup Validator is operated by the Schema.org community and inherited from Yandex's open validator project. It catches schema misuse independent of what any search engine chooses to display. That's exactly why you run it alongside Google's test, not instead of it.

Run the Rich Results Test for Google eligibility

Next, the rich results test. This one answers a narrower question: does this page qualify for a Google rich result feature?

Give it a URL or a code snippet. It reports the structured data types it detected, lists errors and warnings per feature type, and shows a preview of how the rich result could appear.

The tool covers a long list of feature types, including Article, Breadcrumb, Event, FAQ, Job posting, Local business, Organization, Product, Q&A, Recipe, Review snippet, Software App, Video, and more.

Know its limits before you trust it:

• It only validates features Google actively surfaces as rich results.
• It won't validate schema types that aren't used for rich results.
• It doesn't test non-Google engines at all.

So a clean rich results test is a Google-eligibility signal. It is not proof your markup is correct in general, and it says nothing about whether an AI engine can read you.

How you know this step is done: the tool detects the types you expect, with no errors under the feature you're targeting.

Where people go wrong: they treat "no rich result detected" as failure. If you marked up a Service page, there's no rich result to detect. That's the tool's scope, not your bug.

Read errors and warnings the right way

This is where most people either panic or shrug. Let's make it simple.

Errors are blocking. The feature will not be eligible. Fix these.

Warnings are non-blocking. They usually flag a recommended property you left out. Your markup still qualifies. Warnings are a to-do list, not an emergency.

Now, a warning is still worth attention. Recommended properties often carry the entity detail that helps a machine understand what it's looking at. dateModified is a good example: it's rarely required, and it signals content freshness.

Errors sort into three families, and each has a different fix path:

1. Missing required field. The feature needs a property you didn't include. Check Google Search Central's docs for that specific feature type.
2. Invalid value format. A price without priceCurrency, a date that isn't ISO 8601, a duration written as 2h 30m instead of PT2H30M. Follow the format specs exactly.
3. Policy violation. Markup describing content that's hidden from users, or applied to irrelevant pages. Only mark up visible, relevant content.

Most format errors come from the same short list, so keep it somewhere you can check quickly:

• URLs must be absolute. https://example.com/page, never /page. This applies to image, url, and sameAs fields.
• Dates must be ISO 8601. 2024-03-15, or 2024-03-15T08:00:00+08:00 when you need the time.
• Durations must be ISO 8601 duration format. PT2H30M.
• Numbers must be numeric. Drop the quotes. 29.99, not "29.99".
• Prices must include priceCurrency. USD, EUR, whatever applies.

Include datePublished and dateModified on content pages while you're at it. Both take ISO 8601, and dateModified is what signals freshness downstream.

Feeling buried by a long error list? Sort by page template, not by page. One broken template usually explains hundreds of errors, and one fix clears them all.

Confirm the live page actually renders it

Here's the layer that catches the failures nobody sees coming. Your markup can be perfect and still be invisible.

Use URL Inspection in Google Search Console, and specifically the "Test Live URL" option. It tells you how Googlebot sees a live URL after rendering. It reports whether structured data was detected, lists the detected types, and shows indexability status and canonical selection.

This is the only step that confirms actual rendering instead of theoretical validation. Run it after every deploy.

The silent failures it catches:

• JavaScript not firing. Schema injected by JS that doesn't execute for the crawler. Googlebot does render JavaScript before parsing structured data, so JS-injected schema can work. "Can" is doing a lot of work in that sentence, which is why you verify.
• CDN stripping markup. Some CDNs remove JSON-LD during optimization. Check your post-CDN markup via View Source or URL Inspection.
• Robots.txt blocking. If you disallow resources needed to render the schema, the crawler can't assemble it.
• Canonical mismatch. Schema present only on a non-canonical version. It needs to be on the canonical URL.

While you're here, check the Enhancement reports in Search Console too. They surface warnings and errors Google has already recorded across your property, which is a useful cross-check against what you think you deployed.

How you know this step is done: the detected structured data in URL Inspection matches what you deployed, field for field.

Common mistake: validating a code snippet in a text box and calling it shipped. The snippet test proves your JSON is correct. It proves nothing about your website. These are different claims, and the gap between them is where most schema silently dies.

If you only test structured data one way, make it this way. A live-URL check is the only one that includes your CDN, your JavaScript, your robots.txt, and your canonical logic in the answer.

Scale the check across your whole site

Testing one URL at a time is fine for one page. It falls apart at 500.

For bulk validation, crawl the site with a tool like Screaming Frog SEO Spider. It extracts every JSON-LD, Microdata, and RDFa block, validates each against the Schema.org vocabulary, and flags missing required properties, deprecated properties, and value-type mismatches. You can filter by error type or URL pattern and export to a spreadsheet.

This is the right tool for three jobs:

• Large sites with thousands of pages.
• Post-template-change audits, to catch mass regressions before anyone else notices.
• Continuous monitoring, when you schedule it.

That second one deserves emphasis. A single template edit can break structured data across every page using it. You won't feel that as one bug. You'll feel it as a slow, unexplained decline.

A crawler also catches the thing single-URL tests structurally can't: drift. Page 12 has the author object. Page 400, built from an older template, doesn't. Both pass their own tests. Only a site-wide view shows you the inconsistency.

How you know this step is done: you have an exported list of validation errors grouped by type, and you know which template each cluster belongs to.

Where people go wrong: they crawl once during a big audit, fix everything, and never schedule it again. The value is in the repeat run, not the first one.

Make validation continuous, not a one-time event

Validation isn't a launch task. It's a maintenance habit, and it's the difference between markup that works and markup that used to work.

Build a rhythm in three phases.

Before deploy: lint the JSON, run the schema.org validator for vocabulary, run the Rich Results Test for eligibility, and check Google's feature docs for required properties.

After deploy: run URL Inspection immediately. Verify the detected data matches what you shipped, check the Enhancement reports for new warnings or errors, and confirm the page is indexed with the right canonical.

Ongoing: schedule a crawl weekly or bi-weekly. Filter errors by type and URL pattern. Investigate template changes that introduce mass errors. Cross-reference Search Console Enhancement reports against your crawler data, and set an alert for sudden spikes in structured data errors.

Treat it like a CI/CD step. Every template change risks breaking structured data across hundreds of pages, so the check belongs in the process, not in someone's memory.

If you're producing content at any real volume, the sustainable move is to get schema right at creation instead of auditing it back in later. That's the thinking behind how DeepSmith handles production: schema markup, heading structure, internal linking, and metadata are part of the writing pipeline rather than a cleanup pass after the draft exists. Fewer articles shipped with markup nobody validated.

Know what AI engines do with the markup you just validated

You validated for correctness. Now here's why it matters beyond a rich result.

AI search engines and LLMs, including ChatGPT, Perplexity, Claude, and Gemini, treat structured data as machine-readable entity metadata. Analysis of how these systems extract information indicates they parse JSON-LD to identify entities, relationships, and extractable facts, not just as separate metadata off to the side. Schema becomes a signal for entity disambiguation and citation.

A few engine-specific notes worth knowing:

• ChatGPT parses JSON-LD as part of page content extraction. Clear entity definitions help it identify authoritative sources.
• Perplexity treats schema as on-page content for entity identification, and particularly values Organization schema and sameAs links.
• Gemini and Google AI Mode inherit Google's structured data processing. Article, Organization, Product, and FAQ schemas influence AI Overview citations.
• Claude uses structured data for entity resolution and fact extraction, and rewards consistent entity definitions.

The practical takeaway: sameAs links matter more than most teams think. Pointing your Organization and Person markup at Wikipedia, Wikidata, LinkedIn, and official social profiles helps AI systems resolve who you are and verify identity. For Google surfaces, sameAs links to Knowledge Graph sources like Wikidata and Wikipedia carry outsized influence.

One more rule that spans every engine: match visible content. Every value in your schema should be visible to users on the page. Mismatches violate Google's guidelines and erode trust with AI systems.

Worth remembering that Google restricts FAQ rich results to authoritative government and health sites. The FAQ rich result may never appear for you. The schema is still valuable for AI extraction, which is a good example of why validating against the vocabulary and validating against Google's feature list are two different jobs.

What to do next

Pick your highest-value template. Not your whole site, one template.

Run it through all four layers today: lint the JSON, check vocabulary, test eligibility, confirm the live render. If you find errors, fix that template and you've fixed every page built on it. That's the leverage in this work, and it's why one careful pass beats a scattered afternoon of spot checks.

You've probably already done the hardest part, which was adding the markup at all. Learning to validate schema markup properly is the smaller half.

Then put the recurring crawl on your calendar. Momentum matters more than a perfect first pass.

If the real problem is that schema keeps falling off the list because your team is already behind on publishing, that's a production problem wearing a technical costume. DeepSmith builds schema markup and AEO formatting into articles during creation, and tracks which of your pages AI engines actually cite, so you can see whether the work is landing. Start a free trial and see what your pages look like when the structure is handled from the start.