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.com que algunos servicios agregan a los links salientes para llevar registro interno. Morgan considera esto innecesario porque el header HTTP Referer ya cumple esa función cuando el cliente decide enviarlo.- UTM parameters: utm_source, utm_medium, utm_campaign y 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: msclkid para Bing Ads.- YouTube: si para 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 Referer ya 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=xxx al 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.