Verificación JavaScript o bloqueo por IP: dos enfoques contra los bots

El bloqueo por IP decide antes de que cargue la página y no cuesta nada en velocidad, pero no ve a los bots que usan direcciones domésticas. La verificación JavaScript mira el navegador por dentro, pero necesita tiempo y se equivoca con dispositivos poco comunes. Vemos qué detecta cada enfoque y por qué una protección madura usa los dos.

Bots y fraude12 min de lectura
Contenido
  1. Bloqueo por IP: cómo funciona
  2. Verificación JavaScript: cómo funciona
  3. Comparación de los enfoques
  4. Por qué se combinan
  5. Cómo afecta a la velocidad de la página
  6. Ejemplo: tres visitas vistas por dos capas
  7. Dónde la verificación sobra o perjudica
  8. Cómo funciona en ArtisanClo
  9. En resumen

Cuando un anunciante decide protegerse de los bots, la primera pregunta suele ser técnica: ¿bloquear por IP o poner un script en la página? Son dos maneras distintas de mirar una visita. El bloqueo por IP valora de dónde viene la petición. La verificación JavaScript valora qué programa la envió. Cada enfoque tiene su punto ciego, y precisamente por eso una protección seria no elige entre ellos, los combina.

A continuación: cómo funciona cada enfoque, qué detecta bien, dónde se equivoca y cómo hacer que trabajen juntos sin perder velocidad de página.

Bloqueo por IP: cómo funciona

El servidor recibe la petición y sabe poco de ella: la dirección IP, las cabeceras del navegador, la página de origen. Pero una IP dice bastante:

  • a quién pertenece la red: proveedor doméstico, operador móvil, hosting, nube (por el número de sistema autónomo, ASN);
  • país y ciudad, con precisión suficiente para un filtro geográfico;
  • marcas en bases de datos: VPN conocida, proxy, Tor, dirección de trampas de spam;
  • historial: cuántas veces ha llegado ya esa dirección y cómo terminó.

La decisión se toma antes de servir la página. Esa es la gran ventaja del enfoque: no cuesta nada en velocidad y funciona incluso contra programas que no saben ejecutar scripts.

Qué detecta el bloqueo por IP

  • Bots de servidor. La mayoría de bots baratos, scrapers y escáneres funcionan en centros de datos. Bloquear los ASN de hosting los elimina casi sin errores. Más en el artículo VPN, proxies e IP de centros de datos.
  • VPN conocidas y proxies de servidor. Sus direcciones entran en las bases con regularidad.
  • Direcciones que se repiten. Un límite de clics por IP y una lista negra de IP frenan a los visitantes insistentes y al competidor que hace clic desde su oficina.
  • Geo equivocada. Un clic desde un país al que no segmentaste casi nunca es un comprador.

Puntos débiles del bloqueo por IP

  • Proxies residenciales y móviles. El bot sale a internet por la dirección de un abonado doméstico o por la SIM de un operador. Para un filtro por IP, es una persona normal. Hay un artículo aparte sobre esto: proxies residenciales y móviles.
  • Direcciones compartidas. Detrás de una IP móvil hay cientos de abonados, detrás de una de oficina, decenas de empleados. Bloquearla deja fuera a personas reales.
  • Rotación. Un bot que cambia de dirección en cada clic esquiva los límites de frecuencia y las listas negras.
  • Retraso de las bases. Una dirección nueva llega a la base horas o días después, y para entonces ya ha hecho su trabajo.
  • Sin visión interna. La IP no dice si es un navegador o un script, si tiene pantalla o si el ratón se mueve.

Verificación JavaScript: cómo funciona

La página entrega al visitante un script pequeño. Se ejecuta en el navegador y recoge lo que solo se ve desde dentro:

  • señales de automatización: la bandera webdriver, rastros de herramientas de control del navegador, rasgos típicos del modo headless;
  • huella del dispositivo: pantalla, tarjeta gráfica, fuentes, capacidades del navegador;
  • ajustes del sistema: zona horaria, idioma, distribución del teclado;
  • coherencia: si lo que declara la cabecera User-Agent coincide con lo que el navegador realmente sabe hacer;
  • comportamiento: movimientos del ratón y del dedo, scroll, tiempo hasta la primera acción.

El script envía el resultado al servidor y el servidor decide. Cómo se construye la huella y dónde se falsifica lo contamos en navegadores headless y huella digital del navegador.

Qué detecta la verificación JavaScript

  • Programas sin navegador. Los scrapers y bots simples que descargan la página pero no ejecutan el script nunca devuelven respuesta. Eso ya es una señal fuerte.
  • Navegadores headless y automatización. Incluso con una IP residencial, un bot que maneja un navegador deja rastros.
  • Dispositivos falsificados. Un «iPhone» con tarjeta gráfica de servidor y pantalla de 1920×1080 se delata por la contradicción.
  • Desajuste entre red y sistema. IP de Alemania, pero zona horaria e idioma asiáticos. La red no lo ve, el script sí.
  • Comportamiento mecánico. Movimientos perfectamente rectos, salida instantánea, un clic sin ningún movimiento previo.

