Agentic SEO: How Merchants Should Expose Product Data to AI Agents

A practical guide to the standards, protocols, and best practices for being found and correctly understood by AI shopping agents.

Why should you care as a merchant?

For twenty years, the job of a product page was to persuade a human. Good photography, layout, UI/UX, a compelling description, a clear "Add to Cart" button. The machine reading it was a Google indexer seeking SEO clues, so a human could find you

That arrangement alone is quietly ending. When someone asks an AI assistant to "find me the best rated noise cancelling headphones under $300 that ships free and has a class leading return policy" the assistant never loads a homepage, never sees the hero banner, never reads the founder's story. It queries structured data, parses machine-readable fields, and returns whatever best matches the constraints. The homepage is becoming an artifact for a visitor who increasingly doesn't arrive.

I can say this firsthand. 4 months after launching HomeGadgets, about 40% of visitors get there via ChatGPT, Gemini, Claude, etc. and its catalog is built to be machine readable and from many different channels!

The shift from people to machines reading your site has a blunt consequence. In traditional e-commerce, bad product data hurts your conversion rate, resulting on a confused or distrusting shopper who ends up leaving. In agentic commerce, bad product data prevents selection. Your beautiful website is pointless and could make you invisible to human shoppers whose reliance on AI-powered chats to support purchasing decision has grown enormously in the last 18 months.

The AI call or agent never surfaces you at all, because it couldn't confidently understand with confidence what you sell, what it costs, or whether it's in stock. You just don't lose the sale; you're never in the running. You are invisible or not even exist!

This guide lays out how merchants should consider exposing their catalogues so machines can find them, understand them, and recommend them accurately. It's written for people who actually have to implement this, so it favours the concrete over the visionary, and it's honest about what's required today versus what's still a moving target.

The three layers every agent-ready catalogue needs

The single most useful mental model is this: an agent-ready catalogue should exist in three parallel forms, each serving a different way a machine might reach your data, and all three must agree with each other.

Layer one: structured data on the page itself (schema.org / JSON-LD). This is the markup embedded in your product page's HTML. When an agent or bot fetches the page, this is what tells it what the product is, its price, its availability, its identifiers, its reviews, its shipping and return terms. This is the foundation, it's the lowest-cost and highest-leverage change available, and a page without it is competing with one arm tied behind its back.

Layer two: the product feed. A structured file (or API) that syndicates your whole catalogue to a discovery channel. Google Merchant Center has used this model for years; the newer agentic channels (ChatGPT, Gemini) accept their own feed formats. The feed is a push: you send your catalogue to the channel rather than waiting to be fetched.

Layer three: a live, programmatic endpoint (API / MCP). A read-only interface an agent can query directly for the freshest possible answer including catalogue, current offers, live inventory, policy. This is what an agent hits when a cached feed isn't fresh enough for a time-sensitive question.

The discipline that ties these together is reconciliation. The three forms must agree on identifiers and, above all, on price. Agents cross-check. If your feed says $499 and your product page's structured data says $549, that mismatch doesn't just cost you one channel, you are failing the trust test, and a cautious agent will drop you rather than risk recommending a wrong price. Reconciliation is not a one-time export; it's an operational habit.

Layer one in detail: schema.org markup done properly

