Tracking-Parameter mit Cloudflare Workers und Transform Rules entfernen

Warum Tracking-Parameter deine Cache Hit Rate zerstören

Tracking-Parameter wie utm_source, gclid und fbclid helfen Marketern, die Performance von Kampagnen zu messen. Für die Core Web Vitals sind sie ein Albtraum, da sie das Caching stören. Jede eindeutige URL erzeugt einen separaten Cache-Eintrag. Eine einzige auf Facebook geteilte Seite erhält für jeden Klick eine eindeutige fbclid, was bedeutet, dass jeder Besucher von Facebook einen Cache Miss und eine langsame Time to First Byte erhält.

Cloudflare bietet dir drei Möglichkeiten, diese Parameter an der Edge zu entfernen, bevor sie deinen Cache verschmutzen: Transform Rules (ohne Code), Workers (volle Kontrolle) und Cache Key Customization (Enterprise). Ich werde alle drei behandeln.

Zuletzt überprüft von Arjen Karel im März 2026

Das Caching-Problem mit Tracking-Parametern

Caching-Systeme verwenden die vollständige URL als Cache-Key. Wenn eine URL ?utm_source=google oder ?fbclid=abc123 enthält, behandelt der Cache sie als unterschiedliche Seite, selbst wenn der Inhalt identisch ist. Das ist ein Cache Miss. Der Server baut eine Seite neu auf, die er bereits im Cache hat, nur weil die URL einen anderen Query-String-Wert hat.

Das Ausmaß dieses Problems ist größer, als die meisten Leute denken. Es gibt 129 bekannte Tracking-Parameter im gesamten Marketing-Ökosystem. Der fbclid Parameter ist am destruktivsten, weil Facebook ihn an jeden ausgehenden Link-Klick anhängt, nicht nur an bezahlte Anzeigen. Jeder organische Share, jeder Link in einem Kommentar, jeder Post, der auf deine Website verlinkt, erhält einen eindeutigen fbclid Wert.

Laut dem 2025 Web Almanac haben nur 44 % der mobilen Origins eine gute TTFB. Cloudflare berichtete, dass die Behebung des Caching-Verhaltens von Query Strings die Cache Hit Rates im Durchschnitt um 3 % verbesserte und die Origin-Bytes um 5 % reduzierte. Das übersetzt sich direkt in einen schnelleren Largest Contentful Paint für deine Besucher.

Nicht alle Query-Parameter sind Tracking-Müll. Parameter wie ?q=laptops oder ?color=blue verändern den Seiteninhalt. Das Ziel ist es, die Parameter zu entfernen, die den Inhalt nicht beeinflussen, während diejenigen beibehalten werden, die dies tun.

Welche Tracking-Parameter solltest du entfernen?

Hier sind die häufigsten Tracking-Parameter, gruppiert nach Plattform. Diese erzeugen eindeutige, nicht cachebare URLs, ohne den Seiteninhalt zu verändern:

Das ist nicht die vollständige Liste. Die Tracking Query Params Registry dokumentiert alle 129 bekannten Parameter. Für die meisten Websites deckt die Behandlung der Google-, Meta- und Microsoft-Parameter 95 % des Problems ab.

Option 1: Transform Rules (kein Code erforderlich)

Cloudflare verfügt über eine integrierte Funktion namens remove_query_args(), die bestimmte Query-Parameter aus der URL entfernt, bevor sie den Cache erreicht. Dies läuft als Transform Rule, erfordert keinen Code und ist in allen Plänen verfügbar, einschließlich der kostenlosen Stufe.

So richtest du das ein:

1. Gehe in deinem Cloudflare-Dashboard zu Rules, dann zu Transform Rules und anschließend zu URL Rewrite
2. Erstelle eine neue Regel
3. Stelle den Filter so ein, dass er zu deiner Domain passt, zum Beispiel (http.host eq "example.com")
4. Für Query wählst du Rewrite to und dann Dynamic
5. Gib den folgenden Ausdruck ein:
   remove_query_args(http.request.uri.query, "utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content", "utm_id", "gclid", "gclsrc", "wbraid", "gbraid", "dclid", "gad_source", "fbclid", "msclkid", "ttclid", "twclid", "li_fat_id", "epik", "srsltid", "_ga", "_gl")
6. Für Path wählst du Preserve

Das ist alles. Kein Worker, kein Code-Deployment. Der kostenlose Plan erlaubt 10 Transform Rules, der Pro-Plan erlaubt 25. Für die meisten Websites ist dies die beste Option.

Option 2: Cloudflare Workers

Cloudflare hat zwar Out-of-the-Box-Optionen, um Query Strings zu ignorieren, aber ihre konservativen Einstellungen reichen nicht aus, um das meiste aus deinem Cloudflare-Plan herauszuholen. Wenn du mehr Kontrolle benötigst, als Transform Rules bieten (zum Beispiel Regex-Matching, bedingte Logik oder Logging), gibt dir ein Cloudflare Worker volle Flexibilität.

Workers fangen Anfragen an der Edge ab und führen deinen Code aus, bevor die Anfrage den Cache oder Origin-Server erreicht. Cloudflare lädt Workers während des TLS-Handshakes, daher liegt der effektive Overhead unter 1 Millisekunde.

Der Code

Unten ist das vollständige Worker-Skript unter Verwendung der aktuellen ES-Modules-Syntax:

export default {
  async fetch(request) {
    const url = new URL(request.url)

    const trackingParams = /^(utm_|gad_|gclid|gclsrc|wbraid|gbraid|dclid|fbclid|fb_action_|srsltid|msclkid|ttclid|twclid|li_fat_id|epik|igshid|_ga$|_gl$|mc_[ce]id|_hs[em])/

    // Collect matching keys first (do not delete during iteration)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

    keysToDelete.forEach(key => url.searchParams.delete(key))

    return fetch(url.toString(), request)
  }
}

