How to Validate Your Schema Markup Before Publishing

You've spent time writing your JSON-LD, placing it correctly in your HTML, and mapping every property to the right schema type. The last thing you want is to push it live and discover it's been silently broken from the start. Validation is the step most people skip, or do badly, and it's the reason a lot of schema markup does absolutely nothing.

This guide covers exactly how to validate schema markup before it goes anywhere near your live site, what the different tools actually check, and where they fall short.

Why Validation Matters More Than You Think

Invalid schema doesn't just fail to help you. In some cases, it can actively confuse search engines and AI systems by sending contradictory signals about your content. Google has said that structured data with critical errors may be ignored entirely. That means the effort you put into writing the markup is wasted.

There are three types of problems you're looking for when you validate:

• Syntax errors - broken JSON that won't parse at all. A missing closing brace, a trailing comma, an unescaped character. These are fatal.
• Schema errors - technically valid JSON, but properties that don't match what Schema.org defines. Using productName instead of name, for example.
• Missing recommended properties - the markup parses fine, but it's missing fields that Google (or an AI system) would want to see. Not fatal, but you're leaving visibility on the table.

Each type of problem requires a slightly different tool to catch it reliably.

Google's Rich Results Test

This is the most important validator for anything you want to show up in Google's search features. You can find it at search.google.com/test/rich-results.

You can test by URL (if the page is already live or accessible) or by pasting raw code directly. The code snippet option is particularly useful because it means you can validate before the page is anywhere near production.

What it tells you

The Rich Results Test shows you whether Google can detect your structured data, which schema types it found, and whether those types are eligible for rich results. It lists errors and warnings separately. Errors block rich results entirely. Warnings mean you're missing recommended (but not required) properties.

One important thing to understand: not every schema type is eligible for rich results. Product, Review, FAQ, Event, Recipe, and a handful of others are. But Organisation, Person, WebPage, and BreadcrumbList don't produce visible rich results in the same way. They still matter for AI visibility, but Google's Rich Results Test won't flag them as "valid" in the way you might expect. Don't assume a lack of rich results eligibility means the markup is wrong.

Its limitations

The Rich Results Test only checks types Google has built rich result features for. If you're implementing WebSite schema for a sitelinks search box, or speakable schema for voice, it may not give you useful feedback. And it says nothing about how AI engines like ChatGPT or Perplexity interpret your markup.

Google Search Console's Rich Results Report

Once your pages are live, Google Search Console gives you a long-term validation view. Under the Enhancements section in the left sidebar, you'll see reports for each schema type Google has found across your site.

This is where you catch problems that only show up at scale. A template bug that affects every product page, for instance, or a date formatting issue introduced by a CMS update. The Rich Results Test checks one page at a time. Search Console monitors everything, continuously.

Look at the "Error" and "Valid with warnings" counts regularly, not just after initial implementation. Schema can break when themes update, when JavaScript rendering changes, or when new content is added that doesn't match your template assumptions.

Schema.org Validator

The official Schema.org validator lives at validator.schema.org. It's less well known than Google's tool, but it checks something different and arguably more fundamental.

While Google's tool checks whether your markup qualifies for Google's specific rich result features, the Schema.org validator checks conformance against the actual Schema.org vocabulary itself. It tells you whether you're using recognised types and properties, regardless of what Google has chosen to support.

This matters because AI systems don't only care about Google's subset of schema. Tools like Perplexity, Gemini, and ChatGPT read structured data more broadly. If you're adding markup primarily for AI visibility, the Schema.org validator is the better primary check.

How to use it

Paste your JSON-LD directly into the input field or provide a URL. The validator highlights any types or properties it doesn't recognise. It won't tell you whether Google will show rich results, but it will tell you whether your schema is structurally and semantically correct according to the vocabulary.

A JSON Linter for Syntax Checks

Before you run any schema-specific tool, run your JSON through a plain JSON linter. jsonlint.com is simple and reliable. Paste in your script block contents (not including the surrounding <script> tags) and it will tell you immediately whether the JSON is valid.

This sounds basic, but it's worth doing as a first step every single time. Schema validators will report a broken document, but they sometimes give confusing error messages when the underlying problem is just a stray comma or a mismatched bracket. A JSON linter isolates that immediately.

Common syntax mistakes to look out for:

• Trailing commas after the last property in an object or array
• Single quotes instead of double quotes around strings
• Unescaped special characters (particularly in description fields)
• Missing commas between properties
• Unclosed braces or brackets in nested objects like offers or author