Schema.org is the shared vocabulary, expressed as JSON-LD (a small block of structured JSON in your page's HTML). For a product, the types that matter are:

• Product. The item itself: name, brand, description, and critically its identifiers.
• Offer. The commercial terms: price, currency, availability, condition, seller.
• AggregateRating / Review. Social proof, structured so an agent can weigh it.
• MerchantReturnPolicy. The return terms, as discrete fields rather than a paragraph.
• ShippingDeliveryTime / shipping rate details. What it costs to ship to the different geographies covered and when it arrives.

A few principles separate markup that works from markup that merely exists:

Identifiers are the foundation, and this is where most merchants fail. An agent's superpower is cross-referencing the same product across many sellers to aggregate reviews, compare prices, and gain confidence in a recommendation. It can only do that if you publish a stable, correct manufacturer identifier: a GTIN (the barcode number) or, failing that, Brand + MPN (manufacturer part number). This is not optional plumbing. Industry data suggests a large majority of product feeds contain at least one invalid identifier, and a missing or wrong GTIN means the agent can't match your listing to the same product elsewhere, so it can't pool the reviews, can't trust the price, and recommends you less. If you do one thing after reading this guide, make it audit your identifiers.

Move every fact out of prose and into a field. A 2,000-word description tells a human the product is wonderful. It tells an agent almost nothing structured. Every concrete attribute: material, dimensions, capacity, energy rating, certifications, compatibility, intended use, etc. belongs in a dedicated field, not buried in a paragraph. Keep the prose for tone and brand voice; move the facts into structured attributes where a machine can read them.

Use honest, structured availability states. "In stock" when the real situation is "we can order it, but it ships in six weeks" is the kind of thing that erodes agent trust fast. Structured availability values exist for a reason: InStock, OutOfStock, PreOrder, BackOrder. Use the one that's true. An agent that surfaces a "available now" product which turns out to be a six-week special order learns not to trust your feed. Accuracy is a ranking signal, not just a courtesy.

Structure your policies. Return and shipping terms as a single freeform paragraph are invisible to an agent. Expressed as MerchantReturnPolicy and shipping fields, they let the agent answer the questions that now drive a large share of AI shopping conversations: some estimates put queries of the form "find me X that ships free by Y date with a Z-day return window" at over a quarter of all AI-mediated shopping interactions. If your return window and shipping timeline aren't structured, you simply can't be the answer to those questions.

Handle variants with explicit parent-child relationships. One of the most common and damaging failures is treating each size or colour of the same product as an independent, orphaned record with no link to a parent. An agent that encounters loose variants can't tell whether they're different products or configurations of one, and it treats that ambiguity as a quality problem. Assign consistent item-group identifiers so variants clearly belong to the same parent and make sure parent-level attributes flow down to each variant.

Layer two: feeds and the new agentic channels

Google Merchant Center established the feed model: a structured file (XML, CSV, or via API) covering your catalogue, submitted to the channel. The established best-practice bar is worth stating plainly: aim for over 95% of SKUs carrying Brand plus a valid GTIN or MPN, no high-severity diagnostic errors, and price parity between the feed and the page.

What's new since late 2025 is that the AI platforms have their own feed channels, and they behave differently from a passive fetch:

• OpenAI's product feed for ChatGPT Shopping is a push model: the merchant sends a structured file (CSV, TSV, XML, or JSON) to a secure OpenAI endpoint, rather than being fetched. Notably, updates are accepted as often as every 15 minutes to keep price and stock near-real-time, which tells you how seriously freshness is taken!! OpenAI has been explicit that these results are not ads and are not influenced by paid placement; they depend on feed quality, relevance, and context.
• Google's channel feeds its AI Mode in Search and Gemini, drawing on the same Merchant Center discipline retailers already know, extended to cover the policy and freshness fields agents need.

The operational bar has risen accordingly. The rule of thumb now circulating is that price and inventory state should lag reality by no more than about 15 minutes; for fast-moving SKUs, a real-time API sync is the only way to hit that. A daily feed that was fine for traditional shopping ads is increasingly not fresh enough for an agent that's about to help someone spend money.

Layer three: the protocols: ACP and UCP

This is the fastest-moving part of the landscape, and it's worth understanding even if you don't implement it yet, because it's where commerce is heading.

Two open standards now define how an AI agent transacts with a merchant, not just discovers them:

The Agentic Commerce Protocol (ACP) is the standard behind ChatGPT's in-chat purchasing. Before it, every assistant needed a bespoke integration with each merchant and payment provider; ACP replaced those with a shared language for validating credentials, confirming orders, and processing payment. It breaks into a product-feed spec (a merchant catalogue covering 60-plus fields across identifiers, media, pricing, availability, variants, fulfilment, returns, and compliance), an agentic-checkout spec, and a delegated-payment spec. It's already echoed across Salesforce, BigCommerce, Wix, Squarespace, WooCommerce, and PayPal.

The Universal Commerce Protocol (UCP) is Google's and Shopify answer, and it is broader in scope. Where ACP concentrates on discovery and checkout inside the AI surface, UCP aims to cover the entire journey: discovery, pricing, cart, checkout, fulfilment, and post-sale tracking. A notable design choice is that it's built to keep the merchant as the owner of record for every transaction. Shopify and Google co-developed it as an open standard, explicitly analogous to the way HTTPS standardised secure web communication. Essentially a shared language so any agent can talk to any participating merchant.

Two additional observations for merchants trying to decide what to do:

You don't need either protocol to be present in AI conversations today. Solid schema.org markup and a clean feed get your products into LLM-mediated discovery right now. The protocols are about frictionless checkout inside the chat. That will be valuable, but at a later stage.

The likely answer is "both," treated as distribution channels for one well-governed catalogue. The two protocols share enough vocabulary to be tempting to treat as interchangeable and differ enough at the checkout and payment layer that the sane strategy is not to bet on one winner. Early data suggests dual implementations can capture meaningfully more agentic traffic than either alone. The underlying truth is the one worth internalising: whichever protocols win, they all consume the same structured product data. Get the catalogue right: accurate identifiers, honest availability, structured policies, reconciled prices, etc. and you're ready for whichever channel matters. The protocols are the plumbing; your data is the water.

Do's and Don'ts

Avoid the temptation is to chase the newest, shiniest protocol. That's backwards. The order that actually works:

1. Audit your identifiers first. Every product should expose Brand, and a valid GTIN or MPN, as discrete fields. This is the single highest-leverage fix, because it's what lets agents cross-match you against the same product everywhere else. Broken identifiers make everything downstream weaker.
2. Add or correct schema.org/Product + Offer markup on every product page, as JSON-LD. Validate it: Google's Rich Results Test will confirm your JSON-LD parses cleanly as Product and Offer. A page that doesn't validate is a page that gets skipped.
3. Move facts from prose into structured attributes. Material, dimensions, capacity, certifications, compatibility: each its own field. Keep the prose for voice.
4. Structure your availability and your policies. Honest availability states. MerchantReturnPolicy and shipping fields as discrete data, not paragraphs.
5. Get your variants parented correctly with consistent item-group identifiers, and make sure parent attributes propagate to each variant.
6. Generate a clean feed for the channels your buyers use, and enforce price parity between feed and page: the mismatch that kills agent trust.
7. Then, and only then, consider the protocols (ACP, UCP) and a live API/MCP endpoint for the freshest queries, layered on top of a catalogue that's already correct.

The order matters because skipping the first step makes the rest invisible. There is no point syndicating a catalogue with broken identifiers into three protocols; you'll just be broken in three more places.

Now, the checklist of what not to do. Each of these are the failures that recur across every serious treatment of the subject:

• Missing or invalid GTIN/MPN: the agent can't cross-match your product, so it can't pool reviews or trust your price.
• Facts trapped in prose: a beautiful description with no structured attributes is, to an agent, an empty page.
• No JSON-LD at all: the lowest-cost, highest-leverage change, skipped.
• Dishonest availability: "in stock" on a six-week back-order teaches agents to distrust you. It pays to connect your live inventory tools.
• Freeform policies: return and shipping terms that a human can read but an agent can't parse.
• Orphaned variants: sizes and colours with no parent relationship, read as ambiguity, penalised as a quality signal.
• Price mismatch between feed and page: the single fastest way to get dropped, because agents cross-check and mismatches read as untrustworthiness.
• Stale data: a daily feed in a world where the freshness bar is fifteen minutes.

Every one of these is fixable, and none of them requires betting on a particular protocol or platform. They're all about the same underlying thing: a clean, honest, structured, reconciled catalogue.

Happy shopping!

Rodrigo