Schema Markup Validation: Check, Fix, Maintain

Schema markup validation is the process of checking that the structured data on a page is written correctly, matches what's visible to a user, and can actually be parsed by the systems reading it. Most people mean one of two different things when they say "validate my schema," and mixing them up is where a lot of wasted debugging time comes from: checking that the markup is syntactically correct against the schema.org vocabulary, and checking that it's eligible for a specific rich result in Google Search. Those are related checks, run by different tools, and passing one says nothing about the other.

This covers both, plus the parts that get skipped once a site grows past a handful of hand-checked pages: which validator answers which question, the errors that show up most often in practice, how your markup format affects how easy it is to validate, and why a page that validated cleanly at launch can quietly stop validating six months later.

Valid and eligible are not the same test

A page can pass a strict JSON-LD syntax check with zero errors and still never show a rich result. That's not a bug in the validator — Google layers extra requirements on top of the schema.org vocabulary itself. Only a subset of schema.org types are eligible for any rich result at all. The ones that are eligible often need a specific combination of properties that go beyond what schema.org itself marks as required. And Google applies content-matching rules on top of that: the data in your markup has to actually be present and visible on the page, not stuffed in with values a user would never see.

The reverse also happens. Markup can render a preview in a testing tool while technically containing errors against the formal vocabulary, because Google's own tools are intentionally forgiving about certain omissions that don't affect how they render the result. So when you run a check and see "no errors detected" but the rich result still isn't showing up in search, the syntax was never the problem — go check the type-specific eligibility requirements instead of re-scanning the same JSON-LD for typos.

• Syntax validity: is this correctly formed data against the schema.org vocabulary, regardless of what any search engine does with it.
• Rich result eligibility: does this specific type, with these specific properties, qualify for a specific SERP feature, per Google's own documented requirements for that feature.
• Content match: does the marked-up data actually appear, in substance, in the content a visitor sees.

Which validator answers which question

Reach for the wrong tool and you'll get an answer to a question you didn't ask. Schema.org's own validator checks your markup against the vocabulary itself — it's format-aware but search-engine-agnostic, so it will happily confirm a type is well-formed even if no search engine supports a rich result for it. Google's Rich Results Test does the opposite: it only evaluates the subset of types Google has documented rich-result support for, and it will simply ignore markup outside that list rather than tell you it's malformed.

Search Console's structured data and enhancement reports are the only place that shows validation status across an entire site rather than one URL at a time, and they're the only source that tells you something used to be valid and stopped, since they track a history rather than a single snapshot. Viewing the rendered page source, or using a browser extension that surfaces JSON-LD blocks, is the fastest way to answer a narrower but common question: is the markup actually present in what got sent to the browser, or did a template change quietly drop it. No single one of these answers all three questions, which is why a one-off check at launch tends to miss problems that a routine combining them catches early.

• Use a vocabulary-level validator to confirm the data itself is well-formed, independent of any search engine.
• Use Google's testing tool to check whether a specific page qualifies for a specific rich result today.
• Use Search Console's site-wide reports to catch regressions and track trends over time, not just a single page's status.
• Use view-source or a browser extension when you need to confirm markup exists in the delivered HTML at all, before debugging its content.

The errors that actually show up in practice

Most validation failures fall into a small number of repeating patterns, not exotic edge cases.

One category is worth calling out separately: placeholder or boilerplate values that shipped from a template and were never removed. A validator only checks structure, so it has no way to flag that every product on a site claims the same suspiciously perfect rating, or that a review count was pasted in once and never updates again. That's a policy problem, not a syntax problem, and it's exactly the kind of thing that draws a manual review rather than a rendering failure.

