Przez siedem miesięcy każdy, kto wszedł na wppoland.com z linku kampanii, był przekierowywany 301 na ten sam adres bez parametrów śledzących. Od 7 marca 2026 do 10 października 2026 nasz middleware na Cloudflare Pages traktował utm_*, gclid, fbclid i msclkid jak parametry duplikujące treść i wycinał je, zanim przeglądarka zdążyła uruchomić choćby jeden skrypt. Analityka nie widziała kampanii, a Google Ads gubił gclid. Formularz kontaktowy zapisuje źródło leada dopiero od 13 lipca 2026 i od tego dnia do poprawki dostawał puste pola dla każdego wejścia z linku kampanii.
Nie wiemy, ilu leadów to dotyczyło. Nie mamy pomiaru, z którego dałoby się to policzyć, więc nie podajemy żadnej liczby. Wiemy natomiast, że dane o kampaniach z tego okresu są niepełne i nie nadają się do wniosków o kanałach.
Dlaczego znikają parametry UTM po przekierowaniu
Przekierowanie 301 to odpowiedź serwera z nagłówkiem Location. Przeglądarka nie dopisuje do niego niczego od siebie: idzie dokładnie pod adres, który serwer zbudował. Jeśli reguła budująca ten adres pominie query string albo jego część, parametry kampanii przestają istnieć, zanim strona się załaduje.
Ma to znaczenie, bo prawie cała atrybucja dzieje się w przeglądarce. Skrypt analityki czyta utm_source z location.href. Formularz, który zapisuje źródło leada w ukrytych polach, wypełnia je przez JavaScript z location.search. Autotagowanie Google Ads dokleja gclid do adresu docelowego i oczekuje, że ten identyfikator dotrze do strony. Każdy z tych mechanizmów widzi tylko adres, na którym przeglądarka w końcu wylądowała.
Stąd prosta reguła: każde przekierowanie po drodze z reklamy do strony jest miejscem, w którym atrybucja może zginąć. Nie tylko przekierowania pisane ręcznie. Także te z normalizacji hosta, końcowego ukośnika, starych slugów i deduplikacji parametrów.
Jak middleware Cloudflare Pages usuwał gclid i utm_source
Commit z 7 marca 2026, opisany jako poprawa obsługi adresów w middleware i nagłówkach, dodał do functions/_middleware.ts listę parametrów uznanych za duplikujące treść. Funkcja hasDuplicateContentQuery sprawdzała, czy adres zawiera którykolwiek z nich. Jeśli tak, filteredQueryString budowała query string bez tych parametrów, a middleware zwracał 301 na wynik.
Na liście były parametry, które naprawdę tworzą zbędne warianty, takie jak lang, amp, nonamp i s. Były tam też utm_source, utm_medium, utm_campaign, utm_content, utm_term, gclid, fbclid i msclkid. Cel brzmiał rozsądnie: jeden adres na jedną stronę. Efekt był taki, że link /pl/?utm_source=newsletter kończył się na /pl/, zanim jakikolwiek kod w przeglądarce zobaczył słowo “newsletter”.
Middleware w Pages Functions działa przed resztą routingu, przy każdym żądaniu. To czyni go wygodnym miejscem na normalizację adresów, i tak samo wygodnym miejscem na błąd, który dotyka każdej odsłony z kampanii.
Dlaczego ukryte pola UTM w formularzu kontaktowym są puste
Ukryte pola utm_source, utm_medium, utm_campaign i utm_term dodaliśmy do formularza kontaktowego 13 lipca 2026. Wcześniej formularz w ogóle nie zapisywał źródła leada, więc przez pierwsze cztery miesiące błędu nie miał czego zgubić. JavaScript wypełnia te pola z location.search w chwili załadowania strony. Po przekierowaniu location.search było puste, więc pola też: od 13 lipca do 10 października, dla każdego wejścia z linku kampanii. Pomiar dodany do formularza przez trzy miesiące zapisywał puste źródło przy każdym wejściu z kampanii, bo middleware odcinał mu dane wejściowe.
Skutki rozkładają się na trzy miejsca:
- Formularz. Od 13 lipca lead trafiał do skrzynki bez informacji o źródle. Wejście z linku w newsletterze i wejście bez żadnego oznaczenia wyglądały identycznie.
- Analityka. Przez cały okres od 7 marca narzędzie analityczne nie dostawało parametrów kampanii, więc ruch z linków oznaczonych UTM lądował w kanałach ogólnych albo w wejściach bezpośrednich.
- Google Ads. Autotagowanie dokleja
gclid, a nasz 301 go wycinał, także od 7 marca. Bezgclidna stronie docelowej Google Ads nie ma czym powiązać kliknięcia z późniejszą konwersją.
Żaden z tych objawów nie wygląda jak błąd przekierowania. Wygląda jak kampania, która nie działa, albo jak kanał, który nic nie przynosi.
Czy przekierowanie usuwające UTM chroni przed duplikacją treści
Nie chroniło przed niczym, w żadnym momencie. Każda strona na wppoland.com od początku deklarowała canonical bez parametrów, więc Google już wiedział, który adres jest właściwy. Od 7 marca do 11 kwietnia była to jedyna ochrona i w zupełności wystarczała. 12 kwietnia 2026 doszedł plik public/_headers z nagłówkiem:
No-Vary-Search: key-order, params=("utm_source" "utm_medium" "utm_campaign" "utm_content" "utm_term" "ref" "fbclid" "gclid" "msclkid")No-Vary-Search mówi przeglądarce, że wymienione parametry nie zmieniają odpowiedzi, więc wersja z nimi i bez nich może korzystać z tego samego wpisu w cache. Od połowy kwietnia mieliśmy więc dwie warstwy, które rozwiązywały problem duplikacji bez dotykania adresu w pasku przeglądarki. Przekierowanie było kolejną warstwą, która nie dodawała ochrony, a zabierała atrybucję.
Poprawka z 10 października 2026 przepuszcza parametry śledzące bez przekierowania. lang, amp, nonamp i s nadal dostają 301, bo to one tworzą realne warianty. W kodzie został komentarz:
// Tracking params (utm_*, gclid, fbclid, msclkid) pass through: the page
// canonical is already clean, and stripping them killed lead attribution.Jak sprawdzić, czy przekierowanie usuwa gclid
Test zajmuje jedną linię. Unikalna wartość parametru omija cache, więc odpowiedź pochodzi z bieżącej logiki:
curl -sI "https://wppoland.com/pl/?utm_source=t$(date +%s)"Po poprawce zwraca HTTP/2 200, tak samo jak wariant z gclid. Kontrolnie parametr, który nadal ma być przekierowywany:
curl -sI "https://wppoland.com/pl/?lang=en"Ten zwraca 301. Wszystkie trzy wyniki sprawdziliśmy ponownie na produkcji 11 października 2026.
Na własnej stronie zamień domenę i parametr. Sprawdź utm_source, gclid, fbclid i msclkid osobno, bo reguły często traktują je różnie. Jeśli dostajesz 301 albo 302, przeczytaj nagłówek Location: parametr musi tam być. Potem powtórz test na adresach, które przekierowują z innego powodu: bez końcowego ukośnika, na drugim hoście (z www i bez), na starym slugu. Strona, która odpowiada 200, może przejść test, a przekierowanie obok i tak zgubi parametry.
Jak usunąć UTM w Cloudflare bez utraty atrybucji
Ten sam objaw, inną drogą, opisał SHIFT64. Jego artykuł o usuwaniu parametrów śledzących w Cloudflare ukazał się 31 sierpnia 2026, a 7 października 2026 dostał korektę. Pierwotna wersja zalecała Transform Rule, która przepisywała adres na krawędzi (bez przekierowania), żeby cache widział jeden adres na stronę. Przeglądarka zachowywała pełny adres, więc atrybucja miała przetrwać.
Przetrwała tylko wtedy, gdy serwer odpowiadał 200. Gdy serwer odpowiadał przekierowaniem (z domeny bez www na www, dla brakującego ukośnika, z przekierowania kanonicznego WordPressa), budował nowy adres z tego, co dostał, czyli z adresu już obciętego. Przeglądarka szła za przekierowaniem i gclid, fbclid oraz gad_source znikały z paska adresu. Autor przyznaje to wprost:
“Doszedłem do tego twierdzenia rozumowaniem, zamiast przetestować je na prawdziwych przekierowaniach.”
Mateusz Zadorożny, SHIFT64, Strip UTM Parameters at Cloudflare Without Losing Attribution (Corrected), korekta z 7 października 2026, tłumaczenie własne
W korekcie są jeszcze dwa szczegóły. regex_replace() w Cloudflare zastępuje tylko pierwsze dopasowanie, więc niesąsiadujące parametry śledzące były usuwane częściowo. A adres ?fbclid=x&color=red docierał do serwera jako ?&color=red i WordPress odpowiadał na niego 301. Według SHIFT64 w jednym sklepie z Google Ads błąd był widoczny w logach jako 21 płatnych wejść w ciągu około trzech tygodni, plus wejścia na niekanoniczny host, których logi nie policzą. Regułę zastąpił Worker, który dokleja usunięte parametry z powrotem do przekierowań w obrębie tej samej witryny. SHIFT64 radzi też, żeby przy regule [DO NOT EDIT] z tym samym wyrażeniem, utworzonej przez wtyczkę Super Page Cache, wyłączyć w niej opcję usuwania parametrów śledzących. Tej wtyczki sami nie sprawdzaliśmy.
Daty są takie: korekta SHIFT64 z 7 października, nasza poprawka z 10 października. Różnica jest w mechanizmie. SHIFT64 zgubił parametry przez przekierowanie z serwera, które nastąpiło po przepisaniu adresu na krawędzi. My zgubiliśmy je przez własne, celowe przekierowanie deduplikujące.
Czy Gemini dodaje parametry UTM do linków
1 października 2026 Search Engine Journal (tekst Rogera Monttiego) opisał zgłoszenie użytkownika Reddita: Gemini wydaje się dodawać parametry UTM do części linków prowadzących do stron. Zgłaszający pisał, że zjawisko jest bardzo nowe, widoczne od mniej więcej doby. Google tego nie udokumentował. Nie wiadomo, jakie parametry i wartości trafiają do adresu, których linków to dotyczy ani w jakich warunkach. John Mueller odpowiedział tylko: “Chętnie przekażę to zespołowi” (za Search Engine Journal, tłumaczenie własne). To nie jest potwierdzenie. SEJ przypomina przy okazji, że ruch z czatbotów AI potrafi w GA4 lądować w wejściach bezpośrednich, bo kanał bezpośredni to kanał zastępczy dla wizyt bez referrera i bez danych UTM.
Tego samego dnia DemandSphere (Ray Grieselhuber) opublikował dane o zapytaniach brandowych. Odsetek śledzonych fraz z nazwą marki, dla których Google pokazywał AI Overview, wyniósł 26,12% 1 września i 82,06% 29 września (ostatni punkt pomiaru), ze szczytem 90,48% 27 września. Metoda ma granice: to dane z własnej platformy DemandSphere (DemandMetrics), łącznie dla wszystkich rynków i urządzeń, bez opublikowanej wielkości próby, a AI Overview jest liczony niezależnie od tego, czy marka jest w nim cytowana. Google nie ogłosił żadnej zmiany.
Dalej jest nasze wnioskowanie, nie pomiar. Jeśli asystenci AI zaczną oznaczać swoje linki, te oznaczenia przyjdą w tym samym query stringu, który nasz middleware wycinał. Przekierowanie usuwające utm_* usunie i je, a wizyta spadnie do wejść bezpośrednich. Skoro kliknięcia z zapytań brandowych coraz częściej przechodzą najpierw przez AI Overview, każde kliknięcie, które jeszcze niesie oznaczenie, jest warte więcej. Nie twierdzimy, że ruch z Gemini trafiał na wppoland.com ani że go straciliśmy. Nasza własna analityka nie zbiera referrera, a źródła wejść z wyszukiwarki bierzemy z Google Search Console, więc parametry w adresie są dla nas jedynym śladem, skąd przyszła wizyta.
Które reguły przekierowań usuwają parametry UTM
Wniosek nie dotyczy tylko Cloudflare Pages. Każda reguła, która “porządkuje” query string i odpowiada przekierowaniem, ma ten sam profil ryzyka:
- middleware w Pages Functions albo w Workerze,
- reguły Cloudflare: Transform Rules, Redirect Rules, Page Rules,
rewriteireturn 301w konfiguracji nginx,- wtyczki przekierowań w WordPressie, które normalizują adresy albo usuwają “zbędne” parametry,
- przekierowania kanoniczne samego WordPressa, gdy coś wcześniej obcięło adres.
Reguła, którą przyjęliśmy: deduplikacja parametrów zostawia parametry śledzące w spokoju. Duplikację treści obsługuje canonical, a cache obsługuje No-Vary-Search albo klucz cache bez tych parametrów. Przekierowanie nie jest do tego potrzebne. I druga rada, którą SHIFT64 wyciągnął z własnej korekty: testuj przekierowania, nie tylko strony.
Jeśli trzymasz stronę za Cloudflare i chcesz, żeby ktoś przejrzał reguły krawędzi pod tym kątem, to część naszej usługi Cloudflare edge.
Jak traktować dane o źródłach leadów sprzed poprawki
Dane z analityki i z Google Ads od 7 marca do 10 października 2026 są niepełne. Źródło leada w formularzu zapisujemy od 13 lipca 2026, więc dla formularza okres z dziurą to 13 lipca do 10 października, a wcześniejszych danych o źródle po prostu nie ma. Nie znaczy to, że wszystko jest błędne: wejścia bez parametrów kampanii, na przykład z wyników wyszukiwania, nie przechodziły przez to przekierowanie. Znaczy to, że wszystko, co przyszło z oznaczonych linków, zostało przypisane gdzie indziej albo nigdzie.
Praktycznie:
- nie porównujemy skuteczności kanałów, które zależą od UTM, w tym okresie z okresem po 10 października,
- nie wyłączamy kampanii na podstawie zerowej atrybucji z tych miesięcy,
- pierwsze wiarygodne dane o kampaniach, w analityce, w Google Ads i w formularzu, zaczynają się od 10 października 2026.
Warstwa routingu na tym serwisie już raz psuła coś po cichu, gdy reszta wyglądała zdrowo: Cloudflare Pages porzucał reguły z pliku _redirects powyżej 100KB. Szerszy kontekst tej architektury jest w podsumowaniu dwunastu miesięcy migracji z WordPressa do Astro. Zasady dla czystego canonical przy linkach z parametrami opisujemy w technicznym przewodniku po SEO afiliacyjnym.
