Woher l.facebook.com kommt und warum Klicks als Direct landen

Was ist l.facebook.com?

Facebook schreibt ausgehende Links um, sodass jeder Klick über l.facebook.com läuft, den Zwischenschritt, den Meta Link-Shim nennt, bevor der Browser Ihre Seite erreicht. Metas Engineering-Blog nannte das Werkzeug 2012 beim Namen und beschrieb es als Möglichkeit, „to warn people about potentially spammy or malicious links.“ Der Hostname ist ein Weiterleitungsdienst und nichts sonst. Rufen Sie die nackte Domain auf, antwortet sie mit HTTP/2 302 und location: https://www.facebook.com/, geprüft am 12. September 2026.

Meta nutzt ihn weiterhin auf den eigenen Angeboten. Jeder ausgehende Link im Footer von developers.facebook.com ist geshimmt, wodurch sich das Format an einer Live-Seite ablesen lässt statt an einem Screenshot.

Wie sieht eine l.facebook.com-URL aus?

Zwei Query-Parameter tragen alles. Das Ziel steht prozentcodiert in u, eine Signatur in h:

https://l.facebook.com/l.php?u=https%3A%2F%2Fwww.llama.com%2F&h=AUCy45wK_2QEcW5a...

Weil die vollständige Ziel-URL prozentcodiert in u steckt, überlebt ihr eigener Query-String den Umweg. Jedes utm_source oder utm_campaign, das Sie an einen Link hängen, ist noch dran, wenn der Browser ankommt.

Der Parameter h ist kein Hash des Ziels. Zwei Abrufe derselben Meta-Seite am 12. September 2026 lieferten zwei verschiedene h-Werte für dasselbe llama.com-Ziel, was bedeutet, dass die Signatur an die Sitzung gebunden ist, die den Link gerendert hat, und nicht an die URL. Kopieren Sie einen geshimmten Link aus Facebook heraus und fügen Sie ihn anderswo ein, löst er sich nicht auf: Sowohl eine signierte als auch eine unsignierte l.php-Anfrage lieferte ohne die ursprüngliche Sitzung HTTP/2 400 mit Facebooks allgemeiner Seite „Sorry, something went wrong“.

Meta betreibt parallele Hostnamen für seine anderen Oberflächen, und alle verhalten sich gleich.

Warum leitet Facebook Klicks überhaupt über einen Shim?

Aus zwei Gründen, die Meta offen nennt, und nur einer davon kostet Sie etwas. Der erste ist die Malware-Prüfung. Der zweite ist die absichtliche Referrer-Beschränkung.

Metas Beitrag „A faster, better link shim“ von 2012 beschreibt den Umbau, der bis heute gilt. Statt einen Link nach dem Klick zu prüfen, „we now check every link on the page before it's sent to the browser,“ und „if we find a link to be suspicious, we use the old interstitial warning page; otherwise we allow the user through to the link itself.“ Meta bezifferte die Ersparnis auf „around a second every time they click an external link.“

Die Referrer-Hälfte steht genauso deutlich da, unter einer Überschrift namens Restricting the Referrer: „We still need to let the websites you navigate to know the traffic is from Facebook, but we also want to prevent them from reading the full source url. Otherwise, they could know where on the site you were when you clicked their link.“ Das ist kein Nebeneffekt. Das ist das Designziel.

Was macht der Link-Shim mit Ihrem Referrer?

Er gibt Ihnen eine Origin statt einer URL. Metas Beitrag von 2012 sagt, man habe „taken advantage of a new feature called the meta referrer,“ das „allows us to specify how much of the source url to share with the external site via the Referer header.“ Das Tag steht bis heute auf der Seite. Ein Abruf von www.facebook.com am 12. September 2026 liefert das hier im Head:

<meta name="referrer" content="origin-when-crossorigin" id="meta_referrer">

In dieser Zeichenkette steckt ein Haken. Die W3C-Spezifikation Referrer Policy definiert genau neun gültige Tokens, und origin-when-crossorigin gehört nicht dazu. Das ausgeschriebene Token lautet origin-when-cross-origin, mit Bindestrich zwischen cross und origin. Die Spezifikation sagt außerdem, „unknown policy values will be ignored,“ und dass „the default referrer policy is strict-origin-when-cross-origin.“