• A required property missing for the type in use — a Review block with no itemReviewed, a Product with no offers, an Event with no startDate.
• The wrong data type for a property — a price written as a string with a currency symbol instead of a plain number, a date that isn't in ISO 8601 format, a rating written as a word instead of a number.
• Nesting that doesn't match the type's expected structure — an @type placed at the wrong level, or a property that belongs to a nested object attached directly to the parent instead.
• Multiple JSON-LD blocks on one page that describe conflicting entities — two different Organization objects with different names, or a page that inherited a site-wide Organization block and also carries a page-specific one that contradicts it.
• Markup describing content a visitor can't actually see, whether that's hidden fields, content behind a login, or values that were simply never rendered into the page.
• Leftover placeholder values that shipped from a template, like a hardcoded five-star rating repeated on every product page regardless of the actual reviews.

Format changes how easy validation actually is

JSON-LD, Microdata and RDFa all express the same underlying vocabulary, but they don't fail the same way. Microdata and RDFa are embedded directly in HTML attributes, so the markup only validates if the surrounding element structure stays intact — a redesign that removes a wrapping div, or a class rename during a CSS refactor, can silently break the data without anyone touching a single schema property. Because the markup is fused to presentation, a change made for purely visual reasons can quietly take out structured data nobody was thinking about.

JSON-LD sits in a single script block, separate from the DOM that renders the page. That isolation is why Google recommends it and why most sites standardize on it: a template or design change doesn't touch it, so it's far more resistant to accidental breakage from unrelated work. The tradeoff runs the other way — because it isn't structurally tied to the visible markup, nothing forces it to stay in sync with the content around it. A price can change on the page while the JSON-LD block keeps the old value indefinitely, and nothing about the format itself will ever flag that drift. Validating JSON-LD for syntax is easy; validating that it still matches reality takes an explicit check, because the format that makes it easy to maintain is the same one that makes it easy to forget about.

One page validating is not the same as a site validating

On a template-driven site, a single broken data binding at the template level doesn't produce one bad page — it produces one bad page multiplied by every URL built from that template, the moment it deploys. Checking your homepage or one flagship product page and calling the site validated tells you almost nothing about the other several thousand pages using a different template with a different, unchecked binding.

The practical approach is to validate per template, not per URL: pick one representative page from each distinct page type — a product page, a category page, an article page, a location page — and treat a pass there as a signal about the whole template, not just that one URL. Site-wide crawlers and Search Console's aggregated reports exist precisely because spot-checking individual pages doesn't scale, and because a template-level bug is invisible until you look at more than one instance of it.

• Validate one representative page per template, not one page total.
• Re-validate a template any time its underlying code changes, even if the visible design looks unchanged.
• Treat a validation failure on a low-traffic page the same as one on a flagship page if they share a template — the bug is identical, only the exposure differs today.

Validation is not something you finish once

A site that validated cleanly at launch can stop validating without a single person touching the schema deliberately. A CMS plugin update changes how a field gets rendered. A theme update alters the DOM structure that Microdata depended on. A content editor deletes a field the markup was quietly pulling from. None of these read as "structured data changes" to the person making them, so nobody re-checks the markup as part of that work.

Search Console's structured data reports track counts over time rather than a single pass/fail, which is what makes them useful for this: a sudden drop in valid items after a deploy is often the first visible signal that something broke, and it can show up well before the change is noticeable in search results themselves. Treating a launch-day validation pass as permanent is the most common reason sites end up debugging a rich-result loss weeks later with no idea which of several intervening changes caused it.

The fix isn't more tooling, it's cadence: re-check structured data on a schedule, and specifically after CMS updates, theme or template changes, and content migrations, rather than only when something visibly breaks in search.

Building validation into the deploy process

Teams with an actual deploy pipeline have an option that manual spot-checking doesn't: running an automated schema check against a staging build before anything reaches production. In practice this is just parsing the JSON-LD blocks a page renders and validating their structure against the expected type as part of the same test suite that already checks for broken links or failed builds — it doesn't require new infrastructure, just treating structured data as a thing that can regress like any other output of the build.

This matters most for exactly the sites where manual spot-checking breaks down: large template-driven catalogs, frequent deploys, and multiple people touching the templates that render the markup. Catching a broken binding in a pull request costs a few minutes. Catching the same bug three weeks later, after it has shipped across ten thousand product pages and shown up as a Search Console warning, costs a lot more than a few minutes — and by then nobody remembers which deploy caused it.