Bots buenos frente a bots malos: clasifica antes de bloquear

Una IP solicita 600 páginas en 10 minutos. Si es un scraper de precios, querrás detenerlo. Si es Googlebot descubriendo un sitemap nuevo, bloquearlo puede retrasar miles de productos. El comportamiento parece igual de «rápido», pero las decisiones operativas son opuestas.

Los bots buenos y los malos no se pueden separar solo por el user agent, la velocidad o la compatibilidad con JavaScript. Responde a tres preguntas: quién es, qué está haciendo y qué impacto genera.

Bots buenos, malos y desconocidos

Bots buenos

Un bot bueno cumple un propósito que el sitio acepta o del que se beneficia:

• rastreadores de buscadores;
• monitores de enlaces, de disponibilidad o de seguridad que configuraste tú;
• obtención de vistas previas para compartir en redes sociales;
• servicios autorizados de accesibilidad o de archivo;
• clientes de API de socios bajo un acuerdo.

Bueno no significa sin restricciones. Googlebot sigue las reglas de robots en el rastreo automático; tu monitor también debería tener límites de endpoints y de frecuencia.

Bots malos

La automatización mala causa daños o accede al sitio en contra de su propósito:

• clics fraudulentos en anuncios;
• scraping de precios, contenido o datos de clientes;
• credential stuffing y ataques a contraseñas;
• creación de cuentas, spam en formularios o retención de inventario;
• escaneo de vulnerabilidades;
• tráfico falso que corrompe el analytics.

Bots desconocidos

Suele ser el grupo más grande: herramientas SEO, aplicaciones móviles, navegadores headless, proxies de pruebas o servicios de IA nuevos. Un bloqueo inmediato puede romper una integración; el acceso sin restricciones crea riesgo.

El rate limiting y la observación suelen ser mejores que una decisión binaria para este grupo.

Un user agent no es una identificación

Una solicitud que dice:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

no ha demostrado que venga de Google. Cualquier script puede copiar ese texto.

Google recomienda:

1. el DNS inverso debe devolver un hostname válido de Google y el DNS directo debe resolver de vuelta a la misma IP;
2. comparar la IP de origen con los rangos de rastreadores publicados por Google.

Crear una lista de permitidos solo por user agent invita a la suplantación. Bloquear solo por user agent deja pasar a los bots que fingen ser navegadores.

Una matriz de señales para clasificar bots

Ninguna señal aislada es perfecta. Combina varias:

Un rastreador legítimo puede ser rápido y estar verificado, respetar robots y centrarse en el contenido público. Un scraper puede decir que es Chrome mientras omite los recursos, rota las IP y recolecta solo productos.

Seis patrones de comportamiento sospechosos

1. Velocidad alta sin ritmo humano

Cientos de clics separados exactamente por 200ms difícilmente son humanos. Los rastreadores legítimos también son rápidos, así que combina la velocidad con la identidad y las URL objetivo.

2. Las solicitudes se centran solo en endpoints con valor de negocio

Los bots de inventario llaman a la funci?n de a?adir al carrito, los bots de ataque a credenciales se centran en el inicio de sesi?n y el fraude de clics golpea repetidamente las p?ginas de destino de los anuncios; saltarse la navegaci?n normal es una pista s?lida para detectar el fraude de clics.

3. La huella digital y el user agent no coinciden

El user agent dice ser Safari en iPhone mientras que el TLS, el orden de las cabeceras o el viewport se parecen a un Chromium headless de escritorio. La incoherencia es más útil que el texto del propio user agent.

4. Las IP rotan mientras la evidencia del dispositivo permanece

Los proxies residenciales permiten a la automatización cambiar de dirección. Si se repiten las cookies, las huellas digitales, el comportamiento y los objetivos, bloquear una IP cada vez se vuelve interminable.

5. Nunca se cargan los recursos de apoyo

