ChatGPT Product Feeds for PrestaShop

Product discovery is moving into the chat window. ChatGPT Ads went live in February 2026, and the products that appear there do not come from crawling your website - they come from a feed you submit. If you have assumed the file you already send to Google Shopping will cover it, this article explains why it usually will not, and what a compliant feed actually has to contain.

For most of the last years, being found meant being crawled. You published pages, search engines read them, and good technical work made those pages easier to understand. Feeds mattered, but they were a side channel - something you set up once for Google Shopping and rarely thought about again.

That relationship has inverted. When a shopper asks ChatGPT for a recommendation, the assistant is not reading your category pages. It is working from structured catalog data that you have submitted, in a format OpenAI specifies, containing fields OpenAI requires. Your product feed is no longer a side channel. It is the channel.

This is good news for merchants who keep clean data, and a problem for everyone else. A feed is unforgiving in a way a web page is not: a page with a missing attribute still renders, while a feed row with a missing required field is simply rejected.

What a ChatGPT product feed actually is

A ChatGPT product feed is a structured file containing one row per product, uploaded to OpenAI on a schedule. OpenAI ingests and indexes it, and the data becomes the basis for how - and whether - your products appear inside ChatGPT.

There are two things you can be eligible for, and they are controlled separately. Organic discovery, where ChatGPT may surface your product in a conversational answer, is governed by a field called is_eligible_search. Advertising, where your product can appear in the paid units below a response, requires is_ads_eligible to be set to true. The two use the same base schema, so one well-⁠built feed can serve both, but you do have to declare your intent explicitly. Nothing is opt-⁠in by default.

This alone catches people out. Merchants assume that submitting a feed makes their catalog available. Submitting a feed makes your catalog known. The eligibility flags make it available.

"Can I just reuse my Google Shopping feed?"

This is the first question every merchant asks, and the honest answer is: partly, and probably not in the form you currently have it.

Start with the encouraging part. OpenAI does accommodate Google's field naming. You are not required to rename every column to match OpenAI's vocabulary, provided your file meets the core requirements. The specification is explicit that a Google-compatible delimited feed can be uploaded as-⁠is once OpenAI has confirmed your feed supports that format.

Now the part that stops most merchants on day one. OpenAI accepts delimited text files only:

The standard Google Merchant Center feed format is XML - specifically RSS 2.0. If your PrestaShop store generates its Google Shopping feed as XML, which the majority do, then "reuse the Google feed" fails on file format before anyone has looked at a single column name. The compatibility path OpenAI offers applies to Google-formatted delimited files, not to the XML feed most stores are actually producing.

And even if you do have a delimited Google feed, it will not contain everything OpenAI wants. Google has no equivalent of is_eligible_search or is_ads_eligible, because those concepts do not exist in Merchant Center. Google has no seller_name or seller_url, because within Merchant Center the seller identity is the account itself. And Google does not ask you to place your privacy policy and terms of service URLs on every product row.

So the realistic summary is this: a Google feed gets you parsed. It does not get you eligible.

What the specification requires

Fourteen fields are required on every product row, regardless of what you are trying to be eligible for.

A further set of fields is required only in specific circumstances. These are the ones that tend to cause rejections, because a feed can pass validation for most of the catalog and fail on the subset where a condition applies.

A quirk worth knowing about

is_eligible_checkout is still listed as a required field even though OpenAI discontinued Instant Checkout in March 2026. The field has not been removed from the specification, so you still have to supply it.

This has a practical consequence that works in your favour. Because seller_privacy_policy and seller_tos are only required when that flag is true, a merchant who sets is_eligible_checkout to false is not obliged to provide them. If you are chasing discovery and ads rather than in-⁠chat purchasing, that removes two fields from your critical path. We would still recommend populating them - policy transparency helps you elsewhere - but they are not what stands between you and a valid feed.

“And even if you do have a delimited Google feed, it will not contain everything OpenAI wants.”

Formats, encoding and keeping the feed current

The accepted formats are narrow, and worth stating precisely because several published guides get this wrong. OpenAI accepts a UTF-8 tab-delimited .txt or .tsv file, or a comma-delimited .csv file. That is the list.

Encoding matters more than it might appear. UTF-8 is not a suggestion, and stores selling across European markets are the most likely to be caught out by it - accented characters, and Hungarian, Polish or Czech diacritics in particular, will corrupt a feed exported in a legacy encoding. The file will often still upload. The product titles will simply be wrong.

Freshness is the other half of the problem, and it is the half that quietly degrades. A feed is a snapshot. The moment you generate one, your prices and stock levels start drifting away from it. When a shopper is shown a product that is out of stock or priced differently from your store, you have not just lost that sale - you have given the system a reason to trust your data less. Any feed that is generated by hand is stale by definition, because nobody rebuilds a CSV several times a day. This is the argument for automation, and it is a stronger argument than the initial setup convenience.

Where PrestaShop leaves you on your own

PrestaShop has no native export in OpenAI's format. There is no setting to switch on, in any version from 1.6 through 9.0. Whatever you produce, you produce yourself.

