Contadores de visitas: bots que ejecutan JavaScript

Publié le 06 novembre 2026

Mano robótica blanca frente a una red de puntos luminosos conectados sobre fondo azul, símbolo de un bot visitante

La mañana del 4 de noviembre de 2026, el contador de VosPosts mostraba una cifra halagadora: 3352 visitantes «humanos» en un día y otros 2272 antes de la una de la madrugada, en un sitio que suele recibir unas 400 visitas diarias. Nadie había compartido artículos ni se había viralizado ningún enlace. Eran simplemente bots, y nuestro contador los confundía con lectores.

Contamos cómo lo descubrimos, por qué ya no sirve la regla clásica «si ejecuta JavaScript, es humano» y cómo identificar esas visitas falsas en los registros del servidor.

La trampa: «se ejecutó JavaScript, así que es humano»

Muchos contadores propios, incluido el nuestro, se basan en una idea sencilla: el servidor registra la página solicitada y después un pequeño script del navegador envía otra petición que «certifica» la visita. Los bots antiguos solo descargaban HTML sin ejecutar código: la segunda petición nunca llegaba y quedaban fuera de las estadísticas.

Ese filtro ya hace aguas. Hoy muchos bots ejecutan JavaScript como un navegador real:

Los buscadores renderizan las páginas para comprenderlas: Googlebot utiliza Chromium actualizado, y también aparecen Baiduspider-render, Applebot, Bytespider (ByteDance) y meta-webindexer.
El bot publicitario de AdSense (Mediapartners-Google) visita páginas para analizar su contenido.
Los scrapers modernos controlan navegadores reales sin interfaz: Chrome headless, Puppeteer, Playwright o motores más ligeros como Lightpanda, pensados para automatización y agentes de IA.

Para un contador basado en ejecutar scripts, todos parecen lectores. Lo más inquietante es que el problema precedía al ataque: al revisar el 3 de noviembre, un día totalmente normal, descubrimos que 446 de las 621 visitas consideradas humanas eran bots. Más de siete de cada diez.

Señales de un scraper con navegador sin interfaz

El pico del 4 de noviembre presentaba todos los rasgos de un scraping organizado. Ninguna pista demuestra nada por separado; juntas dejan pocas dudas.

Una IP distinta para cada página

Cada página se solicitaba desde una IP diferente, distribuida por todo el mundo. Es característico de los proxies residenciales: redes que canalizan peticiones mediante conexiones domésticas, a menudo sin conocimiento de sus titulares. Por eso bloquear IP no sirve: hay miles y pertenecen a hogares reales.

Navegadores obsoletos desde hace años

Los agentes de usuario repetían una lista reducida: Chrome 118 a 120, Firefox 120 y 121 y Edge 119 y 120. Son versiones de finales de 2023. Sin embargo, Chrome y Firefox se actualizan automáticamente cada cuatro semanas aproximadamente; nuestros lectores reales utilizaban Chrome 148 a 156. Una persona con un navegador de tres años es posible; miles en una noche revelan una lista fija copiada en una herramienta de scraping.

Entre esas identificaciones aparecía incluso, sin disfraz alguno, Lightpanda/1.0.

Un comportamiento demasiado uniforme

Solo ordenadores de escritorio, ningún móvil, aunque la mayor parte del tráfico real procede de teléfonos;
ningún referente: nadie llegaba desde Google, redes sociales u otras webs;
2340 búsquedas diferentes en el buscador interno para extraer el máximo número de páginas;
24 772 peticiones durante el día, el 42 % de todo el tráfico del servidor.

El riesgo oculto: los anuncios

Un navegador sin interfaz ejecuta todo, incluida la carga de espacios publicitarios: ese día, el bot cargó nuestros bloques de anuncios 2939 veces. Para un editor de AdSense es importante: las impresiones de bots constituyen tráfico no válido, que Google descuenta de los ingresos y que, si se repite, puede poner en peligro la cuenta. Un contador inflado no es solo cuestión de ego.

Cómo detectar bots en los registros

