Eliminar parámetros de seguimiento con Cloudflare Workers y Transform Rules

Por qué los parámetros de seguimiento destruyen tu tasa de aciertos de caché

Los parámetros de seguimiento como utm_source, gclid y fbclid ayudan a los especialistas en marketing a medir el rendimiento de las campañas. Para las Core Web Vitals son una pesadilla porque rompen el almacenamiento en caché. Cada URL única crea una entrada de caché separada. Una sola página compartida en Facebook obtiene un fbclid único por cada clic, lo que significa que cada visitante de Facebook obtiene un fallo de caché y un Time to First Byte lento.

Cloudflare te ofrece tres formas de eliminar estos parámetros en el edge antes de que contaminen tu caché: Transform Rules (sin código), Workers (control total) y personalización de Cache Key (Enterprise). Cubriré las tres.

Última revisión por Arjen Karel en marzo de 2026

El problema del almacenamiento en caché con los parámetros de seguimiento

Los sistemas de almacenamiento en caché utilizan la URL completa como clave de caché. Si una URL incluye ?utm_source=google o ?fbclid=abc123, la caché la trata como una página diferente, aunque el contenido sea idéntico. Eso es un fallo de caché. El servidor reconstruye una página que ya tiene en caché, solo porque la URL tiene un valor de cadena de consulta diferente.

La escala de este problema es mayor de lo que la mayoría de la gente cree. Hay 129 parámetros de seguimiento conocidos en todo el ecosistema de marketing. El parámetro fbclid es el más destructivo porque Facebook lo añade a cada clic en un enlace saliente, no solo a los anuncios de pago. Cada publicación orgánica compartida, cada enlace en un comentario, cada publicación que enlaza a tu sitio obtiene un valor fbclid único.

Según el Web Almanac de 2025, solo el 44% de los orígenes móviles tienen un buen TTFB. Cloudflare informó que corregir el comportamiento de la caché en cadenas de consulta mejoró las tasas de aciertos de caché en un 3% de media y redujo los bytes de origen en un 5%. Eso se traduce directamente en un Largest Contentful Paint más rápido para tus visitantes.

No todos los parámetros de consulta son basura de seguimiento. Los parámetros como ?q=portátiles o ?color=azul cambian el contenido de la página. El objetivo es eliminar los parámetros que no afectan al contenido mientras se mantienen los que sí lo hacen.

¿Qué parámetros de seguimiento deberías eliminar?

Aquí tienes los parámetros de seguimiento más comunes agrupados por plataforma. Estos crean URL únicas y no cacheables sin cambiar el contenido de la página:

Esta no es la lista completa. El registro de parámetros de consulta de seguimiento documenta los 129 parámetros conocidos. Para la mayoría de los sitios, cubrir los parámetros de Google, Meta y Microsoft soluciona el 95% del problema.

Opción 1: Transform Rules (sin necesidad de código)

Cloudflare tiene una función integrada llamada remove_query_args() que elimina parámetros de consulta específicos de la URL antes de que llegue a la caché. Esto se ejecuta como una Transform Rule, no requiere código y está disponible en todos los planes, incluido el nivel gratuito.

Para configurarlo:

1. En tu panel de Cloudflare, ve a Rules, luego a Transform Rules y después a URL Rewrite
2. Crea una nueva regla
3. Configura el filtro para que coincida con tu dominio, por ejemplo (http.host eq "example.com")
4. En Query, selecciona Rewrite to y luego Dynamic
5. Introduce la expresión:
   remove_query_args(http.request.uri.query, "utm_source", "utm_medium", "utm_campaign", "utm_term", "utm_content", "utm_id", "gclid", "gclsrc", "wbraid", "gbraid", "dclid", "gad_source", "fbclid", "msclkid", "ttclid", "twclid", "li_fat_id", "epik", "srsltid", "_ga", "_gl")
6. En Path, selecciona Preserve

Eso es todo. Sin Worker, sin despliegue de código. El plan gratuito permite 10 Transform Rules, el Pro permite 25. Para la mayoría de los sitios, esta es la mejor opción.

Opción 2: Cloudflare Workers

Cloudflare tiene opciones listas para usar para ignorar las cadenas de consulta, pero sus configuraciones conservadoras no son suficientes para sacar el máximo provecho de tu plan de Cloudflare. Si necesitas más control del que ofrecen las Transform Rules (por ejemplo, coincidencia de expresiones regulares, lógica condicional o registro), un Cloudflare Worker te da total flexibilidad.

Los Workers interceptan las solicitudes en el edge y ejecutan tu código antes de que la solicitud llegue a la caché o al origen. Cloudflare carga los Workers durante el handshake TLS, por lo que la sobrecarga efectiva es de menos de 1 milisegundo.

El código

A continuación se muestra el script completo del Worker utilizando la sintaxis actual de módulos ES:

