How should merchants prepare for ChatGPT shopping?

ChatGPT shopping changes the unit of competition. A merchant no longer competes only for a query and a click. The product must survive a conversation in which the buyer states a budget, adds constraints, rejects an option, compares tradeoffs, and may finish the purchase without following the path your marketing team designed.

That does not make search obsolete, and it does not give merchants a new SEO trick. It creates a product-data and merchandising problem. Your catalog, product pages, policies, inventory, images, and paid acquisition system must tell the same factual story. If those systems disagree, a conversational shopping experience exposes the mismatch faster than a search results page does.

The practical response is to treat product data as customer-facing infrastructure. Make every sellable variant identifiable, current, comparable, and easy to verify. Then separate organic discovery work from paid ads, because OpenAI does. A merchant that mixes those two systems will misread performance and waste money.

ChatGPT shopping is four different surfaces

Merchants should plan for four distinct surfaces: organic product results, shopping research, merchant selection, and paid ads. Instant Checkout can shorten the purchase path for eligible merchants, but it does not merge those surfaces into one auction.

Organic product results can appear when a conversation shows shopping intent. OpenAI's Shopping with ChatGPT Search help page says the product carousel considers the user's request and context, structured merchant and third-party metadata, other third-party content, model responses, and applicable safety rules. The result is organic. Partnerships do not buy placement there, and ads remain separate.

Shopping research handles harder decisions. A buyer can state several constraints, answer follow-up questions, remove products, request similar choices, and receive a buyer's guide. OpenAI says this process may use merchant product data supplied through the Agentic Commerce Protocol, public product information, and other retail sources. It also warns that price and availability can be wrong, which is why the product page still has to provide the final answer.

Merchant selection happens after product selection. When several stores sell the same item, OpenAI says ChatGPT can rank merchants using availability, price, quality, and whether the merchant is the maker or primary seller. Instant Checkout may also affect merchant ranking, even though it does not make a product more relevant in organic product results. That distinction matters: the model may choose the product first, then choose which offer to show.

Paid ads sit below responses as labeled sponsored units. OpenAI's advertiser documentation describes a separate delivery system that considers conversation context, the landing page, title, copy, advertiser context hints, and expected outcomes. Buying an ad cannot alter the answer or buy a place in the organic carousel.

These are different funnels with different failure modes. Organic discovery fails when the product is missing, ambiguous, stale, or poorly supported. Merchant selection fails when price, stock, fulfillment, or seller quality is weak. Checkout fails when commerce operations cannot complete the order. Ads fail when targeting, creative, landing pages, bids, or measurement are poor. Put each metric under the right owner.

Relevance comes from constraint coverage

A product surfaces when its facts match the buyer's stated and implied constraints. Classic product SEO often optimizes a page around a broad category phrase. Conversational discovery asks whether a particular variant fits a particular situation. A buyer may want a washable rug under a certain price, sized for a narrow hallway, safe around pets, available this week, with returns accepted. A category page that says "premium hallway rugs" answers almost none of that.

Write product data to resolve selection questions, not to repeat adjectives. The title should identify the actual product and variant. The description should state material, dimensions, compatibility, use limits, care requirements, what is included, and meaningful exclusions. Put facts in their proper fields as well as readable prose. A size buried in an image cannot reliably support a size filter.

I use a simple test: can a catalog row answer why this SKU fits and why its nearest sibling does not? If two variants share the same title, description, image, and landing page while differing only in an internal SKU, the catalog has concealed the choice from the shopping system. Group the family, but preserve variant-level color, size, material, price, stock, and image information.

Do not manufacture relevance by stuffing hypothetical prompts into descriptions. A sentence such as "perfect for travelers, parents, students, professionals, and anyone who values quality" carries no evidence. It also makes products less distinguishable. Describe the physical or functional property that makes the item suitable, then let the system connect that fact to intent.

Reviews and product questions can fill gaps that merchant copy avoids. OpenAI's stable feed schema accepts review counts, ratings, review entries, and question-and-answer content. Supply genuine data only. The OpenAI Commerce Policies prohibit misleading listings, fake reviews, fabricated endorsements, hidden fees, and false claims about availability or origin. A fabricated proof point is both a policy risk and bad source data.

Your feed is a production system

The feed should be generated from the same sources that run the store, validated before delivery, and monitored after delivery. A monthly spreadsheet assembled by marketing is not adequate for a catalog whose price and stock change every day.

OpenAI's stable Products feed reference requires core identifiers and customer-facing fields. In the OpenAI schema those include eligibility flags, a stable item_id, title, description, product URL, brand, main image, regular price, availability, seller information, seller URL, return policy, and target geography. Checkout-enabled products need additional merchant policy data. The specification also supports categories, dimensions, weight, variants, promotions, shipping, returns, reviews, related products, and compliance warnings.

