Por qué quitar los parámetros de seguimiento antes de reenviar un enlace, y qué queda después

Una dirección copiada de WhatsApp, una consola de anuncios o una ficha de producto suele llevar, detrás del signo de interrogación, UTM, fbclid y gclid. No es adorno. Esos campos entran en la línea de petición HTTP: la siguiente persona, el anfitrión y el registro de acceso ven de qué canal y de qué clic vienes. Quitarlos solo prueba que esta cadena perdió una query de seguimiento conocida. Los píxeles, las cookies y las marcas en la ruta siguen ahí.

Quédate primero con esto: lo que quitas antes de reenviar es la query que escribe «de dónde hiciste clic» en la dirección. La comprobación no es «el enlace se acortó». Lee la lista de parámetros eliminados y confirma que el pathname y id= / q= siguen. Una URL limpia no es una visita privada, y no prueba que la landing no tenga un script de medición.

Responde a la intención de búsqueda en una frase

Hay que quitar los parámetros de seguimiento antes de reenviar un enlace porque la cadena de consulta forma parte del destino HTTP. Cuando el navegador pide el documento, utm_source, fbclid y gclid detrás del signo de interrogación se escriben en la línea de petición. El anfitrión, un proxy inverso y el registro de acceso están diseñados para verlos. Pegas la cadena entera en WhatsApp, Slack o un ticket, y le entregas también a quien la abra el canal y la marca de clic.

Esta nota es para soporte, operaciones y quien, antes de reenviar una URL, quiera separar «qué ya escribe la dirección» de «qué sigue ocurriendo al cargar la página». No sustituye las instrucciones de la limpieza de privacidad ni repite qué botón produce un enlace limpio. Lo que te llevas es qué escriben los UTM y los IDs de clic, quién los hereda al reenviar, qué puede demostrar el recorte y cómo contrastar la lista de eliminados con Network en este dispositivo.

Lo que va detrás del signo de interrogación entra en HTTP

RFC 3986 §3.4 define la query como el tramo posterior al primer ? y anterior al fragmento. RFC 9110 añade que el URI de destino de la petición incluye la ruta y la consulta, y excluye el fragmento. Una barra de direcciones larga no es un problema estético. Esta petición del documento entrega al otro lado los pares clave–valor que van detrás del signo de interrogación.

El fragmento detrás de la almohadilla se queda, por defecto, en la pestaña actual. Una nota anterior ya cubre cómo comprobarlo. Esta se queda en el signo de interrogación. Mantén las dos reglas a la vista para no leer «el servidor no ve la clave detrás de #» como «el servidor tampoco ve el canal detrás de ?».

La API URLSearchParams del navegador puede partir una query en pares, borrarlos por nombre y reconstruir la dirección. Un limpiador trabaja en esa capa: edita una cadena. No apaga los scripts de la landing. Borrar utm_campaign no cierra el píxel del otro sitio.

UTM escribe un canal, no un sufijo decorativo

Google Analytics describe el etiquetado manual como un conjunto de parámetros de consulta utm_*. La ayuda mapea los habituales así: utm_source al origen, utm_medium al medio, utm_campaign al nombre de la campaña, más utm_term, utm_content, utm_id y campos más recientes como utm_source_platform. El ejemplo oficial es http://www.example.com/?utm_source=google&utm_medium=cpc&utm_campaign=summersale. Es el texto de la nota de Analytics sobre fuentes de tráfico, no una conjetura.

Esos valores le sirven a quien lanzó la campaña: el mismo artículo se puede contar por separado desde un correo, una descripción de vídeo y un anuncio de WhatsApp. Para la siguiente persona que abre el enlace, son una nota en claro. Un ticket que contiene utm_source=vip_whatsapp&utm_campaign=reembolso_202609 deja leer a cualquiera que busque ese ticket después «este clic vino de aquella campaña privada».

El UTM casi nunca lleva un número de documento ni una contraseña. Lo que filtra es contexto: qué correo abriste, en qué anuncio pulsaste, si llegaste por un enlace solo de soporte. En cuanto ese contexto vive en una URL reenviable, ya no se queda en tu pestaña.

Un ID de clic nombra un clic, no una campaña

