El tráfico de aocr.org es un bot: cómo detectarlo y filtrarlo

En resumen: las visitas desde aocr.org en tus analíticas no son usuarios reales. Vienen de un bot que se hace pasar por un Chrome normal y envía un referrer falso. Ya ha dejado 388 sesiones en ocho de nuestros sitios, y en uno de los más pequeños llegó a ser una de cada seis sesiones. Puedes filtrarlo en el panel de analítica o en el servidor, por la cabecera Referer. No bloquees IP, no confíes en robots.txt y no te pongas en contacto con aocr.org.

Qué es este bot y cómo reconocerlo

El análisis más completo es el artículo de tin.computer del 29 de octubre de 2026. Da por confirmadas tres cosas: la huella de red del bot (TLS, HTTP/2, cabecera Accept) coincide con Bytespider, el crawler declarado de ByteDance; sus grabaciones de sesión contienen campos de tiempo con el nombre de Forest, el cargador interno de recursos de ByteDance; y una fuga de WebRTC situó las máquinas reales en la red de centros de datos de China Mobile en Shanxi. No está establecido quién lo opera: un equipo de ByteDance o un cliente de un servicio en la nube de ByteDance, como Volcano Engine. El sitio aocr.org pertenece al American Osteopathic College of Radiology y no tiene nada que ver con todo esto. Cubrimos la parte informativa en nuestra noticia sobre el bot de aocr.org en nowosci.ai (en polaco).

Nuestras propias analíticas cuentan lo mismo. A 7 de noviembre, nuestro Umami autoalojado registra 388 sesiones con referrer aocr.org en ocho sitios, 321 de ellas en el más grande. Según tin.computer, otros propietarios de sitios vienen reportando el bot desde alrededor del 24 de septiembre; en nuestros datos, las primeras visitas son del 18 de septiembre de 2026. Hubo unas pocas decenas de sesiones hasta finales de octubre, y en noviembre el bot aceleró bruscamente: solo el 6 de noviembre sumó 206 sesiones. Cada visita se delata con el mismo conjunto de rasgos:

• Un referrer aocr.org. La cabecera dice https://www.aocr.org/ y Umami lo guarda como aocr.org. Las peticiones además llevan Sec-Fetch-Site: none, el valor que envía un navegador cuando la dirección se escribe a mano o la abre un programa; un clic real desde aocr.org enviaría cross-site (tin.computer).
• Pantalla de 800x600, Windows 10, Chrome 146, en-US. En nuestros datos casi todas las sesiones son de 800x600 (dos fueron de 600x800), y el sistema operativo, el navegador y el idioma coinciden en el 100% de ellas. El user agent por sí solo no demuestra nada, porque el bot imita a un Chrome normal.
• Una página, unos 25 segundos. En el 96% de las visitas el bot ve una sola página, la mediana de la visita en nuestro Umami es de 23,6 s y tin.computer midió unos 28 s de espera y desplazamiento.
• Una IP nueva en casi cada visita, sobre todo de redes de hosting y proxy: Datacamp/CDN77, Web2Objects, M247, Ace Data Centers, NET3. Son las mismas redes que tin.computer enumeró de forma independiente. Por eso Estados Unidos domina el informe de países (75% de nuestras sesiones), aunque solo refleja dónde están los proxies.
• La zona horaria Asia/Shanghai junto a una IP estadounidense y el idioma inglés (tin.computer). En PostHog la encontrarás en la propiedad $timezone.
• Una curiosidad de nuestros logs: el Referer falso se adjunta a cada petición: archivos CSS y JS, imágenes e incluso la llamada de analítica. Un navegador normal enviaría ahí la dirección de tu página, así que la cabecera la pone la automatización, no el navegador. Justamente por eso funciona filtrar por ella.

Cómo filtrarlo

