Key takeaways
- When an assistant searches before it recommends a vendor, its answer rests on the pages it retrieved, and it shows some of them as citations. When it does not search, it rests on what the model already holds, and nothing is cited.
- You can trace the evidence behind one recommendation: pick the answer, read its citations, sort each source by kind and owner, and compare what the recommended vendor has with what you have.
- Check the trace on the next run. A source that keeps coming back is evidence the answers lean on; a source that appears once may be chance.
When AI assistants recommend B2B software vendors after searching the web, they rely on the pages that search returns: the vendors' own pages, review and directory listings, independent comparisons, trade press, studies and community threads, a selection of which the answer shows as citations. When they answer without searching, they rely on what the model learned in training, which leaves no citation to follow. The reliable way to see which evidence carried a particular recommendation is to trace it: read the answer's citations, sort them by kind and owner, and compare the recommended vendor's evidence with your own, over more than one run.
This playbook sets out that trace step by step. Two other pieces cover the ground around it, and this page does not repeat them. How AI assistants choose which B2B vendors to recommend explains why one vendor is put forward and another only named, and how an AI answer is assembled from public evidence walks through the mechanics, from the question to the answer. Here the job is narrower and practical: taking one recommendation apart to see what it stood on.
What the assistants' makers say about sources
Start with what the companies themselves document, because it sets the limits of any trace.
OpenAI's developer guide to web search says the model can choose whether to search based on the question. When it does, the response includes inline citations for URLs found in the search results. The guide also describes a separate list of sources: every URL the model consulted while forming its response. It says inline citations show only the most relevant references, and that the number of sources is often greater than the number of citations. OpenAI's help article on searching the web with ChatGPT says that in ChatGPT a Sources view lists the cited sources and other relevant links, and that search results and citations can be incomplete, out of date or wrong.
Anthropic's documentation for Claude's web search tool says Claude decides when to search, and answers directly from stable knowledge when it does not need current information. When it searches, citations are always on, and each one carries the URL, the title and a short extract of the text it drew on. Anthropic's help article on web search in Claude says answers that search include citations and source links, with quotes where relevant.
Last checkedThree things follow for anyone tracing a recommendation:
- A citation is a selection. What you see cited is what the answer chose to show, not everything it read.
- An uncited answer is not traceable. If the assistant answered without searching, the recommendation rests on the model's existing knowledge, and there is no page to follow.
- The citations can themselves be wrong. Both companies say so, so a trace reads the cited page to check it supports the claim beside it.
Academic work points the same way. A September 2026 preprint on arXiv, Evaluating Brand Retrieval and Ranking in Large Language Model Recommendations, argues that repeated responses to the same question can produce different brands in a different order, that questions stating a buyer's goals and constraints change which brands are retrieved, and that recommendations are best evaluated by sampling many times rather than from one list. An earlier paper, GEO: Generative Engine Optimization, tested content changes on a benchmark rather than on live assistants, and found the effect varies by domain. Read both as direction for how to look, not as a promise about what any change will do.
Last checkedThe trace, step by step
The trace is part of the same five-step method we use for all AI visibility work: measure the questions, read the evidence, find the gaps, act, and measure again. How a B2B tech company gets recommended more often by ChatGPT and Claude covers the whole method. This playbook goes deep on the reading: what one recommendation rests on, and what your own record lacks beside it. Each step names its inputs, its outputs and what it cannot tell you.
The worked example is fictional: a UK HR software company that sells to employers of 200 to 2,000 staff, whose strengths are payroll integration and absence management. It tracks two rivals, Rival A and Rival B.
Step 1: Pick the answer
Choose one answer that recommended a rival for a question that matters to you, ideally one where you were absent or named but not put forward. Take it from a recorded set: an answer you can date, with the assistant and the exact question noted, and with its citations kept. An answer you saw once on a colleague's screen is a poor place to start, because you cannot check it again.
Pick an answer that searched. If it carries no citations, note it, set it aside and pick another; you will come back to the uncited answers at the end.
- Inputs: a recorded answer, its date, the assistant, the exact question and its citations.
- Outputs: one answer chosen for tracing, with the recommended vendor and the claim the answer made for it written down.
- What this cannot tell you: whether this answer is typical. One answer is a starting point for a trace, not a reading of your position.
In the example. The company picks a ChatGPT answer to "Which HR software suits a UK employer of 500 staff that needs payroll integration?". It puts Rival A forward "for its documented connections to the main UK payroll systems", names Rival B as an alternative, and does not mention the HR company. It cites four sources.
Step 2: Read its citations
Open every cited page and read it. For each one, note three things: which claim in the answer it sits beside, whether the page actually supports that claim, and the date the page carries. Anthropic's citations include the extract the answer drew on, which makes the second check quicker; for other assistants, find the passage yourself.
Where your collection keeps the wider list of sources consulted, as OpenAI's API does, look at that list too, but keep it apart. A page that was consulted but not cited was read, and the answer chose not to show it. That is worth knowing, and it is not the same as being cited.
- Inputs: the chosen answer and each cited page.
- Outputs: a list of cited sources, each tied to the claim it supports, with a note where a page does not support what sits beside it.
- What this cannot tell you: how much weight the assistant gave each source, or what it read and did not show. A citation is evidence of use, not a measure of influence.
In the example. The four citations are Rival A's payroll integration page, which names six UK payroll systems; a comparison article on an independent HR blog, which describes Rival A's payroll sync in two sentences; a UK software directory category page, where Rival A's listing names its payroll connections; and a case study on Rival A's site about a 400-person employer. All four support the claim they sit beside.
Step 3: Sort each source by kind and owner
Now sort the sources. Two labels per source are enough.
The kind of page:
- the recommended vendor's own pages (product, documentation, case studies, pricing);
- review sites and software directories;
- independent editorial: comparisons, trade press, analyst notes and blogs;
- studies and research;
- community: forums, social posts and question-and-answer threads;
- documentation from a platform or standards body.
The owner of the page: the recommended vendor, you, another rival, or an independent party. Where you cannot tell who owns a page, say so rather than guessing.
The pattern that comes out is the useful part. An answer resting entirely on the recommended vendor's own pages stands on self-description. One resting on a directory listing and an independent comparison stands on corroboration. The mix tells you what kind of evidence you would need to match.
| Cited source | Kind | Owner | Claim it supports |
|---|---|---|---|
| Payroll integration page | Vendor's own page | Rival A | Names six UK payroll systems |
| Comparison article | Independent editorial | Independent | Rival A syncs with UK payroll |
| Directory category page | Directory | Independent | Rival A lists payroll connections |
| Case study | Vendor's own page | Rival A | Rival A fits a 400-person employer |
- Inputs: the cited sources from step 2.
- Outputs: each source labelled by kind and owner, and a one-line summary of the mix.
- What this cannot tell you: which kind of source mattered most. The sort shows what was there, not why it was chosen.
In the example. The mix is two of Rival A's own pages and two independent pages, a directory and a comparison. The recommendation stands on a specific claim stated by Rival A and repeated by two independent sources.
Step 4: Find what the recommended vendor has that you lack
Put the recommended vendor's evidence beside your own, source by source. For each cited source, ask whether you have an equivalent: a page of yours making the same kind of specific claim, a listing on the same directory saying it, a mention in the same comparison. Where you do, ask why yours was not cited: is it as specific, as current, as readable? Where you do not, you have found a gap.
Sort the gaps using the classes in Evidence gaps, so the trace feeds the same register as the rest of your work. Then check that you are not simply ineligible: if the question asks for something you do not offer, the honest answer is to leave it.
- Inputs: the sorted sources, and your own pages, listings and mentions.
- Outputs: a short list of what the recommended vendor has and you lack, each labelled with its gap class.
- What this cannot tell you: that filling the gap will earn you the recommendation. It shows what stood behind this answer, not what the next one will require.
In the example. The HR company does connect to the same six payroll systems, but says so only inside a product tour that loads by script. It has a listing on the same directory, last updated two years ago, with no payroll connections named. It is not in the comparison article at all. It has no case study about an employer of a similar size. So the trace yields four gaps: a page a crawler can read that names the systems, an updated listing, an accurate mention in the comparison, and a case study with checkable facts. The first two are within its control this month.
Step 5: Check it again on the next run
Ask the same question again, of the same assistant, more than once, and repeat steps 2 and 3 on the new answers. Sources that come back across runs are the evidence the answers lean on for this question. Sources that appear once may be chance. A rival recommended in every run on the same sources is in a different position from one that appears now and then on different ones.
Then look at the uncited answers you set aside in step 1. If they recommend the same rival without citing anything, the recommendation sits in the model's existing knowledge as well as in search, and the public record behind it is broad. That is slower to change, and it is worth knowing.
- Inputs: new runs of the same question, traced the same way.
- Outputs: the sources that recur, the ones that do not, and a revised gap list.
- What this cannot tell you: what will happen on runs you have not seen. Answers change from run to run, and a provider can change its assistant at any time.
In the example. Two more runs both put Rival A forward. The directory page and the comparison article are cited in both; Rival A's case study appears once. One run also cites a review site with a thread about Rival A's onboarding. The company concludes that the directory listing and the comparison are the evidence this question leans on, and puts its own listing update at the top of its list. Turning AI visibility data into a content plan shows how a list like this becomes briefs, an order of work and a re-measure date.
What tracing cannot show
The trace is the closest view a company gets of what a recommendation stood on. It still has limits, and they should be stated as plainly as the findings.
- Uncited training material. An answer that did not search rests on what the model learned earlier. No trace reaches it, and nothing published today changes it until the provider trains again.
- Change from run to run. The same question can return different vendors on different sources the next day. A single trace is one observation; only repeated traces show a pattern.
- What was read but not shown. Citations are a selection. Even where a wider source list is available, it shows what was consulted, not how each source was weighed.
- Why the assistant chose. The trace shows what was cited and how the sources compare. It does not show the assistant's reasoning, and no one outside the provider can see it.
- What any fix will do. A gap found by tracing is a good bet for where to work, not a promise of a result. No one outside OpenAI, Anthropic or any other provider controls what their assistant recommends.
If you want this run for you
A trace can be done by hand on a few answers. If you want it done across all your buyer questions, the AI visibility audit records the answers, reads which sources the assistants lean on and maps the evidence gaps, and AI visibility measurement and marketing repeats the trace each month on the same questions and does the work that supplies the missing evidence. Mention, citation and recommendation explains the three outcomes every trace keeps apart.
