A single missing comma in your JSON-LD can wipe out a rich result. Google won’t email you. It just stops showing the stars, the FAQ accordion, or the breadcrumb trail — and your click-through rate quietly drops. A schema markup validator is the tool that catches these failures before they cost you traffic.
Structured data is fussy. It follows the schema.org vocabulary, but Google layers its own eligibility rules on top, and the two don’t always agree. Therefore, knowing which validator to run, and how to read its output, matters as much as writing the markup itself. This guide covers the main schema validation tools in 2026, how they differ, the errors that actually break rich results, and a repeatable workflow you can run on every page.
What a Schema Markup Validator Actually Checks
A schema markup validator parses the structured data on a page and reports whether it is syntactically valid and semantically complete. In plain terms, it answers two questions. First, is the code well-formed? Second, does it contain the properties a given schema type requires?
There are two distinct layers of validation, and confusing them causes most of the frustration I see.
- Syntax validation — Is the JSON-LD parseable? Are quotes, brackets, and commas correct? A schema.org validator flags structural breaks here.
- Eligibility validation — Does the markup meet Google’s requirements for a specific rich result, such as
Productreview snippets orFAQPageaccordions? This is where Google’s own tools matter.
For example, your markup can be perfectly valid schema.org and still fail to produce a rich result because Google requires a property that schema.org lists as optional. Consequently, you often need more than one validator. You can run a quick syntax-and-structure pass with our free schema markup validator, then confirm rich-result eligibility with Google’s tool.
The Three Schema Validators You Should Know
The validation landscape consolidated in recent years. Google handed its general structured-data validator to the schema.org community, then split rich-result testing into its own tool. As a result, three tools cover almost every use case in 2026.
1. Schema Markup Validator (schema.org)
The official Schema Markup Validator at validator.schema.org is the successor to Google’s old Structured Data Testing Tool. It checks any schema.org markup against the full vocabulary, regardless of whether Google supports it for rich results.
This validator is vocabulary-agnostic. In other words, it tells you whether your Recipe, Event, or Dataset markup is technically correct schema.org — even for types Google ignores. Therefore, it’s the right tool for general structured-data hygiene and for non-Google search engines.
2. Rich Results Test (Google)
Google’s Rich Results Test answers a narrower question: will this page be eligible for a Google rich result? It only evaluates the schema types Google actively supports, and it applies Google’s stricter requirements on top of schema.org.
For instance, the Rich Results Test will warn you that a Product needs an offers, review, or aggregateRating property to qualify — a rule that lives in Google’s documentation, not in schema.org. Consequently, this is the tool that predicts your actual SERP appearance.
3. Search Console Rich Result Reports
The first two tools test a single URL on demand. Google Search Console monitors structured data across your entire indexed site over time. Its Enhancement reports group errors by type and show trends, which makes it the validator for catching regressions at scale.
Specifically, Search Console tells you that 47 of your product pages suddenly threw a “missing field” error after a template change — something no single-URL tester would surface. I rely on it as the early-warning system, not the debugging tool.
Quick Comparison of Schema Validation Tools
Each validator answers a different question. The table below maps tool to job so you pick the right one fast.
| Tool | What It Checks | Best For | Scope |
|---|---|---|---|
| Schema Markup Validator (schema.org) | Full schema.org vocabulary syntax | General markup correctness, non-Google engines | Single URL or pasted code |
| Rich Results Test (Google) | Google rich-result eligibility | Predicting SERP rich snippets | Single URL or pasted code |
| Search Console | Site-wide structured data health | Monitoring regressions over time | Whole indexed site |
| Our Schema Validator | JSON-LD syntax + required-property hints | Fast pre-flight before Google tests | Pasted code or URL |
JSON-LD vs Microdata: What Validators Expect
Schema.org markup comes in three formats: JSON-LD, Microdata, and RDFa. Validators read all three, but the format you choose affects how easy validation becomes.
JSON-LD is Google’s recommended format, and for good reason. It sits in a single <script> block in the page head, separate from your HTML. Therefore, when a validator flags an error, you fix one isolated block instead of hunting through nested HTML attributes.
Here is a minimal, valid JSON-LD block for an article — the kind a schema validator passes without complaint:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Schema Markup Validator Guide",
"author": {
"@type": "Person",
"name": "Jonathan Henderson"
},
"datePublished": "2026-06-03",
"image": "https://example.com/hero.jpg"
}
</script>Microdata embeds attributes directly in your HTML tags using itemscope, itemtype, and itemprop. It works, but a misplaced closing tag can break the whole item tree, and validators report those errors in ways that are harder to trace. Consequently, I migrate Microdata to JSON-LD whenever I touch a template.
If you’re starting fresh, use JSON-LD. Every major validator and every Google rich-result feature treats it as the first-class citizen.
The Schema Errors That Actually Break Rich Results
Not every validator warning matters. Some are cosmetic; others kill your rich result outright. After validating thousands of pages, these are the failures worth your attention, ranked by impact.
- Missing required properties — A
RecipewithoutrecipeIngredient, or aProductwithoutoffers. This is the single most common reason a rich result silently disappears. - Invalid JSON syntax — A trailing comma, an unescaped quote, or a broken bracket. The browser ignores it, but the validator (and Google) discards the entire block.
- Wrong value types — Supplying text where schema expects a number, such as a
pricewritten as"$19.99"instead of"19.99". - Markup that doesn’t match visible content — Marking up a 4.8-star rating that doesn’t appear on the page. Google treats this as a guidelines violation, not just an error.
- Orphaned references — A
@idpointing to an entity that doesn’t exist in the markup graph.
For example, I once saw a client lose FAQ rich results overnight. The cause was a template update that wrapped answer text in a new <div>, which left the acceptedAnswer.text property empty. The schema.org validator showed green, but the Rich Results Test flagged the missing text. That gap is exactly why you run both.
How to Validate Schema Markup: A Step-by-Step Workflow
A reliable validation routine prevents the silent failures described above. Here is the workflow I run on every page that carries structured data.
- Pre-flight the syntax. Before anything else, paste your JSON-LD into our schema markup validator to catch broken brackets and missing commas instantly. Fixing syntax first saves round-trips to Google’s slower tools.
- Confirm schema.org correctness. Run the same markup through validator.schema.org to verify it matches the vocabulary, including types Google doesn’t support.
- Test rich-result eligibility. Submit the live URL to Google’s Rich Results Test. Read the warnings, not just the errors — warnings often explain why a valid result still won’t show.
- Cross-check the visible page. Confirm every marked-up value (ratings, prices, ingredients) appears in the rendered content. Mismatches invite manual actions.
- Monitor in Search Console. After deployment, watch the Enhancement reports for a week. New errors here usually mean a template or plugin changed your output.
Notably, the order matters. Running the fast syntax check first means you reach Google’s tools with clean code, which turns a five-attempt debugging session into one or two passes.
Where SERP Preview Fits In
Schema validation and SERP appearance are connected, even though they use different tools. A serp preview tool shows how your title tag, meta description, and URL render in Google’s results — the same listing your structured data can enhance with stars, prices, or sitelinks.
Here’s the practical link. Your schema markup might make you eligible for a rich result, but Google still controls the final snippet text. A SERP preview tool lets you check whether your title gets truncated at roughly 580 pixels and whether your description reads well alongside the rich elements your schema enables.
For instance, a Product page with valid aggregateRating markup might show review stars in the SERP. But if your meta description is cut off mid-sentence, the listing still underperforms. Therefore, I treat google serp preview checks and schema validation as two halves of the same pre-publish ritual: validate the data, then preview the result.
| Task | Tool Type | What It Controls |
|---|---|---|
| Verify structured data is valid | Schema markup validator | Rich-result eligibility |
| Check how the listing renders | SERP preview | Title and description display |
| Monitor both over time | Search Console | Site-wide health and CTR |
Common Schema Validator Pitfalls (and Fixes)
Even experienced developers trip over a handful of recurring issues. These are the ones that send people to the validator confused.
- “Valid in schema.org, broken in Google.” The two tools enforce different rules. Fix: always run both, and treat Google’s Rich Results Test as the final word on rich-result eligibility.
- Validating a cached version. Your CMS or CDN may serve stale markup. Fix: paste the live source code directly into the validator, or purge the cache before testing the URL.
- JavaScript-injected schema. If a tag manager adds your JSON-LD client-side, the schema.org validator may not see it. Fix: use Google’s tools, which render JavaScript, and confirm with the URL Inspection tool in Search Console.
- Duplicate markup. A theme and an SEO plugin both inject
Organizationschema, creating conflicts. Fix: validate, find the duplicate@type, and disable one source. - Ignoring warnings. Warnings aren’t errors, but they often explain a missing rich result. Fix: read every warning and add the recommended optional properties when they apply.
How to Read Validator Output Without Panicking
The first time you paste markup into a validator and see a wall of red, it’s tempting to start changing things at random. Don’t. Validator output follows a structure, and reading it methodically turns a scary report into a short to-do list.
Every validator separates findings into three severity levels. Understanding the difference saves hours.
- Errors — These break the rich result. The block is invalid or missing a required property. Fix every error before moving on.
- Warnings — These don’t break the result, but they limit it. Adding a recommended optional property often unlocks a richer snippet. Address warnings when the property applies to your content.
- Info or non-critical items — These are suggestions. They rarely affect display, so treat them as a backlog, not a blocker.
Read the errors first, fix them, then re-validate. Often a single structural error — one missing bracket — cascades into a dozen downstream complaints that all vanish once you close the bracket. In other words, don’t count the line items; count the root causes. I’ve seen a “23 errors” report collapse to zero after fixing one unescaped quote.
When the validator points to a specific property, open the corresponding Google structured data documentation page for that type. The docs list which properties are required versus recommended, which removes the guesswork about whether a warning is worth fixing.
Validating Specific Schema Types
Different schema types carry different required properties, and the validator enforces each one separately. These are the types I validate most often, with the property that trips people up.
| Schema Type | Most-Missed Required Property | Rich Result It Enables |
|---|---|---|
Product |
offers with price and priceCurrency |
Price and availability snippet |
FAQPage |
acceptedAnswer.text |
Expandable FAQ accordion |
Recipe |
recipeIngredient |
Recipe card with ingredients |
Article |
headline and image |
Article rich card |
BreadcrumbList |
itemListElement with position |
Breadcrumb trail in SERP |
For FAQPage specifically, the most common failure is empty acceptedAnswer.text after a theme update, as described earlier. For Product, Google now requires that price and availability data match what shoppers see, so a validator pass alone isn’t enough — the visible page has to agree.
Notably, Google has narrowed which types produce rich results over time. HowTo and FAQ snippets, for instance, lost broad visibility in recent years. Therefore, validating a type doesn’t guarantee a feature; it only guarantees the markup is correct. Always confirm current eligibility against Google’s documentation.
Validating Schema at Scale
Single-URL validators work for spot checks. However, a 5,000-page e-commerce catalog needs a different approach. For sites at scale, combine three layers.
First, build validation into your deployment. Run a structured-data linter in your CI pipeline so broken JSON-LD never reaches production. Second, sample representative templates — one product page, one category page, one article — rather than every URL. Third, lean on Search Console’s Enhancement reports to catch the errors that only appear after real Googlebot crawls.
If you’re planning which schema types each page template needs before you write the markup, a structured-data planning step prevents most validation errors at the source. Mapping types to templates upfront beats fixing broken markup one validator error at a time.
Schema Validation and Technical SEO
Structured data doesn’t exist in isolation. It interacts with crawling, indexing, and canonicalization, so validation is one piece of a larger technical picture.
For example, if Google can’t crawl a page because of crawl budget limits, it never sees your perfectly valid schema. Similarly, if your canonical URLs point elsewhere, Google may attribute your structured data to a different page. Consequently, schema validation works best when your fundamentals — crawlability, canonicals, and performance — are already sound.
Structured data also supports the shift toward AI-driven search. As AI search engines parse pages, clean machine-readable markup helps them understand and cite your content. Therefore, validating schema is increasingly about more than blue-link rich results.
Frequently Asked Questions
What is a schema markup validator?
A schema markup validator is a tool that parses the structured data on a web page and reports whether it is syntactically valid and contains the properties a given schema type requires. It catches errors that would prevent rich results from appearing in search.
Is the schema.org validator the same as Google’s Rich Results Test?
No. The schema.org validator checks markup against the full schema.org vocabulary, including types Google ignores. Google’s Rich Results Test only evaluates the schema types Google supports and applies stricter eligibility rules. You should run both.
Why does my schema pass validation but show no rich result?
Valid markup is necessary but not sufficient. Google requires specific properties for each rich result, your marked-up data must match the visible page, and Google ultimately decides whether to display the result. Use the Rich Results Test to see eligibility warnings.
Which schema format should I use?
Use JSON-LD. It is Google’s recommended format, sits in a single isolated script block, and is the easiest format to validate and debug. Microdata and RDFa work but complicate troubleshooting.
How often should I validate schema markup?
Validate before publishing any page with structured data, after any template or plugin change, and monitor continuously through Search Console’s Enhancement reports. Template updates are the most common cause of sudden schema regressions.
Bottom Line
A schema markup validator is the difference between structured data you hope works and markup you know works. Run a fast syntax check first, confirm schema.org correctness, then verify rich-result eligibility with Google’s tools — and monitor the whole thing in Search Console afterward.
The errors that break rich results are predictable: missing required properties, broken JSON syntax, and markup that doesn’t match the page. Catch them with the right validator at the right step, and pair every validation with a serp preview check so the listing reads as well as it qualifies. Start with our free schema markup validator, then layer Google’s tools on top.