Durante siete meses, quien llegaba a wppoland.com desde un enlace de campaña era redirigido con un 301 a la misma URL sin los parámetros de seguimiento. Del 7 de marzo de 2026 al 10 de octubre de 2026 nuestro middleware en Cloudflare Pages trataba utm_*, gclid, fbclid y msclkid como parámetros de contenido duplicado y los recortaba antes de que el navegador ejecutara un solo script. La analítica no veía las campañas y Google Ads perdía el gclid durante todo ese tiempo. El formulario de contacto empezó a guardar el origen del lead el 13 de julio, y desde ese día hasta la corrección recibió esos campos vacíos en cada entrada de campaña.
No sabemos a cuántos leads afectó. No tenemos una medición que permita calcularlo, así que no damos ninguna cifra. Sí sabemos que los datos de campaña de ese periodo están incompletos y no sirven para sacar conclusiones sobre canales.
Por qué desaparecen los parámetros UTM después de una redirección
Una redirección 301 es una respuesta del servidor con una cabecera Location. El navegador no le añade nada por su cuenta: va exactamente a la dirección que construyó el servidor. Si la regla que construye esa dirección omite la query string o una parte de ella, los parámetros de campaña dejan de existir antes de que cargue la página.
Esto importa porque casi toda la atribución ocurre en el navegador. El script de analítica lee utm_source de location.href. Un formulario que guarda el origen del lead en campos ocultos los rellena con JavaScript a partir de location.search. El etiquetado automático de Google Ads añade gclid a la URL de destino y espera que ese identificador llegue a la página. Cada uno de estos mecanismos ve solo la dirección en la que el navegador acabó.
De ahí una regla sencilla: cada redirección en el camino entre el anuncio y la página es un punto donde la atribución puede perderse. No solo las redirecciones escritas a mano. También las de normalización del host, de la barra final, de slugs antiguos y de deduplicación de parámetros.
Cómo comprobar si una redirección elimina gclid
La prueba ocupa una línea. Un valor único del parámetro evita la caché, así que la respuesta sale de la lógica actual:
curl -sI "https://wppoland.com/pl/?utm_source=t$(date +%s)"Tras la corrección devuelve HTTP/2 200, y lo mismo ocurre con ?gclid=. Como control, un parámetro que sí debe seguir redirigiéndose:
curl -sI "https://wppoland.com/pl/?lang=en"Este devuelve 301. Volvimos a comprobar los tres resultados en producción el 11 de octubre de 2026.
En tu propio sitio cambia el dominio y el parámetro. Comprueba utm_source, gclid, fbclid y msclkid por separado, porque las reglas a menudo los tratan de forma distinta. Si recibes un 301 o un 302, lee la cabecera Location: el parámetro tiene que estar ahí. Después repite la prueba con URL que redirigen por otro motivo: sin barra final, en el otro host (con www y sin él), con un slug antiguo. Una página que responde 200 puede pasar la prueba mientras la redirección de al lado pierde los parámetros igualmente.
Cómo el middleware de Cloudflare Pages eliminaba gclid y utm_source
Un commit del 7 de marzo de 2026, descrito como una mejora del manejo de URL en el middleware y las cabeceras, añadió a functions/_middleware.ts una lista de parámetros considerados de contenido duplicado. La función hasDuplicateContentQuery comprobaba si la URL contenía alguno. Si era así, filteredQueryString construía la query string sin esos parámetros y el middleware devolvía un 301 al resultado.
En la lista había parámetros que de verdad generan variantes innecesarias, como lang, amp, nonamp y s. También estaban utm_source, utm_medium, utm_campaign, utm_content, utm_term, gclid, fbclid y msclkid. El objetivo sonaba razonable: una URL por página. El resultado fue que el enlace /es/?utm_source=newsletter terminaba en /es/ antes de que ningún código del navegador viera la palabra “newsletter”.
El middleware de Pages Functions se ejecuta antes que el resto del enrutado, en cada petición. Eso lo convierte en un lugar cómodo para normalizar URL, y en un lugar igual de cómodo para un error que toca cada visita procedente de una campaña.
Por qué los campos ocultos UTM del formulario llegan vacíos
Nuestro formulario de contacto tiene desde el 13 de julio de 2026 los campos ocultos utm_source, utm_medium, utm_campaign y utm_term. Antes de esa fecha no registraba el origen del lead de ninguna forma, así que de marzo a julio el formulario no tenía nada que perder. JavaScript rellena los campos desde location.search al cargar la página. Después de la redirección location.search estaba vacío, y los campos también, en cada entrada desde un enlace de campaña entre el 13 de julio y el 10 de octubre.
Las consecuencias se reparten en tres sitios:
- Formulario. Desde el 13 de julio el lead llegaba al buzón sin información sobre su origen. Una entrada desde un enlace del boletín y una entrada sin ninguna etiqueta parecían idénticas.
- Analítica. Durante los siete meses la herramienta de analítica no recibió los parámetros de campaña, así que el tráfico de enlaces etiquetados con UTM acababa en canales genéricos o como tráfico directo.
- Google Ads. El etiquetado automático añade
gclidy nuestro 301 lo recortaba. Singcliden la página de destino, Google Ads no tiene con qué vincular el clic a una conversión posterior.
Ninguno de estos síntomas parece un error de redirección. Parece una campaña que no funciona, o un canal que no aporta nada.
Redirección 301 de parámetros UTM y contenido duplicado
La redirección no protegía de nada. Cada página de wppoland.com declara un canonical sin parámetros, y así fue desde el primer día del error, de modo que Google ya sabía cuál era la URL correcta. Del 7 de marzo al 11 de abril esa fue la única capa. El 12 de abril de 2026 se sumó una segunda: el archivo public/_headers empezó a enviar esta cabecera:
No-Vary-Search: key-order, params=("utm_source" "utm_medium" "utm_campaign" "utm_content" "utm_term" "ref" "fbclid" "gclid" "msclkid")No-Vary-Search le indica al navegador que esos parámetros no cambian la respuesta, de modo que la versión con ellos y sin ellos puede usar la misma entrada de caché. Primero el canonical solo, después el canonical junto con No-Vary-Search: en ambos tramos el contenido duplicado estaba resuelto sin tocar la URL de la barra de direcciones. La redirección no añadía protección y se llevaba la atribución.
La corrección del 10 de octubre de 2026 deja pasar los parámetros de seguimiento sin redirección. lang, amp, nonamp y s siguen recibiendo un 301, porque son los que crean variantes reales. En el código quedó este comentario:
// Tracking params (utm_*, gclid, fbclid, msclkid) pass through: the page
// canonical is already clean, and stripping them killed lead attribution.Cómo eliminar parámetros UTM en Cloudflare sin perder gclid
SHIFT64 describió el mismo síntoma por otro camino. Su artículo sobre eliminar parámetros de seguimiento en Cloudflare se publicó el 31 de agosto de 2026 y recibió una corrección el 7 de octubre de 2026. La versión original recomendaba una Transform Rule que reescribía la URL en el edge (sin redirección), para que la caché viera una sola URL por página. El navegador conservaba la dirección completa, así que la atribución debía sobrevivir.
Solo sobrevivía cuando el servidor respondía con un 200. Cuando el servidor respondía con una redirección (del dominio sin www al de www, por la barra final que faltaba, por la redirección canónica de WordPress), construía la nueva dirección a partir de lo que había recibido, es decir, de la URL ya recortada. El navegador seguía la redirección y gclid, fbclid y gad_source desaparecían de la barra de direcciones. El autor lo reconoce sin rodeos:
“Llegué a esa afirmación razonando, en lugar de comprobarla con redirecciones reales.”
Mateusz Zadorożny, SHIFT64, Strip UTM Parameters at Cloudflare Without Losing Attribution (Corrected), corrección del 7 de octubre de 2026, traducción propia
La corrección incluye dos detalles más. regex_replace() en Cloudflare sustituye solo la primera coincidencia, así que los parámetros de seguimiento no contiguos se eliminaban solo en parte. Y la dirección ?fbclid=x&color=red llegaba al servidor como ?&color=red, a lo que WordPress respondía con un 301. Según SHIFT64, en una tienda con Google Ads el error se vio en los registros como 21 entradas de pago en unas tres semanas, sin contar las entradas por un host no canónico, que esos registros no permiten contar. La regla se sustituyó por un Worker que vuelve a añadir los parámetros eliminados a las redirecciones dentro del mismo sitio. SHIFT64 también aconseja, si el plugin Super Page Cache creó una regla [DO NOT EDIT] con la misma expresión regular, desactivar en el plugin la opción de eliminar parámetros de seguimiento. Ese plugin no lo hemos comprobado nosotros.
Las fechas son estas: corrección de SHIFT64 el 7 de octubre, nuestra corrección el 10 de octubre. La diferencia está en el mecanismo. SHIFT64 perdió los parámetros por una redirección del servidor que llegó después de reescribir la URL en el edge. Nosotros los perdimos por una redirección de deduplicación propia y deliberada.
Por qué el tráfico de chatbots de IA aparece como directo en GA4
El 1 de octubre de 2026 Roger Montti contó en Search Engine Journal que Gemini parece añadir parámetros UTM a algunos enlaces hacia sitios web. La fuente es un usuario de Reddit que lo había notado apenas un día antes. Google no lo ha documentado, y no se sabe qué parámetros ni qué valores usa, en qué enlaces aparecen ni en qué condiciones. John Mueller solo respondió que pasaría el aviso al equipo, lo que no es una confirmación. El mismo artículo recuerda por qué importa: el tráfico desde chatbots de IA puede aparecer en GA4 como “direct”, el canal al que va una visita cuando no trae referrer ni datos UTM.
El mismo día DemandSphere (Ray Grieselhuber) publicó la cuota de palabras clave de marca que devuelven un AI Overview en su seguimiento: 26,12 % el 1 de septiembre, 82,06 % el 29 de septiembre (último dato) y un máximo de 90,48 % el 27 de septiembre. Los límites del método pesan: los datos salen de su propia plataforma (DemandMetrics), mezclan todos los mercados y dispositivos, el tamaño de la muestra no se publica y el AI Overview cuenta tanto si cita la marca como si no. Google no anunció ningún cambio.
Lo que sigue es nuestra inferencia, no una medición. Si los asistentes de IA empiezan a etiquetar sus enlaces, esas etiquetas llegan en la misma query string que nuestro middleware recortaba. Una redirección que elimina utm_* las elimina también, y la visita acaba en “direct”. Y si cada vez más clics de marca pasan antes por un AI Overview, los clics que todavía llegan etiquetados valen más. No tenemos ningún dato de que tráfico de Gemini llegara a wppoland.com ni de que lo perdiéramos. En nuestro caso hay un motivo más para cuidar la query string: nuestro propio seguimiento de eventos no recoge el referrer, y la atribución de búsqueda la sacamos de Google Search Console.
Qué reglas de redirección eliminan los parámetros UTM
La conclusión no se limita a Cloudflare Pages. Cualquier regla que “ordena” la query string y responde con una redirección tiene el mismo perfil de riesgo:
- middleware en Pages Functions o en un Worker,
- reglas de Cloudflare: Transform Rules, Redirect Rules, Page Rules,
rewriteyreturn 301en la configuración de nginx,- plugins de redirección de WordPress que normalizan URL o eliminan parámetros “sobrantes”,
- las redirecciones canónicas del propio WordPress, cuando algo recortó la URL antes.
La regla que adoptamos: la deduplicación de parámetros deja en paz los parámetros de seguimiento. Del contenido duplicado se encarga el canonical, y de la caché se encarga No-Vary-Search o una clave de caché sin esos parámetros. Para eso no hace falta una redirección. Y el segundo consejo, el que SHIFT64 sacó de su propia corrección: prueba las redirecciones, no solo las páginas.
Si tu sitio está detrás de Cloudflare y quieres que alguien revise las reglas del edge con este criterio, eso forma parte de nuestro servicio de Cloudflare edge.
Qué hacer con los datos de origen de leads de ese periodo
Los datos de campaña de la analítica entre el 7 de marzo y el 10 de octubre de 2026 están incompletos, y los del formulario de contacto entre el 13 de julio y el 10 de octubre. Antes del 13 de julio el formulario no guardaba ningún origen, así que esa parte no se puede reconstruir desde él. Eso no significa que todos los datos sean erróneos: las entradas sin parámetros de campaña, por ejemplo desde los resultados de búsqueda, no pasaban por esa redirección. Significa que todo lo que llegó desde enlaces etiquetados se atribuyó a otro sitio o a ninguno.
En la práctica:
- no comparamos el rendimiento de los canales que dependen de UTM en ese periodo con el periodo posterior al 10 de octubre,
- no desactivamos campañas basándonos en una atribución nula de esos meses,
- los primeros datos fiables de origen de leads empiezan el 10 de octubre de 2026.
La capa de enrutado de este sitio ya había roto algo en silencio antes, mientras todo lo demás parecía sano: Cloudflare Pages descartaba las reglas de _redirects por encima de 100KB. El contexto más amplio de esta arquitectura está en el resumen de doce meses migrando de WordPress a Astro. Las reglas para un canonical limpio con enlaces que llevan parámetros están en la guía técnica de SEO para afiliados.
