Wenn du auf einer Seite einen Link anklickst, schickt dein Browser an die Ziel-Seite mit: „Ich komme gerade von dieser anderen Seite." Das ist der Referrer, ein 1996 ins HTTP eingebauter Header, der lange unter dem Radar lief — und heute zu den unauffälligsten Tracking-Quellen gehört. Dazu kommen UTM-Parameter in URLs und Analytics-Dienste, die im Hintergrund jede Bewegung mitprotokollieren. Dieser Artikel zeigt, was wirklich weitergegeben wird, wie moderne Browser das einschränken und welche datenschutz-freundlichen Alternativen es gibt.

01 · Abschnitt

Was der Referrer-Header verrät

Beim Klick auf einen Link sendet dein Browser standardmäßig einen Referer-Header (historisches Typo, geblieben) mit der URL der Seite, von der du kommst.

Beispiel: Du bist auf https://wikipedia.org/wiki/Kryptographie, klickst einen Link zu https://heise.de/news/123. Heise bekommt eine HTTP-Anfrage mit:

Plain referer-beispiel.txt 
GET /news/123 HTTP/2
Host: heise.de
Referer: https://wikipedia.org/wiki/Kryptographie
User-Agent: ...
...

Heise weiß damit: „Diese:r Nutzer:in kommt vom Wikipedia-Artikel über Kryptographie." Das ist eine Verkehrs-Information, die Web-Analyse-Werkzeuge gerne sammeln.

Bei manchen Sites geht der Referrer aber deutlich weiter:

  • Suchanfragen mit sensiblen Begriffen in der URL (google.de/search?q=krebsdiagnose+symptome) — der nächste angeklickte Artikel sieht die Suche im Klartext.
  • Mail-Vorschau-Aktivierung (mail-provider.example/...?token=...) — wenn dort sensitive Tokens in der URL stehen, gehen die als Referrer mit.
  • Interner Workflow-State (firmenintern.example/projekt/budget/details) — Aktivität, die nach außen drang, falls dort externe Links sind.

Das kann sehr aufschlussreich sein, und genau deshalb hat sich die Browser-Welt darum gekümmert.

02 · Abschnitt

Referrer-Policy: die Browser-Antwort

Seit ca. 2018 haben moderne Browser den Referrer-Default deutlich reduziert. Heute gilt in den meisten Browsern als Default strict-origin-when-cross-origin — bedeutet:

  • Same-Origin (Klick innerhalb derselben Domain): voller Referrer mit Pfad und Query.
  • Cross-Origin (Klick zu anderer Domain): nur Origin (Schema + Host), kein Pfad, keine Query-Parameter.
  • Downgrade von HTTPS zu HTTP: gar kein Referrer.

Das heißt: bei deinem Klick von wikipedia.org/wiki/Kryptographie zu heise.de sieht Heise heute nur https://wikipedia.org/ — nicht den Artikel-Pfad. Eine deutliche Reduktion gegenüber der Lage vor 2018.

Webseiten-Betreiber können den Referrer-Modus über den Referrer-Policy-HTTP-Header oder per <meta name="referrer" content="..."> selbst granular einstellen — das ist Entwickler-Thema, siehe secure-headers-uebersicht. Aus Nutzer-Sicht gilt: der Default ist heute privatsphäre-freundlicher als noch vor wenigen Jahren.

Browser-Optionen zur Verstärkung:

  • Firefox → about:config → network.http.referer.XOriginPolicy auf 2 (sehr strict: nur Same-Site-Referrer); network.http.referer.XOriginTrimmingPolicy auf 2 (immer nur Origin senden).
  • Brave → standardmäßig sehr strikte Referrer-Policy (auch within Same-Site oft Origin-only).
  • Tor Browser → fast vollständig Referrer-frei zwischen Origins.
03 · Abschnitt

UTM-Parameter: das andere Tracking-Indiz

Wenn du eine Mail mit einem Link öffnest, ist der Link oft mit langen Query-Parametern dekoriert:

https://example.de/produkt?utm_source=newsletter&utm_medium=email&utm_campaign=winter2026&utm_content=banner-top

