Vom 7. März 2026 bis 10. Oktober 2026, rund sieben Monate lang, wurde jeder Besucher, der über einen Kampagnenlink auf wppoland.com kam, per 301 auf dieselbe Adresse ohne Tracking-Parameter umgeleitet. Unsere Middleware auf Cloudflare Pages behandelte utm_*, gclid, fbclid und msclkid als Duplicate-Content-Parameter und schnitt sie ab, bevor der Browser auch nur ein Skript ausführen konnte. Analytics sah keine Kampagne, Google Ads verlor die gclid. Das Kontaktformular speichert die Lead-Quelle erst seit dem 13. Juli 2026, und von da an bis zur Korrektur kam sie bei Kampagneneinstiegen leer an.
Wie viele Leads betroffen waren, wissen wir nicht. Es gibt keine Messung, aus der sich das berechnen ließe, deshalb nennen wir keine Zahl.
Warum verschwinden UTM-Parameter nach einer Weiterleitung
Eine 301-Weiterleitung ist eine Serverantwort mit einem Location-Header. Der Browser ergänzt daran nichts: Er ruft genau die Adresse auf, die der Server gebaut hat. Lässt die Regel, die diese Adresse baut, den Query-String ganz oder teilweise weg, existieren die Kampagnenparameter nicht mehr, bevor die Seite lädt.
Das zählt, weil fast die gesamte Kampagnenattribution im Browser stattfindet. Das Analyse-Skript liest utm_source aus location.href. Ein Formular, das die Lead-Quelle in versteckten Feldern speichert, füllt sie per JavaScript aus location.search. Das Auto-Tagging von Google Ads hängt die gclid an die Zieladresse und erwartet, dass diese Kennung auf der Seite ankommt. Jeder dieser Mechanismen sieht nur die Adresse, auf der der Browser am Ende gelandet ist.
Daraus folgt eine einfache Regel: Jede Weiterleitung auf dem Weg von der Anzeige zur Seite ist eine Stelle, an der die Attribution verloren gehen kann. Nicht nur handgeschriebene Weiterleitungen, sondern auch die aus der Host-Normalisierung, dem abschließenden Schrägstrich, alten Slugs und der Parameter-Deduplizierung.
Mit curl prüfen, ob eine Weiterleitung die gclid entfernt
Der Test ist eine Zeile. Ein eindeutiger Parameterwert umgeht den Cache, die Antwort kommt also aus der aktuellen Logik:
curl -sI "https://wppoland.com/pl/?utm_source=t$(date +%s)"Nach der Korrektur liefert das HTTP/2 200, ebenso eine Adresse mit ?gclid=. Zur Kontrolle ein Parameter, der weiterhin umgeleitet werden soll:
curl -sI "https://wppoland.com/pl/?lang=en"Dieser liefert 301. Alle drei Ergebnisse haben wir am 11. Oktober 2026 auf der Produktion erneut geprüft.
Für Ihre eigene Website tauschen Sie Domain und Parameter aus. Prüfen Sie utm_source, gclid, fbclid und msclkid einzeln, weil Regeln sie oft unterschiedlich behandeln. Bekommen Sie eine 301- oder 302-Weiterleitung, lesen Sie den Location-Header: Der Parameter muss dort stehen. Wiederholen Sie den Test dann an Adressen, die aus einem anderen Grund weiterleiten: ohne abschließenden Schrägstrich, auf dem zweiten Host (mit und ohne www), mit einem alten Slug. Eine Seite, die mit dem Statuscode 200 antwortet, kann den Test bestehen, während die Weiterleitung daneben die Parameter trotzdem verliert.
Warum entfernt Middleware in Cloudflare Pages gclid und utm_source
Ein Commit vom 7. März 2026, beschrieben als verbesserte URL-Behandlung in Middleware und Headern, fügte functions/_middleware.ts eine Liste von Parametern hinzu, die als Duplicate Content galten. Die Funktion hasDuplicateContentQuery prüfte, ob die Adresse einen davon enthielt. Wenn ja, baute filteredQueryString einen Query-String ohne diese Parameter, und die Middleware antwortete mit einer 301-Weiterleitung auf das Ergebnis.
Auf der Liste standen Parameter, die tatsächlich überflüssige Varianten erzeugen, etwa lang, amp, nonamp und s. Dort standen aber auch utm_source, utm_medium, utm_campaign, utm_content, utm_term, gclid, fbclid und msclkid. Das Ziel klang vernünftig: eine Adresse pro Seite. Das Ergebnis: Ein Link auf /de/?utm_source=newsletter endete auf /de/, bevor irgendein Code im Browser das Wort “newsletter” gesehen hatte.
Middleware in Pages Functions läuft bei jeder Anfrage vor dem übrigen Routing. Das macht sie zu einem bequemen Ort für URL-Normalisierung, und ebenso zu einem bequemen Ort für einen Fehler, der jeden Aufruf aus einer Kampagne trifft.
Warum versteckte UTM-Felder im Formular leer bleiben
Unser Kontaktformular hat seit dem 13. Juli 2026 die versteckten Felder utm_source, utm_medium, utm_campaign und utm_term. Davor speicherte es überhaupt keine Lead-Quelle. JavaScript füllt die Felder beim Laden der Seite aus location.search. Nach der Weiterleitung war location.search leer, also auch die Felder, bei jedem Einstieg über einen Kampagnenlink vom 13. Juli bis 10. Oktober 2026. Das Formular kam also erst rund vier Monate nach der Weiterleitung dazu und lief danach rund drei Monate lang ins Leere.
Die Folgen verteilen sich auf drei Stellen:
- Analytics, seit 7. März. Das Analysewerkzeug bekam keine Kampagnenparameter, also landete Traffic aus UTM-markierten Links in allgemeinen Kanälen oder bei den Direktzugriffen.
- Google Ads, seit 7. März. Das Auto-Tagging hängt die
gclidan, unsere 301 schnitt sie ab. Ohnegclidauf der Zielseite kann Google Ads den Klick nicht mit einer späteren Conversion verknüpfen. - Formular, seit 13. Juli. Der Lead kam ohne Lead-Quelle an. Ein Einstieg über einen Newsletter-Link und ein Einstieg ohne jede Kennzeichnung sahen identisch aus.
Keines dieser Symptome sieht nach einem Weiterleitungsfehler aus. Es sieht aus wie eine Kampagne, die nicht funktioniert, oder wie ein Kanal, der nichts bringt.
UTM-Parameter und Duplicate Content mit Canonical lösen
Die Weiterleitung schützte zu keinem Zeitpunkt vor irgendetwas. Jede Seite auf wppoland.com gibt von Anfang an einen Canonical ohne Parameter an, Google wusste also bereits, welche Adresse die richtige ist. Vom 7. März bis 11. April war das die einzige Ebene, und sie reichte. Seit dem 12. April 2026 schickt public/_headers zusätzlich diesen Header:
No-Vary-Search: key-order, params=("utm_source" "utm_medium" "utm_campaign" "utm_content" "utm_term" "ref" "fbclid" "gclid" "msclkid")No-Vary-Search teilt dem Browser mit, dass die genannten Parameter die Antwort nicht verändern, sodass die Variante mit und ohne Parameter denselben Cache-Eintrag nutzen kann. Ab Mitte April gab es also zwei Ebenen, die das Duplikatproblem lösten, ohne die Adresse in der Browserleiste anzufassen. Die Weiterleitung lag darüber, fügte keinen Schutz hinzu und nahm die Attribution weg.
Die Korrektur vom 10. Oktober 2026 lässt Tracking-Parameter ohne Weiterleitung durch. lang, amp, nonamp und s bekommen weiterhin eine 301-Weiterleitung, weil sie echte Varianten erzeugen. Im Code steht dazu dieser Kommentar:
// Tracking params (utm_*, gclid, fbclid, msclkid) pass through: the page
// canonical is already clean, and stripping them killed lead attribution.UTM-Parameter entfernen mit Cloudflare Transform Rule
Dasselbe Symptom auf anderem Weg hat SHIFT64 beschrieben. Der Artikel über das Entfernen von Tracking-Parametern in Cloudflare erschien am 31. August 2026 und erhielt am 7. Oktober 2026 eine Korrektur. Die ursprüngliche Fassung empfahl eine Transform Rule, die die Adresse am Edge umschrieb (ohne Weiterleitung), damit der Cache eine Adresse pro Seite sieht. Der Browser behielt die volle Adresse, die Attribution sollte also erhalten bleiben.
Sie blieb nur erhalten, wenn der Server mit 200 antwortete. Antwortete der Server mit einer Weiterleitung (von der Domain ohne www auf www, wegen eines fehlenden Schrägstrichs, durch die Canonical-Weiterleitung von WordPress), baute er die neue Adresse aus dem, was er bekommen hatte, also aus der bereits gekürzten Adresse. Der Browser folgte der Weiterleitung, und gclid, fbclid und gad_source verschwanden aus der Adressleiste.
Die Korrektur nennt zwei weitere Details. Die Adresse ?fbclid=x&color=red kam beim Server als ?&color=red an, worauf WordPress mit einer 301-Weiterleitung antwortete. Und:
“Nicht benachbarte Tracking-Parameter wurden nur teilweise entfernt, weil Cloudflares
regex_replace()nur den ersten Treffer ersetzt.”Mateusz Zadorożny, SHIFT64, Strip UTM Parameters at Cloudflare Without Losing Attribution (Corrected), Korrektur vom 7. Oktober 2026, eigene Übersetzung
Laut SHIFT64 zeigte sich der Fehler in einem Shop mit Google Ads in den Logs als 21 bezahlte Einstiege in etwa drei Wochen, dazu Einstiege über den nicht kanonischen Host, die die Logs nicht zählen können. Die Regel wurde durch einen Worker ersetzt, der entfernte Parameter bei Weiterleitungen innerhalb derselben Website wieder anhängt. Wer das Plugin Super Page Cache nutzt und dort eine Regel mit dem Vermerk [DO NOT EDIT] und demselben regulären Ausdruck findet, soll laut SHIFT64 die Option zum Entfernen von Tracking-Parametern abschalten. Das Plugin haben wir selbst nicht geprüft.
Der Unterschied liegt im Mechanismus. SHIFT64 verlor die Parameter durch eine Server-Weiterleitung nach einem Rewrite am Edge. Wir verloren sie durch eine eigene, bewusst gesetzte Deduplizierungs-Weiterleitung. Die Korrekturen lagen drei Tage auseinander: SHIFT64 am 7. Oktober, wir am 10. Oktober.
Warum erscheint KI-Traffic in GA4 als direkter Zugriff
Am 1. Oktober 2026 berichtete Search Engine Journal (Roger Montti), dass Gemini offenbar einigen Links zu Websites UTM-Parameter anhängt. Die Quelle ist ein Reddit-Nutzer, der die Beobachtung selbst als sehr neu beschrieb, etwa 24 Stunden alt. Google hat das nicht dokumentiert. Offen ist, welche Parameter und Werte gesetzt werden, an welchen Links und unter welchen Bedingungen. John Mueller schrieb nur, er leite das gern an das Team weiter, was keine Bestätigung ist. Derselbe Artikel erinnert daran, dass Traffic aus KI-Chatbots in GA4 oft als Direktzugriff erscheint, weil Direkt der Kanal ist, auf den GA4 ohne Referrer und ohne UTM-Daten zurückfällt.
Am selben Tag veröffentlichte DemandSphere (Ray Grieselhuber) Zahlen zu Markensuchen. Der Anteil der beobachteten Marken-Keywords, die eine AI Overview auslösen, lag am 1. September bei 26,12 % und am 29. September, dem letzten Datenpunkt, bei 82,06 %, mit einem Höchstwert von 90,48 % am 27. September. Die Daten stammen aus der eigenen Plattform DemandMetrics, über alle Märkte und Geräte, ohne veröffentlichte Stichprobengröße. Gezählt wird jede AI Overview, egal ob die Marke darin zitiert wird. Google hat keine Änderung angekündigt.
Was folgt, ist unsere Schlussfolgerung, keine Messung. Wenn KI-Assistenten anfangen, ihre Links zu kennzeichnen, landen diese Kennzeichen im selben Query-String, den unsere Middleware abgeschnitten hat. Eine Weiterleitung, die utm_* entfernt, entfernt sie mit, und der Besuch fällt auf Direkt zurück. Wenn Markenklicks immer häufiger zuerst durch eine AI Overview laufen, ist jeder Klick, der noch eine Kennzeichnung trägt, mehr wert. Ob Traffic aus Gemini unsere Website erreicht hat oder durch die Weiterleitung verloren ging, wissen wir nicht. Unser eigenes Event-Tracking erfasst keinen Referrer, die Zuordnung zur Suche kommt bei uns aus der Google Search Console.
Welche Weiterleitungsregeln UTM-Parameter entfernen
Die Lehre gilt nicht nur für Cloudflare Pages. Jede Regel, die den Query-String “aufräumt” und mit einer Weiterleitung antwortet, hat dasselbe Risikoprofil:
- Middleware in Pages Functions oder in einem Worker,
- Cloudflare-Regeln: Transform Rules, Redirect Rules, Page Rules,
rewriteundreturn 301in der nginx-Konfiguration,- Weiterleitungs-Plugins in WordPress, die Adressen normalisieren oder “überflüssige” Parameter entfernen,
- die Canonical-Weiterleitungen von WordPress selbst, wenn vorher etwas die Adresse gekürzt hat.
Unsere Regel daraus: Parameter-Deduplizierung lässt Tracking-Parameter in Ruhe. Duplicate Content regelt der Canonical, den Cache regelt No-Vary-Search oder ein Cache-Key ohne diese Parameter. Eine Weiterleitung braucht es dafür nicht. Dazu der Rat, den SHIFT64 aus der eigenen Korrektur gezogen hat: Testen Sie Weiterleitungen, nicht nur Seiten.
Wenn Ihre Website hinter Cloudflare läuft und jemand die Edge-Regeln unter diesem Gesichtspunkt durchsehen soll, gehört das zu unserer Leistung Cloudflare Edge.
Wie man Attributionsdaten nach einem Weiterleitungsfehler auswertet
Die Kampagnendaten in Analytics und Google Ads vom 7. März bis 10. Oktober 2026 sind unvollständig. Das heißt nicht, dass alle falsch sind: Einstiege ohne Kampagnenparameter, etwa aus den Suchergebnissen, liefen nicht durch diese Weiterleitung. Es heißt, dass alles, was über gekennzeichnete Links kam, woanders oder gar nicht zugeordnet wurde. Für das Kontaktformular ist die Lage anders: Vor dem 13. Juli gibt es keine Daten zur Lead-Quelle, vom 13. Juli bis 10. Oktober fehlen sie bei jedem Kampagneneinstieg.
Praktisch bedeutet das:
- Wir vergleichen UTM-abhängige Kanäle aus diesem Zeitraum nicht mit dem Zeitraum nach dem 10. Oktober.
- Wir schalten keine Kampagne ab, weil sie in diesen Monaten keine Attribution hatte.
- Belastbare Kampagnendaten, im Formular wie in Analytics, beginnen am 10. Oktober 2026.
Die Routing-Ebene dieser Website hat schon einmal still etwas kaputt gemacht, während alles andere gesund aussah: Cloudflare Pages verwarf Regeln aus der Datei _redirects über 100KB. Den größeren Zusammenhang dieser Architektur beschreibt der Rückblick auf zwölf Monate Migration von WordPress zu Astro. Wie ein sauberer Canonical bei Links mit Parametern aussieht, steht im technischen Leitfaden zu Affiliate-SEO.
