Entre 7 de março de 2026 e 10 de outubro de 2026, quem chegava a wppoland.com através de um link de campanha era redirecionado com 301 para o mesmo endereço, só que sem os parâmetros de rastreio. O nosso middleware no Cloudflare Pages tratava utm_*, gclid, fbclid e msclkid como parâmetros de conteúdo duplicado e cortava-os antes de o navegador executar um único script. Durante esses sete meses a analítica não viu campanhas e o Google Ads perdeu o gclid. O formulário de contacto só guarda a origem do lead desde 13 de julho de 2026, e daí até 10 de outubro recebeu esses campos vazios.
Não sabemos quantos leads foram afetados. Não temos uma medição que permita contá-los, por isso não damos número nenhum. Sabemos, isso sim, que os dados sobre a origem dos leads neste período estão incompletos e não servem para conclusões sobre canais.
Como verificar se um redirecionamento remove o gclid
Comece pelo teste, porque é uma linha. Um valor de parâmetro único evita a cache, por isso a resposta vem da lógica atual:
curl -sI "https://wppoland.com/pl/?utm_source=t$(date +%s)"Depois da correção devolve HTTP/2 200, e o mesmo acontece com ?gclid=. Como controlo, um parâmetro que deve continuar a ser redirecionado:
curl -sI "https://wppoland.com/pl/?lang=en"Este devolve 301. Voltámos a verificar o comportamento em produção a 11 de outubro de 2026.
No seu site, troque o domínio e o parâmetro. Teste utm_source, gclid, fbclid e msclkid em separado, porque as regras tratam-nos muitas vezes de forma diferente. Se receber 301 ou 302, leia o cabeçalho Location: o parâmetro tem de lá estar. Depois repita o teste em endereços que redirecionam por outro motivo: sem barra final, no outro host (com e sem www), num slug antigo. Uma página que responde 200 pode passar no teste e o redirecionamento ao lado perder os parâmetros na mesma.
Porque é que os parâmetros UTM desaparecem depois de um redirecionamento
Um redirecionamento 301 é uma resposta do servidor com um cabeçalho Location. O navegador não lhe acrescenta nada: vai exatamente para o endereço que o servidor construiu. Se a regra que constrói esse endereço omitir a query string ou parte dela, os parâmetros de campanha deixam de existir antes de a página carregar.
Isto importa porque quase toda a atribuição acontece no navegador. O script de analítica lê utm_source a partir de location.href. O formulário que guarda a origem do lead em campos ocultos preenche-os por JavaScript a partir de location.search. A etiquetagem automática do Google Ads acrescenta o gclid ao URL final e espera que esse identificador chegue à página. Cada um destes mecanismos só vê o endereço onde o navegador acabou por aterrar.
Daí uma regra simples: qualquer redirecionamento no caminho entre o anúncio e a página é um sítio onde a atribuição se pode perder. Não só os redirecionamentos escritos à mão. Também os de normalização do host, da barra final, de slugs antigos e de deduplicação de parâmetros.
Porque é que o middleware do Cloudflare Pages remove utm_source e gclid
O commit de 7 de março de 2026, descrito como uma melhoria no tratamento de URLs no middleware e nos cabeçalhos, acrescentou a functions/_middleware.ts uma lista de parâmetros considerados de conteúdo duplicado. A função hasDuplicateContentQuery verificava se o endereço continha algum deles. Se sim, filteredQueryString construía a query string sem esses parâmetros e o middleware devolvia 301 para o resultado.
Na lista estavam parâmetros que criam mesmo variantes desnecessárias, como lang, amp, nonamp e s. Mas também estavam utm_source, utm_medium, utm_campaign, utm_content, utm_term, gclid, fbclid e msclkid. O objetivo parecia razoável: um endereço por página. O resultado foi que um link /pt-pt/?utm_source=newsletter terminava em /pt-pt/ antes de qualquer código no navegador ver a palavra “newsletter”.
O middleware das Pages Functions corre antes do resto do encaminhamento, em cada pedido. É por isso um sítio cómodo para normalizar endereços, e igualmente cómodo para um erro que toca em todas as visitas vindas de campanhas.
Porque é que os campos ocultos UTM do formulário ficam vazios
O nosso formulário de contacto tem, desde 13 de julho de 2026, campos ocultos utm_source, utm_medium, utm_campaign e utm_term. Antes dessa data não registava a origem do lead de forma nenhuma. O JavaScript preenche os campos a partir de location.search quando a página carrega. Depois do redirecionamento, location.search estava vazio, e os campos também, em cada entrada vinda de um link de campanha entre 13 de julho e 10 de outubro. Ou seja, o formulário recebeu os campos novos já com o redirecionamento ativo, e nunca chegou a ver um valor de campanha até à correção.
As consequências repartem-se por três sítios:
- Formulário. De 13 de julho a 10 de outubro, o lead chegava à caixa de correio sem informação de origem. Uma entrada vinda de um link numa newsletter e uma entrada sem qualquer marcação pareciam iguais.
- Analítica. De 7 de março a 10 de outubro, a ferramenta de analítica não recebia os parâmetros de campanha, por isso o tráfego de links marcados com UTM ia parar a canais genéricos ou a tráfego direto.
- Google Ads. No mesmo período, a etiquetagem automática acrescentava o
gclide o nosso 301 cortava-o. Semgclidna página de destino, o Google Ads não tem como ligar o clique a uma conversão posterior.
Nenhum destes sintomas parece um erro de redirecionamento. Parece uma campanha que não funciona, ou um canal que não traz nada.
Transform Rule do Cloudflare para remover UTM: porque perde o gclid
O mesmo sintoma, por outro caminho, foi descrito pela SHIFT64. O artigo sobre remover parâmetros de rastreio no Cloudflare saiu a 31 de agosto de 2026 e recebeu uma correção a 7 de outubro de 2026. A versão original recomendava uma Transform Rule que reescrevia o endereço na edge (sem redirecionamento), para que a cache visse um único endereço por página. O navegador mantinha o endereço completo, por isso a atribuição devia sobreviver.
Só sobrevivia quando o servidor respondia 200. Quando o servidor respondia com um redirecionamento (do domínio sem www para www, por falta de barra final, pelo redirecionamento canónico do WordPress), construía o novo endereço a partir do que recebia, ou seja, do endereço já cortado. O navegador seguia o redirecionamento e gclid, fbclid e gad_source desapareciam da barra de endereço.
A correção traz mais dois pormenores. O primeiro, nas palavras do autor:
“Os parâmetros de rastreio não adjacentes eram removidos apenas em parte, porque o
regex_replace()do Cloudflare substitui apenas a primeira correspondência.”Mateusz Zadorożny, SHIFT64, Strip UTM Parameters at Cloudflare Without Losing Attribution (Corrected), correção de 7 de outubro de 2026, tradução própria
O segundo: o endereço ?fbclid=x&color=red chegava ao servidor como ?&color=red, e o WordPress respondia com um 301. Segundo a SHIFT64, numa loja com Google Ads o erro apareceu nos registos como 21 entradas pagas em cerca de três semanas, além das entradas no host não canónico, que os registos não permitem contar. A regra foi substituída por um Worker que volta a acrescentar os parâmetros removidos aos redirecionamentos dentro do mesmo site. A SHIFT64 acrescenta que, se o plugin Super Page Cache tiver criado uma regra marcada [DO NOT EDIT] com a mesma expressão regular, convém desligar nele a opção de remover parâmetros de rastreio. Não verificámos o plugin nós próprios.
As datas são estas: correção da SHIFT64 a 7 de outubro, a nossa correção a 10 de outubro. A diferença está no mecanismo. A SHIFT64 perdeu os parâmetros num redirecionamento do servidor que surgiu depois de uma reescrita na edge. Nós perdemo-los num redirecionamento de deduplicação nosso, deliberado.
Porque é que o tráfego de chatbots de IA aparece como direto no GA4
A 1 de outubro de 2026, Roger Montti escreveu no Search Engine Journal que o Gemini parece acrescentar parâmetros UTM a alguns links para sites. A origem é o relato de um utilizador do Reddit, que descreveu o comportamento como muito recente, de cerca de 24 horas. A Google não o documentou. Não se sabe que parâmetros nem que valores aparecem, em que links, nem em que condições. John Mueller respondeu apenas que encaminharia o assunto à equipa, o que não é uma confirmação. O mesmo artigo lembra que o tráfego de chatbots de IA pode aparecer no GA4 como “direto”, porque “direto” é a categoria que sobra quando não há referrer nem dados UTM.
No mesmo dia, Ray Grieselhuber publicou na DemandSphere números sobre pesquisas de marca. A percentagem de palavras-chave de marca acompanhadas que devolviam um AI Overview passou de 26,12% a 1 de setembro para 82,06% a 29 de setembro, o último ponto de dados, com um pico de 90,48% a 27 de setembro. O método tem limites claros: os dados vêm da plataforma da própria empresa (DemandMetrics), juntam todos os mercados e dispositivos, a dimensão da amostra não foi publicada e o AI Overview conta mesmo quando a marca não é citada nele. A Google não anunciou nenhuma alteração.
A ligação ao nosso caso é inferência nossa, nenhuma das fontes a faz. Se os assistentes de IA passarem a marcar os links que dão, essas marcas chegam na mesma query string que o nosso middleware cortava. Um redirecionamento que remove utm_* remove-as também, e a visita volta a cair em tráfego direto. E se os cliques de marca passam cada vez mais por um AI Overview antes de chegar ao site, os cliques que ainda chegam marcados valem mais. Não temos indícios de tráfego do Gemini em wppoland.com nem de visitas desse tipo perdidas. A nossa própria medição de eventos também não recolhe o referrer: a origem do tráfego de pesquisa lemo-la no Google Search Console.
Parâmetros UTM e conteúdo duplicado no Google
Não, se a página declarar um canonical limpo, e por isso o redirecionamento não evitava nada. Cada página de wppoland.com declara um canonical sem parâmetros desde o início, por isso o Google já sabia qual era o endereço certo. De 7 de março a 11 de abril de 2026 essa era a única proteção. A 12 de abril, o ficheiro public/_headers passou também a enviar o cabeçalho:
No-Vary-Search: key-order, params=("utm_source" "utm_medium" "utm_campaign" "utm_content" "utm_term" "ref" "fbclid" "gclid" "msclkid")O No-Vary-Search diz ao navegador que os parâmetros listados não alteram a resposta, por isso a versão com eles e a versão sem eles podem usar a mesma entrada de cache. A partir de 12 de abril tínhamos portanto duas camadas que resolviam a duplicação sem tocar no endereço da barra do navegador, e antes disso uma, que já bastava. O redirecionamento nunca acrescentou proteção e tirou sempre a atribuição.
A correção de 10 de outubro de 2026 deixa passar os parâmetros de rastreio sem redirecionamento. lang, amp, nonamp e s continuam a receber 301, porque são esses que criam variantes reais. No código ficou este comentário:
// Tracking params (utm_*, gclid, fbclid, msclkid) pass through: the page
// canonical is already clean, and stripping them killed lead attribution.Que regras removem parâmetros UTM além do Cloudflare Pages
A conclusão não se limita ao Cloudflare Pages. Qualquer regra que “arruma” a query string e responde com um redirecionamento tem o mesmo perfil de risco:
- middleware em Pages Functions ou num Worker,
- regras do Cloudflare: Transform Rules, Redirect Rules, Page Rules,
rewriteereturn 301na configuração do nginx,- plugins de redirecionamento no WordPress que normalizam endereços ou removem parâmetros “desnecessários”,
- os redirecionamentos canónicos do próprio WordPress, quando algo antes já cortou o endereço.
A regra que adotámos: a deduplicação de parâmetros deixa os parâmetros de rastreio em paz. A duplicação de conteúdo trata-se com o canonical, e a cache trata-se com o No-Vary-Search ou com uma chave de cache sem esses parâmetros. Um redirecionamento não faz falta para isso. E o segundo conselho, que a SHIFT64 tirou da própria correção: teste os redirecionamentos, não só as páginas.
Se o seu site está atrás do Cloudflare e quer que alguém reveja as regras da edge com isto em mente, isso faz parte do nosso serviço Cloudflare edge.
Como analisar dados de atribuição de leads com um período em falta
Os dados de campanha na analítica entre 7 de março e 10 de outubro de 2026 estão incompletos, e os do formulário entre 13 de julho e 10 de outubro também. Isso não significa que estejam todos errados: as entradas sem parâmetros de campanha, por exemplo vindas dos resultados de pesquisa, não passavam por este redirecionamento. Significa que tudo o que veio de links marcados foi atribuído a outro sítio, ou a nenhum.
Na prática:
- não comparamos o desempenho dos canais que dependem de UTM neste período com o período a seguir a 10 de outubro,
- não desligamos campanhas com base em atribuição zero destes meses,
- os primeiros dados fiáveis sobre a origem dos leads no formulário começam a 10 de outubro de 2026, porque antes de 13 de julho o formulário não a registava de todo.
A camada de encaminhamento deste site já tinha estragado algo em silêncio antes, enquanto o resto parecia saudável: o Cloudflare Pages descartava regras do ficheiro _redirects acima de 100KB. O contexto mais amplo desta arquitetura está no balanço de doze meses a migrar de WordPress para Astro. As regras para um canonical limpo em links com parâmetros estão no guia técnico de SEO para afiliados.