Manual Property Checks Against Schema.org Documentation

No automated tool catches everything. If you're implementing a less common schema type, or using properties in a way that's technically valid but semantically wrong, the validators will pass it without complaint.

Get into the habit of checking your key property names directly against schema.org. Every type has a documentation page listing its expected properties, their expected data types (Text, URL, Number, Thing, etc.), and notes on usage.

A few specific things to check manually:

• Date formats - Google expects ISO 8601. That means 2024-03-15, not "15 March 2024" or "03/15/2024".
• URL values - Properties like url, image, and logo should be absolute URLs, not relative paths.
• PriceSpecification details - If you're doing Product schema, check that priceCurrency uses the correct ISO 4217 code (GBP, USD, EUR) and that price is a number, not a string like "£49.99".
• @type capitalisation - Schema.org types use PascalCase. LocalBusiness not localbusiness or local_business.

Testing in a Staging Environment First

If you're adding schema to a Shopify or WordPress site, do your validation in a staging or preview environment before touching the live site. Both platforms let you preview pages before publishing. Use that preview URL in Google's Rich Results Test.

On Shopify, you can test changes in a duplicate theme. On WordPress, staging plugins like WP Stagecoach or your host's built-in staging tools let you validate without any risk to production. This is especially worth doing if you're modifying a theme's template files rather than adding schema through a plugin, because template changes affect every page that uses that template.

At FlinnSchema, every schema implementation goes through a staged validation process before anything touches a client's live site. It adds maybe 20 minutes to the process and has caught real problems more than once.

Checking Rendering: Dynamic and JavaScript-Rendered Schema

If your site renders content via JavaScript (common in headless setups or some Shopify themes), there's an additional layer to check. Googlebot and many AI crawlers need to render JavaScript to see schema that's injected dynamically. Some can't do this reliably.

Use Google Search Console's URL Inspection tool and click "View Crawled Page" then "More Info" to see the rendered HTML. Check that your schema appears in the rendered source, not just in the pre-render source code. If it doesn't, your schema is invisible to crawlers that don't execute JavaScript, which includes many AI systems.

The fix is usually to move your JSON-LD into the static HTML of the page rather than injecting it via JavaScript after page load. This is one reason placing JSON-LD in the correct part of the HTML matters more than it might seem.

What to Do When Validation Passes But Nothing Changes

You've run every check, everything passes, but you're still not seeing rich results or AI mentions. A few things to consider:

First, Google takes time. After fixing or adding schema, it can take several weeks before you see changes in Search Console or in search results. Don't expect instant results.

Second, passing validation is a necessary condition, not a sufficient one. Google also considers page quality, authority, and whether your content actually matches what the markup claims. A product page with a 200-word description and no reviews is unlikely to earn rich results even with technically perfect schema.

Third, if your goal is AI search visibility rather than Google rich results, the signals matter beyond just schema. Content structure, factual clarity, and how well your pages answer specific questions all feed into whether AI engines cite your content. A free AI visibility audit can show you where the gaps actually are, rather than guessing.

If you want to go deeper on which schema types to prioritise for an e-commerce site, this post covers the essential types in detail.

Frequently Asked Questions

Is Google's Rich Results Test enough to fully validate my schema?

No. It's the most important tool if you're targeting Google rich results, but it only checks a subset of schema types and says nothing about Schema.org conformance more broadly or AI engine readability. Use it alongside the Schema.org validator and a JSON linter for a proper check.

My schema has warnings but no errors. Is that fine?

Warnings mean you're missing recommended properties, not required ones. Your markup will still work, but you may be missing out on richer results or better AI interpretability. It's worth looking at each warning and deciding whether adding the property is practical. For Product schema, warnings about review or aggregateRating are worth addressing if you have that data available.

How often should I re-validate my schema after it's live?

At minimum, check Search Console's rich results reports monthly. Also re-validate whenever you update your theme, change your CMS version, modify template files, or add new content types to the site. Schema breaks silently and often goes unnoticed for months.

Can I validate schema for AI search engines specifically?

Not directly. No equivalent of the Rich Results Test exists for ChatGPT or Perplexity. Your best approach is to use the Schema.org validator (which checks the full vocabulary, not just Google's subset), ensure your markup is in static HTML rather than JavaScript-rendered, and test whether AI tools actually mention your business by querying them directly. You can also run a free AI visibility audit to get a clearer picture of how well your site is set up for AI search.