export default {
  async fetch(request) {
    const url = new URL(request.url)

    const trackingParams = /^(utm_|gad_|gclid|gclsrc|wbraid|gbraid|dclid|fbclid|fb_action_|srsltid|msclkid|ttclid|twclid|li_fat_id|epik|igshid|_ga$|_gl$|mc_[ce]id|_hs[em])/

    // Collect matching keys first (do not delete during iteration)
    const keysToDelete = [...url.searchParams.keys()].filter(
      key => trackingParams.test(key)
    )

    keysToDelete.forEach(key => url.searchParams.delete(key))

    return fetch(url.toString(), request)
  }
}

El Worker analiza la URL, prueba cada parámetro de consulta con una expresión regular y elimina las coincidencias. La URL limpia va luego a la caché y al origen. Aquí importan dos detalles: el código recopila las claves en un array antes de eliminarlas, porque eliminar durante la iteración de URLSearchParams puede omitir entradas (este es un problema conocido de la especificación con los iteradores en vivo). Y el script utiliza el formato de módulos ES (export default) porque Cloudflare ha dejado de usar la sintaxis antigua addEventListener.

Despliegue

1. Inicia sesión en Cloudflare. Entra en tu panel de Cloudflare.
2. Crea un Worker. No navegues a tu sitio todavía. Ve a la sección de Workers y crea un nuevo Worker.
   
3. Nombra el worker y despliégalo. Este paso puede parecer un poco contradictorio, pero no te preocupes. Simplemente nombra tu worker vacío 'hello world' y haz clic en deploy.
   
4. Edita tu worker. En la página siguiente, haz clic en Edit Code.
   
5. Pega el script. Copia y pega el script anterior en el editor. Luego haz clic en deploy.
   
6. Vincula el Worker a una ruta. Ahora vuelve y navega a tu sitio en Cloudflare. Haz clic en worker routes y luego en 'Add Route'. Selecciona el worker recién creado y aplícalo a tu sitio.
   

Personalización

Puedes modificar la expresión regular para incluir o excluir parámetros específicos. Si quieres conservar ciertos parámetros utm_ para el procesamiento del lado del servidor, elimínalos de la expresión regular. Si utilizas una plataforma de marketing no cubierta por la expresión regular predeterminada, añade sus parámetros.

Opción 3: Personalización de Cache Key (Enterprise)

Si estás en un plan Enterprise de Cloudflare, puedes configurar claves de caché personalizadas para excluir parámetros de consulta específicos sin eliminarlos de la URL en absoluto. La caché simplemente los ignora al calcular la clave. Este es el enfoque más limpio porque la URL se mantiene sin cambios, pero requiere Enterprise.

Para planes no Enterprise, el enfoque de Transform Rule o Worker logra el mismo beneficio en la caché.

¿Qué enfoque deberías usar?

Para la mayoría de los sitios, empieza con Transform Rules. Si alcanzas el límite de reglas o necesitas más flexibilidad, pásate a Workers.

Si usas WordPress con Cloudflare APO, puede que no necesites nada de esto. APO mantiene una lista de permitidos de más de 25 parámetros de marketing que ignora al calcular las claves de caché. Comprueba si tus parámetros específicos están cubiertos antes de añadir un Worker o Transform Rule.

¿Eliminar parámetros rompe las analíticas?

No. La eliminación ocurre en el edge, entre la CDN y tu servidor de origen. La URL del navegador sigue conteniendo los parámetros de seguimiento originales. Google Analytics, el seguimiento de conversiones de Google Ads y el píxel de Facebook leen desde document.location en el lado del cliente, que todavía tiene la URL completa con todos los parámetros intactos.

El único escenario donde esto podría causar problemas es si tu código del lado del servidor lee los parámetros de seguimiento de la URL (por ejemplo, una implementación de analíticas del lado del servidor). En ese caso, excluye esos parámetros de la eliminación o captúralos en una cabecera de solicitud antes de que el Worker los elimine.

Para una visión más amplia de cómo los scripts de seguimiento y analíticas afectan al rendimiento más allá del almacenamiento en caché, consulta The Case for Limiting Analytics and Tracking Scripts.

Cómo averiguar qué parámetros de URL eliminar

Averiguar qué parámetros de URL eliminar es fácil si utilizas la herramienta adecuada. Las herramientas de Real User Monitoring como CoreDash monitorizan tu sitio las 24 horas del día, los 7 días de la semana, y registran todas las cadenas de consulta junto con su impacto en el rendimiento. En CoreDash, navega hasta Largest Contentful Paint y visualiza los resultados por cadena de consulta.

En los sitios monitorizados por CoreDash, las páginas con los parámetros de seguimiento eliminados muestran entre un 8% y un 15% mejores tasas de aciertos de caché. Para los visitantes que de otro modo tendrían un fallo de caché, eso se traduce en un TTFB de 200 a 500 ms más rápido.

Si usas Cloudflare y la subparte TTFB de la duración de caché es alta, la contaminación por parámetros de seguimiento es una de las primeras cosas que debes comprobar. Combina la eliminación de parámetros con la configuración de Cloudflare adecuada y verás una mejora medible en tus datos de campo.