Beide Wege enden für Sie am selben Punkt. Akzeptiert ein Browser Metas alte Schreibweise, senden Cross-Origin-Navigationen nur die Origin. Lehnt ein Browser sie ab und fällt auf den Standard zurück, senden Cross-Origin-Navigationen ebenfalls nur die Origin. So oder so ist der Referer-Header, der bei Ihrem Server ankommt, eine nackte Origin wie https://l.facebook.com/, nie der Beitrag, die Gruppe oder das Profil, aus dem der Klick stammt.

Der eine Fall, in dem Sie gar nichts bekommen, ist ein Protokoll-Downgrade. Unter strict-origin-when-cross-origin gilt für eine Navigation von einer HTTPS-Seite zu einem HTTP-Ziel: „would send no Referer header.“ Eine Website, die noch schlichtes HTTP ausliefert, verliert die Zuordnung vollständig.

Warum landet l.facebook.com-Traffic in Analytics als Direct?

Weil der Referer-Header nicht ankam, nicht weil Google den Hostnamen falsch einordnet. Genau hier drehen die meisten Ratschläge zum Shim die Sache um.

Google veröffentlicht die Liste der Quellen, die es Kanälen zuordnet, und l.facebook.com, lm.facebook.com, l.instagram.com und l.messenger.com stehen alle als SOURCE_CATEGORY_SOCIAL darauf. Der GA4-Kanal Organic Social greift, wenn die Quelle „matches a regex list of social sites“ oder das Medium eines von social, social-network, social-media und ähnlichen ist. Ein Klick, der mit der Shim-Origin ankommt, ist also bereits als Organic Social eingestuft. Es gibt nichts zu reparieren und keine Referral-Ausschlussregel zu ergänzen.

Der Kanal Direct hat eine viel engere Definition: Die Quelle entspricht exakt (direct) und das Medium ist (not set) oder (none). Dort landet nichts durch Fehleinordnung. Dort landet etwas, wenn das Analytics-Tag weder Referrer noch Kampagnenparameter zur Verfügung hat. Drei Situationen erzeugen das:

• Ein Protokoll-Downgrade, bei dem laut Spezifikation überhaupt kein Referer gesendet wird.
• Eine Übergabe aus einem In-App-Browser an den System-Browser, bei der die neue Navigation kein Linkklick ist und keinen eigenen Referrer trägt.
• Ein kopierter und eingefügter Link, der per Definition ohne Referrer ankommt, weil niemand auf etwas geklickt hat.

Die allgemeine Form dieses Topfes und was sonst noch hineinfällt, behandelt dieser Erklärtext zum Direct Traffic.

Wie hören Sie auf, die Zuordnung zu verlieren?

Taggen Sie die URL, bevor sie den Composer erreicht, denn der Shim bewahrt den Query-String, den er einpackt. Das Ziel wird prozentcodiert in u mitgeführt, utm_source=facebook&utm_medium=social&utm_campaign=spring-launch überlebt also die Weiterleitung und erreicht Ihre Analytics unversehrt. Kampagnenparameter schlagen im Kanalabgleich von GA4 außerdem den Referrer, was bedeutet, dass ein getaggter Link gleich eingeordnet wird, ob der Referer-Header auftaucht oder nicht. Die Namenskonventionen, die das über Netzwerke hinweg einheitlich halten, arbeitet dieser Leitfaden zu UTM-Parametern durch.

Link-Wrapping ist keine Facebook-Eigenheit. X macht dasselbe mit seinem eigenen Kürzungsdienst und schreibt jede veröffentlichte URL in einen t.co-Link um, mit eigenen Folgen für das, was Ihr Server sieht. Metas Crawler-Seite hat dieselbe gespaltene Persönlichkeit: Die Vorschaukarte baut ein separater Abruf durch den Crawler facebookexternalhit, lange bevor ein Mensch den Shim anklickt.

Zwei Zahlensätze gehören getrennt. Impressionen, Reichweite und Klicks, die auf der Facebook-Seite erfasst werden, stammen aus Metas eigenen APIs, und genau das zeigt ein Werkzeug wie adaptlypost unter Social-Media-Analyse. Die Sitzung, die auf Ihrer Website landet, ist ein anderer Datensatz, geführt von Ihrer eigenen Analytics, und der Link-Shim sitzt in der Lücke dazwischen. Das Taggen der URL schließt sie.

Häufig gestellte Fragen

Sollte ich l.facebook.com auf meine Referral-Ausschlussliste setzen?

Nein. Googles veröffentlichte Quellliste ordnet l.facebook.com bereits SOURCE_CATEGORY_SOCIAL zu, GA4 berichtet diese Sitzungen also als Organic Social statt als allgemeines Referral. Den Hostnamen auszuschließen entfernt den Referrer und schiebt diese Sitzungen nach Direct, also genau in das Ergebnis, das die meisten vermeiden wollen.

