Direktzugriffe richtig deuten: Woher Besuche wirklich kommen

Was im Kanalbericht als Direktzugriff landet

Ein Analysewerkzeug sieht nicht, wie ein Mensch auf eine Seite gekommen ist. Es sieht zwei Spuren: die Herkunftsangabe, die der Browser mitliefert, und die Parameter in der aufgerufenen Adresse. Die Herkunftsangabe steht im Referer-Kopf der Anfrage und im Skriptkontext in document.referrer. Die HTTP-Spezifikation nennt einfache Auswertungen und Protokolle ausdrücklich als Zweck dieses Kopfes und hält zugleich fest, dass nicht jede Anfrage ihn enthält (RFC 9110). Fehlen beide Spuren, bleibt für die Einordnung nur ein Eimer übrig: Direkt.

Direkt ist damit keine Herkunft, sondern das Fehlen einer Herkunft. Der Kanal sammelt alles, was keine Spur hinterlassen hat: das echte Lesezeichen ebenso wie den Link aus einem Messenger, der keine Webseite ist und deshalb nichts zu übergeben hat. Wer den Anteil als Markenstärke liest, schreibt verdeckte Verweise der Marke gut und unterschätzt die Kanäle, aus denen sie tatsächlich stammen. Für agentische Browser hat der Beitrag zu KI-Browsern im Analytics das bereits gezeigt. Hier geht es um die übrigen, älteren Ursachen und um die Frage, welche davon sich beheben lassen.

Fünf Ursachen bringen Besuche ohne Herkunft in den Direktkanal, eine sechste Gruppe betrifft Einstellungen und Infrastruktur. Die Übersicht ordnet sie, die folgenden Abschnitte gehen sie einzeln durch.

Die Standard-Policy erzeugt keinen Direktzugriff

Ein verbreiteter Irrtum lautet, die strengere Referrer-Policy moderner Browser habe den Direktkanal anschwellen lassen. Der Standardwert heißt strict-origin-when-cross-origin. Er gilt, wenn eine Seite keine Richtlinie angibt oder einen ungültigen Wert setzt; MDN verweist dafür auf eine Revision der Spezifikation vom November 2020 (MDN). Chrome kündigte an, ihn ab Version 85 schrittweise als Standard zu aktivieren (Chrome for Developers), Firefox setzte ihn mit Version 87 als Standard (Mozilla). Safari kürzt Verweise von Drittseiten standardmäßig auf den Ursprung, im Kopf der Anfrage ebenso wie in document.referrer (WebKit).

Was diese Richtlinie bei einem Klick von einer fremden Seite überträgt, ist klar geregelt: Bei Anfragen an einen anderen Ursprung schickt der Browser nur den Ursprung, solange das Schutzniveau gleich bleibt, also von HTTPS zu HTTPS (MDN). Bei Ihnen kommen Schema, Host und Port an, etwa https://partner.example/, nicht aber der Pfad der Unterseite, auf der der Link stand. Für die Kanalzuordnung genügt das: Der Besuch erscheint als Verweis von partner.example. Verloren geht die Detailebene, nicht die Herkunft. Was das für Seitenübergänge auf der eigenen Website bedeutet, beschreibt der Beitrag zu Nutzerpfaden und Seitenübergängen.

Die Tabelle zeigt, was beim Ziel ankommt, wenn ein Besucher auf https://partner.example/ratgeber/ einen Link zu Ihrer Seite anklickt. Grundlage sind die Beispiele, die MDN zu jeder einzelnen Richtlinie aufführt (MDN). Sie beschreiben das Verhalten nach der Spezifikation; in Safari kommt wegen der Kürzung auf den Ursprung auch bei unsafe-url und no-referrer-when-downgrade von fremden Seiten kein Pfad an (WebKit).

Ursache 1: Links aus Mail-, Chat- und anderen Apps

