ChatGPT product feed: 12 required fields, and 4 are not on your page

What is a ChatGPT product feed, and how does OpenAI receive it?

Three flows are what a merchant implements to support Instant Checkout in ChatGPT, according to OpenAI's key concepts page, and the first of them is the feed. The page states that merchants provide a secure, regularly refreshed feed containing identifiers, descriptions, pricing, inventory, media and fulfillment options, and that integration involves sending an initial sample feed for validation followed by daily snapshots. The word missing from that description is the one a scanner would need: nothing there is fetched.

The delivery mechanics are spelled out on a separate page. OpenAI's file upload overview, read on 2 September 2026, states that merchants push feeds to OpenAI via SFTP, that the supported feed type is a full snapshot treated as the source of truth, and that the recommended cadence is at least daily. It asks for a stable file name overwritten in place on every update rather than a new name each run, recommends up to 500,000 items per shard with shard files targeted under roughly 500MB, and says the SFTP root directory represents the entire catalogue with no completion marker required. After uploads stop changing for a short time, OpenAI processes every file in that directory.

One behaviour on that page is worth reading twice, because it has no equivalent anywhere in crawling. A product is not deleted immediately when it goes missing from a processed snapshot: OpenAI retains its most recently processed record for up to 14 days, which the page says protects products from disappearing because a shard is temporarily delayed. Removing a product by omission therefore takes up to a fortnight. Nothing an AI crawler does works like that. A page removed from a site returns 410 or 404 the next time anybody asks, and the asking is the whole mechanism.

Which fields does the specification mark Required?

Counted on 2 September 2026 from the field tables on the products specification, the schema defines 79 fields across 15 groups: OpenAI Flags, Basic Product Data, Item Information, Media, Price and Promotions, Availability and Inventory, Fulfillment, Merchant Info, Returns, Compliance, Performance Signals, Reviews and Q and A, Related Products, Geo Tagging, and Variants. Sixteen rows carry Required in the Requirement column, 11 carry Recommended, and 52 carry Optional. Six of those 52 are marked as deprecated, which is worth knowing before an engineering team maps a column to one of them.

Four of the 16 are conditional, and the page says exactly what the condition is. is_ads_eligible is required for Ads processing and optional for a non-Ads feed. availability_date is required if availability is pre_order. seller_privacy_policy and seller_tos are each required if is_eligible_checkout is true. That leaves 12 required unconditionally for the plain non-Ads feed most merchants would file first.

Two of the twelve carry limits worth knowing before an export is written: title is copied as plain text up to 150 characters and description as plain text up to 5,000 characters. The specification also documents a compatibility path for merchants who already run a Google product data feed, under which eight columns must appear on every row, being id, title, description, link, image_link, availability, price and brand, and OpenAI maps them into its own field names. That path is narrower than it sounds. The page states that JSON, spreadsheet, XML, RSS and Atom sources are not part of it, so an existing XML product feed has to be exported to a delimited file first.

None of this resembles structured data on a page, and the difference is not only the transport. A schema.org Product node is a description a publisher chooses to attach to a document. A feed row is a record in a catalogue with validation rules, a currency, an ISO country code and a stable identifier. We have measured how thinly the first is used in practice: three of five captured pages carried JSON-LD at all, and one of those held 96 of the 102 nodes in the set.

The four required fields a page does not publish

Eight of the twelve unconditional fields are ordinary product facts. An identifier, a title, a description, a link, a brand, an image, a price and an availability state are all things a well marked up product page already carries, and a merchant exporting them is repeating itself rather than inventing anything. The other four are a different kind of thing, and the specification is clear about it.

is_eligible_search controls whether the product can be surfaced in ChatGPT search results. is_eligible_checkout allows direct purchase inside ChatGPT and requires is_eligible_search to be true first. The heading above both fields states that these flags enable or disable the ChatGPT integrations and do not affect how the product is displayed on your own site. They are switches on OpenAI's side of the boundary, written into a file the merchant sends, and there is no version of them that lives on a web page.

seller_name is marked Required and capped at 70 characters, and the compatibility section states that OpenAI trims and uses the registered merchant display name as the seller identity on every row, so an uploaded seller_name cannot override it. The field is required and simultaneously overridden, which means the identity ChatGPT shows comes from a registration OpenAI holds, not from anything a page asserts about who is selling. target_countries is the fourth: a list of markets in ISO 3166-1 alpha-2 codes, of which the page says the first entry is used.

That is the honest shape of the gap. Perfect structured data for AI on every product page in a catalogue does not produce a valid feed row, because a third of the mandatory columns are not claims about the product. It is also the reason a shop cannot infer its ChatGPT shopping status from a scan of its own site, and why the questions worth asking about getting cited in ChatGPT split cleanly in two: what a crawler can reach, and what a merchant has filed. A scan answers the first. We have written before about how easily the first is misread, including a BreadcrumbList that scored zero on syntax alone.

