Why your AI traffic shows up as Direct / None — and how to fix it

You launched something, an AI assistant started recommending your page, and your real traffic ticked up. But when you open GA4, the new visitors are piling into (direct) / (none) — the same bucket as someone who typed your URL from memory. The assistants sending you traffic are nowhere to be found.

This is the dark-traffic problem, and the LLM era made it worse. Here’s why it happens and what you can actually do about it.

What “Direct / None” really means

(direct) / (none) is GA4’s shrug. It’s where a session lands when the analytics script can’t find any evidence of where the visit came from — no referrer header, no UTM parameters, no click ID it recognizes. It does not mean the person typed your address. It means the signal got lost.

In practice, (direct) / (none) is a junk drawer for:

Links opened from apps that strip the referrer (messaging apps, some email clients).
HTTPS-to-HTTP downgrades (rare now, but historically a big one).
Links pasted into a browser bar.
And increasingly — clicks that originate inside an AI assistant.

Why AI clicks lose their referrer

When a browser navigates from one page to another, it usually sends a Referer header telling the destination where the click came from. Analytics tools read that header to attribute the visit. The problem: AI assistants frequently don’t send a useful one.

A few different things happen depending on the surface:

Some assistants pass no referrer at all. The click looks like it came from nowhere, so it lands in (direct) / (none).
Some pass an opaque or app-level referrer that doesn’t map cleanly to a marketing channel, so GA4 either drops it into Unassigned or files it under a generic referral.
Some do pass a real hostname — you’ll see chatgpt.com, perplexity.ai, gemini.google.com, copilot.microsoft.com, or claude.ai show up in your referral report. But behavior varies by assistant, by whether the answer was generated from training versus live browsing, and by the user’s client.

And there’s a category that has no referrer by definition: Google’s AI Overviews render inside a Google search results page. A click from an Overview surfaces as ordinary google.com organic traffic — there’s no distinct “AI Overview” referrer to capture.

The upshot: you cannot rely on the referrer header to tell you when AI sent you a visit. It’s inconsistent at best and absent at worst.

Most analytics setups are client-side: a JavaScript snippet runs in the visitor’s browser and reports what it can see. That snippet only knows what the browser hands it — the referrer, the URL, the cookies. If the referrer is missing and the URL has no parameters, the snippet has nothing to attribute, and the session defaults to direct.

This is the heart of the problem. The decision about where this visit came from gets made in the browser, using data the AI surface chose not to provide. No amount of dashboard configuration fixes a signal that never arrived.

What actually survives

Two things survive when the referrer doesn’t:

1. UTMs on links you control. This is the big one. If an assistant surfaces a link that you placed — in your own content, a docs page, a syndicated post, a profile — and that link carries UTM parameters, those parameters ride along in the URL. The browser may drop the referrer, but it won’t strip your query string. The visit lands tagged.

So the move is: any canonical link you expose to the world, and especially links you expect AI assistants to read and repeat, should carry a deliberate convention. Something like:

?utm_source=chatgpt&utm_medium=ai-assistant&utm_campaign=docs-launch

Lowercase, hyphen-separated values, every time. (Casing matters — ChatGPT and chatgpt become two different sources and split your report. The full set of rules is in UTM parameters best practices.)

The honest limit: you can only tag links you control. If the model paraphrases your content and writes its own URL, or cites you from memory without a link, there’s nothing in the URL to tag. You catch the clicks that flow through links you seeded — not every mention.

2. Server-side capture. When a request hits your server, the server sees the full URL including any UTMs, plus headers and the landing context, before any client-side script runs and before a single-page app can rewrite the URL. Capturing attribution server-side means the signal is recorded at the most durable point in the chain, not reconstructed later in a browser that may have already lost it.

This is where a server-side layer earns its keep. AnyTrack (anytrack.io) captures the inbound parameters server-side and persists them through the session, so a UTM-tagged AI click stays attributed even when the client-side picture is murky.

A practical fix, in order

Stop expecting the referrer to save you. Treat AI referrers as a bonus signal, not the system of record.
Tag every link you control with a consistent AI convention — utm_medium=ai-assistant and a per-assistant utm_source. Build them once with a builder so the casing never drifts.
Capture attribution server-side so a tagged click survives even when client-side analytics can’t see the origin.
Use ai-assistant, the value GA4 recognizes. GA4’s native AI Assistants channel files utm_medium=ai-assistant automatically — no custom channel group needed. (The bare ai isn’t recognized and still hides in Unassigned, which is why you tag ai-assistant.) Background in Should AI referral traffic get its own channel in GA4?.
Verify in GA4. Check the (direct) / (none) and Unassigned buckets before and after. If tagged AI traffic is moving out of the junk drawer and into the AI Assistants channel, it’s working. The Google Analytics platform reference walks through where these reports live.

The takeaway

AI assistants are a real and growing referral source, but they’re a lossy one — they don’t hand your analytics a clean referrer, so client-side tools default to direct. You can’t make the assistant send better headers. What you can do is control the one part of the URL that survives: the parameters on your own links, captured at a point in the stack that doesn’t depend on a browser cooperating.