Referrer Policy strict-origin-when-cross-origin, Explained
- The referrer policy strict-origin-when-cross-origin is what a browser applies when a site sets no policy: the full URL within your own site, the origin only across sites, and nothing at all from HTTPS to HTTP.
- The receiving analytics tool therefore learns the host of the site that sent a visit and never its path.
- On a site we run, counting empty referrers by pageview put 66.5% of pageviews in the no-referrer bucket. Counting by visit put 53% there. Pageviews inflate the direct pile.
- 360 visits in 30 days carried utm_source=chatgpt.com and no referrer. A tool that reads only the referrer counted every one of them as direct.
- Matching direct visits to an AI assistant's read of the same page by timing found 1 to 2% more matches than chance. Timing cannot tell you where a visit came from.
The policy sends the full URL on same-origin requests, the bare origin when the request crosses to another HTTPS site, and nothing at all when it drops from HTTPS to HTTP. That is it. Everything confusing about your Direct traffic report follows from those three cases.
What the default policy sends
When a site sets no policy of its own, strict-origin-when-cross-origin is the fallback. MDN's reference on Referrer-Policy documents the behaviour for each case.
| Request | What the Referer header contains |
|---|---|
| Same-origin, page to page on your site | Origin, path and query string |
| Cross-origin, HTTPS to HTTPS | Origin only, no path |
| Cross-origin, HTTPS to HTTP | Nothing |
| Any link marked rel=noreferrer | Nothing |
Two details matter for a site owner. Internal navigation carries a full referrer, so a click from your homepage to your pricing page tells the next page exactly where it came from. A cross-site click carries only the origin, so the destination site knows the domain and nothing else. No path, no page title, no campaign parameters sitting in the URL.
What an analytics tool actually receives
Your analytics tool sits on the receiving end of that header. When the referrer is another site's origin, the tool can name the source domain. It cannot name the page.
The empty cases are where reports go wrong. A visit that travels from HTTPS to HTTP sends no referrer. A link marked rel=noreferrer sends none regardless of protocol. Many apps open links with no referrer at all: email clients, chat apps and native mobile apps often send none. A newsletter click lands looking exactly like someone typing your address into the bar.
Counting by pageview inflates the direct bucket
Most tools show you two numbers for the no-referrer case and people quote the wrong one. Here is what we saw on a site we run over 7 days: 5,774 pageviews and 1,628 visits, where a visit is a run of pageviews with gaps of 30 minutes or less.
Counted by pageview, 3,841 pageviews (66.5%) had no outside referrer. A click from one page to another on the same site carries none, so every internal navigation adds to that pile. It says nothing about where the person came from.
Counted by visit, 856 visits (53%) arrived with no referrer and no campaign tag. That is the number to look at. The pageview figure overstates direct traffic by more than thirteen points, and it does so for a boring reason: it counts people moving around your site as if they had just appeared from nowhere.
Most of that traffic is a link, not a typed address
Over 30 days on the same site, 6,745 visits arrived. 3,035 of them (45%) had no referrer and no tag. Of those 3,035, 2,802 (92%) started on a page other than the homepage and 233 started on the homepage.
People rarely type a deep address by hand. Almost nobody types yoursite.com/pricing-2026 from memory. So most of that traffic was a link whose referrer went missing somewhere between the sender and your server.
The landing page is a clue, never a name. It tells you which page caught someone's attention. It does not tell you who sent them, and no tool can recover what the browser never sent.
How Google Analytics labels these visits
Google Analytics applies rules here, and the definitions are narrow. The Direct channel is source exactly (direct) and medium (not set) or (none). Google describes Direct as people arriving by a saved link or by entering your URL. Unassigned is the value Analytics uses when no other channel rule matches the event data.
Read those definitions plainly and you can see the problem. A missing referrer lands in Direct by default. The channel is doing what it was told, and what it was told assumes a typed address or a bookmark, which is one explanation among several.
Some AI visits carry a tag instead
ChatGPT adds utm_source=chatgpt.com to the links in its answers. That tag survives the hop even when the referrer does not.
On the same site, 360 visits over 30 days (5.3%) carried utm_source=chatgpt.com and no referrer. A referrer-only tool counted all 360 as direct. A tool that reads utm_source puts them where they belong. The gap between those two reports is a measurement choice, not a traffic mystery. If you want the longer version of that argument, see AI Visibility Tracking: Sampled Answers vs Recorded Visits.
Timing a visit against an AI read does not work
We tried to find AI-sent visits inside direct traffic by matching a direct visit to an AI assistant's read of the same page in the 10 minutes before it. It found only 1 to 2% more matches than chance, with no peak in the first 2 minutes.
That is a dead end. Timing produces a plausible story and no evidence. Do not build a report on it, and do not let a vendor sell you one.
The crawler side you can measure on your own server
Crawler visits are a different problem with a cleaner answer, because the request arrives at your server with a user agent attached. Kymo classifies those server-side into three groups: live fetches made for one person's question, index crawlers working ahead of time, and training crawls gathering bulk data. OAI-SearchBot (OpenAI's search index crawler) sits in the indexing group. GPTBot (OpenAI's training crawler) sits in training and sends no traffic. CCBot (Common Crawl) is training too. The AI crawler directory lists the rest with their robots.txt tokens, and PerplexityBot: What It Crawls and Why It Matters covers the index side that often gets confused with live fetching.
Why bother? Because AI answers increasingly decide who gets found, and the pages those engines read are the raw material. If you are new to the vocabulary, What Is AEO in Marketing? (Plain-English Answer) covers it without the fog.
Do three things if you run a small site and want a straight answer about traffic. Tag every link you control with utm parameters, treat landing pages as clues rather than sources, and watch crawler requests on your own server instead of inferring them from referrers. Add a free AI visibility check at kymo.in/tools/ai-visibility-checker when you want a starting read on which engines can see your pages. For the fuller method, The Small Business Guide to AEO walks through it.
Stop guessing. Watch.
You can see what AI engines actually do on your own site: which pages they read, how many people their answers send there, and which of those people complete a goal. That beats asking a chatbot and reporting its guess. Or run the free AI visibility check at kymo.in/tools/ai-visibility-checker, which reads a URL from public signals so your site does not need Kymo installed, with the report arriving by email.
Start free → 14-day free trial. No card required.