Un ID de clic está más cerca de «este clic» que de un nombre de campaña. El etiquetado automático de Google Ads añade gclid (Google Click Identifier) a la URL de destino. La forma oficial es www.example.com/?gclid=123xyz. Con el etiquetado automático activo y Analytics en el sitio, ese valor también puede escribirse en una cookie de origen para unir conversiones posteriores a aquel clic. Lo recoge la nota de etiquetado automático de Google Ads.

En algunos casos de iOS 14 o posterior, sin consentimiento no se usa gclid. Google introdujo gbraid (de web a app) y wbraid (de app a web) para seguir midiendo anuncios bajo esos límites de plataforma. Esa división está en la nota de Analytics sobre medición de campañas en iOS 14+, no en una categoría inventada por un limpiador.

En el lado de Meta, el nombre habitual es fbclid. La documentación para desarrolladores dice que, si la URL de la página lleva este parámetro, Conversions API puede seguir construyendo fbc a partir de él. Si el sitio ejecuta Meta Pixel, el id de clic también puede escribirse en una cookie de origen llamada _fbc, con la forma version.subdomainIndex.creationTime.fbclid. La fuente es la nota de Meta sobre fbp / fbc. Reenvías una URL que todavía tiene fbclid, y el compañero que la abre puede dejar que el otro sitio guarde «este clic» en su propia cookie y en eventos posteriores.

La misma familia aparece como msclkid, ttclid, twclid y li_fat_id. Cada uno sirve a su propia cuenta de anuncios. El hecho compartido es más simple: escrito en la query, viaja con la línea de petición; escrito en la cadena que reenvías, lo hereda quien la abra después.

No experimentes con una URL de campaña en vivo, un enlace corto que incrusta el teléfono de un cliente ni un ticket sin enmascarar. Prepara un ejemplo público y pon marcas de un solo uso en los valores. Estás comprobando query y líneas de petición, no volviendo a difundir un canal real.

Al reenviar, la siguiente persona hereda la query entera

Los botones de compartir, «Copiar dirección» y un toque largo sobre un mensaje suelen copiar la URL completa actual, no la ruta corta que el sitio preferiría mostrar en público. WhatsApp, el correo y las vistas previas de anuncios lo dejan claro: crees haber copiado un artículo o un producto, y el portapapeles guarda un pathname más una estela de campos de atribución.

Esos campos aterrizan luego en tres sitios. Primero, el cuerpo del chat o del ticket, donde los lee todo el hilo y quien busque después. Segundo, la barra de direcciones de la otra persona, y cualquier historial que se sincronice desde ahí. Tercero, la petición del documento que envían al abrir: el registro del servidor contendrá la query completa. Borrar la línea de tu propio chat no cambia a quienes ya la abrieron, ni los logs ya escritos.

Soltar un enlace de monitorización de campaña en un anuncio público, pegar de vuelta en un ticket la URL larga que envió un usuario, y adjuntar a una incidencia una URL de reproducción que todavía lleva gclid son la misma acción: convertiste un contexto de clic que estaba en tu barra de direcciones en una marca que puede reutilizar cualquiera que vea esos caracteres.

Qué puede demostrar el recorte, y qué sigue en la dirección

La afirmación que sostiene una URL limpia es estrecha. Escribirla así evita una lectura extra. Puede probar que, en la lista que usaste y en esta pasada, los utm_* conocidos, los IDs de clic y (en un modo más amplio) algunos campos de atribución salieron de la query. El pathname sigue. Los parámetros de negocio como id= y q= deben quedarse por diseño. El enlace debería abrir el mismo artículo.

No puede probar que la landing no tenga píxel, que el otro sitio no tenga cookie de origen, que un salto de enlace corto no añada parámetros nuevos, que la propia ruta no lleve un token de seguimiento, ni que una extensión no reescribiera el portapapeles. Tampoco puede probar «nadie sabrá quién eres después de abrir». Editaste la cadena que vas a enviar. No editaste la sesión de navegación siguiente.