Los navegadores suelen descargar el CSS, el JavaScript, las fuentes y las imágenes necesarios. Un scraper sencillo puede solicitar solo HTML o API. La caché y las herramientas de privacidad hacen que esta sea una señal complementaria, no una prueba.

6. Los fallos avanzan a lo largo de una lista

Los nombres de usuario, cupones, datos de tarjetas o rutas de administración secuenciales delatan la automatización. Los límites por IP no bastan contra bots distribuidos; incluye las dimensiones de cuenta, huella digital y acción.

Evita bloquear a los bots buenos con reglas toscas

Bloquear todos los centros de datos

Muchos bots malos usan centros de datos, pero también lo hacen los monitores, los webhooks, los rastreadores de buscadores y los servicios empresariales. Esto puede encajar en una acción sensible como un cupón, pero no en todo un sitio público.

Bloquear a todo cliente rápido

Los rastreadores de buscadores y los monitores de disponibilidad envían ráfagas válidas. Los rate limits deben reflejar la sensibilidad del endpoint y la identidad verificada.

Exigir desafíos de JavaScript en todas partes

Los rastreadores de buscadores pueden renderizar algo de JavaScript, pero los desafíos antibots, las cookies obligatorias y los CAPTCHA pueden bloquear el descubrimiento. El contenido público importante necesita un camino limpio para los rastreadores verificados.

Confiar para siempre en una lista de permitidos antigua

Los rangos de IP, los servicios y las necesidades del negocio cambian. Cada entrada de una lista de permitidos necesita una fuente, un responsable, una fecha de revisión y un registro de uso.

Política de respuesta según el riesgo

Nivel 1: permitir y registrar

Para rastreadores verificados, monitorización propia y socios conocidos. Las áreas privadas siguen requiriendo autenticación; «bot bueno» no es una autorización.

Nivel 2: rate limit suave

Para automatización desconocida que lee contenido público. Devuelve 429 con Retry-After al superar el umbral en lugar de bloquear permanentemente por un pico breve.

Nivel 3: desafío o capacidad reducida

Para comportamientos de riesgo medio: búsquedas rápidas, carritos repetidos o envíos de formularios. Introduce comprobaciones de JavaScript, un CAPTCHA según umbral o datos reducidos.

Nivel 4: bloquear

Para el credential stuffing, los intentos de explotación, el spam confirmado, el click fraud fundamentado o las coincidencias con una denylist de calidad.

Nivel 5: investigar y conservar las pruebas

En el fraude publicitario sostenido o en las campañas de ataque, conserva el ID de solicitud, la marca de tiempo, la IP con hash, el user agent, la huella digital, la campaña y la acción. Evita almacenar datos personales más allá de lo necesario; el objetivo es poder reproducir las decisiones.

Protege cada superficie de forma distinta

Páginas de contenido y SEO

Permite a los rastreadores verificados, usa una caché agresiva, aplica rate limits a la automatización desconocida y vigila el scraping. No pongas un CAPTCHA delante de los artículos o categorías que deban indexarse.

Login y restablecimiento de contraseña

Limita por cuenta y por IP, detecta las listas de nombres de usuario, usa MFA y avisa ante picos de fallos. Las IP residenciales de bots aún pueden detectarse por los patrones de acción.

Formularios de leads

Los honeypots, el tiempo mínimo de relleno, la validación en el servidor y los rate limits reducen el spam. El CAPTCHA por sí solo es insuficiente frente a granjas asistidas por humanos.

Checkout y cupones

Vigila la velocidad por cuenta, dispositivo, tarjeta y cupón. Bloquear los centros de datos puede ayudar, pero quizá necesite excepciones para los clientes corporativos.

Landing pages de publicidad

Registra la campaña, el ID de clic, la marca de tiempo y la puntuación de calidad. Compara los clics de la red publicitaria con las sesiones, los logs y las conversiones. Las exclusiones financieras requieren más pruebas que una sola solicitud sospechosa.

Investigar una IP o una huella digital