Merchants with a Google-compatible feed may have a shorter implementation path, but only after OpenAI confirms that the registered feed supports that format. The compatibility profile accepts UTF-8 tab-delimited or comma-delimited files, with one product or variant per row. Its required row fields include id, title, description, link, image_link, availability, price, and brand. JSON, XML, RSS, spreadsheets, and Atom are not part of that compatibility path.

Stable identifiers deserve more attention than they get. Keep one identifier attached to the same sellable variant over time. Do not regenerate IDs during an export, reuse an old ID for a new product, or collapse every size into the parent ID. Identity errors poison update logic: a price change can land on the wrong item, reviews can attach to a replacement product, and reporting loses continuity.

Freshness is an operational target, not an adjective in a feed proposal. Decide how quickly a price change, stockout, sale, image replacement, or discontinued SKU must reach every consumer of the catalog. Measure the delay from source update to accepted feed row. Record rejected rows and alert on sudden changes in accepted product count. A feed can upload successfully while individual malformed products fail validation.

Ownership should be explicit. Merchandising owns truthful titles, descriptions, taxonomy, and variant logic. Commerce operations owns price, inventory, shipping, and returns. Engineering owns extraction, validation, delivery, and observability. Growth owns eligibility choices and performance analysis. One person must own the contract across those teams, or every disagreement becomes a silent data defect.

A feed contract catches expensive errors early

A merchant should validate the catalog against business rules before sending it anywhere. Schema validation catches types and required fields. Contract tests catch the mistakes that pass a schema but still mislead a buyer.

This compact Google-compatible sample shows the minimum shape plus identifiers and grouping for two variants. The placeholders deliberately avoid binding the pattern to any store.

id,title,description,link,image_link,availability,price,brand,gtin,item_group_id,color,size
RUG-90-SAND,Washable runner rug 90 cm sand,Machine washable low-pile runner 90 by 300 cm in sand,<product-page>,<image>,in_stock,129.00 USD,North Loom,00123456789012,RUG-90,Sand,90x300 cm
RUG-90-NAVY,Washable runner rug 90 cm navy,Machine washable low-pile runner 90 by 300 cm in navy,<product-page>,<image>,out_of_stock,129.00 USD,North Loom,00123456789029,RUG-90,Navy,90x300 cm

The first useful checks operate across fields and across systems:

1. Reject a row when sale_price is not below price, when currencies differ, or when sale dates are inverted.
2. Reject duplicate item IDs and flag a stable ID whose brand or product family changes unexpectedly.
3. Require variant attributes when a group contains multiple rows, and require a variant image when appearance changes.
4. Compare feed price and availability with the rendered product page for a sample of live SKUs.
5. Confirm that every public image and product page returns successfully without authentication, consent dead ends, or geographic blocking in the target market.

Add business tests that reflect how customers shop. If dimensions drive returns in your category, require them. If compatibility determines whether the product works, require a structured compatibility value and a plain-language explanation. If a hazardous material needs a warning, block publication when the warning is absent. "Optional in the schema" does not mean optional for your business.

The failure I see most often starts with a reasonable shortcut. A team exports parent products because there are fewer rows. The parent says the product is in stock and starts at $79. One popular size is actually unavailable, while another color costs $99. A buyer asks for that size and color under $90. The system finds the parent, shows a plausible match, and sends the buyer to a page where the combination cannot be purchased. Every individual system appears to work, but the data model has lied about the offer. Variant-level rows prevent that failure.

Keep a small set of golden SKUs that exercise hard cases: a sale, a backorder, a product without a GTIN, a grouped variant, a restricted item, a return-policy exception, and a discontinued product. Run them through the export on every catalog change. The exact set should mirror the defects that have already cost your team time or refunds.

Crawlability still decides whether facts can be verified

A feed does not excuse a blocked or incoherent store. Shopping research reads public retail pages, and organic search can depend on web access. Product pages must load for the relevant crawler, present the product facts in rendered content, and avoid contradicting the feed.

OpenAI's crawler documentation draws a sharp line between OAI-SearchBot and GPTBot. OAI-SearchBot supports search visibility, while GPTBot controls whether content may be used to improve generative models. A merchant can allow search crawling and disallow training crawling because the controls are independent. Teams often blur those choices and block both when legal only intended to block model training.

A minimal search rule looks like this:

User-agent: OAI-SearchBot
Allow: /

That rule is only the beginning. The crawler must also pass the CDN, web application firewall, bot protection, geographic rules, and rate controls. OpenAI publishes crawler IP ranges, so security teams can verify requests without opening the site to every declared user agent. Test from outside your office network and inspect server logs. A browser test from an employee laptop proves very little.