Los enlaces cortos son el falso aprobado más habitual. El acortador esconde el destino real detrás de su propia redirección. Limpias https://short.example/abc y la query suele estar vacía, así que la herramienta informa de que no encontró nada que quitar. El seguimiento está en la URL larga después del 302. Para comprobarlo, abre el enlace corto en una ventana privada y copia la URL final de la barra de direcciones. No uses para ese paso un enlace corto que lleve datos privados reales.

Lo que ves Qué puede sostener Qué no puede sostener
El enlace se acortó Faltan algunos caracteres de la query Ya eres anónimo o ya estás a salvo
La lista de eliminados muestra utm_* y fbclid Esas claves salieron de esta URL La landing no escribirá _fbc ni una cookie de Analytics
id= y q= siguen Los localizadores de negocio se conservaron por diseño Toda clave que queda es necesaria para la página
Un enlace corto informa «nada que quitar» Esta dirección corta no coincidió con la lista La URL larga después de la redirección también está limpia
Network no muestra la URL original Esta petición de limpieza no envió el origen como dato de negocio Una extensión o un cliente de chat nunca la guardó

Contrasta ahora: la lista de eliminados y Network

Un eslogan no es una prueba. Dos comprobaciones que puedes terminar en este dispositivo: una sobre el resultado limpio, otra sobre el tráfico de salida. Prepara un ejemplo que puedas tirar, por ejemplo:

https://example.com/article/42?id=42&q=aes&utm_source=whatsapp&utm_medium=social&utm_campaign=share_20260903&fbclid=IwAR0canaryfp&spm=demo.share.0

Pon el canario en los valores de utm_campaign y fbclid. Después de limpiar, la dirección limpia ya no debería contener share_20260903 ni IwAR0canaryfp. id=42 y q=aes deberían seguir.

  1. Lee primero la lista de parámetros eliminados. Deberías ver utm_source, utm_medium, utm_campaign y fbclid. En un modo más amplio, un nombre de atribución de marketplace como spm también debería aparecer. Si la lista está vacía pero el enlace «parece limpio», sospecha un acortador o una marca en la ruta.
  2. Luego lee el pathname de la dirección limpia y la query que queda. Si faltan el id del artículo o el término de búsqueda, es daño colateral. No reenvíes ese resultado.
  3. Abre Network en las herramientas para desarrolladores, activa Preserve log y deja el filtro en All. Pega el canario en el cuadro de búsqueda. No debería aparecer en líneas de petición, cuerpos ni informes de analytics.

Limpiar enlace de FastPwd sigue ese límite: el análisis ocurre en la pestaña actual; una sola URL de más de 8 KB se rechaza; un lote admite como máximo 100 líneas; solo se aceptan http / https. El modo conservador quita utm_* e IDs de clic (incluidos fbclid, gclid, gbraid, wbraid y msclkid). El modo estándar también quita _ga / _gl, tokens de correo como mc_eid / mc_cid, atribución de marketplace como spm / scm, prefijos como _x_*, tokens de compartir como share_token y —salvo que los conserves— ref / referrer. El pathname y id= / q= se quedan. La herramienta está lista para usar; no hay cuenta. La analítica registra nombres de evento del tipo «se limpió un enlace», no la URL original. Una promesa sigue siendo una promesa. Confía en lo que ves en esta pasada en la lista y en Network.

Si no estás seguro de si una clave es un parámetro de negocio, pasa al modo conservador. Saca primero los UTM y los IDs de clic de la cadena que vas a enviar, y decide a mano si spm o ref deben quedarse. Las claves que la lista no toca, las borras con los ojos. No esperes que «se acortó» termine el trabajo.

Tres casos que parecen limpios y no se recortaron

Primero, el seguimiento vive en la ruta. Algunas páginas de compartir usan /s/xxxx o un prefijo de canal en el path, y la query está vacía. Borrar claves de consulta por nombre apenas cambia la dirección. Contrasta la URL canónica después del salto, no la cáscara de redirección que acaba de soltar el botón de compartir.

Segundo, el limpiador edita searchParams y deja hash en paz. Si un rastreador se escribió detrás de la almohadilla, la limpieza de query informará un aprobado. La comprobación sigue siendo poner la cadena completa de la barra de direcciones al lado del resultado completo. No te detengas en los caracteres anteriores al signo de interrogación.

