Interpreting direct traffic: where visits really come from

What ends up as direct traffic in the channel report

An analytics tool does not see how a person reached a page. It sees two traces: the origin information the browser sends along and the parameters in the requested address. The origin information sits in the request’s Referer header and, in the script context, in document.referrer. The HTTP specification explicitly names simple analytics and logging as purposes of this header and states at the same time that not all requests contain it (RFC 9110). If both traces are missing, only one bucket is left for the classification: direct.

Direct is therefore not an origin but the absence of one. The channel collects everything that left no trace: the genuine bookmark as well as the link from a messenger, which is not a web page and so has nothing to pass on. Anyone who reads its share as brand strength credits hidden referrals to the brand and underestimates the channels they actually come from. For agentic browsers, the article on AI browsers in analytics has already shown this. Here the focus is on the other, older causes and on which of them can be fixed.

Five causes bring visits without an origin into the direct channel, and a sixth group concerns settings and infrastructure. The overview sorts them, and the following sections go through them one by one.

The default policy does not create direct traffic

A common misconception holds that the stricter referrer policy of modern browsers has inflated the direct channel. The default value is strict-origin-when-cross-origin. It applies when a page specifies no policy or sets an invalid value; MDN refers to a revision of the specification from November 2020 for this (MDN). Chrome announced that it would gradually enable it as the default starting with version 85 (Chrome for Developers), and Firefox made it the default with version 87 (Mozilla). Safari trims referrers from third-party sites to the origin by default, in the request header as well as in document.referrer (WebKit).

What this policy transmits on a click from another site is clearly defined: for requests to a different origin, the browser sends only the origin, as long as the security level stays the same, that is from HTTPS to HTTPS (MDN). You receive scheme, host and port, for example https://partner.example/, but not the path of the subpage the link was on. That is enough for channel attribution: the visit appears as a referral from partner.example. What gets lost is the level of detail, not the origin. What this means for page transitions on your own website is covered in the article on user paths and page transitions.

The table shows what arrives at the destination when a visitor on https://partner.example/guide/ clicks a link to your site. It is based on the examples MDN lists for each individual policy (MDN). They describe the behavior according to the specification; in Safari, trimming to the origin means that no path arrives from other sites even with unsafe-url or no-referrer-when-downgrade (WebKit).

Cause 1: Links from mail, chat and other apps

A typical source of hidden direct traffic lies outside the browser. When someone taps a link in a mail app, a messenger, a PDF or an office file, the program hands the address to the browser. There is no referring web page, so there is nothing the browser could enter as the origin. The HTTP specification explicitly governs the related situation of input from the keyboard and of bookmarks: if the target address comes from a source without its own address, the browser omits the Referer or sets about:blank (RFC 9110). From the browser’s point of view, a link from an app falls into the same situation. It receives an address but no page it came from.

This affects newsletters, invoice and shipping emails, shared links in messengers, QR codes opened by the camera app and documents sent as attachments. Webmail in the browser is a special case: there the reader clicks on a web page, and depending on the mailbox provider’s policy, its origin arrives or nothing at all. The sender cannot rely on this, because they cannot see how the recipient’s mailbox handles links.

The remedy therefore lies with the sender: campaign parameters in every link you send yourself. A visit with utm_source and utm_medium carries its origin in the address and does not need a referrer. How to set the parameters consistently and which blind spots newsletters, QR codes and print have is shown in the article on campaign tagging and clean channel attribution. For other people’s links, such as a customer’s tip in a messenger, there is no such remedy. They stay in the direct channel and make up the share there that can reasonably be read as word of mouth.

• Your own newsletter: campaign parameters with utm_medium=email in every link, including transactional emails such as order and shipping confirmations.
• Your own QR codes and print material: include parameters in the encoded address so that poster, flyer and packaging stay distinguishable.
• PDFs, quotes and presentations: links with their own utm_source per document type so that they do not end up as direct traffic.
• Shared links in messengers: not controllable. They stay direct and can only be narrowed down via landing page and timing.
• Webmail: depending on the mailbox provider, the origin arrives or nothing. Campaign parameters make the attribution independent of that.

Cause 2: Bookmarks, typing and returning visitors