Das sind UTM-Parameter (Urchin Tracking Module — benannt nach der 2005 von Google aufgekauften Firma Urchin Software). Sie geben der Ziel-Seite Auskunft, woher der Klick kam:

  • utm_source — wo der Link erschienen ist (Newsletter, Facebook, Partnerseite).
  • utm_medium — Kanal-Typ (email, social, cpc, organic).
  • utm_campaign — Kampagnen-Name.
  • utm_term — Suchbegriff (bei bezahlten Anzeigen).
  • utm_content — welcher Banner / welche Position.

Aus Marketing-Sicht legitim: das Unternehmen weiß, welche Newsletter-Kampagne welche Conversion-Rate hat. Aus Privatsphäre-Sicht: die URL dich identifiziert über die Kombination, oder enthält direkt eine Empfänger-ID:

  • ?ref=user_12345 — eindeutige Empfänger-Kennung.
  • ?fbclid=... (Facebook Click ID) — Meta-spezifischer Click-Tracker.
  • ?gclid=... (Google Click ID) — Google-Ads-Click-Tracker.
  • ?msclkid=... (Microsoft) — Bing-Ads-Tracker.

Wenn du eine solche URL weiterteilst (kopieren, in einen anderen Chat schicken), trägt sie die Marker mit — der Empfänger und alle Server, die die URL aufrufen, sehen die Click-IDs.

Praktische Reflexe:

  • Beim Teilen URLs säubern. Vor dem Senden die utm_*, fbclid, gclid, msclkid per Hand entfernen. Manche Browser machen das automatisch — Firefox seit 2022 (network.url.strip_on_share.enabled), Brave seit langem.
  • Beim Surfen Auto-Cleaner. Firefox-Setting + Brave-Default. Chrome hat das nicht eingebaut — Extension wie ClearURLs schließt die Lücke.
  • Beim Klicken in Mails: UTM-Parameter sind oft Bestandteil seriöser Newsletter — Marketing-Tracking ist nicht per se Phishing. Aber: wenn der Mail-Empfänger trackbar gemacht wird (User-spezifischer Click-Identifier), wandert auch die Information „diese Person hat diesen Link geklickt" zum Anbieter. Bei sensitiven Inhalten überlegen, ob direkt zur offiziellen Domain gegangen werden soll.
04 · Abschnitt

Web-Analytics: was wirklich gesammelt wird

Hinter fast jeder Webseite stehen Analytics-Dienste, die Besuche und Verhalten zählen. Drei Hauptklassen:

Tracker-basiert (klassisch):

  • Google Analytics (GA4) — Marktführer; pro Besuch werden Dutzende bis Hunderte Datenpunkte gesendet (Seitenaufruf, Scroll-Tiefe, Klicks, Verweildauer, Geo, Geräte-Klasse, Demografie-Schätzung). Daten gehen an Google-Server.
  • Adobe Analytics — Konzern-Pendant, oft in größeren Unternehmen.
  • Hotjar / Smartlook / Microsoft Clarity — „Session Recording" — zeichnet ganze Mausbewegungen und Klicks auf. Aus Privacy-Sicht besonders aggressiv.
  • Meta Pixel / Facebook Pixel — wird parallel mit GA eingebunden, schickt Daten an Meta. Auch wenn du keinen Facebook-Account hast, baut Meta ein „Schatten-Profil" auf.

Datenschutz-freundlich (modern):

  • Plausible (Estonia) — Open-Source-Analytics, ohne Cookies, keine personenbezogenen Daten. Cookie-Banner-frei einsetzbar.
  • Fathom — kommerzielles Pendant, ähnliches Modell.
  • Simple Analytics — niederländisch, ähnliches Konzept.

Self-Hosted:

  • Matomo (ehemals Piwik) — Open-Source, Self-Hosting möglich, vollständige Kontrolle, kein Daten-Abfluss an Dritte. Cookie-frei konfigurierbar.
  • GoatCounter, Counter.dev, Umami — kleinere Alternativen, oft minimal.

Die wichtige Unterscheidung aus Nutzer-Sicht: bei klassischen Analytics fließen Daten an Drittanbieter — diese können sie mit anderen Tracking-Daten kombinieren. Bei datenschutz-freundlichen Alternativen bleiben die Daten bei der Seite selbst oder gehen nur an einen einzigen, klar definierten Anbieter ohne Datenhandel-Geschäftsmodell.

