# Agentic Commerce: Selling to AI Agents, Not Just People

**Author:** John Morabito (Founder, /winston)
**Published:** September 19, 2026
**Reading time:** 10 minutes
**Canonical:** https://www.winstondigitalmarketing.com/playbooks/agentic-commerce-and-ai-shopping/

Every product page ever built was written for a person. The photography, the badge that says free shipping over seventy-five dollars, the little green dot next to In Stock, the size chart saved as a JPEG because that is what the manufacturer sent: all of it assumes a pair of eyes and a brain that fills in gaps. That assumption has held for as long as there have been product pages to write.

It is starting to come apart. Assistants now do the middle of the shopping job for people, and increasingly the end of it too: gathering candidates, holding them against a set of constraints, and in some configurations completing a purchase. When that happens, the reader of your product data is a program. It does not squint at your badge graphic, and it will not work out that "from $49" probably means the small one. It reads whatever you published in a form it can parse, and everything else is a blank.

## An agent is a literal reader

The difference between a shopper and an agent is tolerance for ambiguity. A person looking at a page with a vague shipping promise assumes it will probably be fine, and buys anyway, because the photos look right and the brand seems legitimate. An agent comparing your listing against four others has to fill a slot marked "delivery estimate," and if your page does not supply one, the slot stays empty.

That empty slot costs you something. In any comparison, the option with missing information is the harder one to recommend, because recommending it means asserting something the agent cannot support. The practical effect of a fact you never published is that a competitor who did publish it looks better.

This is why agentic commerce is a data problem before it is a marketing problem. The persuasion layer you spent years refining still does its job on the humans who land on the page, and does almost nothing for a reader working through a checklist.

## What the checklist contains

The fields are not exotic. What is new is that they have to exist somewhere a machine can read them, separately from the design that shows them to a person.

- **Price, with currency, and which price.** If a list price and a sale price both exist, which one is the offer, and until when.
- **Availability, per variant.** A product that is in stock in one size and gone in three others is not "in stock." An agent shopping for the three that are gone needs to know that before it recommends you.
- **Variant identity as data.** Size, color, capacity, format, quantity per pack. A swatch is a picture of an attribute, not the attribute.
- **Identifiers.** GTIN, MPN, your SKU. These are what let the same physical product be recognized across your store, a marketplace listing, and a review somebody wrote three years ago.
- **Shipping cost and timing**, or at least the rule that determines them. A threshold buried in a banner image is a rule nobody can apply.
- **Return terms.** How long, in what condition, and who pays return shipping. Buyers weight this heavily, which means agents acting for buyers do too.