Keep essential facts in accessible page content. Do not require a shopper to select every option before any price appears. Do not place returns, shipping limits, or compatibility only in a PDF, modal, or image. Use canonical product pages, clean status codes, descriptive titles, and consistent structured data. These are sound web practices because they make the offer legible to customers and machines.

Check contradictions automatically. If the feed says in_stock but the page says sold out, decide which source owns the correction and how fast it propagates. If a sale ended, remove both the sale price and promotional language. OpenAI warns that displayed price and shipping updates may lag. Your goal is to minimize the discrepancy window and make the landing page decisive.

A missing product needs a diagnosis

A product not appearing in one conversation does not prove a penalty, a feed failure, or poor ranking. The system does not show every eligible item, user context can change the result, and a request may not express the constraints your product satisfies. Diagnose the data path before anyone rewrites a hundred descriptions.

Start with eligibility and ingestion. Confirm that the correct feed reached the correct program, the row was accepted, search eligibility is enabled for the organic pipeline, the product is permitted under commerce policy, and the item has not expired. For an Ads feed, confirm ad eligibility separately. An accepted row in one program says nothing about another program.

Next, verify identity and offer state. Search the source catalog for the exact item ID, GTIN or MPN, group ID, title, price, currency, stock value, and target country. Then compare those values with the accepted export and live page. If a parent product has swallowed its variants, fix the model before testing prompts. If an out-of-stock offer is the only row for a product, its absence may be the correct result.

Then test retrieval without pretending that a handful of chats forms a benchmark. Build a repeatable prompt set from customer language: broad category discovery, a strict budget, one decisive feature, several combined constraints, a comparison with a known alternative, and a question about returns or delivery. Run the same set on a schedule and record the full response, surfaced products, cited facts, timestamp, region, and whether personalization or memory could affect the result. The purpose is regression detection, not a homemade share-of-voice statistic.

Test accuracy as well as presence. A surfaced product with the wrong size, price, compatibility, or availability is worse than an absent product because it sends the wrong customer to the store. Grade each factual claim against the catalog source and live page. Record unsupported claims separately from stale claims: the first points to missing or ambiguous evidence, while the second points to propagation delay.

Compare products on constraint coverage, not on how often a brand name appears. If a competitor consistently surfaces for a buyer requirement, inspect the public facts that support that match. It may publish dimensions you omit, expose variant stock clearly, provide a specific delivery promise, or answer a compatibility question on the product page. Copying its prose would be foolish. Filling the missing factual field is useful.

Do not let an optimization vendor turn this into mysticism. There is no merchant-visible prompt that forces organic inclusion, and OpenAI does not publish a fixed weighting formula that a consultant can reverse engineer from screenshots. Treat claims of guaranteed placement as sales claims, not operating knowledge. Work from documented inputs, controlled tests, and customer outcomes.

A sound incident record ends with a cause category: rejected feed data, stale accepted data, crawl denial, page contradiction, missing constraint data, policy ineligibility, poor offer economics, or normal result variation. That classification tells an owner what to fix. A vague ticket titled "ChatGPT does not like us" does not.

Organic visibility cannot be bought

Paid ChatGPT ads and organic product discovery require separate plans, budgets, and reports. OpenAI states that ads do not influence answers and that advertisers cannot shape organic responses. Product results are organic; sponsored units are labeled and visually separated below a response.

This invalidates the familiar assumption that a larger search budget can compensate for weak catalog data. It cannot. Paid coverage can buy eligible impressions or clicks in supported contexts. It cannot repair an ambiguous variant, stale stock, thin product page, poor return policy, or missing identifier in the organic system.

The feed terminology can also cause confusion. The OpenAI product specification includes is_eligible_search, is_eligible_checkout, and is_ads_eligible, but eligibility does not guarantee selection. It means the product may enter the relevant process. Relevance, price, availability, quality, seller status, user constraints, and policy still affect what appears.

Ads product feeds currently have their own operational path in Ads Manager. OpenAI's feed campaign guide says advertisers upload through SFTP, one feed connection is allowed per ad account during the beta, and ad titles and descriptions come from the feed. It also says products uploaded through that Ads flow are eligible only for ads during the beta and do not enter organic conversations. A merchant using a separate direct commerce feed should document which pipeline powers which surface.

For ads, context hints are not exact-match keywords. They describe conversations, topics, or terms where an offer may fit, but they do not guarantee delivery. OpenAI says the system considers the current conversation, landing page, ad title, ad copy, supplied hints, personalization signals when enabled, and expected outcomes. That makes landing-page fidelity part of targeting. A generic page weakens both relevance and conversion.

Do not promise what the page cannot prove. An ad for a quiet appliance should land on the exact product and support the quiet claim with a specific specification or credible evidence. If the catalog title, ad copy, and page use different names, fix the source record before writing clever creative.