Genuine direct traffic does of course exist. Anyone who types the address, accepts a suggestion from the address bar or opens a bookmark arrives without a referral. The HTTP specification names exactly these cases as examples: input from the keyboard and an entry within the bookmarks or favorites (RFC 9110). Add to that pinned tabs and start pages that the browser loads by itself when it opens.

Genuine direct visits have a recognizable profile. They typically land on short addresses: the home page, the login, the customer account, a category with a meaningful name. Hardly anyone types out a product address with a variant parameter or a guide article with a long slug. Returning customers who open their account or their cart form the core of this segment. If it grows, that is a good sign for a shop. If, on the other hand, the share of deep landing pages in the direct channel grows, a source without origin information is more likely behind it.

Cause 3: The switch from HTTPS to HTTP

The third cause is older than any privacy debate. If a page was loaded encrypted and a link leads from there to an address with http://, the browser must not send a Referer with this unencrypted request (RFC 9110). The default policy reflects this: no referrer goes along from HTTPS to HTTP (MDN).

Today almost every website runs encrypted. The Web Almanac 2025 counts 97.5% of desktop and 97.3% of mobile home pages using HTTPS (HTTP Archive Web Almanac 2025). The case therefore occurs mainly when the link itself is outdated: a partner directory, an industry portal or an old press article that still lists your address with http://. You should not assume that the origin reappears after the redirect to HTTPS. Only a link that points to https:// from the start is reliable.

You can check this in two steps. First, run the address as it appears on the partner page through the redirect checker: if the chain starts with http:// and a redirect, the link is outdated. Then ask the partner to switch it to https://. It costs one email and brings back a referral from the direct channel that does not belong there.

Cause 4: The source suppresses the referral

The fourth cause sits on the referring page. It can suppress the referral in several ways: with the response header Referrer-Policy: no-referrer for the whole document, with a meta element <meta name="referrer"> in the HTML or on individual links with rel="noreferrer" or the referrerpolicy attribute (MDN). With no-referrer, the Referer is omitted and requests then contain no origin information at all (MDN). According to the HTML Standard, the link keyword noreferrer means that no referrer information is leaked when following the link; it also implies the behavior of noopener (WHATWG).

How widespread such policies are is shown by the Web Almanac 2025: 37.66% of the websites examined by the HTTP Archive set a referrer policy in some form (HTTP Archive Web Almanac 2025). The most common method is control on individual links, for example with rel="noreferrer", at 24.70% of websites; 10.16% set a policy for the whole document via header (HTTP Archive Web Almanac 2025). The strict value no-referrer, by contrast, is rare as a policy and appears on 0.75% of websites (HTTP Archive Web Almanac 2025).

For interpreting your own direct channel, this means: a hidden referral does not have to come from a page that is configured strictly across the board. A single link with rel="noreferrer" is enough, of the kind that content management systems, forums or comment sections sometimes add to external links automatically. The resulting visit is a genuine referral. It just arrives without a sender.

Besides the referring page, visitors and infrastructure can also remove the referral. In Firefox, the default policy can be changed in the settings, all the way to no-referrer (MDN). The HTTP specification also mentions intermediaries that indiscriminately remove the Referer from outgoing requests (RFC 9110). However, this only affects the header in transit: script-based measurement reads document.referrer in the browser and is unaffected by it, whereas an analysis of server logs is not.

Whether a partner page suppresses the referral can be checked quickly. The header is in the server’s response, the link attributes are in the page source:

Without a command line, the free security score check does the job; among other things, it reads the referrer policy of any address. For partners that send visitors regularly, a look is worthwhile: if they use no-referrer or their links carry noreferrer, it is clear why their visits land in the direct channel. A friendly request for strict-origin-when-cross-origin or for a link with campaign parameters solves this in many cases.

Cause 5: AI browsers and assistants

The most recent cause is AI browsers and assistants that open links from within an answer. Some pass on a referral, others open the link in a context of their own without a referrer, and the visit lands in the direct channel. How the variants differ and how to recognize agentic sessions is covered in the article on AI browsers and separating them in analytics. What revenue visits from AI answers bring is shown in the article on measuring AI referral traffic.

For breaking down the direct channel, one rule is enough here: where an AI service adds campaign parameters to links, the source can be attributed even without a referrer. XICTRAQ® derives the AI source from the referrer and, if that is missing, from utm_source. Such visits count in a dedicated AI referral channel instead of the direct channel.

