Google's Rich Results Test is free, and it's the most commonly recommended way to check schema. It also checks something narrower than most people assume, and knowing the difference keeps you from either trusting a false pass or panicking over a warning that doesn't actually matter.
What it actually checks
The tool loads your page (rendering JavaScript, the same way Google's own crawler does), parses whatever JSON-LD or microdata it finds, and reports whether that markup is eligible for the specific rich result features Google currently supports, things like article, product, FAQ, or local business markup that can produce an enhanced search result. It sorts findings into errors, which block eligibility outright, warnings, which flag missed opportunities without breaking anything, and suggestions for further enhancement.
What it doesn't check
- Types Google doesn't currently give a rich result for. A perfectly valid
HomeAndConstructionBusinessorServiceblock can pass general schema.org validation while the Rich Results Test has nothing to say about it, because Google doesn't attach a visual search feature to that type. That's not a failure; it's just outside what the tool reports on. - Other search engines. This is a Google-specific tool. It says nothing about how Bing or any other engine reads the same markup.
- Every possible syntax error. It's been known to pass JSON-LD with small formatting issues that a stricter validator would catch.
A sensible order to test in
- Validate the raw structure first, with a general schema.org validator, to catch basic syntax problems before worrying about Google-specific eligibility.
- Run the Rich Results Test on the live page, not just a code snippet, so it's checking what actually renders.
- Watch Search Console's structured data reports over time, rather than treating a single passing test as permanent. The Rich Results Test is a snapshot of one moment; Search Console tracks your whole site as it changes and can catch a regression introduced weeks later that a one-time test would never see.
Why a one-time test isn't enough on its own
Schema tends to break quietly. A site redesign, a content update, or a small template change can silently remove or corrupt structured data without anyone noticing, since it's invisible to a normal visitor looking at the page. A passing test today says nothing about six months from now. Search Console's reports are the part of this workflow that actually catches that kind of drift, because they're monitoring continuously instead of checking once.
What a failing test actually costs you
It's worth knowing the scope of the consequence. Google's own documentation on structured data guidelines states plainly that losing rich result eligibility "doesn't affect how the page ranks in Google web search." A schema error costs you a visual feature in the search result, not your position in it. That's a reason to fix it, not a reason to treat it as a crisis.
What changed for FAQ schema specifically
It's worth a direct note here, since it trips people up: Rich Results Test support for FAQ markup was removed in June 2026, as part of Google's broader removal of FAQ rich results from search entirely. If you test a page with FAQPage schema and get no FAQ-specific feedback, that's expected now, not a bug in your markup. See FAQ schema after Google's May 2026 change for the full timeline of what changed and why FAQ schema is still worth having on the page regardless.
Questions
Do I need to test every page individually?
For pages with genuinely different content (each service page, for instance), yes. Testing one page and assuming the rest are fine misses real per-page errors.
What should I do if a type I'm using has no rich result?
Nothing, beyond making sure the markup is technically valid. Not every schema type is meant to produce a visible search feature; some exist purely to help machines understand your content accurately.
How often should I re-check my schema?
After any site change that touches templates or content structure, and periodically by reviewing Search Console's structured data reports rather than relying on memory of a past test.