Puntos débiles de la verificación JavaScript

  • Tiempo. Hay que descargar el script, ejecutarlo y esperar la respuesta del servidor. Es un retraso que el bloqueo por IP no tiene.
  • No todas las visitas la ejecutan. Los navegadores integrados de las redes sociales a veces cargan la página en segundo plano y congelan los temporizadores; los móviles antiguos ejecutan el script despacio; parte de la gente se va antes de que termine la verificación.
  • Se puede falsificar. Los datos vienen del cliente, así que un bot avanzado puede sustituirlos. Los navegadores antidetect existen justo para eso.
  • Falsos positivos en dispositivos poco comunes. Los WebView de las apps, los navegadores reforzados en privacidad, las extensiones que bloquean la huella: todo parece una falsificación, aunque detrás de la pantalla haya una persona.
  • Depende de dónde esté instalada. El script solo funciona donde está puesto. Si el enlace lleva a una página sin él, no hay verificación.

Comparación de los enfoques

Bloqueo por IP Verificación JavaScript
Cuándo decide antes de servir la página después de cargar el script
Impacto en la velocidad casi ninguno unas décimas de segundo
Bots de servidor los detecta muy bien los detecta, pero más tarde y más caro
Bots en IP residenciales y móviles casi no los ve los ve por el navegador y el comportamiento
Programas sin JavaScript solo si la dirección es de servidor por la falta de respuesta
Falsificación los proxies cambian la dirección los navegadores antidetect cambian los datos
Principal riesgo de error direcciones compartidas, bloqueos amplios WebView, navegadores privados, móviles lentos

La tabla deja ver lo esencial: los puntos débiles de los dos enfoques casi no se solapan. Lo que la red no ve, lo ve el navegador, y al revés.

Por qué se combinan

Con solo bloqueo por IP, todo el fraude en direcciones residenciales y móviles atraviesa el filtro, y es justo su parte más cara: los clics parecen reales y se pagan a precio completo. Con solo el script, cada bot de servidor recibe la página, descarga el script y carga el servidor, mientras que los bots simples que no ejecutaron la verificación no se distinguen de las personas que no esperaron a que cargara la página.

Un esquema que funciona es este:

  1. La red como primera capa. Se cortan sin contemplaciones los centros de datos, los bots conocidos, las direcciones de la lista negra y la geo equivocada. Es barato, rápido y casi sin errores.
  2. El navegador como segunda capa. Todo lo que pasó la red lo revisa el script: automatización, huella, zona horaria e idioma, comportamiento.
  3. Puntuación de confianza en lugar de prohibiciones. Las señales suaves (marca de proxy, dirección móvil, zona horaria que no cuadra, falta de click ID) no bloquean la visita por sí solas, se suman. La decisión se toma por el total.
  4. Estadísticas por fuente como tercera mirada. Ni la mejor verificación de una visita sustituye mirar la fuente de tráfico completa: proporción de visitas sospechosas, conversiones, tasa de aprobación. Así se ven los clics de granjas y el fraude publicitario sistemático.

Así los errores juegan a favor del anunciante: a una persona real con VPN no se la corta por una sola señal, y un bot con dirección doméstica no pasa solo porque la dirección esté limpia.

Cómo afecta a la velocidad de la página

La velocidad importa por algo más que la comodidad: cada segundo extra de carga baja la conversión, y una protección que espanta a los compradores sale más cara que los bots. Qué se puede hacer:

  • Resolver la parte de red por adelantado. Mientras el navegador carga el script, el servidor ya puede revisar la IP, el ASN y las bases. Cuando el script envía sus datos, media decisión está tomada.
  • Script pequeño y una sola conexión. Cuantas menos peticiones y más cerca esté el servidor del visitante, menos espera. Un script comprimido y la reutilización de la conexión ahorran decenas de milisegundos en móvil.
  • No esperar el comportamiento donde no hace falta. Revisar los movimientos del ratón exige que el visitante haga algo en la página. Se activa para fuentes estrictas, no para todo el tráfico.
  • Cortar a los bots de servidor antes del script. Si un bot cae por la red, no hace falta servirle el script: se ahorran recursos del servidor y las estadísticas quedan más limpias.
  • Medir. Mira el tiempo desde el clic hasta que se muestra la página en visitas reales, no una prueba de laboratorio en un ordenador rápido.

Conclusión sobre la velocidad: bien implementada, la verificación combinada añade fracciones de segundo a la carga. Es bastante menos de lo que se pierde con imágenes pesadas y contadores de terceros, e incomparablemente más barato que los clics de bots pagados.

Ejemplo: tres visitas vistas por dos capas

Para ver cómo se complementan los enfoques, tomemos tres clics en una misma campaña segmentada a Alemania.

Visita A. Dirección de un hosting en la nube en Fráncfort, la cabecera del navegador dice Chrome reciente en Windows. La capa de red la corta al instante: una red de hosting en tráfico publicitario es un servidor, no un comprador. Ni siquiera hizo falta el script, la página no se sirvió y el servidor no gastó recursos.

