What AI tools actually read on your store
AI assistants answer from text that small automated programs fetched earlier. Here is what those programs see, what they miss, and how to check yours.
Someone asks an AI assistant for a waterproof coat for a large dog, in stock, under a hundred pounds. The answer comes back in a few seconds, with a couple of shops named in it. The assistant might use a search index built earlier, fetch a page for that question, or combine both routes. Your store can therefore be found before the question, at the moment somebody asks it, or not at all.
Those programs are the audience this article is about. They are not shoppers, and they read a store in a way that would look strange to you if you watched it happen.
Who is actually visiting
Four companies publish controls that matter for AI training, search, and user-requested visits. OpenAI publishes GPTBot, OAI-SearchBot, and ChatGPT-User. Anthropic publishes ClaudeBot, Claude-SearchBot, and Claude-User. Perplexity publishes PerplexityBot and Perplexity-User. Google publishes Google-Extended, but that one is a control in robots.txt rather than a separate visitor name. Google's existing visitors do the fetching.
The names ending in User work differently from the rest, and the difference is worth a sentence. ChatGPT-User, Claude-User, and Perplexity-User can fetch a page when a person asks for it. The other controls have separate purposes. GPTBot and ClaudeBot cover possible model training, while OAI-SearchBot, Claude-SearchBot, and PerplexityBot support search. So a store can be absent from one company's stored search material and still be fetched for a request, depending on the tool and its rules.
There are nine controls in that list. Eight are named visitors that may appear in server records. Google-Extended appears only as a control in robots.txt, not as the name on a request. The companies document the purposes and current rules here: OpenAI, Anthropic, Perplexity, and Google.
What they actually see
An automated visitor starts by asking your server for a page. Some readers use that first response. Others can run the page's own programs or inspect a rendered page. Google says its search system can process content added by page scripts, and its current guidance says browser agents may inspect the rendered page and its controls. No one viewing the first response should assume it describes every AI tool.
That first response usually carries plenty. Your product names, your descriptions, the words in your navigation and your footer, and your prices when the price is written into the page itself rather than added a moment later.
What they miss
Some storefronts send a shopper a page skeleton first, then fill in the price, the stock status, and the reviews afterward, using a small program that runs inside the shopper's browser. A person may never notice the join. An automated visitor that does not run that program reads the page in its skeleton state. Even Google, which can run page scripts, recommends putting fast-changing product facts in the first response for more reliable shopping results (Google's product guidance).
Words inside a picture are invisible to it too. A size chart saved as an image, a banner with the discount written into the graphic, a returns policy set in nice type as part of a logo block: none of that reaches an assistant unless the same words also exist as text on the page.
Getting in and finding something are two different problems
It helps to keep these apart, because they look identical from the outside and they have completely different fixes.
The first question is access. Is the automated visitor allowed to fetch the page at all. The second question is content. Once it has the page, is anything useful written in it.
A store can pass one and fail the other. A page can be wide open to every visitor on the internet and still hand over a shell with no price, no stock status, and nothing but a product name. Checking one of these tells you nothing about the other.
The file that decides who gets in
Access for compliant automated visitors is guided by a small public file called robots.txt, which sits at yourstore.com/robots.txt on almost every site. It is a plain text file listing rules by visitor name, saying which parts of the site each visitor may read and which parts to leave alone. Think of a sign at a building entrance naming specific visitors and telling each one where they can go. Published training and search programs from the companies above follow the sign. Some user-requested visits are exceptions. OpenAI says the file may not apply to ChatGPT-User, and Perplexity says Perplexity-User generally ignores it.
Most stores use it for something sensible and unrelated to AI, such as keeping automated visitors out of admin pages, the cart, and checkout. The trouble starts when a rule written for one purpose quietly covers something else. A security plugin installed to turn away unwanted traffic can turn away GPTBot and ClaudeBot in the same stroke, and nothing in your admin screen will mention it, because everything still looks perfectly normal to a human visitor.
We go further into reading that file, and into the choice of whether to allow or block AI visitors on purpose, in a companion article on robots.txt.
Check your own store
You do not have to guess at the first-response case. SchemaCart's free scan reads your homepage and a product page without running the page's own scripts, so it reports what a reader using that route receives. It also reads your robots.txt file and reports the nine entries it currently tracks, including Anthropic's newer Claude-SearchBot. The scan takes about a minute, needs only your store's web address, and there is no login and no plugin to install.
Reading your own visitor log
A scan tells you who is allowed in. It cannot tell you who has actually turned up, and only your own records know that.
Most hosting control panels keep an access log, which is a running record of every request made to your site along with the name each visitor sent with it. Search that log for GPTBot, ClaudeBot, or PerplexityBot. A store that has never seen any of those names, month after month, has a different situation on its hands than a store that sees them arrive regularly. If reading raw log files is not something you or your team do, ask whoever maintains your hosting, since it is usually a two-minute search for them.
What to do next
Start with the file, because it is the fastest thing to check and often the fastest thing to fix. Open yourstore.com/robots.txt in a browser and read it. If you find one of the nine controls above followed by an instruction to stay away from the whole site, check the company's published purpose and decide whether anybody meant to restrict it.
Then look at how your product pages are built. If your theme or a plugin fills in the price or the stock status after the page arrives, ask whoever maintains your site whether those details can be written into the page from the start instead. That is normally a one-time change to a template, not a chore you repeat for every product.
Then put it in the calendar. Plugins update, themes get replaced, and a security setting changed for an unrelated reason can reopen the same problem months later. A few minutes now and then is enough to catch it.
The honest limit
None of this decides whether an assistant mentions your store when somebody asks. That call belongs entirely to the companies building these assistants, and nobody outside those companies has a lever on it. What you control is narrower and comes first: whether your store can be read at all when one of these programs arrives. Being readable is not an outcome, it just means you have not been ruled out before anyone looked.
If you want to see what an automated visitor gets from your store today, run the free scan at SchemaCart. No card, no signup, about a minute.