eCommerce SEO for AI Shopping Agents: How Product Pages Need to Change

The eCommerce SEO playbook of the last decade assumed a human would land on a category page, filter, skim, and decide. Increasingly the first visitor to your product data is not a human and never renders your category page at all — it queries a feed, compares attributes across sellers, and returns one recommendation.

That changes what "optimised" means. Persuasion still matters for the humans who arrive. But eligibility, comparison and completion are now decided on structured attributes you may not have looked at in a year.

This guide covers what changed, then works through feeds, product schema, variants, identifiers, availability, reviews, images, shipping, returns and comparison data — with the caveat that most of this is unglamorous data hygiene rather than a new discipline.

1. What actually changed for eCommerce

Three things, and it's worth being precise because the hype around this is considerable.

1. Google's generative AI guidance explicitly covers shopping content. It directs merchants to Merchant Center for product data and Business Profile for local details, as the mechanism by which those surface in AI responses. That is a documented statement, not a prediction: your feed is an input to AI surfaces.

2. Comparison is now a machine task. "Compare product specifications" is one of the two agent use cases Google names by default. A specification that exists only as prose in a marketing paragraph cannot be compared; one that exists as a structured attribute can.

3. Checkout is moving off your site. Agentic commerce protocols — UCP, backed by Google and Shopify, and ACP, OpenAI's standard behind Instant Checkout in ChatGPT — let a purchase complete inside the AI surface. You typically remain merchant of record and keep the customer relationship, but the merchandising, upsell and analytics that came with a site visit do not happen.

What did not change

Almost everything else. There is no AI-specific product schema. There is no new markup to add. Google states structured data is not required for generative AI features at all — it matters here for rich results and for machine clarity, which I've argued at length in the schema evidence review.

The work is data quality. It is not exciting and it is not new. It is simply now load-bearing in a way it wasn't when a human could squint at your page and work out what you meant.

2. Feeds: the layer that decides eligibility

For most merchants the feed, not the product page, determines whether you exist inside an AI shopping surface. If the attribute is missing from the feed, the assistant cannot filter on it, and you drop out of the consideration set silently — no error, no report, no ranking drop to investigate.

The attributes that carry weight

Freshness

Price and availability are the volatile fields, and staleness here has a direct cost: an assistant that recommends a product your checkout then reports as out of stock produces an abandoned journey and, if it happens repeatedly, a source the system learns to trust less.

Use scheduled fetches at a cadence that matches how fast your catalogue actually moves, and supplemental feeds or the Content API for rapid changes. OpenAI's product feed spec permits refreshes as often as every 15 minutes — a useful indication of the cadence these systems expect from a serious merchant.

3. Product schema: what to include and why

Two framings to keep separate. Schema is not a ranking factor and is not required for generative AI features. It is how a machine reading your rendered page — rather than your feed — extracts attributes without guessing, and it is the only product data available to systems that never see your Merchant Center account.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/p/widget-pro#product",
  "name": "Widget Pro 3000",
  "sku": "WP-3000-BLK",
  "gtin13": "0123456789012",
  "mpn": "WP3000B",
  "brand": { "@type": "Brand", "name": "Example" },
  "image": ["https://example.com/img/wp3000-1.jpg"],
  "description": "…",
  "offers": {
    "@type": "Offer",
    "price": "149.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "priceValidUntil": "2026-12-31",
    "shippingDetails": { "@type": "OfferShippingDetails" },
    "hasMerchantReturnPolicy": { "@type": "MerchantReturnPolicy" }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "212"
  }
}

Three things people get wrong:

• Marking up a price that isn't on the page. A policy violation, and it breaks agent trust the moment the two are compared.
• Fake or aggregated-from-nowhere ratings. Rich-result eligibility loss at best. Only mark up reviews that genuinely exist and are visible.
• Omitting priceCurrency. A number without a currency is not a price. On a multi-market site this is a real ambiguity, not a pedantic one.

4. Variants, SKUs and identifiers

Why identifiers decide whether you're in the comparison

An assistant asked to find the best price on a specific product must first establish that your listing and four competitors' listings refer to the same object. gtin is the reliable join key; mpn plus brand is the fallback; a product title is guesswork.

Without identifiers you are not compared — you're a separate, unmatched item. For a seller with a genuine price or availability advantage, that is the difference between winning the recommendation and never entering it.

If you manufacture your own products and have no GTIN, supply consistent mpn and brand, and be rigorous about it. If you resell, use the manufacturer's GTIN — do not invent one.

Modelling variants explicitly

The common failure: a product page with colour and size swatches implemented in JavaScript, where the initial HTML contains one variant and the rest appear only on click. A fetcher-class crawler sees one variant. A browser-based agent sees swatches it must infer meaning from.

