WooCommerce has no native ChatGPT Shopping integration. Build a product feed, wire Stripe for AI agents, and make product pages agent-readable — the manual playbook.
You can sell to ChatGPT from a WooCommerce store, but nobody is going to do it for you. Shopify and Etsy merchants got handed discoverability: their catalogs sync into ChatGPT Shopping through platform-level integrations, so a store owner who never read a single article about agentic commerce is already showing up in agent results. WooCommerce sits on the other side of that line. There is no toggle, no app you install once, no platform deal that does the plumbing. If you run WordPress and WooCommerce, the path into ChatGPT shopping exists, but it is a manual build. This is the playbook for that build.
The short version: ChatGPT Shopping pulls product data from sources it has structured access to, and Shopify and Etsy are two of them. Those platforms expose every merchant's catalog through a single, consistent feed format, so the engine can ingest millions of products without negotiating with each store. A Shopify merchant inherits that integration for free. The work was done once, at the platform layer, on their behalf.
WooCommerce is not a hosted platform with one central catalog. It is a plugin running on your own WordPress install, and every store is configured differently: different themes, different page structures, different ways of rendering price and stock. There is no single feed an aggregator can point at. That flexibility is the whole reason people choose WooCommerce, and it is also exactly why no aggregator has pre-integrated it. The data is there. The standard surface to read it from is not, unless you create one.
So the gap is not that WooCommerce is worse at commerce. It is that the discovery layer ChatGPT relies on assumes a uniform catalog feed, and WooCommerce hands you the raw materials instead of the finished feed. Closing that gap is your job, and it breaks into three concrete pieces.
There are three things an agent-driven sale needs, and on WooCommerce you have to provide all three yourself.
Route 1: generate a product feed and submit it to the engines. This is the discovery layer. You produce a structured file listing your products in the fields shopping engines expect, host it at a stable URL, and submit or expose it so ChatGPT Shopping and similar surfaces can ingest it. Without a feed, you are relying on an agent crawling and parsing your store page by page, which is slower and far less reliable than reading a clean catalog.
Route 2: use Stripe for the agent-initiated payment layer. When an agent is ready to buy, something has to handle the money. Stripe has been building agentic-commerce tooling so that an AI agent can initiate and complete a payment programmatically rather than driving a checkout form like a human. For a WooCommerce store, Stripe is the realistic payment rail here because WooCommerce already integrates with it and because Stripe is publishing the agent-payment primitives. This part is real but still evolving, and the exact integration surface keeps changing, so treat it as a moving target rather than a finished spec.
Route 3: keep your product pages agent-readable. Even with a feed and a payment rail, agents will still fetch and read individual product pages to confirm details. If your price renders only in client-side JavaScript, or your stock status hides behind an AJAX call, the agent cannot verify what it is about to buy. Server-rendered price, availability, and product schema are the floor.
The order matters. Feed and page-readability come first because they decide whether you are discoverable and verifiable at all. The Stripe payment layer is the finish line, and there is no point optimizing the finish line if the agent never reaches it.
A product feed is a structured list of everything you sell, in fields the shopping engines recognize. The format owes its lineage to the Google Merchant feed spec, which most agent shopping surfaces borrow from, so if you build a feed that satisfies Google's product schema you are in good shape for ChatGPT Shopping too.
The fields that matter most:
id — a stable unique identifier per product or varianttitle — the product name, written for a shopper, not stuffed with keywordsdescription — accurate, specific, the actual product copylink — the canonical product page URLprice — with currency, matching what renders on the pageavailability — in stock, out of stock, preorderimage_link — a direct URL to the main product imagegtin — the barcode or global trade item number where you have itbrand — the manufacturer or your own brandYou have three ways to produce this on WooCommerce. The first is a dedicated feed plugin. Tools like Google Product Feed or Product Feed PRO map your WooCommerce product data to the Merchant feed fields and output a hosted XML or CSV file at a fixed URL, refreshed on a schedule. This is the path most stores should take, because the plugin handles variant mapping, currency formatting, and the field-naming quirks you would otherwise debug by hand.
The second is a custom export. WooCommerce already exposes product data through its REST API and its internal data store, so a developer can pull products and write a feed file directly. Worth being precise here: the REST API is not itself a shopping feed. It returns WooCommerce's own JSON shape, not the Merchant field schema, and it is built for app integrations rather than catalog ingestion. You still have to transform that data into a proper feed. The REST API is a convenient data source for building one, not a shortcut around building one.
The third is a manual CSV for a small catalog. If you sell twelve products, you can maintain a spreadsheet and export it. This breaks the moment your catalog or prices change often, so it is a starting point, not a system.
Whichever route you pick, the non-negotiable is that the feed price and availability match what an agent sees when it fetches the actual product page. A feed that says $39 while the page renders $49 gets your listing distrusted or dropped. Consistency between feed and page is the thing that quietly decides whether your products stay in the index.
Discovery dies at robots.txt if you block the wrong agents. For ChatGPT and the other shopping-capable assistants to find and verify your products, your robots.txt has to allow at least these user agents: OAI-SearchBot (OpenAI's search and shopping crawler), ChatGPT-User (live fetches triggered by a real person's prompt), PerplexityBot, and Claude-User. A surprising number of WooCommerce stores inherited a restrictive robots.txt from an old SEO plugin config and are quietly invisible to exactly the crawlers they now want.
Here is the part nobody warns WooCommerce operators about: those same bots wreck your store analytics. WooCommerce reporting, and most WordPress analytics stacks, count sessions and page views without cleanly separating agent traffic from human traffic. When OAI-SearchBot and PerplexityBot start fetching your product pages dozens of times a day, your "traffic" climbs while your conversion rate looks like it cratered, because bots browse and never check out. This is a real, documented WooCommerce pain point, not a hypothetical. You end up making merchandising decisions off numbers that are half robot.
The fix is two-sided. Allow the agents you want in robots.txt, and separately, get visibility into which bots are actually hitting you so you can read your human numbers honestly. Server logs hold the truth that Google Analytics filters out by design. Knowing that PerplexityBot pulled your bestseller forty times yesterday is both a discovery signal worth celebrating and a correction your analytics needs.
An agent that finds your feed will still fetch the product page to confirm the details before it acts. That page has to answer three questions in HTML the agent can read without executing your full JavaScript bundle: what is this, what does it cost, and can I get it. The answers need to live in the server-rendered markup, plus schema.org/Product structured data with offers, price, priceCurrency, and availability.
This is where WooCommerce themes diverge sharply. WooCommerce core does output Product schema and server-rendered pricing on a standard product template. But theme authors override those templates constantly, and plenty of popular themes move price into a client-side cart widget, lazy-load the schema, or render variant pricing only after a JavaScript event fires. The result is a store that looks perfect to a human and shows a blank or wrong price to a crawler-style agent. You cannot assume your theme gets this right just because WooCommerce can. You have to check the actual rendered HTML.
The practical test: fetch your own product page the way a non-browser agent would, with JavaScript disabled or via a raw HTTP request, and look for the price, the availability, and the JSON-LD Product block in the response body. If they are missing from that raw HTML, no shopping engine and no agent is going to reliably parse your store, no matter how good your feed is. Compare it against the end-to-end agent purchase flow and you can see exactly which stage your theme breaks at.
Submitting a feed and editing robots.txt feels like progress, but the only proof that any of it landed is observed agent behavior. Before you tell yourself the store is agent-ready, get evidence on three things.
First, confirm the allowed bots are actually fetching. Pull your server logs and look for OAI-SearchBot, ChatGPT-User, PerplexityBot, and Claude-User requesting your product URLs. If they are hitting your pages, your robots.txt change took and your pages are reachable. If they are not, something is still blocking them, and the feed submission was premature.
Second, confirm what the agents see. A 200 response is not the same as a parseable page. Verify that the price, availability, and Product schema appear in the raw HTML those crawlers receive, not just in the browser-rendered view.
Third, watch for the gap between feed and reality. If your feed lists products the agent never successfully fetches, or prices that do not match the page, that mismatch is the failure mode that quietly drops you from results. The WordPress llms.txt guide covers the companion file that helps agents navigate which pages matter, and the ChatGPT Shopping feed guide goes deeper on feed field requirements. To shortcut the whole verification loop, the free Agent-Ready Grader fetches your store as an agent would and reports back what it can and cannot read.
WooCommerce did not get the free integration Shopify did, but the underlying capability is all yours to wire up. Build the feed, point Stripe at the payment layer, harden the product pages, and verify with real crawls. The stores that do this now are discoverable while their category is still mostly invisible.
Written by Crawlytics Team. Crawlytics tracks AI bots, generates llms.txt, and powers WebMCP commerce, all from one snippet on any stack. See how it works →
Yes, but not automatically the way Shopify and Etsy stores do. ChatGPT Shopping ingests product data from structured feeds, and Shopify and Etsy expose every merchant's catalog through a platform-level integration. WooCommerce has no equivalent native integration, so a WooCommerce store appears in ChatGPT Shopping only after you generate a product feed yourself, host it at a stable URL, and keep your product pages server-rendered and parseable. The capability is fully available to WooCommerce. The difference is that you build the connection manually instead of inheriting it from a hosting platform.
You do not strictly need Stripe to be discovered, but it is the realistic payment rail for agent-initiated purchases on WooCommerce today. Stripe has been building agentic-commerce tooling that lets an AI agent complete a payment programmatically rather than filling out a human checkout form. Because WooCommerce already integrates with Stripe and Stripe is publishing the agent-payment primitives, it is the most direct path to the payment layer. This area is still evolving, so the exact integration details are a moving target. Discovery, feed, and page-readability work matters first regardless, since an agent has to find and trust your product before payment is ever in question.
WooCommerce has published direction toward agentic commerce, so native support is plausible, but no specific shipped feature or timeline should be assumed. The honest read as of mid-2026 is that a roadmap and intent exist publicly, while the concrete integration most stores need is still the manual build described here: feed generation, Stripe for payments, and agent-readable pages. Treat any claim of finished native ChatGPT integration with skepticism until WooCommerce ships and documents it. Building the manual path now costs little and does not get wasted if native support later arrives, because the feed and schema work it relies on are the same foundation.
Allow OAI-SearchBot, ChatGPT-User, PerplexityBot, and Claude-User at minimum for ChatGPT and the major assistant shopping surfaces to discover and verify your products. OAI-SearchBot handles OpenAI's search and shopping crawling, while ChatGPT-User represents live fetches triggered by a real person's prompt. Many WooCommerce stores inherited a restrictive robots.txt from an old SEO plugin and are accidentally blocking these. Be aware that allowing them also means they will appear in your traffic, inflating WooCommerce session counts and depressing your apparent conversion rate, so allow them in robots.txt and separately filter them out of your analytics reporting.
Check your server logs for AI user agents, because Google Analytics and most WordPress analytics plugins filter or miss them. Look for OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-User, and GPTBot, and note which product URLs they request and how often. ChatGPT-User hits specifically mean a real person's prompt led ChatGPT to fetch your page live. The free Crawlytics Agent-Ready Grader automates this by fetching your store as an agent would and reporting what it can read, and Crawlytics ongoing tracking identifies which AI crawlers touch which pages over time so you can separate agent interest from human traffic.
This page is part of Crawlytics.app. View all pages: llms.txt · llms-full.txt