Blog Details

blog
about

Your product feed is the new storefront

Your product feed is the new storefront

A shopper used to arrive at your store with a search query and a credit card. Now a program arrives with a schema. It does not scroll your hero banner. It does not read the brand story you paid a copywriter for. It queries a feed, compares rows, and either recommends your product or moves on to the next merchant in the list.

This is already how a large share of product research happens. ChatGPT's shopping surfaces, Google's AI Mode, Gemini and Perplexity read structured product data instead of rendering your carefully designed product page. Two open specifications define how that data gets exchanged: the Agentic Commerce Protocol (ACP), published by OpenAI with Stripe, and the Universal Commerce Protocol (UCP), from Google and Shopify. Both describe the same underlying requirement. Your catalog has to exist as clean, current, machine-readable facts.

Most catalogs were never built to that standard. They were built for humans who tolerate ambiguity, and for ad platforms that accept a title, a price and an image and fill in the rest with guesswork.

What an agent actually consumes

A shopping agent works from a feed. The ACP product feed specification accepts CSV, TSV, XML and JSON, and it defines attributes at the level of a single sellable variant. That last detail matters more than it sounds. A row is not "the Trail Runner". A row is "Trail running shoes, black, size 10", with its own identifier, its own price and its own availability.

OpenAI's documentation is explicit about identifiers. The item_id must be stable and unique per item or variant within the feed, and it must never be reused for a different item. That single rule is where a surprising number of catalogs fail, because identifier reuse is invisible in a browser and catastrophic in a feed. Reuse an SKU after a seasonal line retires, and an agent that cached the old association now believes your new jacket is last year's model at last year's price. Nobody sees an error. You just stop being recommended.

The Google-compatible path through the same pipeline carries its own traps. Products uploaded that way are treated as discovery-only: search enabled, checkout disabled. If you want per-item search controls, you need a feed confirmed to follow the OpenAI format, not the Google one. Zero-price items are rejected unless they identify a supported mobile device through a specific category ID and carry a subscription cost. None of those rules are arbitrary. They come from a system that would rather drop a row than show a shopper something wrong.

The fields that decide whether you appear

Most teams treat a product feed as a marketing export: title, description, price, image, category. An agent needs more, and it needs it in a form it can compare across merchants.

Availability and availability date come first. An agent answering "what can arrive by Friday" cannot use a product page that says "in stock" in a green pill. It needs a field it can evaluate against a delivery estimate, and it needs that field to be true.

Variants come second. Colour, size and offer identifier have to be separate attributes, not squeezed into a description. "Available in black and tan, sizes 7 to 12" is a sentence. It is not data. An agent asked for a size 11 in tan will skip you entirely rather than parse the prose.

Fulfillment comes third. Shipping cost and delivery estimate belong in the feed, because that is the constraint shoppers actually give agents. "Under two hundred dollars, arrives before the seventeenth" is the typical query, and a merchant with no fulfillment field is invisible to it.

Seller policy links come fourth, and they are only required when checkout is enabled, which tells you where the protocol expects liability to sit. Return window, refund terms and seller identity are not decoration. They are the merchant's half of the transaction contract.

And seller_name is required on each row in the OpenAI format, not inherited from account registration. Teams that assumed their merchant profile populated the feed discovered otherwise when rows failed validation. Malformed rows are rejected individually while valid rows keep processing, so a feed can look healthy at the aggregate level while a fifth of your catalog quietly disappears.

Freshness is the hard part

Static feeds go stale, and a stale feed is worse than no feed. If your price changes at nine in the morning and the file uploads at two, an agent quotes the wrong number for five hours. If an item sells out and the feed still says available, you have taught the agent that your availability field is unreliable, and there is no penalty mechanism more effective than an agent deciding to trust a competitor's data instead.

OpenAI's guidance is a full snapshot daily through file upload, plus incremental updates through the API during the day. That is a reasonable architecture, and almost nobody has it. The common setup is a nightly export from an ERP, a transformation job nobody owns, and a hope.

The fix is usually one more output profile at the point where product data already leaves your platform, not a new system. If you run Shopify, the platform emits what you need and the work is mapping and validation. If you run a custom or headless build, the work is a data model: a canonical attribute taxonomy, one source of truth for price and availability, and a publisher that writes to your web front end, your shopping feed and your agent feed from the same record. Do that and the agent channel becomes a subscriber rather than a project.

What happened to checkout inside the chat

In 2025 the pitch was simple: agents will buy inside the chat. By late 2026 that pitch has narrowed considerably. Rye, a checkout infrastructure vendor with every commercial reason to frame the shift its own way, reports that OpenAI moved Instant Checkout into apps, with retailers like Instacart, Target and Expedia handling the purchase, after roughly a dozen of Shopify's merchants went live with native checkout. The same account quotes Shopify's president saying the bottleneck sits with the AI companies rather than with merchant willingness.

Treat the framing with the skepticism a vendor blog deserves and the core fact still stands: Instant Checkout is limited to approved partners, and the open feed path is a different thing from the open checkout path.

Most agentic commerce advice gets this backwards. It tells merchants to prepare for a transaction channel that is not open to them and may not be for a while. What is open today is discovery. ChatGPT and Google's AI surfaces will read your catalog and recommend your product whether or not you can complete the sale in the chat window. A recommendation that sends a buyer to your own checkout is still revenue, and it is available now without a line of payment integration.

So build for discovery first. Treat checkout as a later integration decision that depends on your platform, your fraud tolerance and your volume.

What this means for the rest of the stack

Product pages still matter, and not only because humans land on them. Every page cited in an AI answer needs something to extract, and JSON-LD with schema.org Product markup is the cheapest version of that. A page with clean product structured data, a real price, a visible availability state and a policy page that loads is easy for an agent to trust. A page that renders price through JavaScript after a three-second delay is easy to skip.

Robots and log hygiene matter too. If you blocked GPTBot last year because a dashboard showed it crawling thousands of pages for free, you may have removed yourself from the answer set. If your logs show a crawler hammering 404s, the problem is usually your sitemap or your internal links, not the crawler. Crawl access is a decision with a cost, and the cost is now measured in citations rather than bandwidth.

An audit you can run this month

Start with counts. Export your catalog and check how many rows carry a stable, non-reused item_id. Then check availability, price, variant attributes, shipping estimate and seller name for fill rate. Anything under ninety-five percent on core attributes is a data quality problem before it is an agent problem.

Next, diff three layers: the feed, the product page and the checkout. Pick twenty products and compare price and stock across all three. Every mismatch is a number an agent will get wrong when it compares you with a competitor.

Then check the paths. Confirm which feed format you are actually publishing, because the OpenAI format and the Google-compatible format are not interchangeable and the Google path silently disables per-item search controls. Confirm whether your market configuration is real, since target countries do not default to worldwide and an omitted value is not a global opt-in.

Finally, instrument the channel. Segment AI referrals in analytics, watch server logs for the named crawlers, and track whether the pages they fetch are the pages you want cited. That gives you a baseline, and without a baseline every agentic commerce proposal is a guess with a slide deck.

What good looks like

A catalog that agents can use is not a marketing asset with extra fields. It is an operational system with a single source of truth, a validation gate that rejects bad rows loudly, a publisher that keeps every destination in sync, and a monitoring loop that notices when a crawler starts seeing 404s.

The merchants who win this channel over the next two years will not be the ones with the biggest ad budget. They will be the ones whose data survives contact with a machine that has no patience and no context, and whose product pages answer a question in one parse instead of three.

It is unglamorous work, and it decides whether your products are in the answer at all.

Send Us a Message