What one captured storefront actually published

This scanner stores golden fixtures: complete raw and rendered captures of real pages, kept so that a scoring change can be tested against something that does not move. Two of them are storefronts, both captured on 15 July 2026, and we re-parsed them on 2 September 2026 to see how much of a feed row the crawler view holds. We have used the same set before to describe what a crawler meets on a real storefront.

Only one of the two can be read at all. The Allbirds capture returned HTTP 200 to nobody: its stored baseline status is 429, the render was skipped, and the raw body is 18 bytes. That is a rate limit, not a finding about the site, and it is in this post only because leaving it out would make the sample look larger than it is.

The Gymshark capture is complete. Parsed with an HTML parser on 2 September 2026, its raw HTML holds two JSON-LD script blocks, both of which parse, carrying two typed nodes: one WebSite and one Organization. The rendered HTML holds the same two. There are no Product nodes and no Offer nodes in either. The same document links 20 unique product page paths, identical in raw and rendered, and its visible text carries 11 distinct price strings before rendering and 6 after, with three pound-denominated prices present in the raw HTML and absent from the rendered one. We did not determine why the currency set narrowed, and it would take a second capture with the same locale to say.

The limit on all of that is important enough to state twice: this is a home page, not a product detail page. It says nothing about what a Gymshark product URL publishes, and a storefront that types nothing on its home page may type everything on the pages that matter. What it does show is the shape of the problem. Twenty products are reachable from the front door, priced in visible text, and typed by nothing, which is the ordinary condition of an ecommerce home page and the reason our stack guide for Shopify is about the pages underneath it. How the scanner scores what it finds is set out in the methodology, and what GPTBot sees will show you the same view of your own front page.

Three documentation pages, three format lists

Reading the three pages together on 2 September 2026 turned up something a merchant building an export would hit on the first attempt. They do not agree on what file to send.

The key concepts page says merchants provide a feed in CSV or JSON. The products specification, describing the Google-compatible path, says to upload a UTF-8 tab-delimited txt or tsv file or a comma-delimited csv file, adds that the gzip forms txt.gz, txt.gzip, tsv.gz and csv.gz are supported, and states explicitly that JSON is not part of that path. The file upload overview says to prefer parquet, ideally with zstd compression, and lists jsonl.gz, csv.gz and tsv.gz as also supported.

Read charitably, these are three scopes rather than three contradictions: a plain-language summary, a compatibility profile for merchants arriving from an existing Google feed, and the delivery guidance for a production pipeline. Read as instructions, which is how documentation is read, the first says JSON, the second says JSON is not accepted on the path it describes, and the third recommends a columnar format neither of the others mentions. A merchant who follows the summary and exports JSON has followed a page OpenAI publishes and can still be on the wrong path.

We are not reporting a defect, and we have not tried to upload anything. We opened three pages of one documentation set on one day and wrote down what each says, which is the same standard we hold anything to. The specification does describe how the ambiguity resolves in processing: OpenAI samples records from every eligible file, checks its own product schema first, falls back to the Google-compatible profile only if that profile accepts at least one sampled record from each file that yielded records, and then uses the selected parser for every row without switching between them. That is a real answer, and it is three clicks from the page a merchant starts on. Documentation drift of this kind is not unique to OpenAI: we found something comparable when ten AI crawlers fetched markdown by URL and none by content negotiation.

What a crawler-side scan can and cannot tell a shop

The useful conclusion is a boundary, not a warning. For a merchant, product presence in ChatGPT shopping is decided by a file that OpenAI holds and nobody else can request, and no scanner measures it. This one does not, and any tool that claimed to would be describing something it cannot see. That split is the same one behind two machines being sold under the name AI visibility tool, and the feed makes it sharper, because here the unobservable part is not a model's behaviour but a file transfer.

What crawler access still decides is everything the feed does not cover. OpenAI's crawler documentation lists separate tokens with separate jobs, and the one that surfaces pages in ChatGPT's search features is not the feed and never was. A blog post, a buying guide, a size chart and a returns policy reach ChatGPT the ordinary way, by being fetched, and a robots.txt group that blocks the search token removes them whatever the catalogue file says. The two channels can be configured to disagree without anybody noticing, because only one of them answers a request. If you want to see which tokens your own origin currently admits, our crawler list is the reference for the tokens themselves.

So the practical checks for a shop divide by which side of the boundary they sit on. On the observable side: does robots.txt admit the search token at every hostname that serves product pages, does a product page render its prose and its price without JavaScript, and does it carry a typed Product node rather than only visible text. On the unobservable side, which needs an account rather than a scan: is a feed registered, is a snapshot landing daily, are the eligibility flags set the way you think, and is the merchant display name registered with OpenAI the name you want a buyer to see. Nothing in the first list answers anything in the second. We publish what this scanner has measured rather than what it infers, and this is one of the places where the honest answer is that a scan stops at the door.