Eine typische Quelle verdeckter Direktzugriffe liegt außerhalb des Browsers. Tippt jemand in einer Mail-App, einem Messenger, einem PDF oder einer Office-Datei auf einen Link, reicht das Programm die Adresse an den Browser weiter. Eine verweisende Webseite gibt es dabei nicht, also auch nichts, was der Browser als Herkunft eintragen könnte. Die HTTP-Spezifikation regelt die verwandte Lage bei Eingabe über die Tastatur und bei Lesezeichen ausdrücklich: Stammt die Zieladresse aus einer Quelle ohne eigene Adresse, lässt der Browser den Referer weg oder setzt about:blank (RFC 9110). Ein Link aus einer App fällt aus Sicht des Browsers in dieselbe Lage. Er bekommt eine Adresse, aber keine Seite, von der sie stammt.

Das betrifft Newsletter, Rechnungs- und Versandmails, geteilte Links in Messengern, QR-Codes, die die Kamera-App öffnet, und Dokumente, die als Anhang reisen. Webmail im Browser ist ein Sonderfall: Dort klickt der Leser auf einer Webseite, und je nach Richtlinie des Postfachanbieters kommt dessen Ursprung an oder gar nichts. Verlassen kann sich der Absender darauf nicht, denn er sieht nicht, wie das Postfach des Empfängers mit Links umgeht.

Die Abhilfe liegt deshalb beim Absender: Kampagnenparameter in jedem Link, den Sie selbst verschicken. Ein Besuch mit utm_source und utm_medium trägt seine Herkunft in der Adresse und braucht keinen Referrer. Wie man die Parameter einheitlich setzt und welche blinden Flecken Newsletter, QR-Code und Print haben, zeigt der Beitrag zu UTM-Parametern und sauberer Kampagnenzuordnung. Für fremde Links, etwa den Tipp eines Kunden im Messenger, gibt es keine solche Abhilfe. Sie bleiben im Direktkanal und bilden dort den Anteil, den man mit gutem Grund als Mundpropaganda lesen darf.

• Eigener Newsletter: Kampagnenparameter mit utm_medium=email in jedem Link, auch in Transaktionsmails wie Bestell- und Versandbestätigungen.
• Eigene QR-Codes und Drucksachen: Parameter in die kodierte Adresse aufnehmen, damit Plakat, Flyer und Verpackung unterscheidbar bleiben.
• PDFs, Angebote und Präsentationen: Links mit eigenem utm_source je Dokumentart, damit sie nicht als Direktzugriff enden.
• Geteilte Links in Messengern: nicht steuerbar. Sie bleiben Direkt und lassen sich nur über Einstiegsseite und Zeitpunkt eingrenzen.
• Webmail: je nach Postfachanbieter kommt der Ursprung an oder nichts. Kampagnenparameter machen die Zuordnung unabhängig davon.

Ursache 2: Lesezeichen, Eingabe und wiederkehrende Besucher

Den echten Direktzugriff gibt es natürlich. Wer die Adresse eintippt, einen Vorschlag der Adresszeile übernimmt oder ein Lesezeichen öffnet, kommt ohne Verweis. Genau diese Fälle nennt die HTTP-Spezifikation als Beispiel: die Eingabe über die Tastatur und einen Eintrag in den Lesezeichen beziehungsweise Favoriten (RFC 9110). Dazu kommen angeheftete Tabs und Startseiten, die der Browser beim Öffnen selbst lädt.

Echte Direktzugriffe haben ein erkennbares Profil. Sie landen typischerweise auf kurzen Adressen: der Startseite, dem Login, dem Kundenkonto, einer Kategorie mit sprechendem Namen. Kaum jemand tippt eine Produktadresse mit Variantenparameter oder einen Ratgeberartikel mit langem Slug ab. Wiederkehrende Kunden, die ihr Konto oder den Warenkorb aufrufen, bilden den Kern dieses Segments. Wächst er, ist das für einen Shop ein gutes Zeichen. Wächst dagegen der Anteil tiefer Einstiegsseiten im Direktkanal, steckt eher eine Quelle ohne Herkunftsangabe dahinter.

Ursache 3: Der Wechsel von HTTPS zu HTTP