The obvious workaround - export the catalog, open it in a spreadsheet, reshape the columns - falls apart quickly for reasons specific to how PrestaShop models a catalog:

• Combinations. A single PrestaShop product with three sizes and four colours is twelve purchasable things. Each needs its own row, its own identifier, its own price and its own stock state. Deciding how combinations map to feed rows is a real decision, not a detail.
• Multistore. Different stores mean different catalogs, prices, currencies and policy pages - and therefore different feeds, not one feed with a column added.
• Languages and currencies. target_countries and store_country are per-⁠feed decisions. Selling into four markets is closer to four feeds than one.
• Tax. The price in your database is frequently not the price the customer pays. Whether tax is included, and at which rate, has to be resolved before export rather than corrected afterwards.
• Policy URLs. Privacy policy, terms and return policy are CMS pages whose URLs differ per language and per store, and they belong on every row.

None of this is intellectually difficult. It is simply too much bookkeeping to redo by hand every time stock moves.

What changed recently

Accurate as of August 2026. OpenAI has been revising the commerce specification roughly once a quarter, so it is worth re-checking before you build.

Instant Checkout was discontinued in March 2026. Launched in September 2025 and withdrawn roughly five months later, it did not work commercially. Walmart's published data showed in-⁠chat checkout converting around three times worse than sending the shopper to Walmart's own site, adoption stalled at a handful of Shopify merchants, and the implementation never handled sales tax or fraud properly. OpenAI now routes purchases through third-⁠party apps inside ChatGPT instead. The strategic read is that discovery in AI followed by purchase on your own site is the model that survived - which makes your feed's job to win the recommendation and deliver a click, not to close the sale.

Ads have matured quickly. ChatGPT Ads launched in the United States in February 2026 and extended to Canada, Australia and New Zealand in March. The minimum spend requirement was removed in May, which is what makes the channel realistic for mid-⁠sized merchants rather than enterprise only. Feed management moved into a dedicated Ads Manager in June. On 7 August 2026 a multi-product carousel unit went live, showing several feed products in a single placement, and conversion-optimised bidding has now opened up to product feed campaigns.

Advanced matching becomes the default on 17 August 2026. OpenAI has notified advertisers that automatic advanced matching will be enabled by default on existing web pixels, with a limited window to opt out. This deserves attention from any merchant trading in the EU or UK. Advanced matching means the pixel begins sending hashed customer identifiers, and hashing is not anonymisation under GDPR - it is pseudonymisation, and it still requires a lawful basis. If your consent banner does not currently gate this, enabling it by default is a change to what you are processing, not merely a change to how well it is measured. Our guides to Google Consent Mode v2 and GDPR for webshops cover the underlying consent architecture, and the same logic applies here.

Generating a compliant feed from PrestaShop

We built the ChatGPT Product Feed Generator to remove the bookkeeping described above. It addresses the specific problems in this article rather than offering a generic export.

It writes CSV and TSV, which are the formats OpenAI accepts, so the XML wall never arises. It populates the OpenAI-specific fields that no Google feed contains - the eligibility flags, seller identity, and target_countries and store_country. Policy pages are configured once and attached to every row, which handles seller_privacy_policy, seller_tos and return_policy without manual editing.

For catalog structure, combinations can be exported using a choice of strategies, so variants become proper rows rather than being flattened away. Pricing rules resolve tax handling, adjustments and rounding at export time, so the feed price matches the shelf price. Multistore is supported natively, and feeds can be generated per language and per currency.

Two operating modes cover different situations. Simple mode produces one feed for the whole catalog and is the right starting point for a single-⁠store, single-⁠market merchant. Advanced mode allows multiple feeds, each with its own filters - by category, manufacturer, supplier, price range, stock state, condition or product ID range, with the option to exclude specific products or restrict to products that have images, descriptions or active sale prices. That granularity matters if you sell into several markets, or if only part of your catalog should be advertised.

Feeds regenerate on a cronjob, which is the part that keeps the data honest over time.

The module also outputs JSON and XML for other integrations where those formats are appropriate. For ChatGPT specifically, use CSV or TSV.

Learn more about the ChatGPT Product Feed Generator

Where to start

If you do nothing else, check two things this week. First, what format your existing Google Shopping feed is in - if it is XML, you do not have a reusable file and it is better to know now. Second, whether your product data actually carries GTIN or MPN values, because gtin or mpn is required unless you explicitly declare that no identifier exists, and gaps there are common in PrestaShop catalogs that have grown over several years.

Beyond that, the work is ordinary ecommerce hygiene made newly consequential: accurate prices, honest stock, real identifiers, complete descriptions, and policy pages that exist and are linked. The difference is that a web page with a weak attribute still ranks somewhere, while a feed row with a missing required field does not appear at all.

Discovery is shifting from crawling to submission. That is a smaller change than it sounds for merchants who have kept their catalog clean, and a larger one for everyone who has been relying on a search engine to interpret a messy one generously.