1. Clasifica la dirección con el IP Checker.
2. Verifica el DNS inverso cuando diga ser un rastreador importante.
3. Obtén la secuencia de acciones en una ventana de 5–30 minutos.
4. Compara el user agent, las cabeceras, la huella digital y las solicitudes de recursos.
5. Revisa la campaña, la landing page y el valor de la acción.
6. Asigna un nivel de confianza en lugar de una etiqueta absoluta de verdadero o falso.
7. Elige entre permitir, limitar, desafiar o bloquear.
8. Dale una fecha de caducidad a las reglas temporales.

Una puntuación de 0–100 conserva la zona gris:

• 80–100: señales humanas claras;
• 50–79: vigilar o aplicar límites ligeros;
• menos de 50: varias señales de automatización o de riesgo.

Los umbrales dependen del producto. Los blogs, los bancos y los juegos tienen una tolerancia al riesgo distinta.

Trata los falsos positivos como una métrica de producto

Un sistema que detiene el 99% de los bots pero pierde al 5% de los clientes reales puede ser peor que uno menos agresivo. Monitoriza:

• los desafíos superados;
• los visitantes bloqueados que contactan con soporte;
• la conversión antes y después de una regla;
• los bots que regresan con IP nuevas;
• los endpoints con tasas altas de falsos positivos.

Cada regla necesita un motivo, un responsable y una vía de reversión. «Esta IP me parece rara» no es una política operativa.

Gobierna las reglas de bots como código de producción

Los controles de bots tienden a acumularse. Un bloqueo de IP de emergencia añadido durante un ataque puede permanecer años, mucho después de que la dirección cambie de propietario. Trata las reglas como lógica de producción con versiones.

Cada regla debería registrar:

• el comportamiento o el incidente que la justificó;
• las señales usadas y el nivel de confianza;
• los endpoints y los grupos de usuarios afectados;
• el responsable y la fecha de aprobación;
• la fecha de caducidad o de revisión;
• las instrucciones de reversión;
• las métricas de falsos positivos que vigilar.

Prueba los nuevos controles en modo solo informe siempre que el riesgo lo permita. Registra qué solicitudes se habrían limitado o bloqueado y compáralas con los inicios de sesión, las compras, los rastreadores verificados y las quejas a soporte que hayan tenido éxito. Este periodo en la sombra revela las regex amplias y las reglas de red antes de que afecten a los clientes.

Despliega por superficie y no de forma global. Una regla estricta puede ser adecuada para canjear cupones pero perjudicial en las páginas de documentación. Una política específica para cada endpoint también produce métricas más claras cuando algo cambia.

Mantén un bypass de emergencia para las operaciones verificadas y una vía de reversión rápida. Durante un incidente de falsos positivos, esperar a un despliegue completo de la aplicación puede costar más que la automatización que la regla estaba diseñada para detener.

Por último, revisa las listas de permitidos con tanto cuidado como las denylist. Un token de socio comprometido o una excepción obsoleta para un rastreador pueden convertirse en una brecha permanente. La confianza debe estar acotada, ser observable y revalidarse periódicamente.

¿Es robots.txt una herramienta de defensa contra bots?

Robots.txt es una convención para rastreadores cooperativos. La automatización maliciosa puede ignorarlo. Sigue siendo esencial para Googlebot y los rastreadores legítimos, pero no sustituye a un WAF, a la autenticación, al rate limiting ni al análisis de comportamiento.

Usa el Robots.txt Checker para asegurarte de que un cambio contra el scraping no haya bloqueado por accidente a los rastreadores de buscadores.

Mira el panorama completo: lee cómo funciona el Quality Score del tráfico y ejecuta una auditoría SEO gratuita antes de aplicar una regla de bloqueo en todo el sitio.

Conclusión

Verifique la identidad del rastreador con el método oficial del proveedor y revise sus acciones. Las cabeceras de seguridad no establecen su identidad ni si el WAF permite su acceso.

Referencias: Google Search Central – Googlebot y Google crawler overview.