TL;DR
Google's own documentation explicitly distinguishes two separate validation tiers: the Schema Markup Validator checks spec compliance (valid types, allowed properties), while the Rich Results Test checks Google-specific eligibility — markup can pass one and fail the other. As of January 2026, Google removed FAQ rich results from Search Console and the Rich Results Test entirely, meaning markup that validated cleanly for years suddenly produced zero visible results with no build error. The default failure mode isn't bad markup but silent drift: a CMS field rename, a cloned template with the wrong @type, or a redesign that drops a required property — none of which throws an error until traffic drops weeks later.
The article's verdict is a repeatable workflow: map each content type to a fixed set of schema.org types before writing markup, build from templates (not by hand), lint JSON syntax pre-commit, run the Schema Markup Validator against rendered output, then run the Rich Results Test per page pre-publish, and finally automate periodic re-checks of published pages using Search Console reports to catch drift after the fact.
Structured data validation is the practice of checking schema.org markup — usually JSON-LD — against two separate standards before it ships: whether it's syntactically valid per the schema.org vocabulary, and whether it meets the specific eligibility requirements of the search or AI system consuming it. Those are different checks, run by different tools, and conflating them is the single most common reason schema "passes" in one tool and silently fails in another.
Most content teams treat validation as a one-time step: someone pastes markup into a tester when a template ships, sees a green checkmark, and moves on. That works until a CMS field gets renamed, a template is copy-pasted into a new page type with the wrong @type, or a required property quietly goes missing after a redesign. None of that throws a build error. It just stops showing up in rich results, and nobody notices until traffic or citations drop weeks later.
What "valid" actually means — two different bars
Google draws this distinction directly in its own documentation: the Schema Markup Validator checks strict compliance with the schema.org vocabulary — is the JSON well-formed, does the type exist, is the property allowed on that type — while the Rich Results Test checks something narrower and stricter: whether this specific page meets Google's requirements for a specific rich result feature. Markup can be perfectly valid schema.org and still fail the Rich Results Test because it's missing a property Google requires for that feature, or pass the Rich Results Test for one property set while omitting recommended fields that would improve result quality.
Google's General Structured Data Guidelines formalize this as two tiers. Technical guidelines are the automatable ones — supported format, no blocking via robots.txt or noindex, required properties present — and the guidelines page states plainly that you can test these with the Rich Results Test and the URL Inspection tool, which catch most technical errors. Quality guidelines are the second tier, and Google is explicit that these "aren't easily testable using an automated tool": markup has to be an accurate representation of visible page content, not describe information the user can't actually see, and not exist on a page created solely to hold structured data. A tool can tell you your Recipe markup is syntactically perfect. No tool can tell you the recipe isn't actually on the page.
The workflow breaks because it's manual and one-shot
The default failure mode isn't bad markup — it's markup that was correct once and drifted. A template change ripples across hundreds of pages before anyone re-checks a sample. A CMS migration remaps a field name. Someone adds a new content type by cloning an existing template and forgets to update the @type. Google's own changelog shows how often the ground shifts under teams that "validate once": as of the January 2026 deprecation cycle, Google removed FAQ rich results from Search Console reporting, the Rich Results Test, and search appearance filters entirely — markup that validated cleanly for years stopped producing any visible result, through no fault of the page. Teams running validation only at template-launch time had no way to catch that until organic click-through on FAQ pages quietly dropped.
Tools compared
| Tool | What it actually checks | Best used for | What it misses |
|---|---|---|---|
| Schema.org Markup Validator | Spec compliance: valid types, allowed properties, correct nesting, JSON-LD/RDFa/Microdata parsing | Development-time authoring; confirming markup matches the schema.org vocabulary | Says nothing about Google-specific eligibility or which rich result (if any) will render |
| Google Rich Results Test | Google's eligibility rules for a specific rich result feature on a specific URL; live preview of the rendered result | Pre-publish check on templated pages, one page at a time | Doesn't check schema.org compliance broadly, doesn't check quality guidelines, no bulk/URL-list mode |
| URL Inspection tool (Search Console) | Whether a page as Google actually crawled and indexed it carries valid structured data | Confirming what Google saw, not what your CMS renders | Only works post-indexing, one URL at a time, requires property verification |
| Search Console rich result reports | Aggregate errors/warnings across every indexed page with a given markup type | Catching site-wide drift after the fact | Reactive by design — surfaces problems days after Google recrawled, not before publish |
| JSON syntax lint / schema check in CI | Whether the JSON-LD block is well-formed and matches an internal required-fields contract | Blocking a broken template from merging at all | Doesn't know Google's or schema.org's actual rules unless someone encodes them — catches your bugs, not spec violations |
No single row in that table is a complete workflow. The Schema Markup Validator and the Rich Results Test check different things on purpose, and both operate on one URL or snippet at a time — neither is built to watch hundreds of published pages for drift.
For the broader toolkit beyond validators — first-party data sources, crawlers, and AI-answer tracking tools — see our roundup of 20 free GEO and AEO tools for AI search visibility.
A repeatable workflow
- Decide which schema types apply per content type. Not every blog post needs
FAQPage; not every product page needs the fullOffernesting. Map content types to a fixed, documented set of schema.org types before anyone writes markup, so validation later has a known target instead of "whatever looks right."
- Build markup from a template, not by hand per page. Google explicitly recommends JSON-LD specifically because it lives in a single script tag, separate from visible HTML — that's what makes it template-able and what makes drift detectable, since the markup isn't tangled into layout markup that changes for unrelated reasons.
- Lint JSON syntax pre-commit. A malformed JSON-LD block (trailing comma, unescaped quote) is the cheapest possible failure to catch, and the only one worth catching before any external tool is involved.
- Run the Schema.org Markup Validator against the rendered output. This is the spec-compliance gate: correct
@type, only properties that type actually supports, correct nesting. It catches structural mistakes the Rich Results Test won't flag because they don't map to a specific Google feature.
- Run the Rich Results Test against representative URLs per template, not every page. Because it's Google-eligibility-specific, this is where required-vs-recommended properties get checked. Test one real page per template, not every instance — the point is catching template-level defects, not brute-forcing every URL.
- Do a manual pass against Google's quality guidelines. This step has no tool. Someone has to confirm the markup describes what's actually visible on the page and isn't padded with information a user can't see — the General Structured Data Guidelines page names this directly as untestable by automation.
- Gate merges on steps 3–5 in CI, and treat step 6 as a required reviewer checklist item on any new template, not a one-time audit.
- Spot-check post-publish via Search Console's rich result reports. This is the drift detector — it catches template regressions and spec deprecations (like the FAQ rich results removal) that only show up after Google has recrawled at scale.
- Re-run the full workflow whenever a template changes, a CMS field is renamed, or Google announces a structured data deprecation — treat schema.org and Search Central changelogs as a dependency to watch, not a one-time reference.
What this doesn't guarantee
Passing every check above does not guarantee a rich result, and it does not do anything for AI citation on its own. Google has said this directly and repeatedly: at a Search Central Live event, Search Relations staff including John Mueller stated there's no special optimization for appearing in AI Overviews, and that structured data is not required for generative AI search — reported in detail by Search Engine Journal, which also notes Google has said structured data is not a ranking factor. Search Engine Roundtable's coverage of Mueller's comments on schema and LLMs lands on the same point: no AI-specific schema type exists, and none confers an advantage in AI answer generation.
What structured data actually does is remove ambiguity for systems that are already trying to understand your page — both Google's rich-result pipeline and, plausibly, retrieval-augmented systems grounding an AI answer in a source. It doesn't create relevance or authority that isn't already there in the content. Valid Product markup on a page with thin, unverifiable product information will validate cleanly and still never be cited by anything, because the markup was never the bottleneck — the content was. Treat validation as removing a structural barrier to being read correctly, not as a lever for being read more.
It's also worth internalizing that "valid" has a shelf life. Schema.org's vocabulary and Google's supported-feature list both change; the FAQ rich results removal is the clearest recent example of markup that was correct on the day it shipped losing its visible payoff without any change to the markup itself.
Where nqzai fits
nqzai's structured data checks run against published pages on a schedule, not just at template-launch time — flagging when markup drifts from a page's actual visible content, when a required property silently disappears after a CMS or template change, and when a schema type a page relies on gets deprecated upstream. That drift detection is paired with tracking of whether pages are actually showing up in AI-generated answers, so a content team can see both sides at once: is the markup still structurally sound, and separately, is the content it describes actually getting cited. The two signals are kept distinct on purpose, because — per Google's own statements above — fixing the first doesn't move the second by itself.
FAQ
Does valid schema.org markup guarantee my page shows a Google rich result?
No. Technical validity (schema.org compliance, Rich Results Test pass) is necessary but not sufficient. Google's own structured data guidelines list separate, tool-untestable quality guidelines — accurate representation of visible content, no hidden data — that can prevent a rich result even when markup is technically flawless.
Do AI Overviews or other AI search features require structured data?
No. Google's Search Relations team has stated there's no special AI optimization and no AI-specific schema type, as reported by Search Engine Journal and Search Engine Roundtable. Structured data can still help by making page content unambiguous to any system parsing it, but it isn't a prerequisite for AI citation.
What's the actual difference between the Schema Markup Validator and the Rich Results Test?
The Schema Markup Validator checks generic schema.org spec compliance — valid types and properties, correct nesting — with no awareness of Google features. The Rich Results Test checks whether a specific page qualifies for a specific Google rich result feature and previews how it would render. Use the validator during authoring; use the Rich Results Test before publishing a new template.
Should validation run in CI, or is a pre-publish manual check enough?
Syntax and required-field checks belong in CI, because template-level bugs otherwise ship silently to every page using that template. Quality-guideline review (does the markup match what's visibly on the page) has no automated equivalent and needs a human reviewer step on any new template — CI can't substitute for it.
How often should already-published pages be re-validated, not just new ones?
At minimum whenever a template or CMS field changes, and periodically against Search Console's rich result reports, which surface drift and deprecations (like the FAQ rich results removal) that don't show up in a one-time pre-publish check. Markup that was correct at launch can go stale without a single edit to the page.