05 · Abschnitt

Server-Side-Tagging: das stille Comeback

Eine Entwicklung der letzten Jahre, die viele Browser-Schutz-Maßnahmen umgeht: Server-Side-Tagging (auch Conversions API, Server-Side Google Tag Manager).

Prinzip: Statt dass das Tracking-Skript im Browser läuft und Daten direkt an Google/Meta schickt, läuft das Tracking auf dem Server des Webseiten-Betreibers. Der Browser sendet Daten an einen eigenen Subdomain-Endpunkt (tag.example.com), der Server leitet sie an Google/Meta weiter.

Was sich daraus ergibt:

  • uBlock Origin und Tracker-Blocker greifen weniger. Der Tracking-Request geht an tag.example.com — eine First-Party-Domain. Blocker erkennen das nicht zuverlässig.
  • First-Party-Cookies sind unbedenklicher als Third-Party — auch wenn die Daten letztlich bei einem Werbenetzwerk landen.
  • Conversions API (Meta) und Enhanced Conversions (Google) übermitteln Server-zu-Server gehashte Mail-Adressen und Telefonnummern.

Aus Nutzer-Sicht ist das kein direkt blockierbares Problem. Was hilft:

  • Datenschutz-freundliche Seiten unterstützen. Plausible-, Matomo-, GoatCounter-Setups sind unterscheidbar, weil sie kein Cookie-Banner brauchen und keine Drittanbieter laden.
  • Account-Hygiene. Wer in Google/Meta eingeloggt ist, gibt mehr Daten her — auch über Server-Side-Tagging.
  • Mail-Hash-Reduktion. Wer für sensitive Sites eine separate, nicht-personalisierte Mail-Adresse nutzt, lässt sich nicht so leicht über die Hash-Kette verbinden.
06 · Abschnitt

Datenschutz-freundliche Analytics als Trend

Eine positive Entwicklung: nicht nur Nutzer-Schutz, sondern auch das Anbieter-Setup wandert in Richtung Privatsphäre.

Warum Anbieter umstellen:

  • DSGVO-Compliance ohne Cookie-Banner-Aufwand. Plausible & Co. sind so designt, dass sie ohne personenbezogene Daten auskommen — kein Cookie-Banner nötig, kein Einwilligungs-Workflow.
  • Performance. Plausible-Script ist ca. 1 KB; Google Analytics über 70 KB plus Folge-Requests.
  • EuGH/Schrems-II-Risiko. Google-Analytics-Setups, die Daten in die USA übertragen, sind in mehreren europäischen Aufsichts-Verfahren als rechtlich problematisch eingestuft worden (CNIL Frankreich 2022, DSB Österreich 2022). Plausible & Co. hosten in Europa.
  • Geschäftsmodell ohne Daten-Verkauf. Anbieter wie Plausible verkaufen das Tool, nicht die Nutzer.

Was du als Nutzer:in davon hast:

  • Die Seite, die du besuchst, sammelt weniger über dich — auch wenn du nichts machst.
  • Browser-Performance ist besser.
  • Cookie-Banner sind oft kürzer oder fehlen ganz.

Wenn du selbst Webseiten betreibst: datenschutz-freundliche Analytics sind heute das vernünftige Default. Mehr im Entwickler-Kapitel.

07 · Abschnitt

Praktische Schritte für Nutzer:innen

Konkrete Reflexe, die deinen analytischen Fußabdruck reduzieren:

  • Browser mit gutem Default. Firefox-Strict-Modus, Brave, Safari haben gute Referrer-Policies und gute Tracker-Blocker out of the box.
  • uBlock Origin + EasyPrivacy. Blockt einen Großteil der klassischen Analytics-Trackers.
  • ClearURLs oder vergleichbares. Entfernt UTM, fbclid, gclid & Co. beim Klicken und Kopieren. In Firefox einfach: network.url.strip_on_share.enabled in about:config auf true.
  • Auto-Lösch-Setup. Cookies und LocalStorage von Sites, die du nur selten besuchst, beim Schließen löschen.
  • Konten ausloggen, wenn nicht aktiv genutzt. Während des Surfens nicht in Google/Meta eingeloggt zu sein, reduziert Cross-Site-Identifikation erheblich.
  • Container-Tabs für identifizierte Aktivitäten. Google-Suchen, Meta-Inhalte, Recherchen je in eigenen Containern.
  • Bei sensiblen Themen: Tor Browser oder Mullvad Browser für die Sitzung.

