E-commerce AXO Guide

Retail is the vertical where agent experience optimization is least speculative. A shopping assistant comparing three products is doing a concrete, mechanical job: pulling attributes, prices, availability and sentiment, then ranking them against what the shopper said they wanted. If your data is missing, stale, or only expressible as marketing prose, you lose that comparison before a human ever sees your site.

Product data is the asset

For a content site, the asset is the writing. For a retailer, it is the catalog — and specifically the catalog as structured data, not as rendered pages. Everything downstream of discovery reads fields.

Structured Product and Offer markup

This is the format every consumer already understands. Emit it server-rendered on every product page, generated from the same data that renders the page so it cannot drift.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/merino-crew#product",
  "name": "Merino Crew Sweater, Midweight",
  "description": "18.5 micron Australian merino, 320 gsm, fully fashioned shoulders. Machine washable on wool cycle.",
  "sku": "MC-320-NVY-M",
  "mpn": "MC320NVYM",
  "gtin13": "0123456789012",
  "brand": { "@type": "Brand", "name": "Example Apparel" },
  "image": [
    "https://example.com/img/merino-crew-1x1.jpg",
    "https://example.com/img/merino-crew-4x3.jpg"
  ],
  "color": "Navy",
  "size": "M",
  "material": "100% merino wool",
  "audience": { "@type": "PeopleAudience", "suggestedGender": "unisex" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/merino-crew",
    "price": "148.00",
    "priceCurrency": "USD",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@id": "https://example.com/#organization" },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "0.00",
        "currency": "USD"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "US"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 0,
          "maxValue": 1,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 2,
          "maxValue": 5,
          "unitCode": "DAY"
        }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "US",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": 412,
    "bestRating": "5"
  }
}
</script>

A few things this example is doing deliberately. Physical attributes — micron count, gsm, construction, wash instructions — are in description as specifics rather than adjectives, because those are the terms a shopper's question will contain. Identifiers are present so a comparison engine can match your listing to the same product elsewhere. Shipping and returns are declared rather than buried in a policy page, because they are decision fields. And aggregateRating appears only because there are genuinely 412 reviews; emitting it unconditionally from a template for products with none is a policy violation, covered in the schema markup guide.

Accurate availability and pricing

Accuracy here is not a data hygiene nicety, it is the product. An assistant that surfaces you at $148 in stock and delivers a shopper to a $169 out-of-stock page has produced a bad experience that the shopper attributes to you and the assistant attributes to your feed. Both consequences are bad and only one of them is recoverable.

• Generate availability from live inventory at request time, not from a nightly export. If your architecture cannot do that, be conservative — LimitedAvailability on a thin item is honest; InStock on a sold-out one is not.
• Model variants properly. One Offer per purchasable SKU, or an AggregateOffer with lowPrice and highPrice when you are describing a family. A single price that only applies to the smallest size reads as a bait price the moment anyone checks.
• Keep promotional pricing in sync in both directions. Sale prices that persist in markup after the sale ends are a slow, invisible accuracy leak.
• Make the page price and the markup price the same variable. If a human has to remember to update two places, they eventually will not.

Unique descriptions, not manufacturer boilerplate

If forty retailers carry the same item and thirty-nine paste the vendor's copy, there is nothing to distinguish them and a retrieval system has no reason to pick any particular one. It is also the case that identical copy across the web has always been a weak signal in classic search; answer engines inherit that problem and add a new one, since summarizing forty identical pages produces one answer with no citation-worthy source.

What differentiates you is information the manufacturer does not have: how the item fits relative to other things you sell, what your own returns data says about sizing, which use case it is actually good for, what it does not do well. That last one is disproportionately valuable — honest limitations are rare enough in retail copy that they read as credible, and they answer the comparison question a shopper is actually asking.

What actually happened to agentic commerce

The 2025 pitch was that agents would complete purchases end to end inside the assistant. The 2026 reality is more modest and, for merchants, considerably more workable.

