When Your Schema Is Valid But Your Data Isn't

Your schema can be technically valid and still fail commercially.

The Rich Results Test validates structure. Google evaluates trust. That means your Product schema can pass every validator while still losing rich results, triggering Merchant Center disapprovals, suppressing Shopping visibility, and weakening AI retrieval confidence — because the underlying product data is stale, inconsistent, or contradictory across your page HTML, your schema, and your Merchant Center feed.

These are the data-layer failures most ecommerce teams never audit — the ones that produce no errors, raise no flags, and quietly cost you: stale price and availability, mismatched identifiers, bad AggregateRating data, broken images, and thin schema. Then the model that explains why they're systematic rather than random, and the audit that catches them.

What the Rich Results Test actually validates

The Rich Results Test validates syntax, not truth. It checks that your JSON-LD is parseable, that required properties are present, and that values are the correct type. price is a number. priceCurrency is a string. availability is an ItemAvailability enum — accepted as a short value like InStock or a full schema.org URL. Pass those checks and you get a green tick.

That green tick does not mean Google will use the data. It means the data can be read. Those are different things.

After the crawl, Google runs its own verification layer: comparing the price in your schema against the price on the page, checking availability against what a user would actually encounter, cross-referencing your identifiers against the Merchant Center feed. Those checks happen after the green tick, and they are the ones that determine whether the data gets used.

Five product data failures: suppression, disapproval, and silent underperformance

1. Price and availability staleness

The flash sale failure pattern is the most common version at scale. The sale goes live. The page price updates dynamically. The static JSON-LD was generated at the last build. The Merchant Center feed is on a 24-hour upload cycle. During the sale launch window, the three sources fall out of alignment. Products disapprove. Rich results drop. Reapproval typically happens on the next crawl once alignment is restored, but the damage window during a high-traffic promotion is real.

JavaScript-rendered prices create a quieter version of the same problem. Googlebot reads your pre-render HTML first, then renders the JavaScript. If your schema is generated from the same cached layer as the pre-render HTML, you can have a schema-to-page mismatch even though the displayed price is correct. The fix is ensuring the live price is available in the static HTML response, not only in the JavaScript output.

The fix is process, not markup. Trigger the feed refresh and schema regeneration as part of the sale-launch process, not on a fixed schedule — and make a stock-status change invalidate the schema cache rather than waiting for a CDN TTL to expire. A restock that takes 12 hours to reach the schema is 12 hours of suppressed availability annotations that nothing flags.

2. GTIN and identifier mismatches

GTIN is how Google matches your product to a known entity in its knowledge graph. Get it right and your listing gets price comparison features, Shopping knowledge panels, and stronger AI Overview eligibility. Get it wrong and the product appears without being matched — no price comparison, no knowledge panel, weaker signals across the board.

The schema vs. feed drift problem is subtler. GTINs live in two places: your JSON-LD and your Merchant Center feed, maintained by different teams on different update cycles. A GTIN corrected in the feed after a supplier update doesn't automatically update the page template. A product relaunch that changes the identifier gets the feed updated; the schema is generated from a CDN-cached data layer that nobody flushed. Neither produces an error. Google just sees two sources disagreeing and applies a lower confidence score to both. The fix is at the process level: a relaunch should trigger an immediate PIM-to-schema sync rather than waiting for the weekly cycle — five days of conflicting identifiers during a relaunch is exactly when Shopping impression share matters most.

The practical check: pull 20 high-traffic PDPs and compare the gtin in the schema against the gtin [gtin] in the Merchant Center feed for the same product. They should be identical. For full identifier field definitions and format requirements: Product Identifiers for Ecommerce SEO.

3. AggregateRating data problems

Three patterns cause suppression:

ReviewCount that doesn't match the page. Schema says 1,247. The page shows 23. The 1,247 comes from a legacy feed that aggregated reviews across all channels — marketplace, email, direct — before the methodology changed. Google crawls the page, sees 23, compares it to 1,247 in the schema, and stops trusting the schema. The annotation disappears.

Store ratings in a product context. A Trustpilot merchant score presented as a product-level AggregateRating in your Product schema. A store rating reflects what customers thought of buying from you. A product rating reflects what customers thought of a specific item. Google knows the difference. For the full distinction: Google Store Ratings vs Product Ratings: How Each Works.

RatingValue that doesn't match the page. Schema says 4.8. The page says 4.2. One was cached. The other wasn't. Google takes the conservative position and suppresses the annotation rather than surfacing data it can't verify independently. The rule: schema values must match what a user can visibly see on the page at the time of crawl.

The fix that catches all three: a review-provider migration needs a schema data-source audit, not just a front-end integration check. The old provider's API often keeps feeding a cached count to your schema long after the page has switched over.

4. Image compliance failures

• 404s from CDN migrations. The product image moved to a new path. The HTML was updated. The schema wasn't. Google can't fetch the image, no thumbnail appears, and nothing flags it in Search Console. The fix: include schema image URLs in your post-migration crawl checks — image 404s never surface in the Rich Results report.
• Dimensions below Google's minimums. The validator doesn't enforce dimensions. For schema image, Google's stated minimum for rich results is 160×90px, but the practical minimum for Discover and AI retrieval is higher. For Merchant Center's image_link: 100×100px (non-apparel), 250×250px (apparel). Both Google and Merchant Center recommend 800×800px. An undersized image passes validation and still causes features to be withheld.
• Wrong image on variant pages. Where all variants share a single URL, the image property sometimes points to a generic shot rather than the variant being described. Google may show the wrong product in Shopping, or none at all.
• Redirect chains. The image URL resolves — eventually — through multiple redirects. Google follows them, but long chains create uncertainty and images can be skipped during high-volume crawls.