Tercero, limpiaste la cadena que ibas a enviar, y el cliente de chat añadió parámetros al salir. Algunos clientes marcan los enlaces salientes con su propia marca de clic. Después de enviar, abre el mensaje en otra ventana y vuelve a leer la barra de direcciones. La limpieza ocurre antes de pegar. Aun así, haces una comprobación puntual después de enviar.

Preguntas frecuentes

Después de quitar los UTM, ¿la persona que abre el enlace sigue pudiendo ser rastreada?

Sí. Has quitado la query de la cadena que vas a enviar. La landing puede seguir ejecutando píxeles, cookies de origen y una sesión iniciada. La documentación de Meta también señala que, aunque la URL ya no tenga fbclid, un sitio que ya escribió _fbc puede seguir adjuntándolo a eventos posteriores. Quitarlos solo prueba que esta URL perdió parámetros de seguimiento conocidos. No prueba que la visita siguiente sea anónima.

¿Un limpiador de URL también borra el id del artículo o el término de búsqueda?

Con una lista por nombre, el pathname y las query de negocio como id= o q= deben quedarse. Si no estás seguro, usa el modo conservador, que solo quita utm_* e IDs de clic. Después de limpiar, lee la lista de parámetros eliminados. No tomes un enlace más corto como prueba. Si una clave que necesitas aparece en esa lista, descarta este resultado.

¿Hay que quitar primero los parámetros de un enlace corto?

Un enlace corto suele no llevar UTM. El seguimiento está en la dirección larga después de la redirección. Limpiar solo la forma corta casi nunca quita nada. Ábrelo en una ventana privada, copia la URL final de la barra de direcciones y quita los parámetros de esa. No uses como prueba un enlace corto que lleve datos privados reales. Basta un ejemplo público.

Cuando limpio un enlace en FastPwd, ¿se sube la URL original?

Según la ficha del producto, el análisis y el recorte terminan en la pestaña actual. La URL original no se envía como dato de negocio HTTP ni se escribe en analytics. La analítica registra nombres de evento del tipo «se limpió un enlace». Para comprobar esta pasada, busca el canario en Network: no debe aparecer en líneas de petición, cuerpos ni informes de analytics. Localhost no envía analítica por defecto; repite la comprobación en el nombre de host en línea si quieres una pasada más cercana al uso real.

Contrasta el mismo enlace con una herramienta lista para usar

Si quieres una página que deja por escrito la lista de recorte, abre la limpieza de privacidad de FastPwd. Sin registro. Pega el ejemplo de arriba, ejecuta el modo conservador, luego el estándar, y compara los dos chips de «eliminados». Deberías ver que ambos modos se llevan UTM y fbclid; solo el estándar debería tocar spm. En el resultado limpio, id y q deberían seguir.

La misma página puede pasar a ocultar datos para teléfonos y correos en el cuerpo de un ticket; eso es otro artículo. Cuando un secreto completo debe llegar a un compañero, usa Burn-Link: cifra en local con AES-256-GCM, el servidor solo guarda texto cifrado y la clave va detrás de la almohadilla del enlace. No pegues en el mismo hilo una URL de negocio recién limpia y un Burn-Link completo.

Antes del siguiente reenvío, quédate con tres hechos. Primero: el signo de interrogación entra en HTTP; el canal y los IDs de clic viven ahí. Segundo: el recorte solo cambia la cadena que vas a enviar; no apaga la analítica de la landing. Tercero: los enlaces cortos, las marcas en la ruta y los parámetros añadidos al enviar piden cada uno su propia comprobación. Una observación que puedes repetir es la que merece entrar en la nota de salida de tu equipo.

Para seguir leyendo

No mezcles el signo de interrogación con la almohadilla. Por qué una clave puede ir detrás de #, y qué capa cae al pegar el enlace completo en un chat, está en Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla. Cómo contrastar teléfonos, documentos y API Key en un ticket antes de que salgan de este equipo está en Antes de pegar un ticket o un registro en una IA, comprueba qué campos salen de este equipo. Para confirmar que el propio limpiador no envió la URL original como dato de negocio, usa los pasos del canario en Cómo comprobar que el cifrado local del navegador no envió el original.