The markup that carries most of this is [Product schema](https://www.winstondigitalmarketing.com/playbooks/product-schema-for-ai-shopping/), and I wrote up the field-by-field spec separately so this page does not turn into a vocabulary reference. Treat that piece as the how and this one as the what and the why.

## Parity is worth more than completeness

The one rule I would enforce across every catalog I have ever looked at is that the structured data has to say what the page says, down to the digit. Approximately right is not right here.

Drift is the normal state of affairs, and it happens for boring reasons. The markup is generated by a plugin that reads a field the merchandising team stopped updating. A sale ran through a promotions engine that changes the displayed price without touching the feed. A product was discontinued in the admin but the schema still declares InStock. Each of these produces a page where a human sees one thing and a machine sees another.

That is worse than publishing nothing. A missing field leaves a gap, while a wrong field gives a reader reason to distrust every other field you published, including the correct ones, and the systems consuming this data are getting better at noticing when a declared price does not match the visible one. Run a spot check on twenty products a month and compare the rendered page against the structured record. It takes an hour and it catches the drift before it compounds.

> If a promotions engine, a feed, and your on-page markup all write price independently, assume they disagree until somebody has compared them side by side. That somebody should be a named person, because in most stores it is nobody.

## Stable addresses

An agent that finds your product needs to be able to come back to it, and sometimes needs to hand the address to something else, including the person it is shopping for. That gives URL stability a commercial weight it did not use to carry.

The usual failures are familiar from ordinary SEO, with higher stakes. A product that lives at three addresses because of category paths gives three different answers to the same question. A URL that changes when a variant is selected means the address in hand may not be the thing that was evaluated. Session parameters, referral decorations, and cart state appended to the address of record all produce URLs that resolve today and are meaningless in a week.

One product, one canonical URL, variants addressable in a predictable pattern, and no state in the address. If your canonical situation is already tangled, the cleanup is the same cleanup described in [fixing thin and duplicate content](https://www.winstondigitalmarketing.com/playbooks/fixing-thin-and-duplicate-content/), and it pays for itself twice: once in ordinary search, once here.

## Policies a machine can read

Shipping, returns, and warranty are the terms that decide a comparison once the products are close in price. Most stores express them in the least readable form available: a support-center article written as prose, an accordion that loads on click, a PDF, or a graphic.

What you want instead is dull. The policy exists as text on a crawlable URL, and it states the rules as rules, with numbers in them. Thirty days from delivery, unopened, buyer pays return shipping unless the item is defective, is a policy. We want you to love your purchase is not. Where a structured vocabulary exists for shipping and return details, declare it there as well, so the terms travel with the offer rather than sitting one click away in a document nobody fetched.

A policy written as explicit rules also happens to be the version your support team can apply consistently, which tends to be an improvement on the status quo regardless of who is reading it.

## Nothing that matters can live in an image or a script

Two failure modes account for most of the product pages that are effectively invisible to an agent, and neither is visible from a browser.

The first is the fact trapped in an image. Size charts, compatibility tables, ingredient panels, spec sheets, the shipping threshold in a promotional banner. To a person this is fine. To anything parsing the response, an image is an image. Every one of those needs a text equivalent on the page, and the fix is usually an afternoon of transcription rather than a project.

The second is the fact assembled in the browser. A price fetched by a client-side call after first paint, a stock count rendered by a widget, a variant matrix that only exists once a framework boots. Some systems reading your pages execute JavaScript and some do not, and you do not get to know which ones are doing it today. The safe assumption is that the response your server returns is the page.

Testing this is trivial and almost nobody does it. Request the product URL with something that does not run scripts, curl will do, and read what comes back. If the price is not in there, the price is not published. Do it on your five best sellers before you do anything else in this playbook.

## Where thin templates and iframe storefronts become fatal

A thin product page has always been a mild disadvantage. Agentic comparison turns it into a disqualification.

If your product description is the manufacturer's paragraph, your page carries no information that the agent cannot get from the twenty other retailers running the same paragraph. There is nothing to prefer. Whatever tiebreaker gets applied at that point, whether it is price, delivery speed, or how well known the retailer is, is a tiebreaker you did not influence. The way out is to publish what is true of *your* listing rather than of the product in general: what is in the box as you ship it, dimensions you measured, compatibility you confirmed, your warranty, your return terms, and answers to the questions your own support inbox keeps receiving.

Iframe storefronts are the harder version of the same problem. When your catalog renders inside a frame served from a third-party domain, the document at your product URL is a container. The content lives at an address you do not control, cannot get canonicalized to your domain, and cannot reliably include in your own sitemap. Everything else in this playbook assumes the product data is on your URL. If it is not, that is the first thing to fix, and it is a platform decision rather than an SEO one. The same applies to interstitials, region selectors, and age gates that block the first render, because a wall in front of the page is a wall in front of the data.

## What this is and is not

Two adjacent things, so it is clear which problem you are solving. [Product schema for AI shopping](https://www.winstondigitalmarketing.com/playbooks/product-schema-for-ai-shopping/) is the markup specification: the properties, the nesting, the common mistakes. [Ecommerce GEO and product citations](https://www.winstondigitalmarketing.com/playbooks/ecommerce-geo-product-citations/) is about getting mentioned in the first place, which is mostly an off-site and corroboration problem. This page is the transactional layer underneath both: whether an agent that has already found you can evaluate and act on what it found.

A word on what I am not claiming. I am describing the shape of the requirement, not any particular assistant's roadmap. Which platforms complete purchases, under what arrangements, and with which merchants is moving fast enough that specifics written today will be wrong by the time you finish the work. The requirement underneath is stable, because it is not a feature of any product. It is what any program needs in order to act for someone: facts it can read, an address that resolves, and terms it can evaluate. Build for that and the specifics can change without costing you the work.

## The readiness check

Pick your twenty highest-value products. For each one, fetch the URL as a plain request, no JavaScript, no cookies, and answer six questions using only what came back:

1. What does it cost, in what currency, and is that the current offer?
2. Is it in stock in the specific variant being asked about?
3. What will shipping cost and when will it arrive?
4. Can it be returned, for how long, and who pays?
5. What exactly is this product, in terms specific to your listing?
6. Is this address stable, canonical, and free of state?

Score each product out of six and sort ascending. The result is your backlog, and it is usually shorter than people fear, because the same three template-level defects tend to produce every low score in the catalog. Fix the template, re-run the test, and confirm the fix landed rather than assuming it did.

The broader catalog work this sits on top of, category structure, product page quality, technical handling at scale, is covered in the [ecommerce SEO guide](https://www.winstondigitalmarketing.com/playbooks/ecommerce-seo/). Agentic readiness is a layer you add to a store that already works; it will not rescue one that does not.

We do this work as part of [generative engine optimization](https://www.winstondigitalmarketing.com/services/generative-engine-optimization/), usually starting with the fetch test on a sample of the catalog, because the gap between what a product page appears to say and what it actually publishes is where most of the findings are.

## Frequently asked questions

### What is agentic commerce?

Agentic commerce is shopping where a software agent does part or all of the work on a buyer's behalf. Rather than a person browsing several stores, comparing options and checking out, the person states an intent and an assistant gathers candidates, tests them against stated constraints such as budget, size, delivery date or return terms, and in some cases completes the purchase. The shift that matters to a merchant is who reads the page. A human shopper interprets a layout, infers meaning from a badge graphic and tolerates a vague answer. An agent reads whatever the page exposes in a form it can parse, and treats anything it cannot determine as unknown. In a comparison against stores that published the fact, unknown tends to lose.

### How is optimizing for AI shopping agents different from ecommerce SEO?

Ecommerce SEO is mostly about being found and being chosen by a person: relevance, category structure, internal links, page experience and copy that persuades. Optimizing for an agent is about being evaluated. The agent has already decided to consider you, and what it needs is a complete and unambiguous record of the offer: which price, in which currency, for which variant, in stock or not, what shipping costs and when it arrives, the return window and who pays return shipping, and identifiers that let the same product be matched across sources. Most of that never had to exist in a parseable form, because a person could read it off the page. The two disciplines share a foundation, since a page an agent cannot fetch or parse usually has ordinary technical problems too, but the finish line is different.

### What product data does an AI shopping agent need?

At minimum: the price and its currency, and which price it is when a sale price and a list price both exist; availability per variant rather than for the product as a whole; variant identity expressed as data, so size, color, capacity or format are attributes rather than swatches in an image; identifiers such as GTIN, MPN or your SKU, so the item can be matched against the same product elsewhere; shipping cost and delivery timing, or at least the rule that determines them; and the return window with who pays return shipping. Two conditions matter as much as the fields themselves. The structured version has to match what the page shows a human, because a mismatch makes the whole record untrustworthy rather than merely incomplete. And the data has to be present in the response your server returns, not assembled afterwards in the browser.

### Why do iframe storefronts and JavaScript-rendered prices cause problems here?

In both cases the fact is not in what gets fetched. If your catalog renders inside an iframe served from a third-party domain, the document at your product URL holds a frame reference and very little else, while the real content sits at an address you do not control and usually cannot get treated as canonical. If your price, stock count or shipping threshold is painted in by a client-side script after the initial response, then anything reading that response without executing the script sees a page with no price on it. A human never notices either problem, because the browser resolves both. The test is to request the URL and read exactly what comes back before any script runs. Whatever is missing from that response is missing for a meaningful share of the systems now reading product pages.

### How do you test whether your product pages are ready for agents?

Take your twenty highest-value products and, for each one, fetch the URL as a plain request with no JavaScript execution and no cookies, then try to answer six questions from what came back: what does it cost, is it in stock in the variant I want, what will shipping cost and when does it arrive, can I return it and on what terms, what exactly is this product, and is this address stable enough to come back to. Score each product out of six. The exercise is unglamorous and it usually surprises people, because every one of those facts feels present when you look at the rendered page in a browser. Fix the lowest scores first, then re-run the same test rather than assuming the fix landed.