Diese Stack-Mischung kostet einmalig 30 Minuten Setup. Danach läuft sie unsichtbar im Hintergrund und reduziert deinen analytischen Fußabdruck dauerhaft.

08 · Abschnitt

FAQ

Sind UTM-Parameter immer Phishing?

Nein. UTM-Parameter sind in Marketing-Mails seriöser Anbieter Standard und helfen, Kampagnen zu evaluieren. Sie werden Phishing-Hinweis, wenn sie eine sehr personalisierte ID enthalten und auf einer Domain landen, die nicht zur erwarteten Marke passt. Domain prüfen, nicht UTM ignorieren.

Macht es Sinn, den Referer komplett abzuschalten?

Manche Sites lehnen Anfragen ohne Referer ab — Hot-Linking-Schutz, manche CAPTCHAs, manche Anti-CSRF-Mechanismen. Default „strict-origin-when-cross-origin" ist in der Regel der richtige Mittelweg. Komplettes Abschalten lohnt nur für sehr spezielle Use-Cases (Recherche im Tor Browser etc.).

Was ist mit YouTube-Embeds in anderen Seiten?

YouTube-Player auf fremden Seiten setzen YouTube-Cookies und Tracking. Storage Partitioning hilft, aber wer YouTube-eingeloggt ist, kann von YouTube auf der Drittseite erkannt werden. Privatsphäre-Schutz: YouTube nutzen nur in eigenem Browser-Tab/Container, nicht über Embeds (oder „Privacy Enhanced Mode" bei YouTube — youtube-nocookie.com als Embed-Domain).

Plausible vs. Google Analytics — was sieht der Webseiten-Betreiber?

Plausible: aggregierte Zahlen pro Tag/Woche, Quellen (Referrer-Origins), Geräte-Klassen, ungefähre Standorte. Keine individuellen Nutzer-Profile, keine Cross-Session-Verfolgung. Google Analytics 4: pro Nutzer (über eine ID) sehr detaillierte Verhaltens-Muster über Sessions hinweg, Demografie-Schätzungen, oft mit Werbe-Identifikatoren verknüpft. Beide haben legitime Use-Cases, aber die Daten-Tiefe ist drastisch unterschiedlich.

Wie erkenne ich, ob eine Seite datenschutz-freundliche Analytics nutzt?

Drei Indizien: (1) kein Cookie-Banner für Analytics nötig, (2) ein einziger Analytics-Endpunkt sichtbar in den DevTools-Network-Requests (kein Google-Tag-Manager-Initialisierungs-Code), (3) auf der Impressum-/Datenschutz-Seite wird ein Anbieter wie Plausible, Matomo, Fathom genannt. Sites mit „Google Analytics", „Facebook Pixel", „Hotjar" im Datenschutz-Text sind die anderen.

Server-Side-Tagging ist DSGVO-rechtlich nicht automatisch besser

Wer den Datenfluss über die eigene Domain leitet und am Ende doch an Google/Meta schickt, ist datenschutz-rechtlich nicht in einer besseren Position als bei klassischem Tagging. Die Aufsichtsbehörden bewerten das anhand der Daten-Verarbeitung, nicht der Transport-Architektur. Server-Side-Tagging löst Browser-Tracking-Blockaden, nicht Compliance-Fragen.

Hotjar & Session-Recording: was die wirklich machen

Tools wie Hotjar, Smartlook, FullStory zeichnen Mausbewegungen, Klick-Muster, Scroll-Verhalten und teils Eingaben in Formularen auf. Damit lassen sich Sessions vollständig nachvollziehen. Aus Datenschutz-Sicht aggressiv; oft ohne adäquate Einwilligung eingesetzt. Wer privacy-orientiert ist: Sites mit Hotjar-Embed sind ein klares Signal für entgegenkommende Datenschutz-Disziplin.

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Tracking & Privatsphäre

Zur Übersicht