Product Pages for AI Shopping: Facts, Variants, Prices and Feeds

Prepare product pages for AI shopping by making the buying facts explicit: identity, specifications, fit, limitations, variant, current offer and applicable policies. Then keep those facts consistent with the feeds and structured data used by each sales channel. There is no single feed or markup recipe that guarantees inclusion across all shopping assistants.

In short

• Put the facts that decide a purchase in visible text: identity, specifications, fit, limits, variant, price and policy.
• Keep every variant’s identity, price and stock correct, in the page and in markup.
• Reconcile the page, the markup, the feed and the checkout; they must say the same thing.
• Test with real buying questions, and record marketplace and owned-site outcomes separately.

Start with the decision a shopper must make

For one product family, collect the questions that distinguish a suitable purchase from a return. A bag’s capacity, laptop compartment dimensions and care instructions may matter more than another paragraph calling it versatile. A replacement part needs compatibility and exclusions, not only a category label.

Build a fact sheet reviewed by the product owner. Include units, model identifiers, materials, dimensions, intended uses and limits. Distinguish a tested specification from promotional language. If suitability depends on another product, name that dependency and link the relevant specification.

A fictional product record might identify a bag as suitable for devices up to its measured compartment dimensions. Do not infer suitability for every “15-inch laptop,” because screen size and enclosure size are different facts.

Keep variant identity intact

A shopper’s question may require the blue, medium version rather than the parent product. Ensure the chosen variant has a stable identifier, a resolvable URL or selector state, and the correct price, stock and image. A page should not show the selected variant while exposing markup for a different one.

Google’s variant documentation describes ProductGroup, hasVariant, variesBy and group identifiers, with separate examples for single-page and multiple-page implementations. Pick the model that matches the site. Do not canonicalize every genuinely distinct variant to a parent merely because one configuration seems simpler.

Reconcile the four places facts appear

Surface	Common mismatch to test
Visible page	Selected variant is available, but a generic stock statement says otherwise
Structured data	Offer refers to the wrong currency or variant
Merchant feed	Old price or unavailable landing-page URL
Checkout and policy pages	Shipping, returns or market restrictions differ from the product promise

Schedule checks around catalog changes. Record which system owns each fact and when its update reaches other surfaces. Test an unavailable variant and a sale ending; a successful test of one in-stock product is not enough.

Treat Google and Amazon as separate channels

For Google, review Merchant Center’s product data specification and the applicable Search structured-data guidance. Use correct identifiers and maintain agreement between feed, landing page and offer. Feed acceptance and rich-result validation are eligibility checks, not a promise of selection in an AI answer.

Amazon’s documentation describes its shopping assistant drawing on product listings, reviews, community questions and wider information. It also records that Rufus was renamed Alexa for Shopping in May 2026. The older name still appears in customer questions. See Amazon’s product announcement.

Maintain the Amazon listing’s own facts and permissible content. Do not assume a Google Merchant Center submission configures Amazon’s assistant, or that copying third-party reviews into your page establishes a trustworthy claim.

Check the answer, not only the markup

Choose a set of real buying questions covering fit, variants, exclusions and policy. Verify that the answer exists in readable page content and matches the selected market. Then save answer-engine observations separately: wording, date, surface and cited source.

A marketplace citation may help sell the product while leaving your own domain uncited. Record product visibility and owned-site citations as different outcomes. Include failed observations rather than deleting them from a reporting denominator.

What the sources say

• Google’s Shopping Graph is built from product data that merchants send. Brands and retailers send names, descriptions, prices, images and reviews through Merchant Center and Manufacturer Center, and Google uses the Shopping Graph in Search, ads and generative AI features. Product data reaches Google Search through Product structured data, a Merchant Center feed opted into free listings, or both (feeds power AI shopping, grade A). Google recommends providing as much product information as is available, and says structured data plus a feed maximises eligibility and helps it verify the data (product facts, structured, grade A).
• Variants have their own markup. ProductGroup with hasVariant, variesBy and a group identifier declares that several products are variations of one parent, in either a single-page or a page-per-variant implementation, with different prices and availability per variant (variant identity, grade A).
• Prices, availability and state are data. Price, currency and availability should be readable as data, not only in a design (offer state as data, grade A), and not inserted only by client-side script (raw HTML price and action, grade C).
• Review markup has rules. Marked-up review content must be readily visible, ratings must come from users, and a business that controls reviews about itself is not eligible for star results, including through an embedded widget (review markup rules, grade A). Do not create a rating to satisfy a validator.

A product fact sheet, step by step

1. Identity. Name, model or SKU, brand, the identifier a feed uses (GTIN or MPN where one exists).
2. Specifications with units. Dimensions, weight, materials, capacity, compatibility. Say what was measured and what is a claim.
3. Fit and limits. Who it suits, who it does not, what it is not compatible with.
4. Variants. For each: identifier, URL or selector state, price, stock and image.
5. Offer. Current price and currency, availability, any validity window.
6. Policy. Shipping, returns and market restrictions that apply to this product.

A worked example, with invented values

A fictional shop, Harbor Goods, sells a 20-litre rucksack in three colours. The generic copy says “fits a laptop”. The fact sheet says: padded compartment 36 by 25 centimetres; fits laptops with an enclosure up to those dimensions; not designed for a 17-inch laptop. A shopper asking “will it fit my 15-inch laptop?” now has an answer that depends on a measurement, not a label. The values are invented for the example.

Common mistakes

• Showing the selected variant while the markup describes a different one.
• Canonicalising every genuine variant to the parent page for convenience.
• A feed that still carries last month’s price.
• Reusing manufacturer copy that every competitor also publishes.
• Treating a validator pass as a sign the product will be chosen.

Questions people ask

Do I need a feed if my page has markup?

Google says markup plus a feed maximises eligibility. They are eligibility signals, not a promise of selection.

Will Amazon use my Google feed?

No. Maintain the Amazon listing separately; the channels are separate.

Should product pages answer comparison questions?

Where a shopper must decide between your own variants or against a stated alternative, yes, with facts. Avoid unsupported superlatives.

Vercatus’s setup for stores checks product pages and the sources engines cite for them. Use the pricing-content guide for qualifier placement and the tracking guide to distinguish what a page can answer from what an assistant actually cites.