Does your WooCommerce store let GPTBot in? Check it in two minutes
Everyone checks robots.txt, and that is almost never where the problem is. Here are the exact commands to find out whether ChatGPT can read your store, and the four things that actually block it.
It is this year's conversation, and it always starts the same way: "my store doesn't appear in ChatGPT, there must be something in robots.txt".
So I went and checked. I took the WooCommerce stores I could genuinely verify — confirming with the Store API that they really were WooCommerce, rather than trusting how the site looked — and read their robots.txt one by one.
None of them blocked GPTBot. Not ClaudeBot, not PerplexityBot either. Almost all of them served WordPress's stock robots.txt, which does not name a single AI crawler.
Small sample, and I'll say so up front: this is a spot check, not a study. But it points at something that matches everything else I see: robots.txt is almost never the culprit, and while you're looking there you're not looking where it hurts.
What WordPress writes by default
If you haven't touched anything, WooCommerce doesn't generate its own robots.txt. WordPress generates a virtual one, and it says roughly this:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://yourstore.com/wp-sitemap.xml
That's it. User-agent: * includes GPTBot, and Disallow: /wp-admin/ doesn't stop it reading your products. That file lets them through.
So if your store isn't showing up in ChatGPT, the reason is somewhere else. There are four of them.
1. Cloudflare, blocking without telling you
This is by far the most common and the most invisible.
Since July 2025 Cloudflare blocks AI crawlers by default on newly onboarded domains, and offers a one-click block for existing ones. Plenty of people pressed it at the time, or have it on without knowing because it came switched on.
What matters is where it blocks: at the edge, before anything reaches your WordPress. Your robots.txt still says yes. Your server returns 403. And since you browse with a normal browser, you never see anything wrong.
Fix it in the Cloudflare dashboard, under Security → Bots → AI Scrapers and Crawlers. If you want AI to find you, that block needs to be off.
2. The checkbox left over from the build
In WordPress under Settings → Reading there's a checkbox that says "Discourage search engines from indexing this site".
If it's ticked, WordPress rewrites your entire robots.txt as:
User-agent: *
Disallow: /
That's a door slammed on everyone: Google, Bing, GPTBot, ClaudeBot, all of them. And it's surprisingly common, because it gets ticked while the store is being built and nobody remembers to untick it.
Check it right now: open yourstore.com/robots.txt in your browser. If you see a bare Disallow: /, you've found it.
3. Your host's WAF or a security plugin
Plenty of firewalls look at the user agent and cut off whatever they don't recognise, or apply rate limits so tight that the crawler gets a 429 and doesn't come back. Security plugins with a "block fake bots" option do the same thing to the real ones.
This one shows up in no file. You only find it by testing.
4. Product pages rendered with JavaScript
This isn't a block, but the result is identical.
GPTBot does not run JavaScript. If your price, stock or product description is painted by the browser after load, the crawler sees the gap. The page loads with a perfect 200 and there's nothing inside worth quoting.
How to check it yourself, in two minutes
This is all it takes. Request your store pretending to be GPTBot, and compare it with what a browser gets.
curl -s -o /dev/null -w "GPTBot: %{http_code}\n" -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot" https://yourstore.com/
curl -s -o /dev/null -w "Browser: %{http_code}\n" -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0 Safari/537.36" https://yourstore.com/
How to read the result:
- Both 200 — you're letting them in. Keep reading, because the important part comes next.
- Browser 200, GPTBot 403 / 429 / 503 — there it is. Something is blocking at the edge: Cloudflare, the WAF or the host. That's your problem.
- Both 403 — this isn't about AI; your server rejects anything that doesn't look like a full browser.
Repeat it on a product page, not just the homepage: that's what you actually want AI to read, and sometimes the homepage passes while product pages don't.
And to find out whether there's real content or just the skeleton:
curl -s -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.2; +https://openai.com/gptbot" https://yourstore.com/product/whatever/ | grep -c "€"
If that returns 0, JavaScript is painting your price and the crawler can't see it.
How to let them in, and say so clearly
User-agent: * already covers them, but it's worth naming them one by one. It's explicit, it survives someone adding stricter rules later, and it puts your intent on the record:
User-agent: GPTBot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: ChatGPT-User
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Google-Extended
Allow: /
Sitemap: https://yourstore.com/wp-sitemap.xml
They're worth telling apart, because they don't do the same job:
- OAI-SearchBot builds the index ChatGPT answers from when it searches the web. If you're only going to allow one, allow this one.
- ChatGPT-User is the one that shows up the moment a user pastes your link or asks "take a look at this store".
- GPTBot is the training crawler. It's the one most often blocked on principle, and that's a legitimate choice: it doesn't affect whether you get cited today.
One caveat: if you use an SEO plugin that manages robots.txt, edit it there rather than uploading a file, or the plugin will overwrite you.
The part almost everyone misses
Being allowed in is not the same as being quotable.
A crawler that reaches your store finds a catalogue spread across hundreds of pages, with navigation, menus, a cookie banner and a footer in front of it. To answer "where can I buy a Goku figure for under €50?" it needs to know what you sell, at what price, and whether it's in stock. Working that out page by page is expensive, and usually it doesn't bother.
That's what llms.txt is for: a single file, at the root of your domain, saying what you are and what you sell in a format a model reads in one go. It's the difference between a passing mention and an answer that says "it's €24.90 and it's available here".
We cover it in full, with the code to generate it from your catalogue, in how to add an llms.txt to WooCommerce.
What to do today, in order of impact:
- Open
yourstore.com/robots.txt. If it saysDisallow: /, go to Settings → Reading and untick the box. One minute, fixes everything. - Run the two
curlcommands above, on the homepage and on a product page. - If GPTBot gets a 403, check Cloudflare before anything else.
- Once they're being let in, give them something to read.
Is your store losing sales to searches that find nothing?
WildRock adds a search to your WooCommerce that understands what shoppers mean, and tells you in euros how much it generates. Free plugin, no code.
Keep reading
Synonyms in WooCommerce search: 495 searches returning zero because they were spelled differently
"blue lock" finds 22 products; "bluelock", zero. Measured today on a real store: six words customers write differently from the catalogue added up to 495 searches in 68 days, and the store had zero synonyms configured. How to find yours and fix them today.
Why Google Analytics doesn't tell you what happens in your store
Measured today on a real WooCommerce store: 47,956 searches in a month, and not one of them changed the URL, which is the only thing Google Analytics looks at to detect a search. Nor would it know which ones returned zero results: its event doesn't carry that. Here is what GA misses in a store, and how to log it yourself today with a 30-line mu-plugin.