What to do instead:

• Group variants with a shared item_group_id in the feed, each variant its own item with its own gtin, price and availability.
• Use ProductGroup with hasVariant in schema, and declare variesBy so the differentiating axes are explicit.
• Expose variant attributes in server-rendered HTML — a table of sizes with availability beats a swatch row that requires interaction.
• Give each variant a crawlable, canonical URL where it materially differs in price or availability.

5. Reviews, images, shipping and returns

Reviews

Reviews serve two distinct purposes: aggregateRating as a comparable numeric attribute, and individual review text as a source of the specific claims an assistant can quote ("runs small", "battery lasts two days"). Both need to be genuine and visible on the page. Third-party review platforms that render inside an iframe often contribute nothing machine-readable to your page — check whether yours does.

Images

Image quality is a merchant-listing eligibility issue before it is anything else: adequate resolution, the product isolated, no promotional overlay text, no watermarks. Multiple angles help humans and give vision-based agents more to work with. Descriptive alt text carries genuine information here — "Widget Pro 3000 in matte black, rear ports" rather than "product image".

Shipping

For an assistant comparing three sellers of an identical SKU, delivered cost and delivery date are frequently the deciding attributes. If your shipping cost is only discoverable at step three of checkout, you are effectively withholding a comparison input, and the seller who publishes theirs wins on a comparison you never entered.

Declare shipping in the feed and in offers.shippingDetails, including free-shipping thresholds and handling time.

Returns

Same argument. Return window, who pays return shipping, and any restocking fee are purchase criteria. hasMerchantReturnPolicy makes them machine-readable, and a generous policy that no machine can read provides no competitive advantage in a machine-mediated comparison.

6. Comparison information and machine-readable attributes

The highest-value commercial queries are comparative, and comparison depends entirely on attributes being extractable.

Do:

• Put specifications in a real HTML table with proper <th> headers and scope attributes
• State units inside the cell — "2.4 kg", not "2.4" with the unit in the column header three rows up
• Use consistent attribute names across your whole catalogue, so your own range is internally comparable
• Include the unflattering attributes; an assistant filtering on a spec you omitted excludes you

Don't:

• Ship specifications as an image or a PDF datasheet only
• Hide specs behind an accordion that fetches on click
• Bury numbers in marketing prose — "impressively lightweight" is not a weight
• Use different names for the same attribute across product lines

7. When the agent tries to buy

Discovery is only half of it. If an agent is completing a purchase on your site rather than inside an AI surface, your checkout has to be machine-completable — which is a different problem from being feed-complete.

The failure points I see most: multi-step wizards that hide state, custom date and address pickers with no keyboard or DOM equivalent, honeypot fields and timing traps that catch legitimate agents alongside bots, CAPTCHAs on the conversion path, and SMS OTP loops the agent cannot access.

And before any of that — bot rules. A WAF rule written in 2023 to stop scrapers will happily block a customer's shopping agent in 2026. I've covered the whole agent journey, including the accessibility tree and form semantics that determine whether a checkout can be completed by a machine, in the agent-readiness guide.

8. The checklist

9. Frequently asked questions

Where I'd start

Pull your top 50 SKUs and compare price and availability across feed, schema and rendered page. It's an afternoon's work, it needs no new technology, and in my experience it finds a real discrepancy on most catalogues.

Everything else on this list is a quarter's work. That one is the difference between being compared accurately and being quietly excluded.

Work with me

Product data that machines can find, compare and trust

I'm Jayant Solanki — an SEO, GEO and automation strategist working with eCommerce, local-service and global brands. I've built category, product and faceted architecture that scales past thousands of SKUs, and the Merchant Center and schema layer underneath it.

An eCommerce engagement typically covers:

• Feed, schema and page reconciled on price, availability and specifications
• Identifier and variant modelling so your products match across sellers
• Faceted and category architecture that scales without spawning index bloat
• Checkout tested for machine completability, not just conversion rate
• GA4 measurement that separates agent sessions from human ones

Book a technical review → See how I work

Ranked #1 for "metal buildings" · 25% checkout drop-off identified via GA4 funnel rebuild · +30% YoY organic traffic

Sources

• Google Search Central, Optimizing your website for generative AI features on Google Search
• Google Search Central, Product structured data
• Google Merchant Center, Product data specification
• Google Developers Blog, Under the Hood: Universal Commerce Protocol
• OpenAI, Agentic Commerce key concepts
• web.dev, Build agent-friendly websites

Jayant Solanki

AI-Ready SEO, GEO & AIO strategist based in Indore, India, working with eCommerce, local service and global brands across India, the UAE and the US. Ranked a client #1 for a 45,000/month commercial keyword; builds the measurement and automation behind the work.

More about Jayant →