The first thing to verify, before treating this as a mystery, is whether the implementation is actually identical, because at scale it rarely is. Templated e-commerce schema looks identical in the abstract (same JSON-LD structure, same properties populated from the same CMS fields), but the actual data flowing into that template diverges page to page: different stock/price sync timing, different underlying page quality (thin variant pages, near-duplicate content across color/size variants), different crawl and index recency, or different individual-page policy compliance. “Identical pattern” is not the same as “identical outcome,” and the diagnostic work is in finding which specific difference is driving the split.
Why identical markup can produce different rich-result outcomes
Google’s own position, stated across its general structured data guidelines, is that valid markup is necessary but not sufficient for rich result display. Display eligibility factors in page-level and site-level quality signals, policy compliance, and algorithmic decisions that aren’t fully disclosed, on top of pure schema validity. This means two pages with byte-for-byte identical Product/Offer/aggregateRating JSON-LD can genuinely receive different treatment if the pages around that markup differ in ways Google’s broader quality systems weigh, even when the schema itself is equally well-formed on both.
A diagnostic workflow
Check per-URL validation status individually, not just the template. Run the Rich Results Test or Search Console’s URL Inspection tool against several of the underperforming pages specifically, not just a representative template sample. Confirm there isn’t a page-specific rendering or data issue (a missing price on one product due to a feed sync failure, a null field the template doesn’t handle gracefully) that makes that one page’s actual served markup subtly different from the template’s intended output, even if the template code is identical.
Check Search Console’s Merchant listings / Product snippets report. This report is built to show product-schema performance and issues at the URL level. It will often directly surface which pages have detected issues (missing required fields, price/availability mismatches, policy flags) versus which are clean, which is faster than manually diffing markup page by page.
Check for quality differences the schema doesn’t control. Variant pages (the same core product in different sizes or colors) are a common culprit: if several near-identical variant pages exist with largely duplicated content, Google’s broader duplicate-content and page-quality handling can suppress rich results on some of them even with valid Product schema, simply because the underlying page isn’t distinct enough to warrant separate rich-result display. Similarly, thin pages with minimal unique content beyond the schema itself are more likely to be affected than pages with substantive unique product descriptions.
Check stock, price, and attribute consistency between the page’s visible content and the marked-up data. Google’s general structured data guidelines require markup to match visible page content. If a feed or database sync issue causes the schema to state a price or availability status that doesn’t match what’s actually rendered on the page for some SKUs, that mismatch alone can suppress the rich result for those specific pages while leaving properly synced pages unaffected.
Check crawl and index recency per page. Rich results depend on Google having recently and successfully processed the current version of the page. A large catalog with uneven crawl frequency (common on sites with tens of thousands of SKUs and finite crawl budget) can have some product pages running on stale index data that predates a schema fix, while others have been recrawled and reflect current markup. URL Inspection will show the last crawl date and whether the indexed version matches current content.
Consider that Google can selectively withhold rich results across parts of a domain for reasons unrelated to any individual page’s markup. If a subset of the site has triggered a broader quality or policy concern (even one not specific to those exact product pages), Google’s systems can be more conservative about extending rich-result display to nearby URLs, independent of those URLs’ own markup correctness. This is harder to verify directly, but if the affected and unaffected pages cluster in ways schema-validity alone doesn’t explain (by category, by recent site section changes, by proximity to flagged content), it’s worth considering as a contributing factor.
A hypothetical illustration
Hypothetically, imagine a mid-size outdoor apparel retailer, “Cairn & Co.,” where product rich results appear reliably for its jacket category but only sporadically for its glove category, despite both using the same Product schema template. Working through the diagnostic checklist might reveal two compounding causes: the glove pages have a dozen near-identical color-variant URLs with almost no unique descriptive copy beyond the swapped color name, and a recent inventory feed sync issue caused a handful of those pages to display “in stock” on the page while the schema still stated an outdated “out of stock” value from before the sync ran. Neither issue alone would fully explain the pattern, but together they illustrate why “identical schema” doesn’t guarantee identical rich-result treatment, and why the fix here is content differentiation plus feed-sync reliability, not a schema rewrite.
Why there’s no single root cause to expect
This is inherently a multi-hypothesis diagnostic, not a single-answer lookup. At the scale where this question typically arises (a catalog large enough that “some pages but not others” is even a noticeable pattern), it’s common for more than one of the above factors to be present simultaneously, a mix of stale crawl data on some URLs, a feed sync issue on others, and genuine thin-variant-page quality differences on a third group. The practical approach is running through the checklist above across a sample of both affected and unaffected pages and looking for the actual point of divergence in each case, rather than assuming there’s one universal fix that will restore rich results across the board.
