eCommerce · Product Data Reconciliation
Make your product facts usable in search and AI shopping.
Keep the product page, feed and structured data in agreement. Then answer the product-specific questions a buyer still needs before choosing.
Keep the product page, feed and structured data in agreement. Then answer the product-specific questions a buyer still needs before choosing.
Start with the facts: product identity, variant, price, availability, shipping and returns. A polished description cannot repair a feed that names a different item or markup that shows an old price.
Accurate data can make a product eligible for more discovery experiences. It cannot guarantee inclusion, placement, recommendation, orders or revenue.
Private review page. Platform, feed/catalog and merchandising/operations reviewers must approve every implementation, product, price, stock, shipping, return and identifier statement.
A polished product page can still send conflicting data.
A shopper sees one product page. Search and shopping systems may also read a product feed, structured data and merchant-policy records.
If those records disagree, the product has several public identities.
The page may say an item is in stock while the feed says it is unavailable. The visible price may include a sale while the markup still carries the regular price. A size or color may inherit the wrong image or URL. Shipping and return terms may change in operations but remain stale on the page.
Those are not writing problems. They are ownership problems.
Google’s product guidance explains that merchants can provide product information through structured data, Merchant Center or both. The practical standard is agreement: the same fact should resolve to the same current value wherever it appears.
Start with one product identity.
Define the product before optimizing its description.
Use the identifiers the business actually owns. Keep the brand, product title, SKU and any assigned GTIN or MPN accurate. Never invent an identifier to fill a field.
For each sellable variant, record:
- the product group it belongs to;
- the variant attributes that make it distinct;
- a stable internal identifier;
- the correct URL or selection path;
- the correct image;
- the current price and currency;
- the current availability;
- the approved shipping and return facts.
Google’s product-variant documentation describes ways to group variants while preserving their distinct identities. The exact implementation depends on the platform and page behavior. A qualified platform reviewer should confirm the approach.
Do not merge variants so aggressively that a shopper cannot reach the right offer. Do not split them so carelessly that search systems and feeds treat the same item as unrelated products.
The test is simple: can a buyer select the intended variant and see the right title, image, price, availability and policy information?
Reconcile the page, feed and markup.
Make one record responsible for each product fact. Then compare every public copy of that fact.
| Product field | Visible page | Product feed | Structured data | Source owner | Mismatch action |
|---|---|---|---|---|---|
| Product identity | Current name and variant | Current title and IDs | Product or ProductGroup identity | Catalog owner | Hold unsupported or conflicting values |
| Price and currency | Buyer-visible offer | Current price fields | Offer price and currency | Pricing owner | Correct before relying on eligibility |
| Availability | Current purchase state | Current availability | Offer availability | Inventory owner | Reconcile fast-changing data |
| Image | Correct product or variant | Approved image URL | Matching image reference | Merchandising owner | Replace wrong or stale media |
| Shipping | Visible cost and timing | Approved shipping fields | Visible supported policy facts | Operations owner | Align scope and exceptions |
| Returns | Visible window and conditions | Approved return fields | Visible supported policy facts | Operations/legal owner | Correct hidden or conflicting terms |
The table is a control record, not a performance score. A green row means the records agree at the time checked. It does not mean a platform will show or recommend the product.
Google’s Merchant Center product data specification defines current field requirements. Its structured-data setup guidance also stresses that page, feed and structured values should match.
Use platform validation tools to find errors. Then confirm the correction against what the shopper sees. Passing a test does not make an inaccurate page true.
Add the buyer answers the feed cannot supply.
A feed can carry many facts. It cannot answer every question that stops a purchase.
Buyers may still need to know:
- whether the product fits a specific use;
- which size, model or variant fits the situation;
- what it works with;
- what is included or excluded;
- how to use or care for it;
- which limitation should rule it out;
- what happens before delivery, return or exchange.
Answer those questions in visible language on the product page or the right supporting page. Use the product team’s records, approved tests, support themes and merchandising knowledge. Do not convert a common question into a universal claim.
Keep answers specific. “Works everywhere” is weak. “Compatible with the approved models listed below; not tested with other models” gives the buyer a boundary.
Do not repeat the feed mechanically. A paragraph that restates color, size and price adds little. Explain fit, use, compatibility, care, limitation or decision context the structured fields cannot carry well.
Handle variants without identity drift.
Variant problems often look like content problems because the wrong facts appear together.
Use this decision path:
- Does the option change what the buyer receives? If no, it may not be a product variant.
- Does the variant have a stable identifier? If no, fix the catalog record.
- Can the buyer reach and select it directly? If no, review the URL and selection behavior.
- Do image, price and availability change to the correct values? If no, hold the public claim.
- Do the feed and structured data identify the same variant? If no, reconcile the mapping.
- Does the variant need a distinct buyer answer? If yes, make that answer visible and maintainable.
Do not create fake GTINs, reuse identifiers across different products or attach an offer to the wrong variant. Do not use a parent product’s stock state for every child item unless that is the real catalog rule.
Fast-changing price and availability deserve special care. Google notes that generated markup can be less reliable for rapidly changing information in some shopping contexts, and its variant guidance recommends product markup in the initial HTML for relevant implementations. Treat that as platform guidance to review, not a universal build rule.
Make products crawlable from the catalog.
Accurate product data cannot help a crawler that cannot reach the page.
Google’s eCommerce site-structure guidance recommends crawlable links from menus to categories, subcategories and product pages. An onsite search box alone may not expose every product.
Keep the catalog path clear:
home or collection → category → subcategory where needed → product
Use normal crawlable links for important products. Keep canonical URLs consistent. Use feeds and sitemaps as supporting discovery records, not replacements for a usable catalog.
The semantic product architecture guide owns the wider catalog and product-identity model. The faceted navigation guide owns filters, crawl controls and indexation choices. This page stays with product-level fact reconciliation and buyer answers.
Treat platform eligibility and observed inclusion separately.
Platform documentation explains what merchants can provide and what policies apply. It does not promise a result for a specific product.
Google states that valid structured data does not guarantee a rich result. Merchant Center eligibility does not guarantee a particular placement. OpenAI describes shopping results and merchant data sources, including merchant feeds and provider relationships, but a feed does not guarantee that a product will appear for a prompt.
OpenAI’s shopping help explains that product results are selected independently and are not ads. OpenAI’s commerce policies require truthful listings and restrict deceptive practices.
Keep five records separate:
- Eligible: the product appears to meet stated data and policy requirements.
- Observed: the product appeared in a dated search or shopping sample.
- Visited: a measurable visit reached the product page.
- Ordered: the commerce system recorded an order.
- Return-adjusted: the financial record reflects returns, refunds and the approved revenue rule.
A product mention is not an order. An order is not the same as return-adjusted revenue. The product-discovery-to-order measurement guide owns those downstream definitions.
Refresh when products or platform specifications change.
Product data has two clocks.
The business clock moves when price, stock, variant, image, shipping, returns or product facts change. The platform clock moves when feed specifications, structured-data guidance, policies or shopping surfaces change.
Use both scheduled reviews and change triggers. The owner of each source system should notify the reconciliation record when a material field changes.
Record:
| Trigger | First owner | First check |
|---|---|---|
| Price or sale change | Pricing/merchandising | Page, feed and offer value |
| Stock change | Inventory/operations | Availability across all records |
| Variant change | Catalog/platform | IDs, URLs, images and mapping |
| Shipping or return change | Operations/legal | Visible terms and platform fields |
| Feed specification change | Feed/catalog | Required and deprecated attributes |
| Structured-data change | Platform/engineering | Supported visible markup |
| Commerce-policy change | Legal/operations | Eligibility and prohibited practices |
Date platform statements because the surfaces change. Remove obsolete claims instead of preserving them as evergreen “AI shopping” advice.
Find the first product-data mismatch.
Choose a small, commercially important product sample. Include at least one product with variants and one with price or availability changes.
Compare the visible page, feed and structured data field by field. Then record the top buyer question that remains unanswered after the facts agree.
Fix the first material mismatch before producing more optimization copy. It may be the wrong variant identity, stale availability, a hidden return condition, a broken catalog path or a missing compatibility answer.
Mindflow can review a limited sample of the public path from discovery to buyer action. The Free Visibility Check does not edit a feed, validate a catalog, implement structured data, confirm platform eligibility or audit orders.
Request your Free Visibility Check
Mindflow will review a limited sample of the public path from discovery to buyer action and return the first visible priority.
Sources
- Google: Product structured data
- Google: Product variants
- Google Merchant Center: Product data specification
- Google Merchant Center: Supported structured data
- Google Merchant Center: Set up structured data
- Google: eCommerce site structure
- OpenAI: Shopping with ChatGPT Search
- OpenAI: Commerce policies
Research sources checked 18 August 2026. Platform specifications, catalog facts and merchant policies require current owner review.