Visita B. Dirección de un proveedor doméstico en Múnich, limpia en las bases, click ID presente. Por la red no hay nada que objetar. El script informa: bandera de automatización activada, tarjeta gráfica por software, zona horaria America/New_York, ningún movimiento del ratón antes del clic. El bloqueo por IP habría dejado pasar esta visita y la habrías pagado como real. La capa del navegador la detiene.

Visita C. Dirección móvil de un operador alemán, marcada como compartida, navegador integrado de una red social, zona Europe/Berlin, idioma alemán. El script se ejecutó con retraso porque la app cargaba la página en segundo plano. Si el filtro cortara las direcciones móviles o exigiera una respuesta inmediata del script, este comprador se habría perdido. La puntuación de confianza ve que las señales cuadran y deja pasar la visita.

En este ejemplo cada capa por separado se habría equivocado al menos una vez: solo la red habría dejado pasar la visita B, y un script rígido sin puntuación de confianza habría arriesgado cortar la visita C. Juntas resolvieron bien las tres. Con tráfico real pasa lo mismo: la capa de red, barata, quita la mayor parte de la basura, la del navegador atrapa lo que se disfraza de persona, y la suma de señales protege contra rechazos innecesarios.

Dónde la verificación sobra o perjudica

  • Páginas sin tráfico de pago. Si ningún anuncio lleva a la página, una verificación estricta del navegador estorba más de lo que ayuda.
  • Fuentes donde casi todo llega por navegador integrado. Ahí conviene suavizar la exigencia de ejecutar el script y apoyarse en la puntuación de confianza.
  • Rastreadores de buscadores en el sitio principal. Hay que proteger las landing pages de las campañas, no todo el sitio con su tráfico SEO. Más sobre cómo elegir en antibot para sitio web.

Cómo funciona en ArtisanClo

ArtisanClo usa las dos capas: las comprobaciones de red filtran el tráfico de centros de datos, VPN y proxies, y la verificación del navegador detecta la automatización y la falsificación del dispositivo en direcciones que por la red parecen limpias. Cada clic del registro muestra el código de motivo de la decisión, así que se ve enseguida si actuó la red o el navegador. El tracker integrado cuenta gasto, conversiones, beneficio y ROI por campaña, de modo que se ve cuánto dinero se fue en tráfico basura y qué fuente lo trae. Todas las comprobaciones están en la página de funciones.

En resumen

El bloqueo por IP y la verificación JavaScript responden a preguntas distintas: de dónde vino la visita y qué programa la envió. El primero es rápido, barato y fiable contra bots de servidor, pero no ve los proxies en direcciones domésticas y móviles. La segunda ve el navegador por dentro, pero cuesta tiempo, los bots avanzados la falsifican y falla con dispositivos poco comunes. Sus puntos débiles casi no se solapan, por eso la red va en la primera capa, el navegador en la segunda, las señales suaves se suman en una puntuación de confianza y el resultado se contrasta con las estadísticas por fuente. Para calcular cuánto cuestan los bots que se cuelan, lee cuánto presupuesto se pierde con los bots.

Preguntas frecuentes

01

¿Qué protege mejor contra bots: el bloqueo por IP o la verificación JavaScript?

Ninguno resuelve el problema por sí solo. El bloqueo por IP elimina de forma rápida y barata servidores, VPN conocidas y direcciones de listas negras, pero no ve los bots en IP residenciales y móviles. La verificación JavaScript detecta navegadores automatizados y dispositivos falsificados, pero un bot puede no ejecutarla o falsear los datos. Lo más fiable es la red como primera capa y el navegador como segunda.

02

¿La verificación JavaScript ralentiza la carga de la página?

Un poco. El script tiene que cargarse, recoger datos y recibir la respuesta del servidor, normalmente unas décimas de segundo, algo más con internet móvil lento. El retraso se reduce si las comprobaciones de red corren en paralelo al script y el script es pequeño y se sirve desde un servidor cercano.

03

¿Se puede saltar la verificación JavaScript?

Un bot simple sin JavaScript directamente no la pasa. Un bot avanzado sobre un navegador real ejecuta el script, pero deja rastros de automatización e incoherencias en la huella. Un navegador antidetect bien disfrazado y con comportamiento humano es difícil de distinguir, por eso el script se complementa con el análisis del comportamiento y las estadísticas por fuente.

04

¿Por qué el bloqueo por IP corta a personas reales?

Porque una dirección no pertenece a una sola persona. Detrás de una IP móvil hay cientos de abonados, detrás de una de oficina está toda la oficina, y la dirección de un proveedor doméstico pasa a otro cliente. Un bloqueo amplio por subred o por país acaba afectando a compradores, por eso las señales de red suaves conviene tratarlas como penalización.

05

¿Qué hacer con los visitantes que tienen JavaScript desactivado?

Entre la gente que llega desde anuncios son muy pocos: JavaScript desactivado casi siempre indica un programa. Aun así, exigir la ejecución del script debe depender de la fuente: en algunas apps el navegador integrado carga la página en segundo plano y ejecuta el script con retraso.

Sigue leyendo

Comprueba tu tráfico en la práctica

Conecta ArtisanClo a tu sitio, mira quién llega realmente desde tus anuncios y por qué cada clic recibió su decisión.