• Umami: en tus vistas, añade un filtro de Referrer “is not” aocr.org, sin www, porque así guarda Umami el dominio. Las visitas antiguas se quedan en la base de datos, pero dejan de distorsionar tus gráficos.
• Plausible y Fathom: excluye el referrer www.aocr.org en tus filtros (consejo de tin.computer). Revisa tu informe de fuentes para ver si la herramienta guarda el dominio con o sin www.
• GA4: crea un segmento que excluya las sesiones con la fuente aocr.org (consejo de tin.computer).
• PostHog: excluye los eventos en los que $referring_domain sea www.aocr.org. Si el bot cambia de referrer, tin.computer sugiere filtrar por $timezone = Asia/Shanghai junto con $screen_width = 800.

Si alojas tú mismo tus analíticas, puedes dejar de contar el bot por completo. Desde el 7 de noviembre lo hacemos en nginx, delante de Umami: cada llamada al tracker (/api/send) cuya cabecera Referer apunte a aocr.org recibe una respuesta 204 vacía y nunca llega a la base de datos. Las páginas siguen disponibles; solo se bloquea el conteo. Y como un navegador real envía al tracker la dirección de tu página, un visitante genuino de aocr.org (si alguna vez aparece) sigue contándose. Esta es la versión mínima de la regla, con el bloque map en el contexto http:

map $http_referer $aocr_referrer {
    default 0;
    "~*^https?://([^/]+\.)?aocr\.org(/|$)" 1;
}

server {
    # ... the server block of your analytics host
    location = /api/send {
        if ($aocr_referrer) { return 204; }
        proxy_pass http://127.0.0.1:3000;  # your Umami upstream
    }
}

¿Quieres detener el bot y no solo dejar de contarlo? Para Cloudflare, tin.computer propone una regla personalizada de WAF con la acción Managed Challenge: la cabecera Accept contiene image/heif,image/avif y no hay cabecera sec-ch-ua. Una segunda regla, más sencilla, comprueba si el campo http.referer contiene aocr.org. Antes de activar el challenge, mira qué captura la regla: tin.computer recomienda empezar en modo de registro (log), si tu plan lo incluye. El autor también señala que la regla por huella afecta de paso al Bytespider declarado.

Qué no hacer

• No bloquees direcciones IP. En los logs de nuestro servidor, 5365 peticiones del bot llegaron desde 1020 direcciones distintas, y solo 7 de ellas aparecieron más de un día. Una lista de bloqueo así queda obsoleta antes de desplegarla. El artículo de tin.computer dice lo mismo.
• No confíes en robots.txt. El bot no se identifica como Bytespider, así que una regla para Bytespider no le afecta. Si quieres bloquearlo, hazlo en la CDN o en el firewall.
• No te pongas en contacto con aocr.org. Es el sitio web del American Osteopathic College of Radiology, nada indica que haya sido hackeado y tin.computer pide expresamente que no se les contacte por este tráfico.
• No te apresures a borrar el historial. Nosotros mantuvimos las visitas antiguas en la base de datos y las ocultamos con un filtro. Si el bot cambia de referrer, los datos en bruto te ayudarán a rastrearlo por sus otros rasgos.

Por qué importa en proyectos pequeños

Medimos la proporción del bot desde su primera visita en cada sitio. En nuestro sitio más grande es el 0,18% de las sesiones, porque el tráfico alto lo diluye. En raba.pl ya es el 8,45% (18 de 213) y en openclaw.com.pl, el 16,3% (7 de 43). Si desarrollas proyectos paralelos con vibecoding y usas las analíticas para decidir cuál está despegando, este bot te suma usuarios que no existen. Lo mismo vale para un agente al que le das acceso a tus estadísticas. También distorsiona otras cifras: en nuestro sitio más grande acumuló 924 “visualizaciones” de banners de socios y envió 321 peticiones de eventos a PostHog. Los filtros de analítica y la regla de nginx no bloquean contenido, solo el conteo de visitas, así que son unos minutos de trabajo que no cambian quién puede leer tu sitio.

Fuentes: tin.computer: Getting traffic from aocr.org? That's ByteDance crawling your website.