Los registros de acceso de Apache o Nginx en formato «combined» contienen todo lo necesario. Bastan unos comandos. Primero, los agentes de usuario más frecuentes:

awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -30

Después, la distribución de versiones de Chrome. En una web normal, la mayoría se concentra en las cuatro o cinco versiones recientes; un grupo numeroso de versiones antiguas destaca enseguida:

grep -oE 'Chrome/[0-9]+' access.log | sort | uniq -c | sort -t/ -k2 -n

El volumen por hora permite precisar el comienzo y el final de una oleada:

awk '{print substr($4, 2, 14)}' access.log | sort | uniq -c

Por último, para una firma sospechosa, compara las peticiones con las IP diferentes. Si las cifras son casi iguales, has encontrado tu red de proxies:

grep -c 'Chrome/119.0.0.0' access.log
grep 'Chrome/119.0.0.0' access.log | awk '{print $1}' | sort -u | wc -l

Un detalle útil: desde 2022, Chrome solo envía su versión principal seguida de .0.0.0. Por tanto, Chrome/119.0.0.0 es un formato normal; lo que delata al bot es el 119.

Qué medidas aplicamos

Dejar de contar sin bloquear

Primera capa: el contador decide en el servidor si una visita merece contarse. Ya no se registra como humana cuando el agente de usuario está vacío, declara ser un bot (bot, spider, crawler, herramientas HTTP como curl o Python, navegadores sin interfaz) o indica un Chrome o Firefox de más de dos años y medio. El umbral se recalcula con la fecha, sin actualizar versiones a mano:

$jours = (time() - mktime(0, 0, 0, 12, 5, 2023)) / 86400; // Chrome 120, décembre 2023
$version_actuelle = 120 + (int)floor($jours / 28);           // une version toutes les 4 semaines
if (preg_match('/Chrome/(d+)./', $ua, $m) && (int)$m[1] < $version_actuelle - 32) {
    return true; // navigateur trop ancien pour être un lecteur réel
}

Una precaución importante: siempre contamos a los usuarios que han iniciado sesión, independientemente del navegador. El filtro apunta a desconocidos, no a miembros fieles que no han actualizado su viejo ordenador.

Rechazar scrapers y permitir buscadores

Segunda capa, más agresiva: el servidor devuelve ahora un error 403 a las firmas del scraper, con una excepción expresa para los rastreadores legítimos. En Apache bastan unas líneas:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Lightpanda|HeadlessChrome) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Chrome/1(18|19|20).0.0.0 [OR]
RewriteCond %{HTTP_USER_AGENT} Firefox/12[01].
RewriteCond %{HTTP_USER_AGENT} !(bot|spider|crawl|google|bing|facebook) [NC]
RewriteRule ^ - [F]

Las tres primeras condiciones están unidas por [OR]; la última añade un «y» implícito: se bloquea una firma salvo si el agente de usuario dice pertenecer a un buscador o red social. Tras implementarlo comprobamos ambos casos: el scraper recibe 403, mientras que Chrome reciente, iPhone, Googlebot, Bingbot y el bot de AdSense siguen accediendo.

Bloquear Googlebot por error puede costar mucho más que unas estadísticas infladas. Prueba cada regla con los agentes de usuario de los buscadores antes de activarla en producción.

Límites que conviene recordar

Un agente de usuario puede falsificarse en una línea. Cuando este scraper diga ser Chrome 155, las reglas dejarán de detectarlo. No es protección definitiva, sino higiene básica: elimina los bots descuidados, que son mayoría, y vuelve a dar sentido a las cifras. Para ir más lejos hay que combinar señales (sin referente, una página por IP, sin movimiento del ratón ni desplazamiento) o recurrir a un servicio especializado en detectar bots.

La verdadera lección es otra: un contador que miente una vez al año durante un pico espectacular probablemente miente también, más discretamente, el resto de los días. Si nunca has mirado tus registros de acceso, dedica diez minutos a ejecutar estos comandos en un día normal. Puede que el resultado te sorprenda.