I am publishing this research a week before it is finished, because I honestly don’t expect ChatGPT to leave this open. It doesn’t make sense for them to do so.
ChatGPT disclosed far more about its own search tooling and process than I expected it to, and there is no guarantee it keeps doing that. This kind of introspection gets closed routinely, usually without an announcement. If it stops answering these questions next month, I would rather people had a month with it than a tidier document afterwards.
The guide I’m working on is at How AI Search Works, From Prompt to Response. It includes the complete conversation where ChatGPT described the tools it uses to research an answer, ran 20 of those tools live, and printed its process in excruciating detail. Every word of every response is verbatim.
I was not looking for this. I was building a guide to AI search for marketers, and I asked ChatGPT for some information on fanout queries. In the reply it mentioned, in passing, that some result cards had been screened out before their URLs were kept.
I had never heard the term “result cards”, so I asked what a result card was, and then I kept asking. Eleven turns later I had the request format it sends to its search tools, each step of the process, the text format that comes back, a catalogue of 16 result types, the criteria it uses to decide which pages to open, and a seven-stage pipeline it follows for commercial recommendations.
Two things came out of that which matter more than the rest, and I want to put them up front. The first is that consistent ranking reports for AI search are further out of reach than most of the industry currently assumes. I already had a study running on that, comparing 1,363 answers across six models to see how much the recommendations move when one irrelevant word changes in the prompt. What this session added is a second layer of variability underneath the one I was already measuring, in the retrieval step, where the searches themselves get written and the results come back pooled with no record of which query found what. That is a compounding problem, and I will come back to it below.
The second is a working conclusion I have been circling for months and now hold with more confidence: AI search optimization belongs to the whole marketing team. Read the evidence the model goes looking for before it recommends anything, and the work stops fitting inside one person’s job description.
What a result card is
A result card is one returned search result as the model receives it. A title, a URL, the publisher, a date when one was detected, a short extract, a type, and an internal reference ID it can use to open the page later.
Three details in that object are worth your attention. Start with what is absent: there is no ranking score of any kind. No PageRank, no domain authority, no relevance score, no backlink count. ChatGPT can see what order the results arrived in and nothing about why. That does not mean the search engine behind it lacks those signals. It means they never reach the model that writes your answer, so the model evaluates sources on provenance, methodology and freshness instead of on an authority number.
There is no structured data either. No JSON-LD, no schema.org objects, no Open Graph tags, no author markup. That markup may well shape the title, the date and the extract upstream, before the card is assembled. It does not arrive as something the model can read.
And the extract is capped. Cards carry a marker like [wordlim: 200], which limits how much of that source can be used in the answer. Dates arrive as relative strings such as “Crawled: 5 months ago”, never as real timestamps.
A card is a clue about what a page might contain. It is not evidence that the page says it. Opening the page is a separate call, and plenty of URLs never get opened at all.
References
- ChatGPT Search, OpenAI Help Center. OpenAI’s public description of ChatGPT Search, including that it may rewrite one request into several targeted queries and then issue narrower follow-ups. This is the page ChatGPT itself cites throughout the session for the publicly documented parts of its behavior.
- What a result card is. The turn where the term gets defined, along with the eight-stage filtering pipeline the model describes for going from a broad search to a set of cited sources.
What the session establishes, and what it does not
I want to be precise about what this is, because this is where a piece like this usually overreaches. Nothing here came from inside OpenAI, and nobody handed me a document. What happened is that one model reported on its own tool interface, was pushed repeatedly on the difference between what it can observe and what it is guessing, and was then made to demonstrate rather than describe.
The turning point is turn seven. Up to that point ChatGPT had been writing out JSON shapes for every result type, and they looked authoritative. I asked whether any of it was real or whether it was reconstructing. It admitted the sample values had not been captured from actual calls. So I told it to go and run the calls, and from that point the values are real: an actual stock quote, an actual baseball score, an actual Reuters article with its byline, an actual heat warning for Phoenix.
Because that distinction decides how much any of this is worth, every code block in the published guide is colored by what it is. Green means the values came from a real call. Blue means the model invented them. Amber means it came from OpenAI’s published documentation. Purple means proposed or inferred. About a third are not sorted yet and say so.
The most useful findings are in the parts that are real, and the first one is structural. Requests go out as JSON. Responses come back as plain text, not as data. That single fact explains a lot about how AI answers behave, and it is visible in a rendering bug the session caught: a finance result printed -17.66000 (-0.03272%) when the actual change was -3.272%. Something attached a percent sign to a decimal fraction without multiplying by 100. Information is being flattened on the way to the model.
Fan-out results come back pooled. Four queries went out in one live call, and one undifferentiated set came back with nothing tying any result to the query that found it. Any tool telling you which fan-out query produced your brand is inferring that, not reading it.
Blocked pages are results. During a live test the search returned a robots.txt block naming a domain as non-retryable. A blocked page is not invisible to the model. It is visibly absent, and the model knows it.
Here is one of those returned results in full. This is a product card, from the worked example where ChatGPT researches a smoothie blender. The green marking is how the published guide labels a block whose values came back from a real call, as opposed to one the model constructed.
See this card in context, in the blender walkthrough. The reference ID and the merchant URL are replaced with placeholders; everything else is as it arrived.
That is not JSON, and it is not a web page. It is a text record with labeled sections, and the labels vary by retailer. The description is truncated with an ellipsis. The rating and the review count are there, the price and the stock status are there, and the category string is the merchant’s own taxonomy rather than anything standardized.
Read it as a marketer and the implication is direct. Your rating, your review count, your price, your availability and your first two lines of product copy are the record. Whatever else is on that page did not travel.
References
- Twenty live tool tests. The longest turn in the session, where ChatGPT runs a call for each result family it can invoke and prints the request and the returned text side by side.
- The color key. How the code blocks are classified, which parts of the session count as exact, and the one caution that matters most: “not exposed” means the model cannot see a field, not that the search engine lacks it.
- OpenAI Responses API reference. The public schema for the web search tool call. Worth comparing against the session: the documented object exposes source URLs and little else, while the model-facing result carries titles, extracts, dates and word limits.
The reflection prompt
The last thing in the guide is the part I expect people to actually use, and it needs its name explained first. Reflection is a programming term. It is the ability of a running program to inspect itself: to look at its own objects and report what they contain, rather than only doing what it was built to do. Not every language supports it. When it exists, it is how you find out what a system is really made of at runtime instead of reading the documentation and hoping.
The reflection prompt does the same job here. It is a prompt you paste as the first message in a new chat, with your own question at the bottom. It asks the model to expose its complete observable research workflow for that question: how it interprets the request, how it decides whether to search, the exact tool requests it sends, the responses that come back, which pages it opens, what it searches for inside them, how it compares candidates, and which parts it cannot resolve through public research at all.
Then run it on your category, with your buyer and your constraints, and you get the same walkthrough for your market that I got for hotels, blenders, CRM software, HVAC contractors and physical therapy clinics. What makes it work is a section on truthfulness that forces the model to label everything it shows: an actual tool request, a close transcription of a response, JSON it created itself, or a schema it read in documentation. Without those constraints the model produces a fluent description of a process it is partly inventing. With them, it separates what it saw from what it assembled.
References
- The reflection prompt. The full prompt, ready to paste, with an explanation of which parts do the work and why the labeling requirements matter.
- A local HVAC company. One of five worked examples running the whole pipeline on a real commercial question. Local is the hardest case in the set, because there is no dedicated local result card in the tool interface being used, so locality has to be established from ordinary web pages.
Why this belongs to the whole marketing team
Look at what the model goes looking for before it names anyone.
In the worked examples it discovers candidates, verifies current facts on official pages, looks for independent evaluation with a published methodology, hunts for recurring complaints in community sources, audits review sites for affiliate disclosures and sponsored placement, matches everything against the specific constraints in the question, and revalidates anything volatile before it answers. Your product pages, your pricing page, your documentation, your press coverage, your review profiles, your community presence, your analyst mentions and your support reputation all get read as evidence for or against you. In one example the model opened a review site and searched inside it for the words “methodology”, “affiliate”, “sponsored” and “how we evaluated”, then read the published scoring weights it found there.
SEO could be one person’s job because the surface being optimized was narrow. This is not that. The evidence base is everything anyone has published about you, and most of it is produced by people who do not report to whoever owns search.
That is an assessment, not a proven claim, and I will say plainly what would change it: if the retrieval step turns out to weight first-party pages far more heavily than the worked examples suggest, the scope narrows back toward something one team can own. The evidence in this session points the other way.
Why I am releasing it early, and what is missing
The guide is incomplete. Parts 1 and 2 are placeholders, and there is a notice at the top of every page saying so.
Those two parts hold the ranking study: 1,363 answers across six models, where the only thing that changes between runs is one word about a car the traveler is picking up, a detail that has nothing to do with the question being asked. The answers move anyway, and they move more once search is switched on, because the irrelevant word ends up inside the search queries the model writes. That work is finished and I am publishing it in the next few days, along with a cleanup pass on everything else.
Everything else is up now, in this state, for the reason at the top of this post. So take the reflection prompt and run it on your own category while it still answers. Read the color key first so you can tell which parts of the session are evidence and which parts are the model talking about itself. That distinction is the whole reason the guide is worth reading, and it is the first thing most coverage of this topic gets wrong.
References
- How AI Search Works, From Prompt to Response. The full resource: the eleven-turn session, five worked examples, the reflection prompt, and the two parts still to come.
- The AI Search Visibility and Ranking Factors report. The larger body of OppAlerts research this sits alongside, covering which signals actually correlate with being recommended across models and industries.