Original diagram by Citera. References: Google’s product data specification and landing page requirements. The sequence is a suggested audit workflow.
Before asking an AI assistant to explain your products, establish what the correct explanation is. A variant-specific dimension, a temporary promotion, and a return exception each need a reliable source and an owner who can update it.
Google documents that Business Agent uses Merchant Center and website information. That makes a coordinated data review sensible. It does not mean we know which source will determine a particular answer or how quickly a changed page will affect it.
This guide, checked on November 9, 2026, provides an editorial audit method. Download the free workbook to record the facts, evidence, responsible people, and follow-up tests.
Start with a specific product variant
Choose a product that customers often ask about or that has a costly misunderstanding risk. Identify the exact variant, including the relevant size, material, color, pack quantity, or model. Use the same identifier throughout the review.
A fictional example is a travel bag sold in 20-litre and 30-litre sizes. “Fits under a seat” is too vague to use as a universal promise. The team needs the dimensions of the specific bag and a carefully scoped explanation of what customers must verify with their carrier.
That example illustrates the review method; it is not a statement about an actual retailer. Avoid adding an unsupported fit, compatibility, or safety claim merely because it makes a product description sound more complete.
In the workbook’s Evidence sheet, keep the expected fact separate from the current website wording. This helps a reviewer find disagreements instead of copying the same unverified phrase into every system.
Compare the feed, page, and purchase path
Google’s product data specification and landing page requirements explain consistency requirements for shopping data. Check the linked rules for the product category and market you actually serve.
Information | What to compare | Example issue to investigate |
|---|---|---|
Product identity | Identifier, selected variant, title, image | A large-size listing opens the small-size page |
Price and currency | Submitted data, visible page, checkout | A promotion ended on only one surface |
Availability | Submitted status and actual buying options | A sold-out variant still appears purchasable |
Quantity | Unit, multipack, bundle, or subscription | The page fails to explain the advertised quantity |
Restrictions | Destination, delivery method, or conditions | A pickup-only item reads as deliverable |
Use an ordinary customer session as well as the technical review. A data field can be correct while the selected variant or a popup makes the page confusing. Record the URL and the state you inspected so another reviewer can reproduce the observation.
Prioritize discrepancies that could cause someone to buy the wrong item, misunderstand the total, or rely on unavailable stock. Do not add arbitrary keyword repetitions as a substitute for resolving those facts.
Make policy answers specific enough to verify
Review shipping, returns, exchanges, warranty terms, and customer contact information against the policies the business actually applies. Include the relevant conditions and exceptions in visible, understandable language.
For example, a fictional retailer might allow ordinary returns but exclude personalized items. A page saying only “easy returns” leaves the exception unexplained. The useful update is an accurate statement of the applicable condition and a link to the full policy, approved by its business owner.
Record effective dates when policies change. Give support and merchandising teams one place to identify the current public policy. A historical campaign landing page that contradicts the current terms is an issue worth recording even if it is not part of the main navigation.
Keep private order details, internal pricing agreements, and personal customer information out of public evidence pages. The public page should explain the policy; the support route should handle the individual customer’s case.
Check structured data against visible facts
Google’s merchant listing documentation describes supported Product and Offer markup and relevant policies. Review the markup for the exact page and variant alongside what a customer can see.
Structured data is another representation to maintain. It does not excuse a confusing visible page, and adding it is not a documented shortcut to a specific Business Agent answer. Use the appropriate validation tools, correct reported errors, and check that price, availability, and product identifiers describe the same offer.
During the review, save the URL, observed values, and date. If the price changes between initial loading and the final rendered page, investigate that behavior as part of the discrepancy rather than assuming the final screenshot tells the whole story.
Assign fixes and retest the original question
For each issue, record the approved fact, affected surface, owner, due date, and evidence of the correction. Suggested owners might be merchandising for product specifications, ecommerce operations for inventory, and support for contact routes. Use the retailer’s real responsibilities.
After the underlying information is corrected, repeat the same customer question and save the answer. The source fix and the observed answer are different records. A corrected page does not prove immediate ingestion, and an improved answer does not establish why it changed.
Expand your sample if you find a pattern. One incorrectly selected variant may point to a shared URL-generation problem. A systematic policy contradiction may require reviewing all pages that repeat that policy. The value of the first pass is finding the scope of the actual issue.
Continue with Business Agent answer testing. For wider catalog preparation, our product discovery data audit covers additional questions to ask across shopping systems.






