Your own referrer policy: what you control

The policy of your own website does not decide what arrives at your site; the referring page determines that. It decides what your site passes on to others. This becomes a measurement question of your own as soon as your offering is spread across several domains: shop and guides on separate domains, a separate domain for campaign pages, a booking system hosted by a service provider. If one domain sets no-referrer or same-origin, its visitors arrive at the other as direct traffic, and your own campaign disappears from the channel report.

The opposite mistake happens too. With unsafe-url, according to the specification, the full address including path and parameters goes to every site, even to unencrypted destinations. MDN explicitly warns that this can leak private information from HTTPS addresses to insecure origins (MDN). In the Web Almanac 2025, 0.50% of websites set this value; the Almanac describes passing on the full address as Chrome-specific behavior that other browsers have deprecated (HTTP Archive Web Almanac 2025). By contrast, only 5.69% specify strict-origin-when-cross-origin explicitly (HTTP Archive Web Almanac 2025). Websites without a setting of their own get the default of the respective browser. If you want to define the behavior instead of leaving it to the browser, set the value yourself:

# nginx, in the server block (location blocks with their own add_header do not inherit it)
add_header Referrer-Policy "strict-origin-when-cross-origin";

# Apache with mod_headers, in the VirtualHost configuration or in .htaccess
Header set Referrer-Policy "strict-origin-when-cross-origin"

# As a fallback in the HTML head if the server configuration is not accessible
<meta name="referrer" content="strict-origin-when-cross-origin">

The XICTRAQ® security scan reads the referrer policy of your monitored websites on every scan. If it is missing, set to unsafe-url or contains an invalid value, a dedicated finding appears, and the recommendation names strict-origin-when-cross-origin. What the other security headers do is summarized in the article on HTTP security headers.

Breaking down the direct channel in six steps

With the five causes in mind, the direct channel can be taken apart systematically. The order follows the effort: first read your own data, then check the sources, and finally retrofit your own links.

1. Set direct as a filter and read the landing pages. Short addresses such as home page, login and account point to genuine direct visits, deep product and article addresses to lost referrals.
2. Split by device. A conspicuously high mobile share on deep landing pages fits links from messengers and mail apps on the phone.
3. Compare over time. If the direct channel rises on the day of a mailing, a press article or a mention in a forum, the cause has usually been found. A marker in the trend helps you find such days again later.
4. Tag your own mailings. Newsletters, transactional emails, QR codes and PDFs get campaign parameters so that they do not reach the direct channel in the first place.
5. Check partner pages. For pages that demonstrably link to you, read out headers and link attributes and report outdated http:// links.
6. Check your own policy. With several domains of your own, make sure none of them sets no-referrer or same-origin if the other is supposed to see the origin.

One point does not belong in the direct channel but on the other side of the same equation: fake origin information. If, besides missing referrals, you also see conspicuous domains in the referral channel, the article on referrer spam and ghost traffic provides the right filters. Both errors distort the same question of where visits come from, just in opposite directions.

Classifying direct traffic with XICTRAQ®

XICTRAQ® cookieless analytics automatically assigns every visit to a channel: direct, organic and paid search, social, referral, email and a dedicated channel for visits from AI answers. A visit only ends up in the direct channel if neither an external referrer nor a campaign source in utm_source arrives. utm_medium=email leads to the email channel, and known click IDs of paid ads assign a visit to the paid channel even without a referrer. Referrals from your own domain do not count as an origin; the spelling with and without www. is treated as the same host.

For breaking down the direct channel, the channel is available as a filter and can be combined with device, browser, country or hostname. The trend card breaks visits down by channel as stacked bars, and markers in the trend record when a newsletter or a press article went out. How the analyses work together is described in the analytics documentation. If you want to hold the shop’s orders against the measurement, the article on reconciling shop orders with analytics covers the next step.

On the header side, the security scan closes the gap: it reports a missing, unsafe or invalid referrer policy on your websites. Because the measurement works without cookies and processes the origin as metadata of the page view, it also belongs in the privacy policy. Which details are expected there is shown in the article on privacy policies under scrutiny. How the channel report, filters and trend look together can be explored in the live demo without signing up.