Can ChatGPT read your WooCommerce store? Test it in 5 minutes

A developer created a five-minute test to check whether AI assistants like ChatGPT, Claude, and Copilot can accurately retrieve product information from WooCommerce stores. The test involves four prompts that assess baseline knowledge, live product listings, specific product details, and discoverability. Results show that most stores fail due to outdated training data or inability to parse JavaScript-rendered content, with the most dangerous outcome being confident but incorrect pricing or invented products.

People increasingly ask AI assistants for shopping help. Not as a replacement for search — as a shortcut past it. "Find me a mid-range espresso machine that ships to Italy." "What's a good gift under 50€ for someone who keeps bees?" The assistant answers with specific products, from specific stores. The uncomfortable question for a store owner is simple: when that conversation touches your category, do you exist in it? You don't have to guess. You can measure it right now. Open ChatGPT, Claude, Copilot, or whichever assistant you like. Then run these four prompts, in order, replacing the placeholders with your real store. Write down what you get. Before you start— for the fairest result: use a fresh chat, enable web search if the assistant offers it, don't upload files, don't paste product data, and note the assistant, the date, and whether it cited live sources. This is not a laboratory benchmark — results vary by assistant, country, language and day. It's a practical visibility test: can a buyer-facing assistant find and repeat the truth about your store? What does yourstore.com sell? This is the baseline. Can the assistant say, in one sentence, what your store is? A wrong or vague answer here means everything downstream is guesswork. Using live web information if available, list some products currently for sale on yourstore.com , with prices and source links. This is where most stores fall apart. Watch closely for products you discontinued years ago, prices from an old promotion, or — the most dangerous case — products that sound plausible but never existed. The assistant isn't lying; it's reconstructing from stale fragments, and it fills the gaps. And if it doesn't cite sources at all, that is already part of the result. How much does exact name of one of your current products cost on yourstore.com ? What is its stock status? Pick a product you know well — current price, current stock status. This test has a right answer, and you know it. The assistant usually doesn't. Compare on stock status in stock / out of stock , not exact quantities — many stores deliberately don't expose quantity, and that's fine. I'm looking for the thing you sell online. Which stores should I check? Don't mention your store at all. This is the discovery test: when a buyer asks the open question — the way real buyers actually ask — does your store enter the answer? For many independent stores, this is where the gap becomes visible. If yours doesn't appear, that doesn't prove your store is bad — it shows the difference between being accessible when named and being discoverable when the buyer has never heard of you . | What you got | What it means | |---|---| | "I don't have information about this site" | Your store is effectively invisible to that assistant. Not penalized — simply absent from what it can use. | | A description that's roughly right, products that are wrong | The assistant has crawled or memorized about you, but has no usable catalog data. It knows the shop exists; it can't sell anything from it. | | Confident, specific, wrong prices or invented products | The most dangerous state. A buyer who gets told your product costs 29€ when it costs 49€ arrives at checkout already feeling cheated — you inherit the assistant's mistake. | | Accurate products, live prices, real stock | Rare today. It means the assistant has a structured, machine-readable path into your catalog — this is the target state. | It's tempting to conclude the AI is bad at its job. The real reason is more mechanical, and it's worth understanding because it tells you what actually fixes it. Your storefront is HTML built for human eyes. Prices live inside styled markup, availability is a badge, variants are a dropdown that only makes sense after JavaScript runs. When an assistant relies on training data, it's working from a snapshot that may be months old. When it browses live, it has to reverse-engineer meaning from presentation — expensive, error-prone, and often blocked halfway by cookie banners, lazy loading, or bot protection. None of this is your theme's fault. Storefronts were never designed to be read by software that needs to act on the answer . A human glances at a product page and knows the price. A machine has to guess which of the seven numbers in the markup is the price, whether it includes tax, and whether "only 2 left " is real inventory or urgency theater. So the fix isn't "better content" or "more SEO" — and it isn't just adding more markup to the page. Many WooCommerce themes already emit schema.org/Product markup, and it helps; but embedded markup still lives inside a page built for humans, with the same staleness and rendering problems around it. The fix is giving machines a stable catalog surface: the same products exposed as structured, current, read-only data — exact price as a number, stock status as a verifiable field, variants as data instead of UI state. Two of the four tests fail for one reason; the other two fail for a different one. This distinction matters, because they have different fixes. Tests 1–3 fail because your store isn't machine-readable. The assistant can't reliably read what you sell even when it's looking straight at you. This is solvable per-store: expose your catalog as structured data. For WooCommerce, that's what KaliCart Bridge does — a free plugin that publishes a read-only, machine-readable version of your existing catalog live prices, real stock status, variants as data without changing anything about your storefront. Any agent that discovers that catalog surface has a cleaner path to the truth than scraping HTML. Test 4 fails for a different reason: readability isn't discovery. An agent that answers "which stores should I check?" can only draw from what it can search. Making your own store readable helps agents that already know your domain — it does nothing for the agent serving a buyer who has never heard of you. That's the problem a federated catalog exists to solve: one shared index across independent stores, queryable in a single call, that an agent can search without knowing any of the stores in it beforehand . A federated catalog doesn't magically guarantee traffic — what it creates is the missing mechanism. It's early, and the network is small today, but it's the only honest answer to Test 4 that doesn't involve paying a marketplace for the privilege. The best property of this test is that it's repeatable. It costs nothing, takes five minutes, and has answers you can verify against your own admin panel. Run it today and write down the results. If you change something — install Bridge, restructure your data, join a federated index — run it again and compare. No dashboard, no vendor report, no promise to take on faith. Just the same four questions, and whether the answers got better. That's also the standard you should hold us to. Have you run these four prompts on your own store yet? What was the most wrong — or most creatively invented — answer you got back? Drop it in the comments.