El desarrollador Chris Morgan publicó el 8 de mayo de 2026 una entrada inusual en su blog: a partir de ese momento, su sitio personal chrismorgan.info rechaza cualquier URL que incluya un query string no autorizado. La medida apunta directamente contra los parámetros de tracking como utm_source, ref y similares que muchos servicios agregan automáticamente cuando comparten enlaces.
No es un experimento académico ni un proyecto open source con seguidores. Es la decisión personal de un programador hartado de que terceros manipulen sus propias URLs sin permiso. Pero la postura abre un debate técnico relevante sobre quién controla los identificadores de recursos en la web.
TL;DR
- Chris Morgan baneó los query strings no autorizados en chrismorgan.info el 8 de mayo de 2026.- Las URLs con utm_source, ref y similares ahora retornan error en su sitio.- El bloqueo se implementa con Caddyfile usando un matcher sobre la directiva query.- Los UTM parameters fueron creados por Urchin (luego Google Analytics) en 2005.- Su argumento: los UTM son herramienta del dueño del sitio, no de quienes linkean al sitio.- El header Referer ya provee información de origen sin modificar las URLs.- Firefox, Safari y Brave ya quitan UTM en algunas funciones de privacidad.
¿Quién es Chris Morgan y qué baneó exactamente?
Chris Morgan es un desarrollador conocido en la comunidad open source por sus aportes a Rust y a infraestructura web. Mantiene un blog técnico en chrismorgan.info, donde escribe sobre temas que oscilan entre minutiae de protocolos HTTP y reflexiones sobre el ecosistema web actual.
El 8 de mayo publicó la entrada titulada I've banned query strings, donde explica una decisión técnica radical sobre su propio sitio: ningún query string no explícitamente autorizado podrá pasar. Si alguien comparte un link a su blog con cualquier parámetro adicional, el servidor lo rechaza.
El detonante fueron dos prácticas comunes:
-
Trackers de referencia: parámetros como
?ref=example.comque algunos servicios agregan a los links salientes para llevar registro interno. Morgan considera esto innecesario porque el header HTTPRefererya cumple esa función cuando el cliente decide enviarlo.- UTM parameters:utm_source,utm_medium,utm_campaigny compañía. Morgan argumenta que estos campos son una convención para que el dueño del sitio identifique sus propias campañas de marketing, no para que terceros los inyecten en links ajenos.
💭 Clave: La distinción técnica importa. Los UTM son útiles cuando el dueño del sitio los agrega a sus propios links salientes (un email newsletter linkeando a su propio post). Cuando Twitter o LinkedIn los agregan a links que apuntan a tu contenido, están usando tu URL para rastrear su propio tráfico.
La historia detrás de los UTM parameters
Los UTM parameters tienen origen en una empresa llamada Urchin Software Corporation, fundada en San Diego en 1995. Urchin desarrollaba un sistema de analítica web que se llamaba, justamente, Urchin Tracking Module — de ahí el prefijo utm_. En 2005 Google compró Urchin y rebautizó el producto como Google Analytics. Los parámetros sobrevivieron al cambio de marca y se convirtieron en estándar de facto.
El esquema era simple: cuando una organización lanzaba una campaña de email marketing o publicidad, agregaba parámetros UTM a los links de cada canal. Al recibir el clic, Analytics leía la URL y atribuía la visita a la campaña correcta. Era una convención voluntaria, no un protocolo, y eso tuvo consecuencias.
Con el tiempo, el patrón se generalizó tanto que muchas plataformas comenzaron a inyectar parámetros propios automáticamente:
-
Facebook:
fbclid, agregado a cualquier link salido de Facebook.- Google Ads:gclid, similar para Google Ads.- Microsoft:msclkidpara Bing Ads.- YouTube:sipara tracking de sesión.- HubSpot, Mailchimp, Substack: parámetros propios en cada email.
El problema con esto es que la URL deja de ser un identificador estable del recurso. La misma página tiene cientos de URLs distintas según de dónde llegue el visitante. Eso rompe caches, ensucia el historial del navegador y hace que los usuarios compartan URLs largas e ilegibles cuando solo querían pasar un link.
Una URL típica con tracking puede multiplicar su longitud cinco veces.
El argumento técnico de Morgan
El planteamiento de Morgan se resume en una frase: are my URLs, leave them alone — son mis URLs, déjenlas en paz. La idea es que quien publica un sitio define cómo se identifican sus recursos. Cuando un cliente HTTP agrega parámetros que el sitio no espera ni usa, está modificando un identificador ajeno.
Hay tres puntos centrales en su argumento:
-
El header
Refererya existe. Si un sitio quiere saber de dónde vienen los visitantes, el navegador envía esa información en el header. No hace falta modificar la URL. Y si el header no está, suele haber una razón legítima (Privacy mode, Referrer Policy, navegación entre HTTPS y HTTP) que merece respetarse.- Los UTM son del dueño. La convención original era para que el operador del sitio se midiera a sí mismo. Cuando Twitter agrega?t=xxxal link que apunta a tu blog, está colonizando un namespace que era tuyo.- Las URLs son frágiles cuando son públicas. Una URL con tracking se copia, se comparte, se indexa. Termina contaminando logs, caches y SEO. El daño se propaga.
Morgan menciona que su implementación inicial es un blanket ban: bloquea cualquier query string. Reconoce que en el futuro podría querer usar query strings legítimos (paginación o filtros) y entonces planea pasar a una whitelist de parámetros conocidos. Mientras tanto, el sitio simplemente no acepta nada después del ?.
Cómo implementar el bloqueo en tu servidor
La idea es replicable en cualquier servidor web moderno. Veamos las tres configuraciones más comunes en LATAM.
Caddy
Caddy es la opción que usa Morgan. Su configuración es notablemente concisa:
example.com {
@hasQuery {
query *
}
handle @hasQuery {
respond "Query strings not allowed" 400
}
root * /var/www/site
file_server
}
El matcher @hasQuery captura cualquier request con query string. El bloque handle responde con un 400 Bad Request. Si preferís quitar los parámetros silenciosamente y servir el contenido, podés redirigir:
example.com {
@hasQuery {
query *
}
redir @hasQuery {path} 301
root * /var/www/site
file_server
}
Nginx
En Nginx la lógica es similar, aunque el uso de if es desaconsejado para casos generales:
server {
listen 443 ssl;
server_name example.com;
if ($args) {
return 301 $scheme://$host$uri;
}
location / {
root /var/www/site;
}
}
La variable $args contiene el query string. Si está presente, redirigimos a la URL sin parámetros con un 301.
Apache (.htaccess)
RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteRule ^(.*)$ /$1? [R=301,L]
El signo de pregunta sin nada después en la regla de RewriteRule le indica a Apache que descarte el query string original. Funciona en Linux, macOS y Windows con Apache instalado de igual forma porque es config declarativa.
⚠️ Ojo: Antes de aplicar este bloqueo en producción, revisá tus propios formularios, sistemas de paginación y links internos. Si tu CMS o framework usa query strings (WordPress y muchos shops sí lo hacen), el bloqueo total romperá el sitio. Una whitelist es más segura que un blacklist.
Cómo se propaga el tracking via query strings
Para entender el costo agregado del problema, ayuda visualizar el ciclo:
flowchart LR
A["Email con utm_source"] --> B["Click del usuario"]
B --> C["Sitio destino"]
C --> D["Analytics registra UTM"]
C --> E["URL en historial"]
E --> F["Usuario copia y comparte"]
F --> G["Tracking se propaga"]
El loop nunca se cierra del todo: cada vez que alguien comparte un link contaminado, los parámetros viajan a contextos donde nadie pidió tracking. Un mensaje en WhatsApp, un foro técnico, una nota de blog que cita el link. El UTM, que era una herramienta de medición de campaña, termina como huella permanente del recorrido del usuario.
El tracking via UTM se propaga cada vez que un usuario comparte una URL contaminada.
¿Por qué importa esto para desarrolladores en LATAM?
El debate puede sonar abstracto, pero tiene consecuencias prácticas para quienes construyen producto desde la región:
- SEO local: Google puede indexar la misma página varias veces si recibe URLs distintas con parámetros. Para sitios con poca autoridad de dominio, eso fragmenta el ranking. Configurar canonical tags y bloquear queries no esperadas mejora SEO.- Costos de CDN: muchos CDNs cachean por URL completa. Si tu cache no normaliza los UTM, perdés hits porque cada visitante con un UTM distinto pega contra origen. En CloudFront, Cloudflare o BunnyCDN esto se nota en facturación.- Analytics propio: equipos que migran de Google Analytics a alternativas open source (Plausible, Umami, PostHog) tienen que decidir cómo manejar parámetros. Bloquear los no propios mantiene los reportes limpios.- Compliance con LGPD/Habeas Data: Brasil, Argentina, Colombia y México tienen marcos de protección de datos que exigen consentimiento para tracking. Aceptar UTM ajenos sin notificación al usuario puede ser un punto de auditoría.
El movimiento más amplio: navegadores limpiando URLs
Morgan no está solo. En los últimos años, varios navegadores y herramientas comenzaron a limpiar query strings de tracking de manera automática:
-
Firefox introdujo en 2021 una opción que strip parámetros conocidos al copiar links desde la barra de direcciones. La función está habilitada por defecto en modo Privado Estricto.- Safari implementó Privacy Click en macOS Monterey: al cliquear un link con tracking conocido, Safari lo despoja antes de hacer la request.- Brave tiene una función similar como parte de su Shields, removiendo
fbclid,gclid,msclkidy otros por defecto.- Vivaldi y LibreWolf incluyen comportamientos similares en su configuración por defecto.
Existen también extensiones especializadas como ClearURLs, que mantiene una base de datos colaborativa de parámetros conocidos de tracking y los elimina en tiempo real. Es la versión cliente del lado de la postura de Morgan.
💡 Tip: Si querés probar el efecto antes de aplicarlo a tu sitio, instalá ClearURLs en tu navegador y observá cómo desaparecen los parámetros UTM, fbclid y gclid de los links que abrís durante una semana. Vas a notar URLs notablemente más cortas y limpias en tu historial.
Lo interesante es que la postura de Morgan invierte la responsabilidad: en lugar de esperar que cada navegador del mundo limpie tracking, el sitio web lo rechaza directamente desde el servidor. Es una forma de defender el contrato de URL al nivel donde realmente pertenece.
¿Qué sigue después?
Es improbable que sitios comerciales grandes adopten un ban total — su modelo de negocio depende de medir campañas y atribuir conversiones. Pero la postura de Morgan tiene chance de extenderse en tres frentes:
- Blogs personales y sitios open source: la fricción para implementar el bloqueo es baja y no perjudica el flujo de usuarios reales. Ya hay reportes en Hacker News de otros desarrolladores adoptando configuraciones similares.- Estandarización vía W3C: la propuesta Privacy Sandbox de Google y los Working Groups de WHATWG están discutiendo formas de regular el tracking via query strings. La presión de browsers ya tuvo efecto sobre cookies de terceros; las URLs son el siguiente capítulo.- Sitios con énfasis en privacidad: redes como Mastodon, Pleroma o Pixelfed podrían adoptar bans similares como diferenciador frente a redes corporativas.
Mientras tanto, lo que Morgan logró con su entrada es reabrir un debate. Las URLs son uno de los pocos identificadores realmente estables del web. Cuando se las trata como un canvas para tracking de terceros, perdemos algo importante de la arquitectura original.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué son exactamente los UTM parameters?
Son parámetros de URL con prefijo utm_ (utm_source, utm_medium, utm_campaign, utm_term, utm_content) usados para identificar campañas de marketing en sistemas de analítica. Fueron creados por Urchin Software en 2005 y heredados por Google Analytics tras la adquisición.
¿Bloquear query strings rompe mi sitio web?
Depende de tu stack. WordPress, Drupal, Magento y muchos frameworks usan query strings legítimamente para paginación, búsqueda y filtros. Un ban total los rompería. Lo recomendable es una whitelist: permitir solo parámetros conocidos y rechazar el resto.
¿Es legal que terceros agreguen UTM a links que apuntan a mi sitio?
No hay ley específica que lo prohíba en la mayoría de jurisdicciones. Sin embargo, la GDPR europea, la LGPD brasileña y leyes de protección de datos en varios países LATAM regulan el tratamiento posterior si esos parámetros generan datos personales. La práctica es legal pero éticamente discutible.
¿Cómo afecta esto al SEO de mi sitio?
Las URLs con parámetros pueden fragmentar tu ranking en Google si el bot las trata como distintas. Configurar la etiqueta <link rel="canonical"> en cada página apuntando a la URL canónica sin parámetros es la solución estándar. Bloquear queries no esperadas refuerza esta limpieza.
¿Qué pasa con paginación y filtros que sí necesito?
La solución es una whitelist explícita. Permití ?page=, ?q=, ?filter= u otros que tu app realmente usa, y rechazá lo demás. En Caddy se hace combinando matchers; en Nginx con map directives.
¿Existen herramientas para limpiar UTM del lado del cliente?
Sí. ClearURLs es una extensión de Firefox y Chrome que mantiene una base colaborativa de parámetros de tracking conocidos. Brave, Firefox y Safari incluyen funciones similares por defecto en modo privacidad estricta.
Referencias
- I've banned query strings — Chris Morgan — el artículo original donde anuncia la decisión y muestra la implementación en Caddyfile.- Caddyfile matchers — Caddy docs — documentación oficial de los matchers de Caddy, incluyendo el matcher query.- HTTP Referer header — MDN — documentación del header HTTP que provee información de origen sin necesidad de modificar URLs.- UTM parameters — Wikipedia — historia y definición de los UTM parameters desde Urchin Software hasta Google Analytics.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.