A un bot simple lo delata que no ejecuta JavaScript. Pero hace tiempo que los anuncios no se revisan con scripts en curl, sino con navegadores reales controlados por programas. Un navegador headless carga la página, ejecuta el código, espera, hace clic y, para una protección ingenua, no se distingue de un visitante. Lo que ayuda a distinguirlo es la huella del navegador, o fingerprint, y los rastros de automatización que el programa deja en el entorno.
Qué es un navegador headless
Headless significa «sin cabeza»: sin ventana gráfica. Es el mismo motor de Chrome o Firefox, solo que ejecutado en segundo plano y controlado por un programa. Las herramientas de automatización populares (Puppeteer, Playwright, Selenium) saben abrir páginas, rellenar formularios, hacer capturas y recorrer cadenas de redirecciones.
Quién usa navegadores headless con tu landing:
- plataformas publicitarias, que revisan la página de destino tal como la verá el usuario;
- spy tools, que guardan landings enteras (más en el artículo sobre protección contra spy tools);
- tráfico fraudulento, que infla clics e incluso conversiones;
- scrapers de la competencia, que recopilan textos, precios y estructura.
El gran problema para el filtro: el navegador headless supera la comprobación de ejecución de JavaScript. Por eso hacen falta señales más finas.
Qué es la huella del navegador (fingerprint)
La huella del navegador es el conjunto de características que el navegador revela al sitio. Unas se envían solas y otras las mide un script.
| Componente | Qué es | Qué puede delatar |
|---|---|---|
| User-agent | cadena con el nombre y la versión del navegador y del sistema | una versión de plantilla u obsoleta |
| Idioma y configuración regional | lista de idiomas del navegador | un idioma que no cuadra con el GEO |
| Zona horaria | la zona del sistema | una zona que no coincide con el país de la IP |
| Pantalla | resolución, profundidad de color, densidad de píxeles | tamaños «redondos» típicos de servidor |
| Gráficos | tarjeta gráfica, renderizador, detalles de dibujo | un renderizador por software en lugar de una GPU real |
| Fuentes | fuentes instaladas | un sistema de servidor «desnudo» |
| Hardware | núcleos, memoria, pantalla táctil | características de escritorio en un «teléfono» |
| Capacidades de la API | qué interfaces del navegador hay | falta de algo que sí tiene un navegador real de esa versión |
La huella se usa de dos maneras. Para reconocer: saber que varias visitas vienen del mismo dispositivo. Y para verificar la autenticidad: saber si ese conjunto parece un dispositivo real. Para la protección contra bots importa más lo segundo; en eso se apoya cualquier antibot para sitios web.
Señales de headless y de automatización
La propiedad webdriver
Según el estándar, un navegador controlado por un programa a través de la interfaz de automatización activa la propiedad navigator.webdriver. Es la señal más conocida y la más fácil de ocultar: se falsea con una línea. Por eso una protección seria no se apoya solo en ella.
Rastros de control
Las herramientas de automatización dejan en el entorno sus propios objetos, variables y cambios característicos en el comportamiento de algunas funciones. Son muchos, cambian con cada versión de las herramientas y es difícil esconderlos todos a la vez.
Contradicciones con lo declarado
El navegador headless se delata a menudo por contradicciones:
- el user-agent dice «Chrome en Windows», pero el conjunto de API es el de una versión headless en Linux;
- se declara un iPhone, pero admite interfaces que Safari no tiene;
- la pantalla es «móvil», pero no hay entrada táctil;
- la tarjeta gráfica aparece como renderizador por software, típico de servidores.
Entorno de servidor
Un conjunto mínimo de fuentes, sin dispositivos multimedia, una resolución «redonda» y valores de hardware poco naturales son señales de un navegador ejecutado en un servidor sin usuario real.
Tiempo y comportamiento
Un programa actúa o al instante o con pausas idénticas. No hay movimientos de ratón, toques ni desplazamiento, o son perfectamente uniformes. También se nota el tiempo en página falsificado: cuando lo que informa el script no cuadra con los tiempos reales.
Consejo. Ninguna señal de esta lista demuestra por sí sola que sea un bot. Lo que lo demuestra es la combinación: tres o cuatro contradicciones independientes en una misma visita casi nunca aparecen en navegadores reales.
Navegadores antidetect: dónde está el límite
Un navegador antidetect falsea la huella para que cada perfil parezca un dispositivo real distinto. En el arbitraje de tráfico es una herramienta de trabajo habitual: los media buyers gestionan en él sus cuentas publicitarias para que la plataforma no las relacione entre sí.
Para el filtro de tráfico conviene distinguir dos casos:
- antidetect manejado por una persona: para la landing es, en la práctica, un visitante normal; la persona mueve el ratón, lee y hace clic;
- antidetect manejado por un programa: la misma automatización, solo que mejor disfrazada; la delatan la incoherencia de la falsificación y el comportamiento.
Dicho de otro modo, la huella no es la única línea de defensa. A un bot bien disfrazado lo delata lo que hace, no su aspecto.
Falsos positivos: navegadores integrados y WebView
El error más común al filtrar por huella es cortar los navegadores integrados en las apps. Facebook, Instagram y TikTok abren los enlaces en un navegador interno basado en WebView, que tiene:
- un user-agent poco habitual con el nombre de la app;
- menos capacidades que un navegador completo;
- señales que coinciden con rastros de automatización;
- a menudo, el referer perdido.
Y, sin embargo, gran parte del tráfico real de redes sociales llega precisamente a través de estos navegadores integrados. Por eso una señal de automatización en un WebView no puede tratarse como un bot claro, sino como una señal más en la evaluación global. Cómo ayuda el identificador de clic de la plataforma a distinguir esa visita de un bot lo explicamos en fbclid, gclid y ttclid.
Cómo funciona la comprobación del navegador en ArtisanClo
En ArtisanClo la comprobación del navegador es un paso propio después de las comprobaciones de red. El script se ejecuta en el navegador del visitante e informa de lo que ha visto; la página permanece oculta hasta que llega la decisión. De esto se encargan varios interruptores de protección:
- Bloquear headless: detecta bots y autoclickers que se hacen pasar por navegador. Con rastros claros de automatización corta de inmediato, y en el registro aparece el motivo «Navegador headless detectado».
- Exigir JS: el visitante sin JavaScript recibe una penalización fuerte y va a revisión. Los bots y scrapers simples tropiezan aquí.
- Verificación de interacción real: observa cómo se mueven el ratón y el dedo; una persona se comporta de forma natural y un bot no. Añade una pequeña espera, así que se activa para plataformas estrictas.
- Tiempo mínimo en la página: el visitante que se queda menos de lo indicado va a una página de espera y se vuelve a comprobar.
Los navegadores integrados de Facebook, Instagram y TikTok y el WebView de las apps se reconocen por separado: en ellos una señal de automatización no corta la visita de inmediato, sino que entra en la evaluación de confianza junto con la red, el tiempo y el referer. Para campañas en las que casi todo el tráfico llega desde el navegador integrado se recomienda el nivel de rigor «Equilibrado».
Los robots-navegador con señales demostradas y el tiempo en página falsificado entran en la lista común de bots a la primera: la siguiente visita desde esa dirección a cualquier flujo de cualquier cliente recibe directamente la White Page.
En las estadísticas, los rechazos de este paso se agrupan en «Comprobación del navegador», y las visitas que no ejecutaron el script ni volvieron, en «La comprobación no volvió». Si crece justo la proporción de «Comprobación del navegador», es señal de revisar el rigor: es el paso donde el filtro se equivoca con más frecuencia.
La comprobación del navegador funciona con la conexión por etiqueta JS y por archivo PHP. La diferencia entre ambas se explica en cómo conectar el cloaker a tu sitio, y la lista completa de comprobaciones está en la página de funciones.
Cómo montar la protección contra headless: pasos prácticos
- Empieza por la red. La mayoría de los bots headless corren en servidores: bloquear centros de datos los corta antes de la comprobación del navegador. Ver VPN, proxy e IP de centros de datos.
- Exige JavaScript donde sea seguro. Si la plataforma envía el identificador de clic y el tráfico viene de navegadores normales, exigir JS corta scrapers sin pérdidas.
- Activa el bloqueo de headless en todos los flujos.
- La verificación de interacción real, resérvala para el tráfico caro y las fuentes con mucha automatización avanzada.
- No endurezcas los navegadores integrados. En redes sociales no actives reglas estrictas de más.
- Revisa los motivos. Si «Navegador headless detectado» salta en masa con el tráfico móvil de una plataforma, hay que investigar, no celebrar.
La lógica general de la protección por capas se explica en cómo filtrar bots, y la lista de señales típicas, en tráfico de bots: cómo reconocerlo.
Huella del navegador y privacidad: lo que conviene saber
La palabra «fingerprint» se asocia a menudo con el rastreo: los sistemas publicitarios usan huellas para reconocer al usuario sin cookies. En antifraude el objetivo es otro. Al filtro no le importa quién es el visitante: necesita saber si el navegador es real y si se comporta como una persona. Por eso, para protegerse de bots no importan los identificadores únicos, sino la coherencia de las características entre sí.
De ahí una consecuencia práctica. Los navegadores recortan poco a poco lo que un script puede medir: añaden ruido al renderizado, unifican las cadenas de user-agent y ocultan detalles del hardware. Para reconocer usuarios es un problema; para verificar la autenticidad, menos: las contradicciones entre lo declarado y lo real no desaparecen. En cambio, una protección construida sobre una o dos señales «mágicas» deja de funcionar con el tiempo, y es otro argumento a favor de evaluar la suma de señales.
Ejemplo: cómo se analiza una visita sospechosa
Supongamos que en el registro hay una visita con un motivo ligado a la automatización del navegador. En la ficha del clic se ve:
- red: hosting en la nube;
- navegador declarado como un Chrome reciente, y dispositivo, ordenador;
- sin identificador de clic publicitario;
- la comprobación del navegador volvió con señales de control por programa.
Aquí todo encaja: red de servidor, ninguna visita desde un anuncio y rastros de automatización. Es el clásico robot de revisión o una spy tool.
Otra visita: operador móvil, navegador integrado de una red social, con identificador de clic y una señal de automatización débil. Esa visita no se puede cortar por una sola señal: lo más probable es que sea una persona normal que abrió el anuncio en la app.
La diferencia entre ambas visitas es la esencia de evaluar la suma de señales: en la primera se contradicen varias señales independientes; en la segunda, solo una, y además se explica por las particularidades del navegador integrado. Si en el registro hay muchas visitas del segundo tipo y van a la White Page, baja el rigor para esa plataforma.
Resumen
Un navegador headless supera las comprobaciones simples, pero deja rastros: propiedades y objetos de automatización, contradicciones en la huella, entorno de servidor y comportamiento poco natural. La huella del navegador ayuda a saber si la visita parece un dispositivo real, y las comprobaciones de comportamiento, si actúa como una persona. La regla principal es la de siempre en antifraude: decide la combinación de señales, no una sola; si no, junto con los bots se irá el tráfico de los navegadores integrados de las redes sociales.
