ChatGPT Shopping: What Small Businesses Must Check

OpenAI's commerce policies, updated September 29, 2026, require truthful product listings and images and prohibit misleading prices, availability and terms. Before a small business puts products into ChatGPT shopping, it needs to check the actual catalog, the product pages customers will reach and the data supplied to OpenAI.

For a service brand with a retail range, I would start with one real item and follow it all the way to purchase. A med spa's skincare shelf or an HVAC company's replacement filters can produce a useful product audit. A treatment appointment or a repair request needs a different assessment; a product feed should not be treated as permission to turn any service into a shopping listing.

Last verified: October 19, 2026.

Start with the product, before the integration

The September policy is an eligibility check. Its prohibited categories include supplements, prescription-only medical products, recalled goods and several regulated goods and services. It also rules out fabricated endorsements, hidden charges and misleading refund terms. Check the complete current policy against each proposed item; an ordinary retail shelf can contain products that need different decisions.

My suggested first pass is deliberately small. Pick a normal item, a variant, an item that is unavailable and anything whose eligibility needs review. Put the real product beside its public page. Ask the person responsible for the catalog to resolve disagreements before anyone builds a larger feed. Keep an unresolved item out of the proposed submission until its status is clear.

This is especially useful when locations sell different ranges. A central team may think a product is available everywhere while a branch sells it only over the counter. In that case, the first task is deciding what the business can fulfill through the promised purchase route.

The current file-upload specification has nine required fields

OpenAI's supported product file-upload specification lists nine required fields: item_id, title, description, url, brand, seller_name, image_url, availability and price. That count comes from the Basic product data table in the Stable schema, checked October 19, 2026.

My suggested check is to ask the catalog owner to identify the exact item and seller, then compare the description with the real product. Open both destination links. Finally, compare the stock and price in the record with the purchase page.

The specification calls for one row per purchasable item or variant. Variant rows also require group_id, listing_has_variations set to true, and variant_dict. Give each variant its own item_id while keeping the shared group stable. Product and image URLs must be public. It also separates discovery from advertising and checkout, which have additional requirements.

Treat those checks as a starting point for a conversation with your feed provider. Ask which supported integration it uses and which record belongs to your business. If someone says the catalog is connected, ask to inspect an actual record and its destination page. Connection status alone does not answer whether the record describes the right product.

Compare the page and the record before expanding

My recommended audit has three stages: establish eligibility, compare the public product page with the real offer, then compare the submitted record with that page. Record an owner and a date for each unresolved discrepancy. This is an operating recommendation, not an OpenAI scoring system.

Consider a made-up filter product sold in two sizes. The photograph shows the smaller size, the title names the larger one and the destination opens a category page. Even if the file uploads successfully, a shopper still has to guess what is being offered. Correct the product record and its destination together, then open the page again as a customer would.

I would also walk through a price change before adding the whole catalog. Change a test item through the business's normal catalog process and inspect the intended downstream record. That exercise reveals who owns an update and where a team needs a readback. Use your provider's test workflow; do not place a live customer order to prove an integration works.

For a multi-location brand, keep the seller and fulfillment scope explicit in the internal audit. If a central store handles shipping, record that. If a branch handles pickup, record which branch and which stock source supports the promise. A national landing page is not enough evidence for every local offer.

Assign one person to own the feed after launch

OpenAI's Merchant Feed Terms, updated October 13, 2026, make the merchant responsible for submitted content and for agents submitting on its behalf. They require current, correct information and the rights to provide that content. They also allow OpenAI to decline to display it. For merchants agreeing to these direct-feed terms, the October 13 update includes crawler and agent access obligations, including signed Web Bot Auth requests. Have the person responsible for the feed agreement and site access review those requirements together before submission.

That makes the handoff to a provider worth documenting. My recommendation is one named catalog owner, one backup and a short record of where corrections begin. Store the provider's support route beside the feed record. When a product is withdrawn, the team should know who can stop its submission and who checks the result.

Keep that ownership separate from an agency's reporting promise. A screenshot of a product appearing once is useful evidence of that observation. It does not establish that every customer will see it, that the item is eligible forever or that the next stock update has reached the same destination.

Shopping, ads and service inquiries need separate checks

OpenAI's shopping help page says product results are selected independently and are separate from ads. Selection considers the shopper's intent and product information, and not every available item is shown. OpenAI also warns that price or shipping updates may take time to appear.

The same help page says Shopify catalogs are already integrated. Check your existing platform connection before commissioning another feed.

Those limits change what I would measure. Keep three observations separate in your reporting: what your business submitted, what the public product page currently says and what a dated shopping check actually showed. Save the query and context with the observation. Do not turn one appearance into a visibility percentage without a defined set of checks.

If the business needs leads for appointments or repairs, use the separate ChatGPT Get Quote readiness guide. If the budget is for paid placement, start with ChatGPT advertising for service brands. Neither guide replaces the product eligibility review.

For broader local discovery, the Cheers AI Visibility Grader checks whether AI tools recommend a business. It is a separate question from whether a specific retail item is represented correctly in shopping.

A useful first deliverable is a checked sample

Before expanding, I would want the owner to be able to show the real item, its product page, its submitted record and a dated note describing what was checked. Unresolved eligibility questions belong with the person authorized to interpret the applicable policy and the business's obligations.

That sample gives the next person something concrete to inspect. If the page and record disagree, correct them at their source. If they agree but the product is absent from a shopping result, keep the observation and investigate without promising a placement.

Sources

• Commerce policies. OpenAI, updated September 29, 2026. Product eligibility and merchant practices.
• Products: supported file uploads. OpenAI Developers, Stable schema checked October 19, 2026. Nine required fields and integration scope.
• Merchant Feed Terms of Service. OpenAI, updated October 13, 2026. Merchant responsibilities and display discretion.
• Shopping with ChatGPT Search. OpenAI Help Center, checked October 19, 2026. Product selection, advertising separation and update delays.

Dylan Allen-Arnegård is the CEO & Co-Founder of Cheers, the local search platform for multi-location service businesses.