Die dritte Ursache ist älter als jede Datenschutzdebatte. Wurde eine Seite verschlüsselt geladen und führt ein Link von dort zu einer Adresse mit http://, darf der Browser bei dieser unverschlüsselten Anfrage keinen Referer senden (RFC 9110). Die Standard-Policy bildet das ab: Von HTTPS zu HTTP geht kein Referrer mit (MDN).

Heute läuft fast jede Website verschlüsselt. Der Web Almanac 2025 zählt 97,5 % der Desktop- und 97,3 % der mobilen Startseiten mit HTTPS (HTTP Archive Web Almanac 2025). Der Fall tritt deshalb vor allem dann auf, wenn der Link selbst veraltet ist: ein Partnerverzeichnis, ein Branchenportal oder ein alter Pressebeitrag, der Ihre Adresse noch mit http:// führt. Ob die Herkunft nach der Umleitung auf HTTPS wieder auftaucht, sollte man nicht unterstellen. Verlässlich ist nur ein Link, der von Anfang an auf https:// zeigt.

Prüfen lässt sich das in zwei Schritten. Zuerst die Adresse, wie sie auf der Partnerseite steht, durch den Redirect-Checker schicken: Beginnt die Kette mit http:// und einer Umleitung, ist der Link veraltet. Dann den Partner bitten, ihn auf https:// umzustellen. Das kostet eine Mail und holt einen Verweis aus dem Direktkanal zurück, der dort nicht hingehört.

Ursache 4: Die Quelle unterdrückt den Verweis

Die vierte Ursache sitzt auf der verweisenden Seite. Sie kann den Verweis auf mehreren Wegen unterdrücken: mit dem Antwort-Header Referrer-Policy: no-referrer für das ganze Dokument, mit einem Meta-Element <meta name="referrer"> im HTML oder an einzelnen Links mit rel="noreferrer" beziehungsweise dem Attribut referrerpolicy (MDN). Bei no-referrer wird der Referer ausgelassen, die Anfragen enthalten dann keinerlei Herkunftsangabe (MDN). Das Linkattribut noreferrer bedeutet nach dem HTML-Standard, dass beim Folgen des Links keine Herkunftsinformation weitergegeben wird; es schließt zugleich das Verhalten von noopener ein (WHATWG).

Wie verbreitet solche Richtlinien sind, zeigt der Web Almanac 2025: 37,66 % der vom HTTP Archive untersuchten Websites setzen eine Referrer-Richtlinie in irgendeiner Form (HTTP Archive Web Almanac 2025). Am häufigsten ist die Steuerung an einzelnen Links, etwa mit rel="noreferrer", bei 24,70 % der Websites; eine Richtlinie für das ganze Dokument per Header setzen 10,16 % (HTTP Archive Web Almanac 2025). Der strenge Wert no-referrer ist als Richtlinie dagegen selten und steht bei 0,75 % der Websites (HTTP Archive Web Almanac 2025).

Für die Deutung des eigenen Direktkanals heißt das: Ein verdeckter Verweis muss nicht von einer Seite kommen, die rundum streng eingestellt ist. Es genügt ein einzelner Link mit rel="noreferrer", wie ihn Redaktionssysteme, Foren oder Kommentarbereiche mitunter selbsttätig an externe Links hängen. Der Besuch, der daraus entsteht, ist ein echter Verweis. Er kommt nur ohne Absender an.

Neben der verweisenden Seite können auch Besucher und Infrastruktur den Verweis entfernen. In Firefox lässt sich die Standardrichtlinie über die Einstellungen ändern, bis hin zu no-referrer (MDN). Die HTTP-Spezifikation erwähnt außerdem Zwischenstationen, die den Referer pauschal aus ausgehenden Anfragen entfernen (RFC 9110). Das trifft allerdings nur den Kopf auf dem Transportweg: Eine Messung per Skript liest document.referrer im Browser und bleibt davon unberührt, eine Auswertung der Server-Logs dagegen nicht.

Ob eine Partnerseite den Verweis unterdrückt, lässt sich schnell prüfen. Der Header steht in der Antwort des Servers, die Linkattribute stehen im Quelltext der Seite:

