I sju måneder ble alle som kom til wppoland.com fra en kampanjelenke sendt med 301 til den samme adressen uten sporingsparametere. Fra 7. mars 2026 til 10. oktober 2026 behandlet middleware i Cloudflare Pages utm_*, gclid, fbclid og msclkid som parametere som dupliserer innhold, og fjernet dem før nettleseren rakk å kjøre et eneste skript. Analysen så ingen kampanjer og Google Ads mistet gclid i hele perioden. Kontaktskjemaet fikk felt for kilden først 13. juli 2026, og fra da til rettingen kom hver henvendelse inn uten kilde.
Vi vet ikke hvor mange henvendelser dette gjaldt. Det finnes ingen måling å regne det ut fra, så vi oppgir ikke noe tall. Det vi vet, er at kildedataene fra denne perioden er ufullstendige og ikke egner seg til konklusjoner om kanaler.
Hvordan teste om en viderekobling fjerner gclid
Testen er én linje. En unik parameterverdi går forbi cachen, så svaret kommer fra logikken som kjører nå:
curl -sI "https://wppoland.com/pl/?utm_source=t$(date +%s)"Etter rettingen svarer den HTTP/2 200. Det samme gjelder ?gclid=. Som kontroll, en parameter som fortsatt skal viderekobles:
curl -sI "https://wppoland.com/pl/?lang=en"Den svarer 301. Alle tre resultatene sjekket vi i produksjon 11. oktober 2026.
På ditt eget nettsted bytter du domene og parameter. Test utm_source, gclid, fbclid og msclkid hver for seg, fordi regler ofte behandler dem ulikt. Får du 301 eller 302, les Location-headeren: parameteren må stå der. Gjenta så testen på adresser som viderekobles av en annen grunn: uten avsluttende skråstrek, på den andre verten (med og uten www) og med gammel slug. En side som svarer 200, kan bestå testen mens viderekoblingen ved siden av likevel mister parameterne.
Hvorfor UTM-parametere forsvinner etter viderekobling
En 301-viderekobling er et serversvar med en Location-header. Nettleseren legger ikke til noe selv: den går nøyaktig dit serveren peker. Hvis regelen som bygger adressen dropper query-strengen eller deler av den, slutter kampanjeparameterne å eksistere før siden lastes.
Det betyr noe fordi nesten all kampanjesporing skjer i nettleseren. Analyseskriptet leser utm_source fra location.href. Et skjema som lagrer kilden i skjulte felt, fyller dem med JavaScript fra location.search. Autotagging i Google Ads legger gclid til måladressen og forventer at identifikatoren kommer fram til siden. Alle disse mekanismene ser bare adressen nettleseren til slutt havnet på.
Derfor gjelder en enkel regel: hver viderekobling mellom annonsen og siden er et sted der kildeattribusjonen kan gå tapt. Ikke bare håndskrevne viderekoblinger, men også de som normaliserer vert, avsluttende skråstrek, gamle slugs og dupliserte parametere.
Hvorfor fjerner middleware i Cloudflare Pages utm_source og gclid
En commit fra 7. mars 2026, beskrevet som bedre adressehåndtering i middleware og headere, la til en liste over parametere som ble regnet som innholdsdupliserende i functions/_middleware.ts. Funksjonen hasDuplicateContentQuery sjekket om adressen inneholdt noen av dem. Hvis ja, bygde filteredQueryString en query-streng uten disse parameterne, og middleware svarte med 301 til resultatet.
Listen inneholdt parametere som faktisk lager overflødige varianter, som lang, amp, nonamp og s. Den inneholdt også utm_source, utm_medium, utm_campaign, utm_content, utm_term, gclid, fbclid og msclkid. Målet hørtes fornuftig ut: én adresse per side. Resultatet var at lenken /nb/?utm_source=newsletter endte på /nb/ før noen kode i nettleseren så ordet “newsletter”.
Middleware i Pages Functions kjører før resten av rutingen, på hver forespørsel. Det gjør det til et praktisk sted for adressenormalisering, og et like praktisk sted for en feil som treffer hver eneste visning fra en kampanje.
Hvorfor er utm_source tom i skjulte felt i kontaktskjemaet
Kontaktskjemaet vårt har hatt skjulte felt for utm_source, utm_medium, utm_campaign og utm_term siden 13. juli 2026. Før det lagret skjemaet ingen kilde i det hele tatt. JavaScript fyller feltene fra location.search når siden lastes. Etter viderekoblingen var location.search tom, og dermed feltene også, for hvert besøk fra en kampanjelenke mellom 13. juli og 10. oktober. Vi bygde altså kildesporing i skjemaet oppå en viderekobling som allerede hadde tømt adressen, og la ikke merke til det på tre måneder.
Følgene fordeler seg på tre steder:
- Skjemaet. Fra 13. juli kom henvendelsene inn uten kilde. Et besøk fra en lenke i et nyhetsbrev og et besøk uten merking så helt like ut.
- Analysen. Analyseverktøyet fikk ikke kampanjeparameterne fra 7. mars, så trafikk fra UTM-merkede lenker havnet i generelle kanaler eller som direkte trafikk.
- Google Ads. Autotagging legger på
gclid, og vår 301 skar den bort. Utengclidpå målsiden har Google Ads ingenting å knytte klikket til en senere konvertering med.
Ingen av disse symptomene ser ut som en feil i en viderekobling. De ser ut som en kampanje som ikke virker, eller en kanal som ikke gir noe.
Mister Cloudflare Transform Rule gclid ved viderekobling
Det samme symptomet, via en annen vei, beskrev SHIFT64. Artikkelen om å fjerne sporingsparametere i Cloudflare ble publisert 31. august 2026 og fikk en korrigering 7. oktober 2026. Den opprinnelige versjonen anbefalte en Transform Rule som skrev om adressen på kanten (uten viderekobling), slik at cachen så én adresse per side. Nettleseren beholdt hele adressen, så attribusjonen skulle overleve.
Den overlevde bare når serveren svarte 200. Når serveren svarte med en viderekobling (fra domenet uten www til www, for manglende skråstrek, fra WordPress sin kanoniske viderekobling), bygde den den nye adressen fra det den hadde mottatt, altså den avkortede adressen. Nettleseren fulgte viderekoblingen, og gclid, fbclid og gad_source forsvant fra adresselinjen. Forfatteren sier det rett ut:
“Jeg resonnerte meg fram til påstanden i stedet for å teste den mot ekte viderekoblinger.”
Mateusz Zadorożny, SHIFT64, Strip UTM Parameters at Cloudflare Without Losing Attribution (Corrected), korrigering datert 7. oktober 2026, egen oversettelse
Korrigeringen har to detaljer til. regex_replace() i Cloudflare erstatter bare det første treffet, så sporingsparametere som ikke sto ved siden av hverandre, ble bare delvis fjernet. Og adressen ?fbclid=x&color=red kom fram til serveren som ?&color=red, som WordPress svarte på med en 301. Ifølge SHIFT64 viste feilen seg i loggene til én nettbutikk med Google Ads som 21 besøk fra betalte annonser i løpet av omtrent tre uker, i tillegg til besøk på den ikke-kanoniske verten som loggene ikke kan telle. Regelen ble erstattet av en Worker som legger de fjernede parameterne tilbake på viderekoblinger innenfor samme nettsted. SHIFT64 råder også dem som har utvidelsen Super Page Cache, og der utvidelsen har laget en regel merket [DO NOT EDIT] med samme regex, til å slå av valget for å fjerne sporingsparametere. Det har vi ikke testet selv.
Datoene er disse: SHIFT64 korrigerte 7. oktober, vi rettet vår feil 10. oktober. Forskjellen ligger i mekanismen. SHIFT64 mistet parameterne gjennom en viderekobling fra serveren etter en omskriving på kanten. Vi mistet dem gjennom vår egen, bevisste viderekobling for å fjerne duplikater.
Hvorfor vises trafikk fra AI-chatboter som direkte i GA4
Search Engine Journal skrev 1. oktober 2026 (Roger Montti) at Gemini ser ut til å legge UTM-parametere på noen lenker til nettsteder. Kilden er én bruker på Reddit som så det i omtrent et døgn. Google har ikke dokumentert noe slikt, og vi vet ikke hvilke parametere eller verdier det gjelder, på hvilke lenker eller under hvilke forhold. John Mueller svarte bare at han gjerne sender det videre til teamet, og det er ingen bekreftelse. SEJ minner også om at trafikk fra AI-chatboter kan havne som direkte trafikk i GA4, fordi direkte er det analysen faller tilbake på når besøket mangler både referrer og UTM-data.
Samme dag publiserte DemandSphere (Ray Grieselhuber) tall for merkevaresøk. Andelen av sporede merkevaresøkeord som ga en AI Overview, steg fra 26,12 % 1. september til 82,06 % 29. september, med en topp på 90,48 % 27. september. Tallene kommer fra deres egen plattform, DemandMetrics, gjelder alle markeder og enheter, og utvalgets størrelse er ikke publisert. De teller AI Overview uansett om merkevaren blir sitert. Google har ikke kunngjort noen endring.
Resten er vår egen slutning, ikke noe kildene sier. Hvis AI-assistenter begynner å merke lenkene sine, kommer merkene i den samme query-strengen som vår middleware kuttet bort. En viderekobling som fjerner utm_*, fjerner dem også, og besøket blir direkte trafikk. Når stadig flere klikk på merkevaresøk går gjennom en AI Overview først, er de merkede klikkene som gjenstår, mer verdt å beholde. Vi har ingen data om at trafikk fra Gemini nådde wppoland.com, og vi påstår ikke at vi mistet noe av den. Vår egen hendelsessporing samler heller ikke referrer, så kildedata for søk henter vi fra Google Search Console.
Gir UTM-parametere duplisert innhold
Viderekoblingen beskyttet mot ingenting. Hver side på wppoland.com har hele tiden oppgitt en canonical uten parametere, så Google visste allerede hvilken adresse som gjaldt. Fra 7. mars til 11. april var det det eneste laget. Fra 12. april 2026 sendte filen public/_headers i tillegg denne headeren:
No-Vary-Search: key-order, params=("utm_source" "utm_medium" "utm_campaign" "utm_content" "utm_term" "ref" "fbclid" "gclid" "msclkid")No-Vary-Search forteller nettleseren at de oppførte parameterne ikke endrer svaret, så versjonen med og uten dem kan dele samme oppføring i cachen. Fra midten av april hadde vi altså to lag som løste dupliseringen uten å røre adressen i adresselinjen. Viderekoblingen kom i tillegg og ga ikke beskyttelse på noe tidspunkt, men tok bort kildeattribusjonen.
Rettingen fra 10. oktober 2026 slipper sporingsparametere gjennom uten viderekobling. lang, amp, nonamp og s får fortsatt 301, fordi det er de som lager reelle varianter. Kommentaren i koden:
// Tracking params (utm_*, gclid, fbclid, msclkid) pass through: the page
// canonical is already clean, and stripping them killed lead attribution.Hvilke viderekoblingsregler fjerner UTM-parametere
Lærdommen gjelder ikke bare Cloudflare Pages. Hver regel som “rydder” i query-strengen og svarer med viderekobling, har samme risikoprofil:
- middleware i Pages Functions eller i en Worker,
- regler i Cloudflare: Transform Rules, Redirect Rules, Page Rules,
rewriteogreturn 301i nginx-konfigurasjonen,- WordPress-utvidelser for viderekobling som normaliserer adresser eller fjerner “unødvendige” parametere,
- WordPress sine egne kanoniske viderekoblinger, når noe tidligere har kuttet adressen.
Regelen vi har tatt i bruk: fjerning av dupliserte parametere lar sporingsparametere være i fred. Duplisert innhold håndteres av canonical, og cachen håndteres av No-Vary-Search eller en cachenøkkel uten disse parameterne. Det trengs ingen viderekobling for det. Og det andre rådet, som SHIFT64 trakk ut av sin egen korrigering: test viderekoblinger, ikke bare sider.
Ligger nettstedet ditt bak Cloudflare og du vil ha noen til å gå gjennom reglene på kanten med dette for øye, er det en del av tjenesten vår for Cloudflare edge.
Kan man stole på UTM-data fra før rettingen
Kampanjedata i analysen fra 7. mars til 10. oktober 2026 er ufullstendige. Kildedata i skjemaet mangler fra 13. juli til 10. oktober, og før 13. juli lagret skjemaet ingen kilde. Det betyr ikke at alt er feil: besøk uten kampanjeparametere, for eksempel fra søkeresultater, gikk ikke gjennom denne viderekoblingen. Det betyr at alt som kom fra merkede lenker, ble tilskrevet et annet sted eller ingen steder.
I praksis:
- vi sammenligner ikke kanaler som avhenger av UTM i denne perioden med perioden etter 10. oktober,
- vi slår ikke av kampanjer på grunnlag av null attribusjon fra disse månedene,
- de første pålitelige kildedataene for henvendelser starter 10. oktober 2026.
Rutinglaget på dette nettstedet har ødelagt noe i det stille før, mens resten så friskt ut: Cloudflare Pages droppet regler i _redirects over 100KB. Den bredere konteksten for arkitekturen står i oppsummeringen av tolv måneder med migrering fra WordPress til Astro. Reglene for en ren canonical ved lenker med parametere beskriver vi i den tekniske guiden til affiliate SEO.
