Referrer-Policy
Was ist die Referrer-Policy?
Die Referrer-Policy ist eine Sicherheitsrichtlinie für Websites. Sie bestimmt, welche Informationen der Browser im HTTP-Header Referer übermittelt, wenn ein Nutzer eine Ressource aufruft oder einem Link folgt. Je nach Einstellung wird die vollständige Ausgangs-URL, nur ihre Herkunft oder überhaupt keine Referrer-Information übertragen.
Wie funktioniert die Referrer-Policy?
Die Referrer-Policy, auf Deutsch einmalig auch Verweisrichtlinie genannt, steuert die Datenweitergabe zwischen einer aufgerufenen Seite und dem Ziel einer HTTP-Anfrage. Der Browser wendet die festgelegte Direktive beispielsweise auf Links, Bilder, Skripte, Stylesheets und eingebettete Inhalte an. Im Referer-Header kann die Zielseite dadurch erkennen, von welcher Website oder URL die Anfrage stammt.
Die Schreibweise Referer im HTTP-Header enthält historisch bedingt nur ein „r“ in der Mitte. Die Richtlinie selbst heißt korrekt Referrer-Policy. Diese beiden Schreibweisen bezeichnen daher keine unterschiedlichen technischen Konzepte.
Welche Information übertragen wird, hängt von drei Bedingungen ab: der gewählten Direktive, dem Verhältnis zwischen Ausgangsseite und Ziel sowie dem verwendeten Protokoll. Bei einer Anfrage innerhalb derselben Herkunft kann der Browser mehr Informationen senden als bei einem Wechsel zu einer anderen Domain. Als Herkunft, englisch origin, gilt die Kombination aus Protokoll, Hostname und Port.
Direktiven der Referrer-Policy
Für die Referrer-Policy stehen acht gebräuchliche Direktiven zur Verfügung. Sie unterscheiden sich vor allem darin, ob eine vollständige URL, nur die Herkunft oder keine Information übertragen wird.
| Direktive | Verhalten |
|---|---|
no-referrer | Der Browser sendet keinen Referer-Header. |
no-referrer-when-downgrade | Die URL wird übertragen, außer eine HTTPS-Seite verweist auf ein HTTP-Ziel. |
origin | Der Browser übermittelt nur Protokoll, Hostname und Port. |
origin-when-cross-origin | Innerhalb derselben Herkunft wird die URL übertragen, bei externen Zielen nur die Herkunft. |
same-origin | Referrer-Daten werden ausschließlich innerhalb derselben Herkunft gesendet. |
strict-origin | Der Browser sendet nur die Herkunft und unterdrückt sie beim Wechsel von HTTPS zu HTTP. |
strict-origin-when-cross-origin | Intern wird die URL übertragen, extern nur die Herkunft und bei einem Protokoll-Downgrade nichts. |
unsafe-url | Die URL wird auch an externe Ziele und bei einem Protokoll-Downgrade übertragen. |
Moderne Browser verwenden ohne abweichende Vorgabe üblicherweise strict-origin-when-cross-origin. Die Direktive erhält bei internen Anfragen aussagekräftige Referrer-Daten, begrenzt die Übertragung an andere Websites aber auf die Herkunft. URL-Fragmente und Zugangsdaten gehören unabhängig von der Direktive nicht in den übermittelten Referer-Header.
strict-origin-when-cross-origin übermittelt ein Link von https://shop.example/kategorie?farbe=blau zu einer anderen HTTPS-Domain nur https://shop.example/. Führt der Link zu einer Seite derselben Herkunft, kann der vollständige Pfad einschließlich Abfrageparametern übertragen werden.Referrer-Policy richtig einbinden
Am zuverlässigsten wird die Referrer-Policy als HTTP-Antwort-Header ausgeliefert. Eine globale Vorgabe sieht beispielsweise so aus:
Referrer-Policy: strict-origin-when-cross-origin
Alternativ kann die Richtlinie im HTML-Dokument über ein Meta-Element festgelegt werden:
<meta name="referrer" content="strict-origin-when-cross-origin">
Für einzelne Elemente steht zusätzlich das Attribut referrerpolicy zur Verfügung. Damit lässt sich die globale Vorgabe gezielt für einen Link, ein Bild, ein Skript oder ein iframe anpassen. Ein Beispiel ist <a href="https://example.org" referrerpolicy="no-referrer">. Die lokale Angabe gilt nur für die Anfrage, die dieses Element auslöst.
Bedeutung für technisches SEO
Die Referrer-Policy ist kein bekannter direkter Ranking-Faktor. Eine restriktive Einstellung kann jedoch Analyse-, Affiliate- und Partnerdaten verändern. Wenn no-referrer verwendet wird, erkennt das Zielsystem den verweisenden Ursprung nicht mehr über den HTTP-Header. Besuche können dadurch in Analyseberichten als direkte Zugriffe erscheinen oder einer anderen Quelle zugeordnet werden.
Für SEO-Manager liegt das konkrete Risiko deshalb in der Dateninterpretation. Ein Rückgang gemessener Referral-Zugriffe muss nicht bedeuten, dass weniger Nutzer über externe Links kommen. Der Rückgang kann durch eine geänderte Referrer-Policy verursacht worden sein. Vergleiche bei auffälligen Kanalverschiebungen den Zeitpunkt der Änderung mit Server-Konfigurationen, Releases und den Daten im Analysewerkzeug.
Suchmaschinen können öffentlich erreichbare Links weiterhin crawlen, auch wenn keine Referrer-Information übertragen wird. Die Richtlinie ersetzt weder robots.txt noch Meta-Robots-Angaben und steuert auch nicht die Indexierung. Für eine umfassende Prüfung solcher Signale eignet sich ein technisches SEO-Audit. Grundlagen zu automatisierten Fehlerprüfungen erklärt außerdem der Beitrag über Crawler im technischen SEO.
Abgrenzung zu verwandten Angaben
Der Unterschied zwischen Referrer-Policy und rel="noreferrer" liegt im Geltungsbereich. Die Referrer-Policy kann eine komplette Website, ein Dokument oder ein Element steuern. rel="noreferrer" gilt ausschließlich für den damit ausgezeichneten Link und verhindert dort die Übertragung der Referrer-Information.
Der Unterschied zwischen Referrer-Policy und Content Security Policy liegt im Schutzzweck. Die Referrer-Policy begrenzt Informationen über die Ausgangsseite. Eine Content Security Policy legt dagegen fest, aus welchen Quellen eine Website Inhalte wie Skripte, Bilder oder Stylesheets laden darf. Beide Richtlinien können als HTTP-Header ausgeliefert werden, erfüllen aber getrennte Aufgaben.
Die Referrer-Policy ist außerdem keine Cookie-Einstellung. Cookies speichern oder übertragen zustandsbezogene Daten nach eigenen Regeln, während der Referer-Header die Herkunft einer Anfrage beschreibt. Eine Website kann Cookies blockieren und trotzdem einen Referrer senden oder Cookies zulassen und den Referrer vollständig unterdrücken.
Typische Fehler bei der Referrer-Policy
Ein häufiger Konfigurationsfehler ist die Annahme, eine möglichst restriktive Direktive sei grundsätzlich die beste Wahl. no-referrer minimiert zwar die Weitergabe der Ausgangsadresse, entfernt aber auch Informationen, die für Attribution, Partnerprogramme oder die Fehlersuche benötigt werden. Die passende Einstellung ergibt sich aus dem Datenbedarf und den verwendeten externen Diensten.
unsafe-url kann Pfade und Abfrageparameter an externe Ziele übertragen. Enthalten URLs interne Kennungen oder andere vertrauliche Parameter, können diese Informationen in fremden Serverprotokollen landen. Prüfe deshalb zuerst, welche Daten deine URLs enthalten, bevor du diese Direktive einsetzt.Messbar ist die Konfiguration direkt in den Entwicklerwerkzeugen des Browsers: Öffne den Netzwerkbereich, rufe einen internen und einen externen Link auf und kontrolliere bei der jeweiligen Anfrage den Header Referer. Teste zusätzlich einen Wechsel zwischen HTTPS und HTTP, sofern ein solches Ziel vorhanden ist. Eine allgemeine Onpage-Optimierung sollte HTTP-Header und Analyseauswirkungen gemeinsam berücksichtigen.
Häufige Fragen zur Referrer-Policy
Welche Referrer-Policy sollte ich verwenden?
Für viele Websites ist strict-origin-when-cross-origin ein ausgewogener Ausgangspunkt. Die Direktive überträgt intern detaillierte Angaben, reduziert externe Informationen auf die Herkunft und sendet bei einem Wechsel von HTTPS zu HTTP keinen Referrer.
Kann die Referrer-Policy das Google-Ranking verändern?
Die Referrer-Policy ist kein bekannter direkter Ranking-Faktor. Sie kann jedoch Analyse- und Attributionsdaten verändern, wodurch SEO-Maßnahmen bei einer ungenauen Auswertung falsch bewertet werden können.
Warum heißt der Header Referer und nicht Referrer?
Referer ist eine historische Fehlschreibung in der HTTP-Spezifikation und wurde aus Kompatibilitätsgründen beibehalten. Der Richtlinienname Referrer-Policy verwendet dagegen die korrekte englische Schreibweise.
Kann ich mehrere Referrer-Policies gleichzeitig setzen?
Mehrere widersprüchliche Vorgaben erschweren die Kontrolle und können je nach Einbindungsort unterschiedlich wirken. Verwende eine klare globale Richtlinie und ergänze elementbezogene Ausnahmen nur dort, wo ein konkreter technischer Grund besteht.
Wie prüfe ich den Referer-Header einer Website?
Öffne die Entwicklerwerkzeuge des Browsers und wechsle in den Netzwerkbereich. Wähle die betreffende Anfrage aus und kontrolliere unter den Anfrage-Headern, ob ein Referer vorhanden ist und welche URL-Information übertragen wurde.
Funktioniert die Referrer-Policy auch bei Bildern und Skripten?
Die Referrer-Policy kann auch Anfragen für Bilder, Skripte, Stylesheets und eingebettete Inhalte steuern. Die globale Richtlinie lässt sich bei unterstützten HTML-Elementen durch das Attribut referrerpolicy gezielt anpassen.
Wenn du HTTP-Header, Crawling-Signale und weitere technische Faktoren deiner Website prüfen lassen möchtest, kannst du einen unverbindlichen Potenzialcheck anfragen.
Sie haben noch Fragen?
