A product page's JSON-LD passes the schema.org validator without errors, but weeks later Google Search still shows no product rich result for those pages. How would you investigate?

## Separate the four things that can be wrong When structured data "does nothing", exactly one of four layers is usually at fault: the markup is not valid, it is valid but not *eligible*, it is eligible but the crawler never saw it, or everything is fine and the feature simply was not granted. Diagnose in that order. ## 1. Valid is not the same as eligible The schema.org validator answers a vocabulary question: are these real types and properties, and is the JSON parseable? A search feature asks a stricter question: does this node carry the properties *that feature* requires. A `Product` with only `name` is perfectly valid schema.org and useless for a product result — the merchant-listing feature wants an `offers` node with `price` and `priceCurrency`, an image, and so on. So run the **live URL** through Google's Rich Results Test rather than pasting a snippet. It reports which features the page is detected for, and lists errors (blocking) and warnings (recommended properties whose absence degrades but does not disqualify). A page with zero detected items and a clean schema.org validation is the classic signature of this layer. ## 2. Does the crawler receive the block at all? Request the page the way a crawler does — a plain HTTP fetch, no JavaScript — and search the response body for `application/ld+json`. If the block is absent, it is being injected at runtime by client-side code. Google does render JavaScript, but rendering happens in a separate, deferred pass, and other consumers may never run scripts at all. Server-render the block; it is inert data, so there is no reason for it to depend on hydration. Other delivery-layer causes worth ruling out: the page is not indexed at all, the block is inside a fragment loaded on interaction (behind a tab or a "show details" toggle rendered only on click), or a build step minified the HTML in a way that broke the JSON. Also check the JSON is genuinely parseable in the delivered form. Escaping bugs — an unescaped closing script sequence in a product title, an ampersand written as a character reference and therefore left literal, a smart quote from the CMS — kill the whole block silently while the page renders normally. ## 3. Does the data describe what the user sees? Search engines require structured data to represent content that is present and visible on the page. Assertions the page does not support are a policy problem, and the outcome is not "no rich result" but potentially a manual action against the site. Look for the usual drift: - a rating or review count that appears nowhere in the UI; - a price the JSON-LD took from the list price while the page shows a promotional one; - `availability` hardcoded to `https://schema.org/InStock` on a template used for sold-out items; - FAQ content marked up but hidden behind an accordion that never renders its answers into the DOM; - markup describing the whole catalogue on a category page as if it were one product. This is where the JSON-LD tradeoff bites: because the block is a second copy of the facts, only discipline keeps it true. The structural fix is to serialize it from the same object that renders the visible content, not to audit it by hand. ## 4. Eligible is not guaranteed, and features change Even a perfect implementation only becomes *eligible*. Whether a given result is shown is a per-query, per-page decision, and search engines have narrowed or retired features over time — FAQ rich results, for example, were restricted to a narrow class of authoritative sites, so pages that once showed them stopped. If the feature you are chasing no longer exists for sites like yours, no amount of markup will bring it back. ## Where to look for evidence **Search Console** is the instrument, not the browser. Its enhancement reports list detected item types with counts of valid, warning and error items, so you can see whether the pages are recognised at scale rather than one URL at a time. "Unparsable structured data" is its own report and is where escaping bugs surface. Manual actions appear under their own section. And a URL inspection tells you whether the page is indexed and what the rendered HTML contained. Give it time, too: indexing and re-processing take days to weeks, so a change made last night explains nothing. ## What a strong answer sounds like The weak answer adds more properties and hopes. The strong answer is a triage: prove the feature's requirements are met with the feature-specific test, prove the crawler receives the block by fetching the raw HTML, prove the data matches the page, then say plainly that eligibility is not a guarantee and set the team's expectation accordingly.