The Difference Between an SEO Product Feed and an Agent-Readable One

If you have spent the last five years tuning a Google Shopping feed and your brand still gets ignored when a buyer asks ChatGPT to find a leather backpack, the gap is usually not catalog quality. It is feed shape. A Google Shopping feed and an agent-readable feed share a lot of fields and almost no access pattern. Treating them as the same file is why most premium brands are invisible to AI shopping assistants.

Why the access pattern matters

A Google Shopping feed assumes the consumer is a crawler with a daily window. The crawler tolerates stale data because the index refreshes overnight. The crawler does not care about latency because the user is reading a search results page, not a live conversation.

An AI assistant assumes the consumer is the assistant itself in the middle of a conversation. The buyer asked a question 30 seconds ago and is waiting. The assistant cannot tolerate stale price or stock. It cannot afford a 4-second download of a 50 MB XML file. It needs a small JSON response on the order of 200 ms.

If your only product feed is a static XML file, the assistant has two options: either skip your store entirely, or fall back to scraping the public PDP. Both are bad outcomes. The scrape is slower, more error-prone, and gets your brand fewer recommendations than competitors with a real endpoint.

What an agent-readable feed needs that a Shopping feed does not

The shared fields are the easy part. The fields and behaviors that change for an AI consumer:

Stable ids. The agent caches ids to follow up on the same product later in the conversation. Use the Shopify GID, the product handle, or any id that does not change when you reorder a collection or sync a PIM. A position-based id breaks the agent.

Cursor pagination. XML feeds are read whole. JSON feeds for agents have to paginate so the agent can fetch 20 products, decide if it needs more, and ask for the next 20. Use a cursor token, not a page number; cursor tokens survive catalog reorders.

Modified-at timestamps. The agent should be able to ask "give me products modified after 2026-04-28T12:00:00Z" so it can keep its cache fresh without re-fetching the catalog. A static feed gives you a daily snapshot; a live endpoint gives you an incremental sync.

A documented schema. Schema.org Product is a fine starting point, but the agent often needs custom fields the schema does not cover (lead time, return policy, materials breakdown, real customer review excerpts). Document those custom fields in the API response so the agent does not have to guess.

Live inventory. A daily snapshot says "in stock"; the agent recommends the product; the buyer arrives and the size they wanted is gone. A live endpoint exposes current inventory by variant. Brands that ship live inventory get fewer post-recommendation refunds.

What a minimum agent-readable feed looks like

A practical v1 fits in three endpoints:

GET /products. List products with filters (price range, availability, collection, tag). Paginated by cursor, default 20 per page. Returns id, title, summary, price, currency, primary image URL, and a modified_at timestamp per product.

GET /products/:id. Fetch one product by stable id. Returns the full record: variants with current price and inventory, materials, dimensions, lead time, return policy, top 3 review excerpts with rating, and any product-level custom metadata.

GET /products/since/:timestamp. Return products modified since the timestamp, paginated. Lets the agent keep a local cache without re-fetching the whole catalog.

That is the entire surface for the read-only feed. Most brands ship more sophisticated MCP servers on top, but this three-endpoint feed already gets you a seat at the AI shopping table.

Why this is not the same as a regular API

Most premium DTC stores already have a Storefront API or a private API the storefront uses. The temptation is to point AI assistants at that and call it done. It does not work for two reasons.

The first is auth. The Storefront API is built for the brand's own frontend, with tokens that expect a known origin. An AI assistant calling from anywhere needs a separate, scoped read-only token that does not let the assistant do anything destructive.

The second is shape. The Storefront API returns shape that fits the storefront UI, often with nested fields the agent does not need and missing fields the agent does need (like a single review excerpt instead of a full review list). The agent-readable feed is a layer on top that shapes the response for an AI consumer.

The MCP server pattern in setting up an MCP server for a Shopify store covers the same idea with a different protocol; an MCP server is one way to ship an agent-readable feed. JSON over plain HTTP is another. Pick the one your team can ship faster.

Where to start if you have not built one yet

If you only have a Google Shopping feed today, start with the JSON feed before the MCP server. Most Shopify stores can put a thin Cloudflare Worker or a Next.js route handler in front of the Storefront API and ship a v1 feed in two days.

The order to ship:

1. GET /products with stable ids, cursor pagination, basic fields.
2. GET /products/:id with full detail and review excerpts.
3. GET /products/since/:timestamp with incremental sync.
4. Submit the OpenAI Commerce file-upload for discovery.
5. Wrap the feed in an MCP server if you want full agent tool semantics.

If your brand is invisible in ChatGPT and you do not know which signal is missing, fix the page-side schema first. How ChatGPT Shopping actually picks products covers the order of operations for getting on-page signals working before the feed pays off.

The buyer is in a conversation. The assistant is reading the catalog. A static XML file does not load fast enough to be in that conversation. The JSON feed does.