5. Thin schema: missing recommended properties

The properties most commonly absent, and most commercially relevant:

• shippingDetails and returnPolicy. These generate the shipping and returns annotations in organic results — "Free delivery over £20 · 30-day returns" appearing beneath your meta description before a click. Optional by spec. In practice, the lowest-effort rich result improvement on most ecommerce sites, because few competitors have implemented it correctly.
• AggregateRating when reviews exist on the page. If your product page displays star ratings and review counts, and your schema doesn't include AggregateRating, you're leaving the most visible organic annotation off the table. The validator has no opinion on this. It will pass your schema with no rating data even if the page is full of reviews.
• description. Not required for rich results. Used by Google as a content signal for AI Overviews, Discover, and Shopping knowledge panels. On large catalogues it's frequently absent or populated with a truncated string from a legacy feed that predates the current product range.
• priceValidUntil. Required for Merchant Listing schema when a price has an expiry. Without it on a promotional price, Google has no signal the price is time-limited.
• brand on products without a GTIN. Without a GTIN, brand combined with mpn is the fallback matching mechanism. Missing brand on a private-label or own-brand product means Google has no manufacturer context and no GTIN; matching confidence drops significantly. For the full identifier hierarchy: Product Identifiers for Ecommerce SEO.
• Variant properties for selectable variants. color, size, material, and pattern properties on individual variant nodes are what enable colour swatches and size selectors in Google Shopping product panels. Omitting them produces valid schema that just never generates variant-level Shopping features.

The 3-layer product data alignment model

Most product data failures don't happen in one place. They happen because the same data is being maintained in three separate systems, by separate teams, on separate update cycles. When any two layers disagree, you get disapprovals, suppression, or a lower-confidence match that nobody tracks.

The failure mode this creates is systematic, not random. Fixing one layer without checking the other two is the reason the same disapproval keeps reappearing. A Merchant Center price mismatch gets resolved by updating the feed. Three days later it reappears — because a promotion updated the page price without triggering a feed refresh. The fix needs to happen at the process level, not the data level.

This is also why schema audits that only check syntax miss the actual problem. The three layers need to be checked against each other, not just internally. The audit checklist below is structured to do exactly that.

Why this is now an AI trust problem, not just an SEO problem

Rich results are one consequence of bad product data. They are no longer the biggest one.

AI shopping agents — Google's AI Overviews, ChatGPT shopping, Perplexity's product recommendations, the agentic-commerce layer turning up across major search interfaces — retrieve product data from structured markup to inform purchase decisions, and they favour data that is internally consistent across page, schema, and feed. Inconsistency reads as low confidence for the same reason it does to Google: one of your sources is wrong, and there's no way to tell which.

A product with valid but inaccurate schema isn't just at risk of losing rich results. It's at risk of being skipped by systems that have no obligation to surface data they can't verify. That's a different kind of visibility problem than anything in your Search Console report.

The validator pass is the floor. What's above it — data consistency, feed alignment, identifier accuracy — is increasingly what determines whether your products surface in AI-assisted shopping at all. For the broader context: Agentic Commerce Optimization: What to Fix in Your Schema, Feeds, and Product Data.

Symptoms you'll actually see

These failures don't announce themselves as schema errors. They show up as operational signals in other systems, usually without an obvious cause.

The audit checklist

Start with 20 high-traffic PDPs, not 200. The goal is to identify systematic failures in your template or pipeline. Individual bad URLs are noise. Patterns are signal.

1. Price spot-check (all three layers) For each URL: compare the price in the JSON-LD, the price in the page HTML, and the price [price] in the Merchant Center feed. All three should be identical. Repeat for sale prices: check priceValidUntil in schema and sale_price_effective_date in the feed, and confirm the promotion is actually live on the page. Any mismatch is a disapproval or suppression candidate.
2. Availability check Compare schema:availability to actual stock status for each URL. Flag InStock on out-of-stock products and OutOfStock on purchasable ones. Check which products had a stock status change in the last 30 days — these carry the highest schema lag risk.
3. GTIN format and cross-layer comparison Extract the gtin from schema and compare against gtin [gtin] in the Merchant Center feed. They should be identical. Check format: GTINs are numeric only, 8, 12, 13, or 14 digits. Values containing letters, or starting with 02, 04, or 2 are GS1-reserved for internal/restricted use and are not usable for Google product matching even if they pass format validation. Use the GMC Feed Analyzer for bulk checks across your full feed.
4. Image URL audit Extract the image URL from each Product schema block and check: HTTP response code (looking for 404s and redirect chains), dimensions (800×800px recommended; anything below 160×90px will be rejected for rich results), and whether the image matches the primary product described on the page. Screaming Frog can extract schema image URLs and check response codes in a single crawl.
5. Rating consistency check For any URL with AggregateRating: compare ratingValue and reviewCount in schema against the values visibly displayed on the page. Identify the data source for each: live review system, daily snapshot, or static template. Flag anything where the two can fall out of sync.
6. Cross-layer failure pattern analysis After steps 1–5: categorise failures by layer. Schema-only failures indicate static templates or stale build-time data. Feed-only failures indicate upload frequency or transform issues. Failures in both layers simultaneously usually mean the wrong data is being fed into multiple systems from a single upstream source. That's the one worth escalating.