ChatGPT Shopping increasingly depends on structured product data, not just product pages.
OpenAI now publishes a formal product-feed specification for commerce integrations. For WooCommerce merchants, that means the practical question is no longer simply “Can ChatGPT crawl my store?” It is also: “Can my catalog be exported as clean, current, machine-readable product data?”
This guide explains what a WooCommerce store should prepare, which product fields matter, how variants should be modeled, how freshness should be handled, and where today’s integration limits still apply.
First: can any WooCommerce store submit a feed to ChatGPT today?
No. OpenAI currently states that product-feed onboarding in ChatGPT is available to approved partners. Creating a technically correct feed does not automatically enroll a merchant or guarantee product inclusion.
That distinction is important because “prepare a feed” and “be onboarded into ChatGPT Shopping” are separate steps.
Still, OpenAI’s published specification gives merchants a concrete target for improving catalog quality now. The same cleanup also benefits Merchant Center, structured data, marketplaces, and other AI shopping systems.
What is a product feed?
A product feed is a structured export of your catalog. Instead of forcing another system to interpret every product page from scratch, the feed provides standardized product facts directly.
OpenAI’s current stable file-upload specification uses one row per purchasable item or variant for discovery feeds. The nine basic required fields are:
item_idtitledescriptionurlbrandseller_nameimage_urlavailabilityprice
Optional data can add richer information around variants, categories, sale pricing, shipping, returns, identifiers, media, and additional product attributes.
1. Start with stable product identity
The feed depends on stable IDs. OpenAI’s specification requires an item_id that is unique to the item or variant and should not later be reused for a different product.
In WooCommerce, do not treat product identity as an afterthought. Review:
- WooCommerce product ID.
- SKU.
- Variation ID.
- GTIN where a manufacturer-assigned identifier exists.
- MPN where relevant.
- Brand.
Your feed-generation logic needs a consistent rule for which identifier becomes the external feed ID. Changing that rule later can create duplicate or disconnected product records downstream.
2. Treat purchasable variations as real feed items
A variable WooCommerce product may look like one page to a shopper, but each purchasable option can have its own price, availability, image, URL state, and attributes.
OpenAI’s guidance recommends variant-level records when those values differ. For example:
- Running Shoe — Black — Size 42.
- Running Shoe — Black — Size 43.
- Running Shoe — White — Size 42.
Each purchasable option should have a stable identity and accurate variant-specific commercial data.
A common feed mistake is sending the parent product with one generic price and one stock state even though the actual variations differ.
3. Keep titles concise and factual
The stable OpenAI feed reference recommends concise product titles and factual descriptions. Avoid keyword stuffing, promotional claims that are not supported by the product page, or titles that hide the actual variation.
A useful title often combines:
- Product name.
- Important variation attribute.
- Size, color, pack quantity, or model where it changes the purchasable item.
Example:
Trail Running Shoes — Black — Size 42
This is more useful to a shopping system than a generic title such as Best Premium Shoes UAE Sale.
4. Make the product URL stable and public
Feed URLs should point to publicly accessible product pages. Where practical, a variation record should resolve to a page state that identifies that same variation.
Avoid:
- Staging-domain links.
- Temporary preview URLs.
- URLs that require authentication.
- Redirect chains caused by old product structures.
- Tracking parameters that change unpredictably between feed snapshots.
If you add attribution parameters for measurement, keep the strategy consistent across feed updates.
5. Use the correct product image
The main image_url should point directly to a public product image. For variants, use the variant-specific image when one exists.
Check that:
- The URL is HTTPS where possible.
- The image is publicly reachable.
- The image actually represents the purchasable item.
- There are no placeholders or broken media URLs.
- Variation images do not contradict the selected color or style.
An image mismatch is a data-quality problem even when the file itself loads correctly.
6. Synchronize price correctly
OpenAI’s stable feed format expects price as money with an amount and currency, for example 79.99 USD.
For WooCommerce, verify the feed against the storefront after:
- Regular price changes.
- Sale price changes.
- Scheduled sales.
- Variation pricing changes.
- Currency changes.
- Tax-display configuration changes that affect what users see.
If your page shows one price and the feed sends another, the feed is not ready even if its syntax is valid.
7. Availability must be current
OpenAI’s stable product-feed specification supports availability values such as in_stock, out_of_stock, pre_order, backorder, and unknown.
Your WooCommerce stock model needs to map cleanly to the supported feed state.
Review:
- Products with inventory management disabled.
- Backorders.
- Variation-level stock.
- Pre-order plugins.
- Products that are technically published but not purchasable.
Availability should change when the store changes. A stale feed can turn good catalog data into inaccurate shopping information very quickly.
8. Brand and seller are separate concepts
OpenAI requires both brand and seller_name in the stable discovery feed.
For a direct-to-consumer brand, these may be the same company. For a retailer or marketplace, they may be different.
WooCommerce does not have one universal built-in “brand” model across every store, so the source may come from:
- A brand taxonomy.
- A product attribute.
- A dedicated brand plugin.
- A custom field.
- A controlled store-wide fallback where appropriate.
The important part is consistency. Do not invent a brand just to satisfy a feed field.
9. Add shipping and returns only when the source data is reliable
OpenAI’s specification supports additional fulfillment and policy data, but optional information should not be added using brittle guesses.
If your WooCommerce store has complex shipping zones, free-shipping thresholds, local delivery, GCC shipping, or different policies by product class, build the mapping deliberately.
The same applies to returns. Policy information should come from a maintained source of truth rather than copied manually into a feed that will go stale.
10. Generate a full catalog snapshot regularly
OpenAI’s file-upload documentation describes a full-snapshot feed model and recommends updating it at least daily.
For a WooCommerce store, the right refresh frequency depends on how often these values change:
- Price.
- Stock.
- New products.
- Product visibility.
- Images.
- Sale status.
- Shipping data.
A store with rapidly changing inventory may need a more responsive pipeline than a catalog that changes once a week.
11. Validate the source before generating the file
A technically valid CSV or JSON file can still contain bad commerce data.
Before export, audit WooCommerce itself for:
- Missing product images.
- Missing brands.
- Duplicate or missing SKUs.
- Missing identifiers.
- Incorrect variation relationships.
- Products without usable descriptions.
- Broken canonical URLs.
- Conflicting schema values.
- Incomplete shipping or return information.
This is why feed generation should be the final layer, not the first.
Our WooCommerce AI readiness audit is a useful starting checklist.
12. Do not confuse a ChatGPT feed with a Google Merchant Center feed
The two systems overlap heavily in the type of product information they need, but they are not identical specifications.
OpenAI also documents a Google-compatible product-feed path for integrations where that format has been confirmed. That path has its own supported columns and rules, and merchants should not assume that an arbitrary Merchant Center XML feed can simply be submitted unchanged.
For Google specifically, see our complete WooCommerce Merchant Center feed guide.
A simple WooCommerce-to-ChatGPT feed architecture
A practical implementation usually has four layers:
- WooCommerce catalog — products, variations, prices, stock, media, identifiers, and policies.
- Normalization layer — maps WooCommerce data into a consistent internal product model.
- Validation layer — rejects or flags incomplete and contradictory records.
- Feed output — generates the required external format and refreshes it on schedule.
This is safer than scattering one-off transformations directly into export templates.
What should UAE stores pay special attention to?
For UAE merchants, there is an additional practical limitation: platform availability and supported target markets may not match your own ecommerce footprint.
OpenAI’s current stable upload documentation describes specific market behavior, and merchants should confirm supported countries and currencies during onboarding instead of assuming global availability.
Internally, however, your WooCommerce catalog should still be clean for:
- AED pricing.
- Arabic and English content.
- RTL presentation.
- UAE/GCC shipping zones.
- Local returns policies.
- Regional product availability.
Those improvements remain useful across Google, marketplaces, structured search, and future AI commerce integrations.
Where Emargy GEO fits
Emargy GEO audits WooCommerce product readiness and helps expose cleaner structured commerce data. Its current capabilities include Merchant Readiness audits, Google Merchant feeds, Product schema, llms.txt, an AI Catalog endpoint, product-level visibility checks, and GA4/GTM ecommerce diagnostics.
Emargy GEO does not claim to enroll a store into OpenAI’s approved-partner product-feed program. Its role is to improve the underlying WooCommerce product data and machine-readable outputs so the catalog is easier to validate and integrate.
Product feed checklist
- Every purchasable item or variation has a stable ID.
- Titles identify the actual purchasable option.
- Descriptions are factual and useful.
- Product URLs are public and stable.
- Brand is real and consistently mapped.
- Seller identity is clear.
- Main images load and match the item.
- Price matches the storefront.
- Availability matches WooCommerce stock state.
- Variant records are not collapsed incorrectly into the parent.
- Shipping and return data come from maintained sources.
- The catalog is validated before export.
- The full feed refreshes on a reliable schedule.
- Changes are monitored instead of assuming the export always succeeds.
The practical next step
Start with five products: a simple product, a variable product, a sale item, an out-of-stock item, and a product without a manufacturer GTIN where that is legitimate.
Build the feed mapping for those records first. Compare every exported field against the live storefront. Once the sample is accurate, scale the same rules across the catalog.
A feed is not useful because it contains many fields. It is useful because the data is accurate, current, and consistent with what the customer can actually buy.