Ohne Kommandozeile geht es mit dem kostenlosen Security-Score-Check, der unter anderem die Referrer-Policy einer beliebigen Adresse ausliest. Bei Partnern, die regelmäßig Besucher schicken, lohnt der Blick: Steht dort no-referrer oder tragen die Links noreferrer, ist klar, warum deren Besuche im Direktkanal landen. Eine freundliche Bitte um strict-origin-when-cross-origin oder um einen Link mit Kampagnenparametern löst das in vielen Fällen.

Ursache 5: KI-Browser und Assistenten

Die jüngste Ursache sind KI-Browser und Assistenten, die Links aus einer Antwort heraus öffnen. Manche übergeben dabei einen Verweis, andere öffnen den Link in einem eigenen Kontext ohne Referrer, und der Besuch landet im Direktkanal. Wie sich die Varianten unterscheiden und wie man agentische Sitzungen erkennt, steht im Beitrag zu KI-Browsern und ihrer Trennung im Analytics. Welchen Umsatz Besuche aus KI-Antworten bringen, zeigt der Beitrag zum Messen von KI-Referral-Traffic.

Für die Zerlegung des Direktkanals genügt hier eine Regel: Wo ein KI-Dienst Links mit Kampagnenparametern versieht, lässt sich die Quelle auch ohne Referrer zuordnen. XICTRAQ® leitet die KI-Quelle aus dem Referrer ab und, falls dieser fehlt, aus utm_source. Solche Besuche zählen im eigenen KI-Referral-Kanal statt im Direktkanal.

Die eigene Referrer-Policy: was Sie selbst steuern

Die Richtlinie Ihrer eigenen Website entscheidet nicht darüber, was bei Ihnen ankommt, das bestimmt die verweisende Seite. Sie entscheidet darüber, was Ihre Seite an andere weitergibt. Zur eigenen Messfrage wird das, sobald Ihr Angebot über mehrere Domains verteilt ist: Shop und Ratgeber auf getrennten Domains, eine eigene Domain für Kampagnenseiten, ein Buchungssystem beim Dienstleister. Setzt die eine Domain no-referrer oder same-origin, kommen ihre Besucher auf der anderen als Direktzugriff an, und die eigene Kampagne verschwindet aus dem Kanalbericht.

Auch der umgekehrte Fehler kommt vor. Mit unsafe-url geht nach der Spezifikation die vollständige Adresse samt Pfad und Parametern an jede Seite, auch an unverschlüsselte Ziele. MDN warnt ausdrücklich, dass dabei private Informationen aus HTTPS-Adressen an unsichere Ursprünge gelangen können (MDN). Im Web Almanac 2025 setzen 0,50 % der Websites diesen Wert; die Weitergabe der vollständigen Adresse beschreibt der Almanac dabei als Verhalten von Chrome, das andere Browser abgeschafft haben (HTTP Archive Web Almanac 2025). Den Wert strict-origin-when-cross-origin geben dagegen nur 5,69 % ausdrücklich an (HTTP Archive Web Almanac 2025). Websites ohne eigene Angabe erhalten den Standard des jeweiligen Browsers. Wer das Verhalten festlegen will, statt es dem Browser zu überlassen, setzt den Wert selbst:

# nginx, im server-Block (location-Blöcke mit eigenem add_header erben ihn nicht)
add_header Referrer-Policy "strict-origin-when-cross-origin";

# Apache mit mod_headers, in der VirtualHost-Konfiguration oder in .htaccess
Header set Referrer-Policy "strict-origin-when-cross-origin"

# Ersatzweise im HTML-Kopf, wenn die Serverkonfiguration nicht erreichbar ist
<meta name="referrer" content="strict-origin-when-cross-origin">

Der Security-Scan von XICTRAQ® liest die Referrer-Policy Ihrer überwachten Websites bei jedem Scan aus. Fehlt sie, steht dort unsafe-url oder ein ungültiger Wert, erscheint ein eigener Befund, und die Empfehlung nennt strict-origin-when-cross-origin. Welche Aufgabe die übrigen Sicherheitsheader haben, fasst der Beitrag zu HTTP-Sicherheitsheadern zusammen.

