El user agent (UA) es la cadena con la que el navegador o cualquier otro programa se presenta al servidor en la cabecera de cada petición: nombre y versión del navegador, motor, sistema operativo y, a veces, modelo del dispositivo. El filtrado por user agent significa que el servidor lee esa cadena y decide según ella a quién deja pasar, a quién le muestra otra página y a quién corta como bot.
El método es sencillo y barato, por eso todavía aparece en scripts caseros y plugins «antibot». Pero la cadena la escribe el propio cliente, y falsificarla es más fácil que cualquier otra señal de la visita. A continuación: qué hay exactamente en el UA, cuándo se puede confiar en esa cadena, cuándo no y cómo usarla junto con otras señales.
Qué es el user agent y qué dice
Una cadena típica de Chrome móvil en Android es así:
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Mobile Safari/537.36
Es más fácil leerla por partes:
| Fragmento | Qué significa |
|---|---|
Mozilla/5.0 |
Prefijo histórico de compatibilidad; lo llevan casi todos los navegadores y no dice nada |
(Linux; Android 10; K) |
Plataforma y SO; en los navegadores actuales, el modelo del dispositivo suele sustituirse por un marcador |
AppleWebKit/537.36 (KHTML, like Gecko) |
Motor de renderizado y otro guiño a la compatibilidad |
Chrome/130.0.0.0 |
Navegador y versión principal; los números menores hace tiempo que se ponen a cero |
Mobile Safari/537.36 |
Señal de maquetación móvil |
De esta cadena, el servidor suele sacar cuatro cosas: el tipo de dispositivo (smartphone, tableta, ordenador, televisor), el sistema operativo, el navegador y si lo que tiene delante no es un navegador, sino un programa o un robot.
Fíjate: la cadena casi no tiene información única. Millones de teléfonos envían el mismo UA, y justamente por eso los navegadores lo «congelaron», para que costara más rastrear a las personas con él.
Client Hints: adónde se mudan los detalles
Los navegadores basados en Chromium van recortando la cadena clásica y entregan los detalles mediante Client Hints: un conjunto de cabeceras Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform y otras. Algunas llegan con cada petición y otras solo si el servidor las pide expresamente. Para el filtrado son útiles de dos maneras: es más difícil inventarlas de forma creíble desde cero, y se pueden contrastar con la cadena principal. Un navegador que en el UA dice ser Chrome en Windows y en las pistas informa de otra plataforma se comporta de forma extraña.
También hay una limitación: Safari y Firefox admiten las pistas de otra forma o no las admiten, así que la ausencia de Client Hints por sí sola no dice nada.
Cómo funciona el filtrado por user agent
En su forma más simple es una lista de subcadenas: si el UA contiene una de las palabras prohibidas, el visitante va a una página de relleno. Un poco más complejo es un parser que descompone la cadena en navegador, SO y dispositivo, con reglas sobre el resultado: «solo smartphones», «sin Smart TV», «solo Android».
Aquí es importante distinguir dos tareas diferentes:
- Segmentación: elegir el público objetivo. ¿Esta oferta necesita escritorio? ¿Encaja iOS? La cadena UA funciona bien aquí, porque las personas normales no la falsifican y el error sale barato.
- Protección contra bots: descartar la automatización. Aquí el UA es casi inútil como señal por sí sola: quien programa un bot lo primero que hace es poner la cadena de un navegador real.
Los filtros de audiencia por dispositivo, SO y navegador se explican en el artículo sobre el filtro por geo, dispositivo y horario. A partir de aquí hablamos de la segunda tarea.
El user agent de un bot: quién se presenta con honestidad
Parte del tráfico automático sí se presenta tal como es. Son dos clases distintas.
Scripts y utilidades toscos. Las librerías de peticiones HTTP, los descargadores de consola y los scrapers envían por defecto su propio UA, con el nombre de la librería y la versión, o no envían ninguno. Una cadena UA vacía o el nombre de una librería en lugar de un navegador es una señal fiable: una persona real que viene de un anuncio no llega así. Esas visitas se cortan al instante y casi sin riesgo.
Crawlers de buscadores y robots «educados». Los buscadores, los servicios de vista previa de enlaces y los monitores de disponibilidad suelen indicar con honestidad su nombre y un enlace a su descripción. Para un sitio normal son visitas útiles, y no se bloquean. Pero también aquí hay un matiz: los scrapers copian a menudo la cadena de un robot de búsqueda conocido para que los dejen pasar donde se deja pasar al buscador. Por eso los propios buscadores recomiendan verificar al robot no por el UA, sino con una consulta DNS inversa a la dirección IP: un crawler auténtico llega desde la red de su empresa.
Conclusión: el filtro por UA atrapa bien a quienes no intentan esconderse. Es una parte notable de las peticiones basura, y cortarla sale barato. Pero no es la parte del tráfico de bots que se come el presupuesto publicitario.
Falsificar el user agent: por qué un filtro basado solo en el UA es débil
Cualquier programa que se disfrace un poco envía la cadena de un Chrome o un Safari recientes. Se hace con una línea de código, y en el navegador, con un selector en las herramientas para desarrolladores. A partir de ahí surgen tres problemas.
La falsificación no se ve en la propia cadena. El UA correcto de un navegador real y el mismo UA en la petición de un script son idénticos byte a byte. No se puede comprobar la cadena contra sí misma, solo contrastarla con otras señales.
Las listas se quedan viejas. Una lista negra de subcadenas exige actualizarla constantemente: aparecen herramientas nuevas, las antiguas cambian de nombre y los navegadores reales cambian el formato de la cadena. Una lista que no se ha actualizado en medio año atrapa sobre todo lo que hace tiempo que no llega.
Falsos positivos con personas reales. Los navegadores integrados en apps, los WebView, los teléfonos antiguos y las versiones corporativas de navegadores envían cadenas poco habituales. La regla «es sospechoso todo lo que no parezca un Chrome estándar» corta justo el tráfico móvil de redes sociales, el que estás pagando. Las particularidades de los navegadores integrados se explican en detalle en el artículo sobre el tráfico in-app y el fraude móvil.
Consejo. Si una regla por UA salta en una parte notable del tráfico de pago, lo más probable es que esté cortando a personas reales, no a bots. Los bots contra los que vale la pena protegerse llegan con una cadena perfecta.
Dónde sí es útil el filtrado por user agent
Pese a todo lo anterior, el UA es una señal normal y necesaria si sabes cuál es su lugar.
- Descartar la automatización tosca. UA vacío, nombre de una librería, de una utilidad de consola o de un framework de scraping: un «no» inmediato. Una capa barata que quita carga al resto de comprobaciones.
- Detectar el tipo de dispositivo para segmentar y enrutar. Smartphone u ordenador, Android o iOS: para repartir el tráfico entre ofertas, la cadena UA suele bastar.
- Reconocer los navegadores integrados. Por el UA se ve que la visita llegó desde un navegador dentro de una app. Esto no sirve para bloquear, sino al contrario: para no castigar esa visita por señales que en un WebView suelen ser falsas.
- Contrastar con otras señales. El UA dice «iPhone», pero la pantalla, las fuentes y el comportamiento del script no. Esa discrepancia es la señal.
- Analítica. Los desgloses por navegador y SO en los informes muestran dónde cae la conversión y de dónde viene un pico sospechoso.
Combinarlo con otras señales: el UA como una voz entre muchas
Una buena protección no pregunta «qué UA tiene la visita», sino «encaja el UA con todo lo demás». Estas son las señales con las que se suele contrastar:
| Señal | Con qué se contrasta el UA |
|---|---|
| Dirección IP y red | Un navegador móvil desde una red de hosting merece atención; más detalles en el artículo sobre VPN, proxies e IP de centros de datos |
| Cabeceras de la petición | El conjunto y el orden de cabeceras de un navegador real difieren de los de una librería, aunque la cadena UA sea la misma |
| Client Hints | La plataforma y la marca del navegador en las pistas deben coincidir con la cadena |
| Ejecución de JavaScript | Un navegador que dice ser un Chrome actual pero no ejecutó el script no se comporta como un navegador |
| Propiedades del navegador en el script | Plataforma, pantalla, señales de automatización; más detalles en el artículo sobre navegadores headless y huella digital |
| Comportamiento | Tiempo en la página, movimiento del ratón y toques |
Cada señal por separado se equivoca. Juntas dan una evaluación que se equivoca mucho menos. Así funciona cualquier filtro de tráfico inteligente actual: una señal aislada añade un poco de sospecha, y una conclusión segura sale de la coincidencia de varias. El esquema general de capas de protección lo vimos en el artículo sobre cómo filtrar bots.
Cómo funciona en ArtisanClo
En ArtisanClo, la cadena user agent es una de las señales, no una regla aparte «por lista». La decisión sobre una visita se compone de varios pasos, y el UA participa en cada uno a su manera.
Red y petición. El primer paso mira la dirección, la red, el proveedor, las cabeceras, el identificador de clic y las reglas del flujo, antes de comprobar el navegador. Aquí se cortan los programas en lugar de navegadores y los robots de las plataformas que generan vistas previas de enlaces: esas visitas reciben siempre la White Page, con cualquier configuración, y el registro muestra el motivo «Un programa, no un navegador» o «Crawler de buscador o plataforma». Es el paso que menos afecta a las personas reales.
Audiencia. En la configuración de filtrado del flujo hay listas de «Dispositivos», «Sistemas operativos» y «Navegadores» con los botones «Permitidos» y «Bloqueados». Entre los dispositivos se distinguen aparte «Bot / rastreador» y «Desconocido». Esto es segmentación: el visitante que no pasa la lista ve la White Page con un motivo claro.
Comprobación del navegador. Quien envió la cadena de un navegador real pasa la comprobación del script, y es su respuesta la que muestra si la visita parece automatizada. El bloqueo de navegadores headless con rastros claros de automatización corta al instante; las señales menos claras van a la puntuación de confianza junto con la red, la VPN y la presencia de proveedor y sitio de origen.
Navegadores integrados. Los navegadores integrados de Facebook, Instagram y TikTok y los WebView de las apps se reconocen aparte. Una señal de automatización en ellos no corta la visita de inmediato, sino que se tiene en cuenta en la puntuación de confianza junto con la red, el tiempo y el referer, porque en esos navegadores suele ser falsa.
Transparencia. Cada clic del registro tiene el motivo de su decisión entre decenas posibles, y el enlace «Informe de la visita» muestra todas las señales y conclusiones de una visita. Si sospechas que el filtro se equivocó, empieza por el artículo por qué el clic fue a la White Page. Todas las posibilidades de filtrado están en la página de funciones.
Errores típicos al filtrar por user agent
- Basar la protección en una lista negra de subcadenas. Solo atrapa a quien no se esconde y exige actualizarla sin fin.
- Bloquear todo lo «no estándar». Caen los navegadores integrados de las redes sociales y los dispositivos antiguos: tráfico de pago real.
- Creer a una cadena que parece correcta. Un UA perfecto de un navegador actual es justo lo que envía un bot bien hecho.
- Confundir segmentación con protección. Elegir «solo Android» es una decisión sobre el público de la oferta, no una forma de librarse de los bots.
- No mirar los motivos del descarte. Si no ves qué regla actuó, no puedes saber si el filtro corta bots o personas. Las señales con las que se ve el tráfico de bots en los informes están en el artículo sobre las señales del tráfico de bots.
En resumen
La cadena user agent es lo que el cliente dice de sí mismo. Se le puede creer cuando hay poco en juego: para detectar el dispositivo, repartir el tráfico y hacer analítica. No se le puede creer como prueba de que delante hay una persona. El filtrado por user agent elimina bien los scripts toscos y las peticiones vacías, pero la protección de verdad empieza cuando el UA se contrasta con la red, las cabeceras, los Client Hints, la ejecución del script y el comportamiento. Entonces una cadena falsificada no ayuda al bot, y una cadena poco habitual no perjudica al visitante real.
