Do structured data really improve the accuracy of Google Merchant Center crawling?

Why does Google emphasize structured data for Merchant Center?

Alan Kent's statement targets a very concrete issue: Merchant Center collects product information through several channels — XML/CSV feeds, site crawling, API. When the bot visits your pages, it needs to extract price, availability, variants, GTIN, etc. Without structured markup, it relies on DOM analysis and artificial intelligence to guess where this information is located.

The result? Frequent extraction errors. A price displayed prominently on the page but not detected because it's in a non-crawlable JavaScript element. Misinterpreted stock availability. Variants confused with distinct products. Structured data eliminates this ambiguity: you explicitly tell Google, 'here's the price, here's the GTIN, here's the availability.'

What’s the difference between the Merchant Center feed and page crawling?

Many merchants think their XML feed is sufficient. Technically yes, but Google cross-checks the feed data with what it finds on the pages. If your feed states €49 and the page shows €59 (or if Google finds no structured price), you create a discordance signal.

Merchant Center may then reject the product, request a manual review, or simply downgrade its trust in your catalog. Structured data serves as a validation bridge: they confirm that what you state in the feed corresponds to what the user actually sees.

What types of structured data are relevant here?

We mainly talk about Schema.org/Product and Schema.org/Offer. Critical properties include: price, priceCurrency, availability, gtin, brand, sku, image, name, description. If you sell variants (sizes, colors), implementation becomes more complex with variesBy and multiple Offers.

Google accepts JSON-LD, Microdata, and RDFa, but JSON-LD remains the de facto standard in 2024 for its ease of maintenance and compatibility with CMS. A common mistake: only marking up the main product and forgetting the specific offers for variants, which creates orphans in Merchant Center.

• Schema.org/Product: structures the complete product sheet (name, description, images, identifiers)
• Schema.org/Offer: details price, currency, availability, and sales conditions
• Essential properties: price, priceCurrency, availability, gtin/mpn, sku, url
• Mandatory validation: use the Rich Results Test and the Issues tab in Merchant Center
• Feed/page synchronization: structured data must exactly match what the XML feed contains

Does this recommendation change anything in observed practices?

Let’s be honest: serious e-commerce professionals have been implementing Product Schema for years. This isn't a revelation. The real question is why Google chooses to remind us now — and the likely answer is that too many sites rely solely on their feed without marking up their pages.

On the ground, we actually observe that Merchant Center accounts with clean structured markup have fewer product rejections and fewer discordance alerts. But — and this is where it gets sticky — Google does not publish any numerical data on this 'significantly.' 10% improvement? 50%? [To be verified] because without benchmarks, it’s just declarative.

What are the real pitfalls of this implementation?

The first pitfall: data duplication. You have an XML feed sending the price to Merchant Center, and a JSON-LD on the page doing the same. If both are not perfectly synchronized — due to a delay in updating, a poorly propagated promotion, or a developer error — you create a conflict that Merchant Center will blame you for.

The second pitfall: variants. Many sites implement a single Product object with a single Offer for all variants. Result: Google only sees an average price or the price of the default variant, and rejects the other SKUs in the feed that show different prices. The best practice: a distinct Offer for each variant, with aggregateRating at the Product level and offers of type AggregateOffer.

The third underestimated pitfall: structured data do not solve crawl problems. If your product pages are fully lazy-loaded JavaScript, the bot cannot execute the JS within the allotted time, or your crawl budget is saturated, having perfect JSON-LD changes nothing. Google must first be able to access the page.

In what cases is this advice insufficient?

For very dynamic catalogs (prices changing several times a day, real-time stock), static structured markup can become a burden. If you generate JSON-LD server-side with data hidden for one hour, and the actual price in the database is already different, you return to the discordance problem.

For marketplaces where multiple sellers offer the same product, Schema.org/Product becomes ambiguous: which seller's offer do you markup? The cheapest? All? Google recommends an AggregateOffer with multiple sellers, but the implementation is rarely done correctly, and Merchant Center poorly manages these complex cases.

What should you prioritize auditing on your product sheets?

First step: check the presence of Product/Offer markup on all active product pages. Not just the best-sellers — all of them. A Screaming Frog crawl with JSON-LD extraction will immediately tell you which pages lack it or have incomplete markup.

Second step: compare structured data with the Merchant Center feed. Export your XML feed, extract 50-100 products at random, and manually check that price, availability, gtin correspond exactly between the feed and the page's JSON-LD. Discrepancies reveal synchronization bugs that need to be corrected at the source.

How to implement correctly without creating technical debt?

The most robust solution: generate JSON-LD from the same data source as the Merchant Center feed. If your XML feed is built from your product API, ensure that the product page template calls the same API to build the JSON-LD. This guarantees consistency by design.

For variants, don’t settle for a single Offer. Use "offers": { "@type": "AggregateOffer", "offers": [...] } with one Offer per SKU. Each Offer must have its own url (the URL of the variant if it exists, otherwise the product URL with a parameter), its price, its availability, and its sku.

What critical mistakes must be absolutely avoided?

Never markup a price excluding tax if your site displays inclusive prices to the user. Google expects the price as it appears visually. Do not duplicate properties inconsistently between Product and Offer — if you put a price at the Product level and another in Offer, it’s Offer that counts, but it creates confusion.

Don't skip priceCurrency — it's mandatory. Don't use a generic availability like 'Available' if the product is out of stock. Use the official Schema.org values: InStock, OutOfStock, PreOrder, Discontinued. And systematically validate with the Rich Results Test before deploying to production.

• Audit 100% of product pages to verify the presence of complete JSON-LD Product/Offer
• Synchronize the generation of the Merchant Center feed and JSON-LD from the same data source
• Implement a distinct Offer per variant with AggregateOffer if necessary
• Manually compare XML feed and JSON-LD on a sample of 50-100 products
• Validate each template with Rich Results Test and correct critical errors
• Monitor Merchant Center alerts weekly to detect discrepancies