It also means the referral is now more valuable than it looks in aggregate analytics. A visitor arriving from an assistant has already compared you against alternatives and chosen. They are further down the funnel than an organic search visitor, they will convert at a different rate, and they will be a small fraction of your traffic — a fraction that most attribution setups will quietly file under direct or referral. See measurement before you conclude the channel is not working.

Comparison-readiness

Assume every product page will be read side by side with two competitors by something that does not care about your art direction. Comparison-readiness is the discipline of making sure the attributes that decide the comparison are extractable.

• Specs in text, with units. Numbers in images are invisible. Numbers without units are ambiguous. Both cost you the comparison silently.
• Consistent attribute names across your catalog. If one category calls it "weight" and another "mass" and a third puts it in a free-text bullet, nothing can compare across your own store, never mind against a competitor.
• Nothing critical behind interaction. Tabs, accordions and modals that fetch on click hide their contents from non-rendering fetchers. If it is in the initial HTML, collapsed-by-default is fine; if it is fetched on click, it does not exist.
• Honest stock status. Including on category and search pages, not just the PDP. A shopper sent to a page that says "3 left" on a discontinued item will not come back.
• A return policy stated in specifics. Window length, who pays return shipping, condition requirements, exclusions. "Hassle-free returns" answers nothing; "30 days, free return shipping, unworn with tags" answers everything and is quotable verbatim.

Reviews and user content

Reviews are the part of a product page that an assistant can use to answer questions your copy never will — does it run small, does the coating hold up, is assembly awful. That makes them worth surfacing properly rather than isolating in a widget.

• Render review text server-side. The most common failure is a third-party review platform that injects everything client-side. Your star rating is visible to shoppers and invisible to fetchers. Check the raw HTML; if the reviews are not there, ask your vendor for a server-rendered or API-fed option.
• Mark up individual reviews, not just the aggregate. Review objects with reviewRating, author and datePublished give a consumer something to quote and date. An aggregateRating alone is a number with no evidence behind it.
• Do not filter out the critical ones. A product page with nothing but five stars reads as curated, to shoppers and to anything summarizing sentiment. Mixed reviews with a visible distribution are more credible and more useful.
• Keep structured Q&A structured. Customer questions with merchant answers are high-value content that maps cleanly to QAPage — note that this is the correct type for user-submitted questions, not FAQPage.
• Never fabricate. Synthetic reviews are a structured data policy violation, a consumer protection issue in several jurisdictions, and an integrity problem that is increasingly detectable. There is no version of this that is worth it.

Preparing for visitors who arrive to transact

Whether the arrival is a human acting on an assistant's recommendation or an agent operating a browser on their behalf, the same properties help: the path from landing to completed order should be short, legible, and free of anything that depends on inference.

• Guest checkout. A forced account creation is the most common hard stop in an agent-assisted purchase and a well-documented conversion tax on humans too. There is no upside here that survives the arithmetic.
• No dark patterns. Pre-checked add-ons, interstitials that obscure the continue button, countdown timers that reset, subscription opt-ins disguised as shipping choices. Beyond being hostile, they are the failure modes that make an agent-assisted flow go wrong in ways the shopper blames on you. Regulators have also moved on several of these.
• Machine-readable errors. "Something went wrong" is unrecoverable. Errors should name the field and the problem in text — "Card declined: insufficient funds", "ZIP code does not match billing address" — associated with the input via aria-describedby, not rendered as a colored border alone.
• Real form semantics. Labelled inputs, correct type and autocomplete attributes, native submit buttons. The accessibility work and the agent-readability work are the same work here, which makes it easy to justify.
• Total cost visible before the last step. Shipping, tax and fees revealed only at confirmation is the classic abandonment cause, and it is worse when an assistant quoted a number earlier in the conversation that your checkout then contradicts.
• Decide your bot policy deliberately. Aggressive fingerprinting or a blanket CAPTCHA will block assistant-driven traffic along with the abuse. Distinguish the crawlers you want indexing you from the automation you actually object to — see AI opt-out controls for how to draw that line rather than blocking by reflex.

For the markup mechanics behind all of this, see the schema markup implementation guide. For the credibility signals that decide whether you get surfaced at all, see trust and authority signals.