Kann ich sehen, aus welchem Facebook-Beitrag ein Klick kam?

Nicht am Referrer. Metas erklärtes Designziel ist es, „prevent them from reading the full source url,“ und der Header, der bei Ihrem Server ankommt, ist eine Origin wie https://l.facebook.com/ ohne Pfad. Ein pro Beitrag eindeutiger utm_content-Wert ist der einzige Weg, zwei Beiträge auseinanderzuhalten.

Warum funktioniert ein eingefügter l.facebook.com-Link nicht?

Weil der Parameter h eine Signatur ist, die an die Sitzung gebunden ist, die den Link erzeugt hat, und nicht an das Ziel. Eine l.php-Anfrage außerhalb dieser Sitzung lieferte am 12. September 2026 sowohl im signierten als auch im unsignierten Test HTTP/2 400 und Facebooks allgemeine Fehlerseite.

Was ist der Unterschied zwischen l.facebook.com und lm.facebook.com?

Die Oberfläche, die den Klick erzeugt hat. lm.facebook.com ist das Gegenstück im mobilen Web, und der nackte Hostname leitet auf https://m.facebook.com/?_rdr weiter, während l.facebook.com auf https://www.facebook.com/ weiterleitet. Google führt beide als soziale Quellen.

Entfernt der Link-Shim meine UTM-Parameter?

Nein. Die Ziel-URL wird komplett prozentcodiert in den Parameter u gepackt, Query-String inklusive, Kampagnen-Tags kommen also mit dem Besucher an. Parameter gehen verloren, wenn ein Link vor dem Veröffentlichen von Hand neu getippt oder gekürzt wird, nicht am Shim.

Läuft jeder Facebook-Link über den Shim?

Metas Beschreibung von 2012 sagt, Links würden geprüft, bevor die Seite an den Browser geht, und verdächtige Links bekämen eine Interstitial-Warnseite, während alles andere direkt zum Link durchgelassen wird. Meta veröffentlicht keine Regel dafür, welche Links zu l.php umgeschrieben werden und welche nicht, behandeln Sie den Umweg also als standardmäßig vorhanden und taggen Sie entsprechend.

Warum leitet Facebook einen Klick über l.facebook.com um, anstatt direkt auf meine Seite zu verlinken?

Meta nennt zwei Gründe für diesen Umweg: Links werden auf Malware geprüft, bevor ein Klick den Browser überhaupt erreicht, und es wird begrenzt, wie viel von der Quell-URL Facebook verlässt. Die Malware-Prüfung läuft direkt auf der Seite, noch vor jedem Klick. Die Referrer-Beschränkung ist ebenso beabsichtigt und steht unter Metas eigener Überschrift Restricting the Referrer.

Macht die Malware-Prüfung im Link-Shim Klicks langsamer?

Meta berichtet das Gegenteil. Die Neugestaltung von 2012, bei der Links geprüft werden, bevor sie den Browser erreichen, sparte laut Meta rund eine Sekunde bei jedem externen Klick gegenüber dem alten System, das erst nach dem Klick prüfte. Verdächtige Links erhalten weiterhin die Zwischenwarnseite, alles andere geht direkt zum Ziel durch.

Warum erhalten zwei Personen unterschiedliche h-Werte für denselben geshimmten Link?

Der Parameter h ist kein Hash der Ziel-URL, sondern eine Signatur, die an die Browsersitzung gebunden ist, in der der Link erzeugt wurde. Ein zweifacher Abruf derselben Meta-Seite am 12. September 2026 erzeugte zwei unterschiedliche h-Werte für dasselbe llama.com-Ziel, was zeigt, dass der Wert von der Sitzung abhängt und nicht vom Link selbst. Ein kopierter Link schlägt außerhalb dieser Sitzung fehl, selbst wenn sein h-Wert frisch ist.

Wie finde ich das tatsächliche Ziel eines l.facebook.com-Links, bevor ich klicke?

Das Ziel steckt percent-codiert im Parameter u der URL, zusammen mit dem restlichen Query-String, etwa utm_source oder utm_campaign. Wird dieser Parameter dekodiert, zeigt sich die genaue Zielseite, ohne den Shim tatsächlich anzuklicken. Der danebenstehende Parameter h ist nur eine Sitzungssignatur und enthält keine Information über das Ziel.