The search ad budget becomes a portfolio

The search ad budget should not move wholesale into ChatGPT ads. It should split into catalog infrastructure, organic discovery, paid conversational demand, measurement, and controlled search coverage. The proportions depend on category economics and current data quality, so any universal percentage would be theater.

Start with contribution margin and incremental orders, not channel novelty. A practical budget model has four ledgers:

• Data and content: feed engineering, product information work, images, variant cleanup, policy pages, and monitoring.
• Organic discovery: crawl access, merchant enrollment, product-page improvements, and query testing.
• Paid acquisition: ChatGPT ad experiments plus the search and shopping campaigns that still produce profitable demand.
• Measurement: conversion instrumentation, experiments, reconciliation, and analyst time.

Treat the first ledger as shared infrastructure. Better product data can improve site search, support agents, marketplaces, paid feeds, merchandising, and conversational discovery. Do not force that entire cost into a single channel's acquisition metric. At the same time, do not hide recurring manual cleanup as a one-time platform investment. If people repair the same fields every week, the pipeline is unfinished.

Keep profitable search campaigns running while you measure substitution. Conversational shopping may capture research that once generated several search queries, but it may also create new discovery sessions. Brand search, high-intent category search, remarketing, affiliate traffic, and ChatGPT traffic can touch the same order. Last-click reporting will award the sale to whichever surface appears last and teach you very little about incrementality.

For paid ChatGPT campaigns, OpenAI Ads Manager supports impression, click, spend, click-through rate, average CPC, average CPM, and conversion reporting. Official guidance describes CPM and CPC buying, conversion-optimized CPC objectives, conversion measurement, and persistent static tracking parameters on landing-page clicks. Use those tools, but reconcile them against orders, cancellations, returns, gross margin, and new-customer status in your own system.

Define an experiment before releasing budget. Choose one product family with clean data and enough demand. Hold product economics, landing pages, and geographic availability constant. Set a spend ceiling and a decision date. Compare incremental contribution after returns, not raw clicks. Watch query quality through the conversations and context your campaign is designed to match, rather than rebuilding a search keyword report that the product does not promise.

A channel earns more budget when it adds profitable orders or creates measurable lift elsewhere. It loses budget when it merely claims orders that would have happened anyway. That rule is boring, and it survives every platform cycle.

A 30-day launch should start with evidence

A merchant can reach a credible first launch in 30 days if the scope stays narrow. Do not begin with the full catalog. Pick a product family that has clear variants, stable inventory, adequate margin, and enough customer questions to test conversational matching.

During the first week, map the sources. Identify where item identity, titles, descriptions, media, price, inventory, shipping, returns, reviews, and compliance facts originate. Record which system wins when values conflict. Sample product pages from the outside and check crawler access. Apply for the relevant merchant or advertiser access instead of assuming a feed URL will be discovered. Shopify merchants should review their platform's current guidance because OpenAI says Shopify Catalog already supplies product data for shopping results.

During the second week, build the smallest complete feed. Export every variant in the chosen family, add stable IDs and identifiers, validate URLs and images, then write contract tests for the category's expensive mistakes. Compare a random sample against live pages. Have merchandising and operations sign off on meaning, not just file format.

During the third week, submit and observe. Record total rows, accepted rows, rejected rows, processing delay, and visible discrepancies. Run a fixed set of buyer prompts that cover broad discovery, exact constraints, comparison, compatibility, budget, availability, and returns. Do not treat your own product appearing once as a ranking win. Record whether the answer is accurate, whether alternatives are sensible, and whether the offer page closes the remaining questions.

During the fourth week, launch a bounded paid test if Ads Manager is available to your account and region. Keep organic and paid dashboards separate. Instrument the landing page and conversion path, attach campaign identifiers, and reconcile completed orders. Review every rejection and mismatch before adding more products.

The launch gate is simple: the feed is repeatable, the pages are crawlable, the facts agree, failures alert an owner, and measurement reaches contribution margin. If those conditions fail, more catalog coverage produces more bad data.

Merchant operations become the growth advantage

The durable advantage in conversational commerce is the ability to publish truthful product facts quickly and keep them consistent through discovery, comparison, advertising, checkout, and service. Marketing cannot fake that capability with copy. Engineering cannot deliver it without merchandising and operations deciding what each field means.

This is where a Team & AI Audit can help a company find duplicate catalog work, broken handoffs, and automation opportunities before it adds another channel. The useful outcome is an owned operating model: fewer manual exports, explicit data contracts, visible failures, and a budget tied to margin.

Assign one product family this week and ask ten real buying questions against it. Trace every answer back to a field, page element, policy, or missing source. The unanswered questions are your backlog. The contradictory answers are incidents. Fix those before you buy more traffic.