I get some version of this question constantly: which schema testing tool is the right one? The honest answer is that none of the three main tools does the whole job, and the disagreements between them are not bugs — they come from each tool measuring something different. Once you know what each one is actually checking, the fact that they give different answers on the same URL stops being confusing.

Rich Results Test: eligibility, not correctness

The Rich Results Test (search.google.com/test/rich-results) answers one question: can Google generate a specific rich result feature from this page. It is scoped to the subset of schema.org types that map to a visible search feature — Product, Review, FAQ, HowTo, Article, and a handful of others. It renders the page the way Googlebot does, executing JavaScript, which means it is the only one of the three tools that reliably tells you whether client-side-injected markup actually reaches the rendered DOM. What it will not do is validate a type it does not use for a rich result. Point it at a page with MedicalEntity or Dataset markup and it has nothing to say, not because your markup is wrong but because Google has no rich result feature tied to that type.

Schema Markup Validator: full vocabulary, no eligibility check

The Schema Markup Validator (validator.schema.org) is the general-purpose tool built and maintained by the schema.org project itself, independent of Google. It checks your markup against the complete schema.org vocabulary, which is thousands of types, not the handful Google surfaces as rich results. This makes it the right tool when you are implementing a type Google does not have a feature for, or when you want to confirm every property you set is spelled correctly and typed correctly regardless of whether Google cares about it. The tradeoff is that a clean pass here tells you nothing about whether a rich result will actually appear. I have seen markup validate perfectly here while the Rich Results Test flags it as ineligible, because the Validator does not apply Google’s additional eligibility rules on top of the base spec.

Search Console: aggregate, delayed, but authoritative

Search Console is different from the other two in a fundamental way — it is not a testing tool you point at one URL, it is a report on what Google has already done across your entire indexed site. The Enhancements reports (Products, FAQ, Breadcrumbs, and so on, depending on what schema Google detects) show you counts of valid, warning, and error pages aggregated across your whole domain. This is the only place you can answer “how is my schema doing site-wide” rather than “how is this one page doing.” The catch is timing: the data reflects Google’s last crawl and processing pass, which can lag actual changes by days to weeks. I never treat Search Console as a same-day feedback loop. I treat it as the record of what actually stuck after the crawl caught up, which is a different and, for auditing purposes, more important question than what a single-URL test tells you at the moment you run it.

Where they disagree, and what to do about it

The disagreements follow a pattern once you know to look for it. A page can pass the Validator (technically correct markup) and fail the Rich Results Test (not eligible for a Google feature, often due to a missing recommended property Google requires for eligibility but schema.org does not require for validity). A page can pass the Rich Results Test today and later show errors in Search Console, because Search Console reflects a crawl that happened after a template change you made in between. And a page can look fine in both single-URL tools while Search Console shows errors, because the two tools tested the version you have now, while Search Console is reporting on the version Google actually crawled and rendered, which is not always identical if there is a rendering, caching, or CDN issue in the path.

None of that means the tools are unreliable. It means each one is answering a narrower question than “is my schema working,” and you need at least two of them, checked in sequence, to get a real answer. I cover the actual sequencing I use for that in my testing workflow, which walks through running all three in the order that catches the most issues with the least wasted effort.

A short buyer’s guide by situation

  • Just deployed new markup on one page and want a fast eligibility check: Rich Results Test.
  • Implementing a type Google does not use for rich results, or want full spec compliance: Schema Markup Validator.
  • Want to know how your schema is performing across the whole site, not one page: Search Console Enhancements.
  • Not sure why a warning is showing and whether it matters: see warnings vs. errors for how I prioritize them.
  • Rich results were showing and then stopped: see why rich results are not showing before assuming your markup broke.

Tools I use alongside the three main ones

Beyond the three tools most people ask about, I lean on two others often enough that they are worth mentioning. The first is a plain view-source check, or a browser’s developer tools, to confirm the JSON-LD block is actually present in the rendered DOM before I bother running any formal test — this catches cases where a caching layer, a CDN edge rule, or a template conditional strips the block out for certain requests but not others, which none of the three main tools will explain on their own since they only tell you the result did not validate, not why the code was not there. The second is a crawler with custom extraction, which I cover in more depth for site-wide checks, since none of the single-URL tools were built to answer “how many of my four hundred product pages actually have this property” in one pass.

I also keep a browser extension installed that flags structured data on any page I visit without needing to open a separate tool, which is useful for quickly checking competitor pages or spot-checking my own site while browsing normally, though I treat what it shows as a rough signal rather than a substitute for actually running the Rich Results Test or Validator when something needs a real answer.

If you are testing across a large site and the pattern of errors is not obvious from any single tool, that is usually a sign the issue is in a template rather than a page, which is the kind of problem I help clients work through in schema markup consulting.