By Greg Nowak. Updated 28 September 2026.
When an ecommerce product disappears from a shopping result, shows the wrong price or looks unavailable while it is in stock, the problem is rarely a lack of AI strategy. More often, the product page, structured data and merchant feed disagree.
That makes product-data plumbing a commercial concern. Business owners need reliable listings. Operations teams need inventory and policy changes to travel cleanly across systems. Agencies need to determine whether a visibility problem belongs in the copy, templates, feeds or underlying catalogue.
AI-assisted shopping adds another interpretation layer, but the sensible response is not speculative optimisation for every assistant. It is to publish product facts that machines can retrieve and reconcile: identity, variant, price, availability, imagery, fulfilment and returns.
AI shopping now consumes structured catalogues directly
This is no longer only about Google rich results. OpenAI now documents product feeds for ChatGPT shopping and commerce experiences. Its guidance describes structured catalogue data containing titles, descriptions, images, prices and availability, delivered through full snapshots and more frequent updates.
Direct ChatGPT feed onboarding is currently limited to approved partners, so it is not an immediate channel for every retailer. The broader lesson still applies: product discovery systems increasingly consume structured commercial data rather than relying exclusively on visible page copy.
Do not build a separate catalogue for each destination. Maintain authoritative product data, then create platform-specific transformations for Google, OpenAI and other channels. Their schemas and validation rules differ, but the underlying facts should not.
One product needs one consistent commercial story
Google can receive product information from page-level structured data, Merchant Center feeds or both. Google says using both maximises eligibility for its experiences and helps it understand and verify the information.
That benefit disappears when each channel carries a different version of reality. The browser may show a sale price while JSON-LD retains the regular price. A feed may mark the parent product as available while the selected size is sold out. A return page may change without the organisation-level policy markup changing.
Choose an authoritative source for every commercial field, then document how it reaches the page, markup and feeds. A PIM might own titles and identifiers while the commerce platform owns live price and stock. The goal is not necessarily one application; it is one accountable source for each fact.
| Check | What must agree | Likely owner | Release control |
|---|---|---|---|
| Identity | Title, brand, GTIN or MPN, variant and canonical URL | Merchandising or PIM owner | Category-specific required fields |
| Price | Visible price, offer markup, checkout and feeds | Trading and engineering | Tests for regular and sale prices |
| Availability | Selected variant, page status, markup and feeds | Operations | Stock-change and cache checks |
| Returns | Policy page, checkout terms and structured policy | Customer service or legal | Effective-date and market review |
| Presentation | Primary image, description and landing-page content | Content or ecommerce | Rendered-page inspection |
Treat every feed as a production integration
A merchant feed is not a spreadsheet that marketing uploads and forgets. Google’s product data specification covers identifiers, titles, links, images, prices, availability, variants and market-specific requirements. OpenAI has its own feed contract. Each connection needs field mapping, validation, monitoring and an owner.
Pay particular attention to variants. The landing URL, selected colour or size, image, availability and price must describe the same offer. A technically valid record can still mislead if it combines the image of one variant, the stock state of another and a generic parent URL.
For each destination, record the required attributes, accepted formats, update method and rejection process. Log failed exports, review platform diagnostics and test catalogue-model changes before release. When a category launches, decide its identifier and variant rules before hundreds of incomplete products enter the system.
Automatic corrections are warning lights
Merchant Center can use landing-page markup and data extraction to correct certain price, availability and condition mismatches. Google is explicit that these automations address temporary problems affecting a small proportion of products; they do not replace frequent, accurate updates.
If corrections recur, investigate the route and timing of the data. Is the feed generated before a promotion update finishes? Does a CDN cache stock longer than the export interval? Does client-side rendering show a current price while the initial markup remains stale?
Google recommends placing product markup in the initial HTML, particularly for merchants targeting shopping experiences. Dynamically generated markup can make crawling less reliable for fast-changing price and availability data. Validate syntax, but also compare the rendered page, structured data, checkout and submitted item. Valid markup can still contain the wrong value.
Return policies need operational ownership too
Google supports a standard MerchantReturnPolicy nested under organisation markup. Product-level policy information can override that standard when a particular product has different terms.
This creates a workflow requirement. When customer service or legal changes a return window, fee, method or country rule, whoever maintains the structured implementation must be notified. Seasonal exceptions need start and end dates. The customer-facing policy, checkout terms and machine-readable version should describe the same arrangement.
Run an audit that produces assignable work
Start with a representative sample rather than crawling every SKU immediately: a bestseller, a discounted item, a product with variants, a low-stock item, an out-of-stock item and a discontinued product. For each one, trace its facts from the source system through every feed to the rendered page, markup and checkout.
The first pass should answer five questions:
- Which system is authoritative for every required field?
- How quickly must price and stock changes propagate?
- Do variants remain consistent across URL, image, price and availability?
- Which automated tests run before template or feed changes ship?
- Who responds to diagnostics, policy changes and rejected products?
Write discrepancies as operational defects. “Improve schema” is too vague. “The promotion service supplies the visible sale price, but JSON-LD reads yesterday’s ERP export” tells a team what broke and where to investigate.
Make the boring layer an advantage
Campaigns and redesigns are visible; mappings, cache rules and validation jobs are not. Yet this hidden layer determines whether shopping platforms can accurately represent what you sell. Clean plumbing supports conventional search and current AI shopping integrations without pretending that one field or schema guarantees visibility.
If your catalogue, feeds and product pages have become separate versions of reality, Greg can help map the data path, prioritise the commercial risks and coordinate the technical and operational fixes. Talk to Greg about a practical product-data review.
Related on GrN.dk
- AI Shopping Makes Product Data Integrity a Technical Ops Job
- Google’s 2026 AI Search Guidance: SEO Still Matters, but Reporting Has Changed
- Google’s August 18, 2026 Content API Cutoff: Feed Cleanup Before Merchant API Migration
Need help with this kind of work?
Talk to Greg about a product-data review Get in touch with Greg.