rec 26 · re-instrumented 2026
first published 2026-06-30
How ChatGPT actually picks sources, and what it changes
Prompt-counting studies infer ChatGPT's machinery from its outputs. Watching the actual network traffic shows the retrieval routing underneath — and why brand strength decides which route you get.
1,849 words · 8 min read · 12 min listen
read by jamie mckaye — his own voice, via his voice model. not a studio take.
00:00 / --:--
Every few months someone publishes a "we tested 10,000 prompts in ChatGPT and counted the brand mentions" study. The numbers get quoted everywhere. Agencies build slide decks. Tool vendors release new dashboards. And the underlying methodology — fire prompts, scrape outputs, infer machinery from results — stays exactly the same. Black-box in, black-box out.
This week Suganthan Mohanadasan published something different in Search Engine Journal. He didn't count outputs. He read the network traffic ChatGPT sends to his own browser, in JSON, and lifted out the engine's internal labels — the field names, the vendor identifiers, the sub-queries the model writes for itself, the way it routes a question before it ever touches the web.
It is the most useful piece of writing I've read on AI search this year, and almost nobody in the optimisation industry is going to know how to talk about it. So let me try.
The headline finding is not "Reddit gets cited a lot." That's the directional bit, and Mohanadasan is admirably blunt that his percentages come from one logged-in Pro account doing mostly SaaS and tech queries. If you ran the same capture on health or fashion queries you'd get different leaderboards. The directional numbers are the least interesting part of the piece.
The structural findings are what matter. And they reframe a lot of what the GEO industry has been saying for the past eighteen months.
What "result_source" actually means
When ChatGPT retrieves something to answer a query, it stamps each result with a label. Mohanadasan saw four: serp, labrador, bright, oxylabs. The last two are the giveaway — Bright Data and Oxylabs are commercial proxy and web-scraping providers. ChatGPT is not running a single index in the way Google does. It is, at retrieval time, deciding which vendor to pull from based on what kind of question you asked.
The optimisation surface for ChatGPT is not "ChatGPT." It is the subset of queries the engine decides to send through a retrieval backend at all.
That detail alone should end a lot of conversations. The optimisation industry has been talking about "ChatGPT's index" as if it were a unified thing you could rank in, the same way you rank in Google's index. It isn't. It's a routing layer over multiple retrieval backends, each with different freshness, different coverage, different blind spots. Whether your page gets surfaced depends partly on which backend ChatGPT decided to invoke for that query.
Mohanadasan also documented six values for turn_use_case — the engine's internal classification of what the query is for. And the kicker: pure text queries skip the web entirely. No retrieval. No citations. The model just answers from its training data and whatever sits in its context window.
The optimisation surface for ChatGPT is not "ChatGPT." It is the subset of queries the engine decides to send through a retrieval backend at all.
That's a much smaller surface than the industry has been pretending. And it's invisible to any study that only reads the outputs.
Why this isn't a tooling problem
The obvious reaction, if you sell GEO software, is to say "great, we'll build a tool that classifies queries by turn_use_case and tells you which backend they hit." Some vendor will try. It won't work, and the reason it won't work is the more interesting half of Mohanadasan's piece.
When ChatGPT runs in Thinking mode, it doesn't just take the user's query and search it. It writes dozens of sub-queries on the fly — site: operators, price verification lookups, follow-up retrievals based on what the first batch returned. These sub-queries are generated per-session, per-context, often per-turn. They aren't a fixed taxonomy you can target. They're a function of the conversation.
Which means the unit of optimisation isn't a query anymore. It's a topic neighbourhood broad enough that any of the model's spontaneous sub-queries land on you.
I've been saying for a while that brand is the moat in AI search. This is the mechanical version of that argument. If the model is writing its own search queries on the fly, the only way to be reliably present is to be the entity it associates with the topic strongly enough that whatever angle it picks, you're in the result set. That's brand. There isn't a keyword strategy underneath it.
The Similarweb study connects to this directly
Earlier this week Rand Fishkin co-published Similarweb's clickstream study on the downstream impact of AI brand mentions. I wrote about it on Monday — the short version is that brands mentioned in AI answers see meaningful lifts in direct visits and branded search within seven days. American Express +7.2%, Capital One +14.2%, real numbers from real panel data.
In agentic retrieval, brand affects which queries the machine writes about you in the first place. That's a different and more powerful position.
The Similarweb study tells you presence in AI answers matters. The Mohanadasan piece tells you what determines that presence.
Read together, they describe a closed loop the optimisation industry has been talking around. AI mentions drive branded demand. Branded demand reinforces the entity associations the model uses when writing its own sub-queries. Stronger entity associations make you more likely to be retrieved next time. Brands compound. Generic SEO targets don't.
This is not a new dynamic in principle — search has always rewarded brand strength. What's changed is the mechanism. In classic SEO, brand affected click-through rates and trust signals. In agentic retrieval, brand affects which queries the machine writes about you in the first place. That's a different and more powerful position.
What the visibility studies cannot see
Mohanadasan is careful to draw a hard line between structural facts (high confidence, from reading the wire) and frequency observations (directional, small sample). The studies that get the most airtime in our industry are almost entirely on the wrong side of that line. They measure frequencies. They cannot see the structure.
When a visibility dashboard tells you "your brand appeared in 12% of prompts in your category last month," that number is doing several things at once:
It's mixing queries that hit the web with queries that didn't. It's collapsing different retrieval backends into one count. It's ignoring whether your appearance came from a site: sub-query the model wrote for itself versus a general retrieval. And it's giving you a number that, even if perfectly accurate, doesn't tell you the lever to pull, because the lever isn't a keyword.
This is the measurement problem I keep coming back to. The category is being sold dashboards before anyone has built the instrumentation to know what the dashboards should measure. Mohanadasan's piece is the first I've seen that actually opens the box and looks at what's moving inside. It should be the methodological baseline for anyone serious about this.
What it means for how you spend your effort
I'll resist the urge to turn this into a checklist, because most of what falls out of Mohanadasan's findings isn't tactical. It's a reordering of what to invest in.
If text-only queries skip the web entirely, then for a meaningful slice of ChatGPT interactions, the only way you exist in the answer is if you exist in the training data. That's a multi-year game played through brand mentions, Wikipedia, well-regarded third-party coverage, and being the entity the model has seen consistently associated with your topic. There is no schema markup tactic that gets you into the training set. You have to be there because the open web has been talking about you for long enough.
For the queries that do hit retrieval, the backend routing means the same page can be invisible on one query and surfaced on another, depending on which vendor the engine pulled from. Which means coverage matters more than ranking. Being indexed and findable across Reddit, your own site, third-party reviews, and trade publications gives you more retrieval surface than being #1 in a single channel. It's the closest thing in this space to genuine diversification.
And for the Thinking-mode behaviour — the model writing dozens of sub-queries per session — the strongest position is being the obvious answer for the broad topic, because the sub-queries fan out from there. Optimising for the user's literal query stops being the unit of work. Owning the topic neighbourhood does.
This is the SEO playbook from 2015 with the variable names changed. Brand authority. Topical depth. Diversified earned media. Technical hygiene. The honest version of GEO is mostly that, plus a tolerance for measurement ambiguity that the industry hasn't yet developed.
Where I'd push back on myself
The strongest objection to all of this is that Mohanadasan's piece is one person, one account, a few days of capture. The structural findings are real — you only need to see a field once to know it exists — but the importance of those findings depends on whether the architecture he documented holds across product surfaces, user tiers, and updates. OpenAI ships changes weekly. The labels he read off the wire today could be reorganised by next quarter.
That caveat matters, but it doesn't change the conclusion much. Even if result_source gets renamed and the backend mix shifts, the underlying shape — multi-vendor retrieval, query-routing, model-written sub-queries, a meaningful chunk of queries skipping retrieval entirely — is consistent with everything we know about how these systems are built. The specifics will change. The shape probably won't.
The other objection is from the tooling industry, which will argue that knowing the structure is exactly why you need a sophisticated platform to track it. Maybe. But the platforms have to actually read the structure, not just count outputs. The current generation of GEO dashboards I've looked at are still output-counters with prettier charts. Until someone is selling instrumentation that operates at the level Mohanadasan is reading at, treat the dashboards as directional and the structural understanding as the real asset.
The piece this points to
What we need, and what nobody is going to fund, is the same exercise Mohanadasan ran but at scale. Multiple accounts, multiple tiers, multiple geographies, queries across categories, captured continuously over months. That would turn his directional numbers into actual measurement, and it would give the industry the first honest baseline of how AI retrieval routes traffic.
Until someone runs that study, we have one person reading the wire on a Pro account, the Similarweb panel data on what happens downstream, and a lot of vendors selling certainty they haven't earned. The first two are worth your attention. The third isn't.
The optimisation industry spent the last eighteen months arguing about whether AI search was a new discipline or the old one in new clothes. Mohanadasan's piece points to the answer underneath that argument, which is that it doesn't matter what we call it. The machinery underneath is multi-vendor, query-routed, brand-weighted, and partially invisible. The work that pays off in that environment is the work that's always paid off in search. We just have less ability than ever to measure it in real time, and more incentive than ever to be honest about that.
