How can you tell if an AI assistant read your page live or answered from memory?
Check your server or CDN logs for user-initiated fetchers such as ChatGPT-User, Claude-User, or Perplexity-User at the moment someone asked a question. A live fetch leaves a request in your logs. Then test with a detail you changed recently. If the answer reflects the change, the assistant read a current copy.
This question matters more than it sounds. When a buyer asks an assistant about your product, the answer can come from three very different places: what the model learned during training, a search index the assistant keeps, or a page it fetched right then. Each source updates on a different schedule, and each needs a different fix when the answer is wrong.
I work on AI search visibility for B2B sites, and the first step in any diagnosis is figuring out which source produced a bad answer. Here is how I separate them.
What are the three ways an AI assistant can know about your page?
An assistant can know your page from training data, from a search index built by a crawler, or from a live fetch triggered by a user's question. Training data is the oldest and slowest to change. A search index refreshes on the crawler's schedule. A live fetch reads whatever your page says at that moment.
Training memory is baked into the model. If your pricing changed after the model's training cutoff, the model alone will not know. It may still answer confidently with the old figure, because it has no way to sense that its information is stale.
Search indexes sit in the middle. Assistants with search features crawl the web ahead of time and keep an index of pages they can cite. Live fetches are the freshest. When a user asks a question that needs a specific page, the assistant may request that page in real time and read it before answering.
Which crawlers fetch pages live when a user asks a question?
The major assistants publish separate user agents for user-initiated fetches. OpenAI documents ChatGPT-User, Anthropic documents Claude-User, and Perplexity documents Perplexity-User. Each vendor describes these agents as fetching pages in response to a person's request, which is different from their crawlers that build training sets or search indexes.
OpenAI's bot documentation says that when users ask ChatGPT or a custom GPT a question, it may visit a web page with the ChatGPT-User agent, and that this agent is not used for crawling the web in an automatic fashion. OpenAI also notes that because these actions are started by a user, robots.txt rules may not apply.
Perplexity's documentation describes Perplexity-User as supporting user actions within Perplexity and says it generally ignores robots.txt rules because a user requested the fetch. Anthropic's support page says blocking Claude-User prevents its system from retrieving your content in response to a user query. Those three agents are the fingerprints of a live read.
How are search crawlers different from training crawlers?
Search crawlers build the index an assistant cites in search answers, while training crawlers collect content that may be used to train future models. Blocking one does not block the other. OpenAI separates OAI-SearchBot from GPTBot, Anthropic separates Claude-SearchBot from ClaudeBot, and Perplexity describes PerplexityBot as a search crawler.
The difference matters for visibility. OpenAI says sites that opt out of OAI-SearchBot will not be shown in ChatGPT search answers, and that disallowing GPTBot signals content should not be used to train its foundation models. Anthropic gives a similar split: blocking ClaudeBot excludes future content from training, while blocking Claude-SearchBot affects indexing for search.
Perplexity says PerplexityBot is designed to surface and link websites in search results and is not used to crawl content for AI foundation models. If you want to appear in AI answers but keep content out of training, these separate agents are how you express that choice. I discuss one version of that decision in whether to block AI crawlers from your pricing page.
How do you check your logs for a live fetch?
Pull raw request logs from your server or CDN, filter by the user-initiated agents, and look for requests to the page in question around the time you or a colleague asked the assistant. A matching request means a live read. No request, combined with an answer, means the assistant used its index or its memory.
Not every host gives you raw logs, so check what your hosting plan or CDN offers before you plan this test. If you cannot see logs directly, some teams put a CDN or proxy in front of the site that records requests. Either way, you need timestamps and user agent strings to make the comparison.
Run the test deliberately. Open the assistant, ask a question that should require your specific page, and note the exact time. Then search the logs for that window. Repeat with two or three different assistants, since each behaves differently.
How can you test without access to server logs?
Use a freshness probe. Change a small, harmless, verifiable detail on the page, such as a dated note or a new example sentence, then ask the assistant a question whose answer depends on it. If the assistant repeats the new detail, it read a current copy. If it repeats the old one, it used stored information.
Keep the probe honest and useful. Do not add fake facts to your site to trick an assistant. A real update, like adding this month's date to a changelog entry or a new answer to an FAQ, works fine and helps human readers too.
Ask the assistant to show its sources as well. Many assistants cite links when they search. A citation to your page is a good sign it used your page, though it does not tell you whether the copy was fetched live or pulled from an index. Combine citations with the freshness probe for a clearer picture.
What should you fix when the answer comes from memory?
If the assistant answered from training memory with stale facts, you cannot edit the model, but you can make current information easier to fetch and cite. Keep key facts on clear, crawlable pages, state them in plain sentences, and make sure search and user-initiated agents are allowed. Then the assistant has a fresher source to prefer.
Memory errors are frustrating because they persist. The practical move is to give the assistant a reason to look things up. Clear pages that answer the exact question a buyer asks are more likely to be retrieved than facts scattered across a long page.
When the answer comes from an outdated index instead, the fix is about recrawling. My post on why AI answers cite an old version of your page covers that case, and how AI answer engines decide a page is still current explains the signals that help.
How often should you run this check?
Run it whenever an important fact changes, such as pricing, plans, integrations, or your product's main use case, and otherwise once a quarter for your most important pages. The goal is not constant monitoring. It is knowing which source to fix when a buyer reports that an assistant told them something wrong.
The method I recommend is simple. Keep a short list of the questions buyers ask most about your product. After any major site change, ask those questions in a few assistants and note where each answer came from. That takes little time and catches problems before sales hears about them on a call.
Record the results in a simple sheet with the date, the assistant, the question, the answer, and whether it matched your current site. Over a few quarters, the sheet shows which assistants refresh quickly and which lag.
What should you do next?
Pick one page with a fact that changed recently, ask three assistants about it, and check your logs or run a freshness probe to see which source answered. Then review your robots.txt to confirm you allow the search and user-initiated agents you want. That one test tells you more than any visibility score.
The useful mindset is that wrong AI answers have causes. Memory, index, and live fetch each fail in their own way. Once you know which one produced the answer, the fix becomes a normal web task rather than a mystery.
If you want help diagnosing how AI assistants describe your product, or setting up the pages and crawler rules that keep those answers current, reach out. I help B2B teams get found and cited by AI engines. Let's chat.
Get found, cited and the back office automated
Let's make your site the source AI engines quote and wire up the systems behind it.
Read more blogs
Let's get your website found and cited by AI
Tell me what you're working on, whether AI search is skipping your product, your back office is buried in manual work, or you need a build that does both.