"AI traffic" is a category with five or six major members that behave almost nothing alike. Treating them as one channel is like reporting "search traffic" without distinguishing a search engine from an email client that happens to have a search box.
This is a field guide to the handoff — the specific moment an assistant stops rendering an answer and starts sending a human to your server. What each one sends, what it strips, and what you can realistically observe at the edge.
Why the handoff differs at all
Three product decisions, made independently by each vendor, determine what you receive.
Where the answer is rendered. A web interface at a normal origin can send a normal referrer. A native desktop or mobile app has no web origin to send.
How the link is opened. A standard anchor in a browser produces ordinary navigation. An app that opens the link in an embedded webview crosses a process boundary, and referrer preservation there depends entirely on the webview class and its configuration.
Whether the vendor tags outbound links. Appending a campaign parameter is a deliberate choice. Some vendors made it, partly in response to publisher pressure for measurable attribution. Others have not.
Cross those three and you get the matrix below.
Three decisions that determine what arrives at your server
Each vendor answers these independently, and answers them differently across their own surfaces.
Rendering surface
Web origin, native desktop app, or mobile app — only the first has a referrer to send.
Link opening
System browser navigation preserves context; an embedded webview frequently does not.
Outbound tagging
Whether the vendor appends campaign parameters to links it renders.
What you receive
Anything from a fully tagged, referred visit to a bare request indistinguishable from Direct.
The specimens
A caution before the table. Everything below is observational, describes behaviour as generally reported through mid-2026, and is subject to change without any announcement. Treat it as a starting hypothesis to verify against your own logs, not as a specification.
Observed handoff behaviour by assistant
Behaviour varies by surface within each product. 'Sometimes' means the behaviour depends on which surface or client version produced the click.
| Assistant | Referrer | Campaign tag | Dominant surface |
|---|---|---|---|
| ChatGPT | Sometimes (web) | Commonly utm_source=chatgpt.com | Mobile app and web |
| Perplexity | Often (web) | Sometimes | Web, search-style |
| Google Gemini | Sometimes | Rarely | Web and Android integration |
| Microsoft Copilot | Sometimes | Rarely | Web, Windows, Edge sidebar |
| Claude | Sometimes (web) | Rarely | Web and desktop app |
Observational, mid-2026. Vendors change this without notice — verify against your own traffic.
ChatGPT
The largest source by volume for most sites, and the one that has moved furthest toward giving publishers something usable. Links rendered in answers are commonly tagged with a campaign parameter identifying chatgpt.com as the source, which is the single cleanest AI-referral signal available anywhere today.
The caveat is proportion. ChatGPT's usage skews heavily mobile, and the mobile app opens links in its own webview. So the tagged, well-behaved visits are real but represent a slice, and the slice's size depends on your audience's device mix rather than on anything you control.
Perplexity
Structurally the most legible of the group, because it is architecturally closest to a search engine. It renders a web interface at a normal origin, cites sources inline, and drives comparatively high click-through — its whole interaction model is built around sending you to sources rather than replacing them.
If your AI traffic looks unusually well-attributed, a Perplexity-heavy mix is a likely reason.
Google Gemini
The hardest to reason about, because "Gemini traffic" is not one thing. Gemini appears as a standalone assistant, as an integration inside Google's own surfaces, and as a layer on Android. Each path has different referrer behaviour, and some of it is entangled with Google's existing search referral handling in ways that make a visit hard to categorise as either search or assistant.
Expect ambiguity here and resist the temptation to resolve it with a confident rule.
Microsoft Copilot
Similar dispersion. Copilot exists on the web, inside Windows, in the Edge sidebar, and embedded across Microsoft 365. A sidebar click and a web click are different navigation events from the same brand.
The Edge sidebar case is worth calling out specifically: it can produce a browser navigation with characteristics that look nothing like either a normal browser visit or a mobile webview.
Claude
Web and desktop surfaces, with desktop use meaningful enough to matter. The desktop app case is the awkward one, for the same reason as every native app: there is no web origin to put in a referrer header. Web-surface clicks behave more conventionally.
The dominant-surface column matters more than the referrer column
An assistant whose users are mostly on mobile will deliver mostly unattributable visits regardless of how well-behaved its web interface is. When you estimate how much of an assistant's traffic you can see, start from its surface mix, not from its referrer policy.
What this means for detection
Three practical consequences.
One rule per assistant is never enough
Every product in the table has at least two surfaces with different behaviour. A rule that says "ChatGPT means this referrer" will be right for the web surface and blind to the mobile one — which is the larger of the two. Detection has to work per-handoff-pattern, not per-brand.
Campaign parameters are the best and least durable signal
When a campaign tag is present it is close to conclusive. It is also a product decision the vendor can revise in any release, with no changelog you subscribe to and no versioning.
Build for the tag, absolutely. But a detection system whose accuracy depends on it will degrade silently the week a vendor changes format, and you will find out from a graph that dropped rather than from an announcement.
The strongest signal available is also the one most likely to change without telling you. Depend on it; do not depend on it alone.
The dark share is not evenly distributed
Because surface mix varies by assistant, so does the fraction you can observe. A Perplexity-heavy audience yields far better visibility than a ChatGPT-mobile-heavy one — and this has an unpleasant second-order effect: the assistants you can see best are not necessarily the ones sending you the most.
Reporting only what you can observe therefore does not produce a smaller version of the true picture. It produces a differently shaped one, systematically overweighting whichever assistant happens to preserve the most signal. That is worse than an undercount, because it is wrong in a direction you would never guess from the numbers themselves.
Illustrative: same true volume, different observable share
A worked illustration, not measured data. If observable share varies by assistant, the reported mix diverges from the real mix even when the underlying volumes are identical.
Illustrative example. Substitute your own observed-versus-estimated figures.
How to build a table like this for yourself
You do not have to take anyone's word for the matrix above, and you shouldn't. The exercise is straightforward:
- Log the raw signals. For every request, capture referrer, full query string, user agent, and the client hints your platform exposes. Store them alongside the visit, not just the derived channel.
- Segment on the unambiguous cases. Start with visits carrying an explicit campaign tag or a recognisable referrer host. These are your labelled examples.
- Characterise the labelled group. Look at how those known-AI visits differ from your general traffic in client characteristics — platform, viewport, client hint combinations, navigation timing.
- Look for the same shape in the unlabelled traffic. Visits in Direct that match the characterised pattern are your candidate dark AI traffic.
- Sanity-check against behaviour. AI referrals should convert above your organic baseline. If your candidate group behaves like average Direct traffic, your characterisation is picking up something else.
Step five is the one people skip, and it is the only step that can tell you the previous four were wrong.
Keep the raw signals, not just the verdict
The single most valuable thing you can do today is start retaining the raw request signals alongside each visit. Detection logic improves; last month's traffic does not come back. A team that kept the inputs can reclassify history when the rules get better. A team that only kept the label cannot.
What to expect next
Two trends worth planning around.
More tagging, not less. The publisher relationship is now a live commercial question for every assistant vendor, and measurable referral is the cheapest concession available. Expect more products to tag outbound links, and expect the formats to be inconsistent with one another.
More surfaces, each worse than the last. Assistants are moving into operating systems, browsers, sidebars, and increasingly agentic flows that fetch pages without a human ever seeing a browser. Each new surface tends to preserve less context than the web interface it supplements. The share of AI-driven activity you can observe by conventional means will keep falling even as the volume rises.
That second trend is why cryptographic verification matters more each quarter. When the agent is the one making the request, a signed request is the only thing that survives — and it is also the point at which you need to be very clear about whether you are looking at a crawler or a human.
Frequently asked
Sometimes, from its web interface. Clicks originating in the mobile app frequently arrive with no referrer, because the link opens in an embedded webview rather than through ordinary browser navigation. ChatGPT has commonly appended a utm_source=chatgpt.com campaign parameter to links it renders, which is often the more reliable signal of the two.
Perplexity, generally. It is architecturally closest to a search engine — a web interface at a normal origin, citing sources inline — so more of its handoffs preserve a usable referrer than assistants whose primary surface is a mobile app.
Usually a surface mix shift rather than a policy change. Your traffic is a blend of web, desktop and mobile clicks from the same brand, each with different referrer behaviour, so the visible proportion moves as the mix moves. Vendor-side changes also happen, without announcement.
Use them, but not exclusively. A campaign tag is close to conclusive when present and is the strongest signal available. It is also an unversioned product decision that can change in any release, so a system depending on it alone will fail silently rather than loudly.
Assume quarterly at minimum, and verify against your own logs rather than a published table. Vendors do not publish changelogs for outbound link behaviour, so the only reliable source of truth is traffic arriving at your own edge.
Sources & further reading
- 01Referrer-Policy — HTTP header reference — MDN Web Docs
- 02Overview of OpenAI crawlers and user agents — OpenAI
- 03What Is AI-Referred Traffic? 2026 Benchmarks — Contentsquare
- 04How to Get Cited by ChatGPT, Perplexity, and AI Search Tools — AIOSEO