Validation Is a Gate, Not a Goal
Most teams treat the Rich Results Test as the finish line for structured data. Mark it up, validate it, ship it. But Google’s validation pipeline and its actual usage of schema for ranking or SERP feature eligibility are two separate systems, and conflating them is why you can have perfectly valid JSON-LD producing zero SERP impact for months.
That gap matters more now. As AI Overviews, Knowledge Panels, and entity-based features pull more heavily from structured data, the distance between “validates” and “gets used” is the distance between appearing in features and not appearing at all.
What Validation Actually Checks
Google’s Rich Results Test and Schema.org validators check syntax and required property coverage against the spec. Is the markup well-formed? Are the minimum required fields present? For Product, that means name. For Article, headline and author. Pass those, get a green checkmark.
What they don’t check:
- Whether the marked-up content matches what’s actually visible on the page
- Whether Google’s indexing pipeline has processed the rendered version of the page, not just the raw HTML
- Whether the entity described in the markup is resolvable in Google’s Knowledge Graph
- Whether the page’s quality tier is high enough to be eligible for the feature in the first place
That last one bites the most. A low-trust domain can have flawless schema and still not get the rich result. Google has said explicitly that structured data eligibility depends on search quality guidelines — E-E-A-T signals feed into whether the feature fires, not just whether the markup is valid.
The Rendering Gap Most Audits Miss
If your structured data lives inside JavaScript-rendered content — injected by a tag manager, React component, or CMS plugin — it may not exist in the HTML Googlebot processes at crawl time. It only exists after rendering.
Google does eventually render pages through its secondary indexing wave, but “eventually” isn’t synchronous with crawling. There’s often a multi-day gap between when Googlebot fetches a URL and when it processes the rendered DOM. During that window, your schema doesn’t exist as far as the indexing pipeline is concerned.
Run a fetch in Search Console via the URL Inspection tool’s “Test Live URL” option and check the rendered HTML, not the source HTML. If your JSON-LD block only appears in the rendered version, that’s the problem. Server-side render the structured data or inject it into the raw HTML response. Once you’ve confirmed the diagnosis, the fix is straightforward.
Entity Resolvability: The Harder Problem
This is the issue that gets almost no coverage in structured data guides.
When you mark up an Organization, Person, or Product entity, Google attempts to resolve that entity against its Knowledge Graph. If the entity isn’t resolvable — no Wikidata ID, no strong co-citation signal, no corroborating mentions from trusted sources — the structured data is technically valid but the entity claims carry very little weight.
This is why adding sameAs properties pointing to Wikidata, LinkedIn, Crunchbase, or Pitchbook entries isn’t a nice-to-have. It’s how you connect your markup to an entity Google can actually verify. Without that connection, you’re asserting claims about an entity Google can’t confirm exists, and Google’s default behavior is to downweight unverifiable claims.
We’ve seen this pattern in client work: two sites with identical schema markup, one with a resolvable entity in the Knowledge Graph, one without. Knowledge Panel fires for one, not the other. The feature isn’t broken — the entity just isn’t grounded.
Property Coverage vs. Property Signal Strength
Schema.org specs define required and recommended properties. Required means the feature won’t fire without them. Recommended means it may fire without them, but feature quality and likely signal strength depend on them.
Take AggregateRating. You can validate a Product with a ratingValue of 5.0 from a reviewCount of 1. Passes validation. But Google applies manual quality checks here — suspiciously high ratings with implausibly low review counts, or aggregate ratings that don’t match the reviews actually on the page, get treated as manipulative. The feature either won’t fire or fires and then gets suppressed when the quality classifier flags it.
None of that is documented in the Rich Results spec. It’s enforced through a layer of quality heuristics that run after validation, which means your testing environment doesn’t surface it.
FAQ and HowTo: The Post-Helpful-Content Reality
Worth addressing directly because a lot of sites still have these deployed at scale: Google reduced FAQ rich results to only high-authority government and health sites in late 2023. HowTo results were removed from desktop almost entirely at the same time.
If you’re still relying on FAQPage markup for rich result eligibility on a standard informational site, you’re not getting the feature. The markup may still carry some entity and topical context signal, but the visible SERP feature is gone for most sites. Your validation will still pass. The feature just won’t fire.
This is the clearest example of the validation-vs-usage gap. Google changed usage behavior without changing the spec or the validator. Nothing in your tooling tells you the feature is no longer available to you.
What Actually Moves the Needle
In rough priority order:
- Server-render your JSON-LD. It needs to be in the raw HTML response, not just the rendered DOM.
- Add
sameAsto resolvable external identifiers. Wikidata, LinkedIn, Crunchbase for organizations. ORCID or Google Scholar for individuals. GTIN, ISBN, or MPN for products. Connect your entity to something Google can verify independently. - Keep marked-up content consistent with visible page content. Google explicitly flags markup that describes content not present on the page as a violation — and beyond the penalty risk, it degrades signal quality.
- Don’t pad for coverage. A
Productpage with 40 schema properties, half of them empty strings or placeholders, is weaker than one with 12 accurate, populated properties. - Audit feature eligibility before deploying at scale. Search Console’s Rich Results report shows what’s actually appearing, not what’s validating. The gap between those two numbers tells you more than any test tool.
One Caveat Worth Naming
A lot of structured data impact is domain-quality-gated in ways schema work alone can’t fix. If a site is carrying an unhelpful content penalty or is a low-PageRank domain, fixing schema implementation is the last marginal gain, not the first. The quality classifier has to clear before feature eligibility matters.
If you’re validating at 90%+ but appearing in features at a fraction of that, the gap is almost certainly entity resolvability or domain quality — not markup syntax. That’s where the next sprint should go, not on finding more properties to populate.