How ChatGPT Actually Picks Sources (I Read the Network Traffic, Not the Outputs) — Suganthan inline style so that every rule<br>using var(--color-*) resolves correctly before the external stylesheet<br>loads. This fixes Safari dark-mode where links were invisible because<br>the CSS variables still held their light-mode :root defaults during<br>first paint. --><br>~/about ~/projects ~/tools ~/blog ~/notes ~/work ~/newsletter

How ChatGPT Actually Picks Sources (I Read the Network Traffic, Not the Outputs)<br>I read 2 days of ChatGPT's raw network traffic to see how it picks sources, which domains get cited, and how to rank in and get cited by ChatGPT.

By Suganthan Mohanadasan<br>Updated 27 Jun 2026 (posted 24 Jun 2026 ) 18 min read

Tags:<br>#geo<br>#ai-seo<br>#chatgpt<br>#content-strategy

I keep getting the same question from clients and SEOs (GEOs?).

“How do we show up in ChatGPT? ”

The answer is always the same. Write good content, do listicles, comment on Reddit.

The usual.

But, how do we actually know any of that works? Most of it gets repeated on faith, one expert quoting the last.

So instead of taking it on trust, I spent a few days reading what ChatGPT sends my browser underneath the reply. The raw network traffic, in readable JSON.

This is a walk through what I found, roughly in the order I found it.

Before you quote a number from this, read this. It’s one person, one logged-in Pro account, a few days of traffic, not a population study. I logged about 1,240 source records across a few dozen searches. The structural findings, the fields ChatGPT uses and how they behave, are firm, because you only need to see a field once to know it’s real, and I saw them again and again. The numbers and percentages are a different matter. They come from a small batch of mostly SaaS and tech queries, so treat them as direction, not measurement. I flag which is which throughout.

How this differs from the big visibility studies, and what you can take to the bank

There are two ways to do such a study, and they point in opposite directions.

The big studies, the ones the platforms and the well-funded tools run, fire thousands of prompts, record which brands appear in the answers, and roll that up into share-of-voice reports. Large sample, but black box. They only ever see the finished answer, so they have to infer the machinery underneath from the output.

This is the other way round. I read the network traffic, the JSON the engine sends to my own browser, and lift out the engine’s own internal labels: the result_source it stamps on each result, the turn_use_case it files each query under, the vendor names, the search queries it wrote, the model it actually ran. I’m not measuring how often something happens across a population. I’m documenting that the machine has a thing, and what the machine calls it.

That difference decides what you can trust here, so I am going to be blunt about it.

Two confidence levels, do not mix them up

Structural facts (high confidence)

That result_source exists and carries serp, labrador, bright, oxylabs. That bright is Bright Data and oxylabs is Oxylabs. That there are six turn_use_case values. That text queries skip the web entirely. That Thinking fires dozens of site: and price-verification sub-queries. These are read straight off the wire. One clean capture proves a field exists and what it is named, and a prompt case study, however enormous, cannot see any of it.

Frequency observations (directional only)

Anything with a percentage or a ranking, “70% bright”, “Reddit is the most cited domain”, “YouTube never gets cited”, comes from tens of queries on a single account, and my own query choice skews it. I picked SaaS and tech, which is exactly why Reddit and the tech review hubs lead here; a batch of health or fashion queries would crown different ones. Read these as the shape of the thing, not the measurement. Where a direction has a mechanical reason behind it (Reddit is text so it gets quoted, YouTube is video (metadata) so it does not), trust the direction and ignore the exact number.

First, the boring truth about “packet analysis”

Skip this section if you don’t want to get into nitty gritty technical details.

My first instinct was wrong. You cannot sniff packets and read queries, because the payload is TLS encrypted, so a capture hands you scrambled cipher text for the actual messages. What the capture does leak is the metadata.

The destination hostname, the IPs, and the fact that the ChatGPT app talks over QUIC (HTTP/3), not plain TCP. That is why, in the screenshot below, Wireshark can still show “openai” in the handshake. It reads the unencrypted server name, not the conversation. QUIC obfuscates its first packet with fixed keys from the spec, so a tool can unwrap that opening packet to show the ClientHello.

The real request and response bodies sit in later protected payloads that stay unreadable. So the readable layer is the browser itself, after decryption, in the Network panel.

That’s where...