Den Direktkanal in sechs Schritten zerlegen

Mit den fünf Ursachen im Kopf lässt sich der Direktkanal systematisch auseinandernehmen. Die Reihenfolge folgt dem Aufwand: erst die eigenen Daten lesen, dann die Quellen prüfen, zuletzt die eigenen Links nachrüsten.

1. Direkt als Filter setzen und die Einstiegsseiten lesen. Kurze Adressen wie Startseite, Login und Konto sprechen für echte Direktzugriffe, tiefe Produkt- und Artikeladressen für verlorene Verweise.
2. Nach Gerät aufteilen. Ein auffällig hoher Mobilanteil bei tiefen Einstiegsseiten passt zu Links aus Messengern und Mail-Apps auf dem Telefon.
3. Zeitlich abgleichen. Steigt der Direktkanal am Tag einer Aussendung, eines Pressebeitrags oder einer Erwähnung in einem Forum, ist die Ursache meist gefunden. Eine Markierung im Verlauf hilft, solche Tage später wiederzufinden.
4. Eigene Aussendungen kennzeichnen. Newsletter, Transaktionsmails, QR-Codes und PDFs bekommen Kampagnenparameter, damit sie den Direktkanal gar nicht erst erreichen.
5. Partnerseiten prüfen. Für Seiten, die nachweislich auf Sie verlinken, Header und Linkattribute auslesen und veraltete http://-Links melden.
6. Eigene Richtlinie prüfen. Bei mehreren eigenen Domains sicherstellen, dass keine davon no-referrer oder same-origin setzt, wenn die andere die Herkunft sehen soll.

Ein Punkt gehört nicht in den Direktkanal, sondern auf die andere Seite derselben Rechnung: gefälschte Herkunftsangaben. Wer neben fehlenden Verweisen auch auffällige Domains im Referral-Kanal sieht, findet im Beitrag zu Referrer-Spam und Ghost-Traffic die passenden Filter. Beide Fehler verzerren dieselbe Frage, woher Besuche kommen, nur in entgegengesetzte Richtungen.

Direktzugriffe mit XICTRAQ® einordnen

Die Cookieless Analytics von XICTRAQ® ordnen jeden Besuch automatisch einem Kanal zu: Direkt, organische und bezahlte Suche, Social, Referral, E-Mail und ein eigener Kanal für Besuche aus KI-Antworten. In den Direktkanal gelangt ein Besuch nur, wenn weder ein fremder Referrer noch eine Kampagnenquelle in utm_source ankommt. utm_medium=email führt in den E-Mail-Kanal, und bekannte Klick-Kennungen bezahlter Anzeigen ordnen einen Besuch auch ohne Referrer dem bezahlten Kanal zu. Verweise von der eigenen Domain zählen nicht als Herkunft; die Schreibweise mit und ohne www. gilt dabei als derselbe Host.

Für die Zerlegung des Direktkanals steht der Kanal als Filter bereit und lässt sich mit Gerät, Browser, Land oder Hostname kombinieren. Die Verlaufskarte schlüsselt Besuche nach Kanal als gestapelte Balken auf, und Markierungen im Verlauf halten fest, wann ein Newsletter oder ein Pressebeitrag erschien. Wie die Auswertungen zusammenspielen, beschreibt die Analytics-Dokumentation. Wer die Bestellungen des Shops gegen die Messung legen will, findet im Beitrag zum Abgleich von Shop-Bestellungen mit Analytics den nächsten Schritt.

Auf der Seite der Header schließt der Security-Scan die Lücke: Er meldet eine fehlende, unsichere oder ungültige Referrer-Policy Ihrer Websites. Weil die Messung ohne Cookies arbeitet und die Herkunft als Metadatum des Seitenaufrufs verarbeitet, gehört sie auch in die Datenschutzerklärung. Welche Angaben dort erwartet werden, zeigt der Beitrag zur Datenschutzerklärung im Prüffokus. Wie Kanalbericht, Filter und Verlauf zusammen aussehen, lässt sich in der Live-Demo ohne Anmeldung ansehen.