Der Worker parst die URL, testet jeden Query-Parameter gegen eine Regex und entfernt Übereinstimmungen. Die saubere URL geht dann an den Cache und Origin-Server. Zwei Details sind hier wichtig: Der Code sammelt Keys in einem Array, bevor er sie löscht, da das Löschen während der Iteration von URLSearchParams Einträge überspringen kann (dies ist ein bekanntes Spezifikationsproblem mit Live-Iteratoren). Und das Skript verwendet das ES-Modules-Format (export default), da Cloudflare die ältere addEventListener-Syntax veraltet hat.

Deployment

1. Bei Cloudflare anmelden. Logge dich in dein Cloudflare-Dashboard ein.
2. Einen Worker erstellen. Navigiere noch nicht zu deiner Website. Gehe stattdessen zum Bereich Workers und erstelle einen neuen Worker.
   
3. Den Worker benennen und bereitstellen. Dieser Schritt mag etwas unintuitiv wirken, aber keine Sorge. Benenne einfach deinen leeren 'Hello World' Worker und klicke auf Deploy.
   
4. Deinen Worker bearbeiten. Auf der nächsten Seite klickst du auf Edit Code.
   
5. Das Skript einfügen. Kopiere das obige Skript und füge es in den Editor ein. Klicke dann auf Deploy.
   
6. Den Worker an eine Route binden. Gehe nun zurück und navigiere zu deiner Website in Cloudflare. Klicke auf Worker Routes und dann auf 'Add Route'. Wähle den neu erstellten Worker aus und wende ihn auf deine Website an.
   

Anpassung

Du kannst die Regex anpassen, um bestimmte Parameter einzuschließen oder auszuschließen. Wenn du bestimmte utm_ Parameter für serverseitige Verarbeitung beibehalten möchtest, entferne sie aus der Regex. Wenn du eine Marketing-Plattform verwendest, die nicht von der Standard-Regex abgedeckt wird, füge ihre Parameter hinzu.

Option 3: Cache Key Customization (Enterprise)

Wenn du einen Cloudflare Enterprise-Plan hast, kannst du benutzerdefinierte Cache Keys konfigurieren, um bestimmte Query-Parameter auszuschließen, ohne sie überhaupt aus der URL zu entfernen. Der Cache ignoriert sie bei der Berechnung des Keys einfach. Dies ist der sauberste Ansatz, da die URL unverändert bleibt, erfordert jedoch Enterprise.

Für Nicht-Enterprise-Pläne erzielen der Transform Rule- oder Worker-Ansatz denselben Cache-Vorteil.

Welchen Ansatz solltest du verwenden?

Beginne bei den meisten Websites mit Transform Rules. Wenn du das Regel-Limit erreichst oder mehr Flexibilität benötigst, wechsle zu Workers.

Wenn du WordPress mit Cloudflare APO verwendest, brauchst du all dies möglicherweise gar nicht. APO führt eine Allowlist von über 25 Marketing-Parametern, die es bei der Berechnung von Cache Keys ignoriert. Überprüfe, ob deine spezifischen Parameter abgedeckt sind, bevor du einen Worker oder eine Transform Rule hinzufügst.

Zerstört das Entfernen von Parametern Analytics?

Nein. Das Entfernen geschieht an der Edge, zwischen dem CDN und deinem Origin-Server. Die Browser-URL enthält weiterhin die ursprünglichen Tracking-Parameter. Google Analytics, Google Ads Conversion Tracking und das Facebook Pixel lesen alle auf der Client-Seite aus document.location, was nach wie vor die vollständige URL mit allen intakten Parametern aufweist.

Das einzige Szenario, in dem dies Probleme verursachen könnte, ist, wenn dein serverseitiger Code Tracking-Parameter aus der URL ausliest (zum Beispiel bei einer serverseitigen Analytics-Implementierung). Schließe diese Parameter in diesem Fall entweder von der Entfernung aus oder erfasse sie in einem Request-Header, bevor der Worker sie entfernt.

Für einen umfassenderen Blick darauf, wie Tracking- und Analytics-Skripte die Performance jenseits des Cachings beeinflussen, siehe The Case for Limiting Analytics and Tracking Scripts.

Wie du herausfindest, welche URL-Parameter du entfernen solltest

Herauszufinden, welche URL-Parameter entfernt werden sollten, ist einfach, wenn du das richtige Tool verwendest. RUM-Tools (Real User Monitoring) wie CoreDash überwachen deine Website rund um die Uhr und protokollieren alle Query Strings zusammen mit ihren Auswirkungen auf die Performance. Navigiere in CoreDash zu Largest Contentful Paint und sieh dir die Ergebnisse nach Query String an.

Über von CoreDash überwachte Websites hinweg zeigen Seiten mit entfernten Tracking-Parametern etwa 8 bis 15 % bessere Cache Hit Rates. Für Besucher, die andernfalls einen Cache Miss erhalten würden, übersetzt sich das in eine 200 bis 500 ms schnellere TTFB.

Wenn du bei Cloudflare bist und dein Cache-Dauer TTFB-Sub-Part hoch ist, gehört die Verschmutzung durch Tracking-Parameter zu den ersten Dingen, die du überprüfen solltest. Kombiniere das Entfernen von Parametern mit der richtigen Cloudflare-Konfiguration, und du wirst eine messbare Verbesserung deiner Felddaten feststellen.