Cómo detectar el web scraping: logs, consultas de IP y puntos ciegos

Una solicitud de un scraper es solo un GET. Tiene un código de estado, una ruta y un User-Agent, como cualquier otra línea de tu log. El scraping solo aparece a lo largo de cientos de líneas y en toda una red: un script de Python en un servidor en la nube, un navegador headless controlado con Puppeteer o Playwright, un rastreador de entrenamiento de IA, un rastreador SEO como AhrefsBot o una API de scraping que vende proxies rotativos por gigabyte.

El 8/10/2026 pasamos siete IP de tipo scraper por la API de GeoIPHub. Cuatro rastreadores verificados (Googlebot, CCBot, ClaudeBot, AhrefsBot) venían todos de redes de hosting y obtuvieron allow. Un servidor en la nube Linode normal obtuvo 10, también allow, y un nodo de salida de Tor y un servidor VPN de Mullvad obtuvieron ambos 100, block. La IP te da la red. El veredicto sobre el scraping sale de tus logs.

A continuación mostramos cómo detectar bots de scraping en un log de acceso, rastreamos una línea del log que dice ser Googlebot, mostramos dónde se quedan ciegos los datos de IP y relacionamos lo que encuentres con allow, limitar la frecuencia, desafiar o bloquear. Si primero quieres las señales de IP una por una, nuestra guía central cubre la detección de bots por IP, señal por señal; este artículo las aplica al scraping.

Cómo detectar el web scraping: frecuencia, ruta, cliente y red

Para detectar el web scraping, revisa cuatro grupos de señales: con qué rapidez pide un cliente (frecuencia), qué pide y en qué orden (ruta), qué dice de sí mismo (cliente) y desde dónde se conecta (red). OWASP incluye el scraping como amenaza automatizada propia, OAT-011, definida como recopilar "contenido de la aplicación u otros datos para usarlos en otro lugar" (OWASP Automated Threats). Esa definición habla de la intención, que no puedes ver. Los cuatro grupos son lo que sí puedes ver.

• Frecuencia. Solicitudes por minuto por IP y por red. Por red nos referimos al ASN o, para agrupar con más detalle, al /24 en IPv4 y al /64 en IPv6. Los scrapers suelen funcionar a una frecuencia constante las 24 horas; las personas llegan a ráfagas y duermen.
• Ruta. URL de listados y de paginación recorridas en orden, un sitemap leído de principio a fin, solo páginas de productos o de precios, y ninguna solicitud de CSS, JavaScript o imágenes.
• Cliente. Lo que declara el User-Agent, la ausencia de la cabecera Accept-Language, cookies que no se conservan entre solicitudes y marcadores de automatización. En el navegador, navigator.webdriver es true cuando Chrome se ejecuta con --headless o --enable-automation (MDN), aunque un scraper decidido lo parchea. En el edge, una huella TLS (JA3 o JA4) suele revelar una biblioteca HTTP detrás de un User-Agent que dice ser Chrome.
• Red. Lo que devuelve una consulta de IP: una IP de centro de datos (hosting), que la API marca como detection.is_hosting, un rastreador verificado, Tor, una VPN o un escáner.

Lo difícil de la detección de web scraping es que cada señal tiene un gemelo inocente. Una CDN que tira de tu origen, un monitor de disponibilidad, una oficina detrás de una sola dirección NAT y un lector de RSS parecen raros en algún eje. Los indicios de scraping salen de las señales que coinciden.

Cómo saber si están haciendo scraping de tu web: lee primero tus logs de acceso

Para saber si están haciendo scraping de tu web, agrupa tus logs de acceso por red y busca clientes que piden muchas páginas, las piden en orden y nunca cargan los recursos que cargaría un navegador. Las señales externas suelen llegar antes: los textos de tus productos o tus precios aparecen en otro sitio, o el ancho de banda y el coste de los servidores suben en las páginas de listados mientras las conversiones no se mueven. Para comprobarlo desde fuera, busca entre comillas una frase característica de tu página, y vigila si tus precios reaparecen en sitios agregadores a las pocas horas de un cambio. Los logs te dicen quién lo hizo.

Así se ve en un log de acceso en formato combinado. Son valores ilustrativos, no tráfico real. 45.33.32.156 es el host de pruebas público de Nmap en Linode, y no envió estas solicitudes; representa a "un servidor en la nube" porque no podemos publicar la IP de un visitante real.

Destacan tres cosas. Las páginas suben de una en una, con 1 o 2 segundos de separación, a las 3 de la madrugada. No hay referrer ni una sola solicitud .css o .js entre ellas. Y el cliente dice ser Googlebot, algo que se pone a prueba en las siguientes secciones.

No necesitas una plataforma de logs para encontrar clientes así. Estos comandos de una línea funcionan con un log combinado estándar; ejecútalos primero sobre una hora de mucho tráfico:

Revisa la salida con esta lista:

• Páginas visitadas. ¿Los clientes más activos se concentran en listados, precios, resultados de búsqueda o el sitemap?
• Frecuencia por IP y luego por red. Después de enriquecer las IP, suma las solicitudes por ASN; 50 direcciones de hosting de un mismo ASN que recorren las mismas páginas probablemente son un solo actor.
• Profundidad de la sesión. Cientos de páginas por sesión, sin usar el carrito, el inicio de sesión ni el buscador.
• Orden. URL de paginación o del sitemap pedidas en secuencia.
• Recursos. Solo HTML, sin CSS, JavaScript, fuentes ni imágenes.
• Identidades de rastreador. Cada User-Agent de Googlebot, Bingbot, GPTBot o ClaudeBot va a una lista para verificarlo por IP.
• Marcadores de automatización. User-Agents de bibliotecas (python-requests, curl, Go-http-client) e indicios de navegadores headless.

Direcciones IP de scrapers: qué devuelven las consultas reales de GeoIPHub

Las direcciones IP de los scrapers se reparten en unos pocos tipos de red, y una consulta te dice qué tipo estás viendo, no si la solicitud era de un scraper. En nuestras consultas de GeoIPHub, los rastreadores verificados obtuvieron de 0 a 23 (allow); las salidas de Tor y de VPN obtuvieron 100 (block). El 8/10/2026 hicimos una consulta anónima por tipo, con cuatro segundos de separación:

Son consultas únicas en un solo día, no una comparativa, y los valores cambian a medida que cambian los rangos. Un fallo conocido: el no_ptr_datacenter de las filas de Googlebot y AhrefsBot es cosa de nuestros datos, no de ellos. La API no guarda registro PTR para algunos rangos de rastreadores aunque el DNS inverso se resuelva (192.178.4.40 se resuelve a crawl-192-178-4-40.googlebot.com). En la IP de ClaudeBot la señal es correcta: no tiene DNS inverso.

Esta es la respuesta de CCBot, recortada pero con valores reales y la estructura original:

El propio rastreador de Common Crawl funciona en AWS y aun así obtiene 0. La IP está en 18.97.14.80/29, un rango que Common Crawl publica en su archivo ccbot.json, y el ajuste por rastreador verificado de nuestra puntuación (−28,5) anula la señal de centro de datos. GeoIPHub comprueba así 19 fuentes oficiales de rangos de rastreadores, entre ellas las de Google, Bing, OpenAI, Anthropic, Common Crawl y Ahrefs. Si quieres que un rastreador cuyos datos alimentan modelos de IA, como CCBot o GPTBot, lea tus páginas es una cuestión de política. La consulta solo aclara quién es.

AhrefsBot fue la sorpresa. Salió verificado (5.39.1.230 está en 5.39.1.224/27, dentro de los rangos de rastreadores publicados por Ahrefs), pero también con is_abusive: true y abusive_listed entre los métodos, para una puntuación de 23, todavía allow. No hemos averiguado qué lista lo marcó. La lección vale en cualquier caso: "verificado" te dice quién es un rastreador, no si lo quieres. Un rastreador SEO que mapea tu sitio para el informe de backlinks de un competidor sigue haciendo scraping, solo que de forma declarada.

Suplantación de rastreadores en los logs de scraping: una línea, rastreada

Una solicitud que dice Googlebot en su User-Agent pero viene de un servidor en la nube es una identidad no verificada. GeoIPHub puede decirte que la IP no está en un rango de Google, pero la comparación con el User-Agent se hace en tu código, porque la consulta nunca ve tus cabeceras. Toma la cuarta línea del log ilustrativo: 45.33.32.156, GET /products?page=37, User-Agent Googlebot/2.1.

1. Consulta la IP. La consulta real devolvió el ASN 63949, Akamai Connected Cloud (Linode), detection.is_hosting: true, threat.crawler.name: "none", verified: false, fraud_score 10, allow, con los métodos ["datacenter_ip"].
2. Compara lo declarado. Tu código compara el token del User-Agent con threat.crawler.verified y threat.crawler.name.
3. Decide. El UA dice Googlebot; la IP no está en ningún rango de Google. Eso la convierte en "no verificada como Googlebot". Limita su frecuencia o desafíala. Un desafío (un CAPTCHA o una comprobación de JavaScript) es la forma de actuar ante la acción step_up de la API. No la llames falsa: un rango nuevo de Google puede tardar hasta unos dos días en verificarse en nuestros datos, porque los archivos de rangos se descargan a diario y la base de datos de consultas se reconstruye a diario.
4. Compara con el caso real. El Googlebot real en 192.178.4.40 devolvió verified: true, name: "Googlebot", verification_method: "ip_range_list", puntuación 0.

Google documenta dos formas de hacer tú mismo la misma comprobación: DNS inverso sobre la IP seguido de una consulta directa del nombre de host, o una comparación con sus archivos de rangos publicados, como common-crawlers.json (Google Search Central). La comparación en código es así:

Este es el caso en que la puntuación dice allow y el patrón dice scraper. Solo por la IP, esta solicitud tiene 10 y allow, porque un servidor en la nube es una señal débil por sí sola. El veredicto de scraping sale de tres cosas que la puntuación no ve: la discrepancia del UA, la frecuencia constante y el recorrido página a página. Para el procedimiento completo de Google, consulta cómo verificar Googlebot por DNS inverso y con los archivos de rangos de Google; para GPTBot, ClaudeBot y los agentes firmados, consulta cómo verificar rastreadores de IA por IP, DNS inverso y Web Bot Auth.

Lo que los datos de IP no ven: proxies residenciales y navegadores reales

Los datos de IP no ven a los scrapers que pasan por proxies residenciales o móviles, y GeoIPHub no detecta proxies residenciales; el campo is_residential_proxy es una inferencia aproximada basada en el ASN, así que trátalo como si no aportara señal. Una red de proxies residenciales envía cada solicitud a través de la conexión doméstica de alguien. En la capa de IP, la solicitud parece de ese hogar: un ISP de consumo, una ciudad real, sin indicador de hosting, una puntuación limpia.

La rotación lo empeora. Un pool puede dar a cada solicitud una IP doméstica nueva, así que los contadores por IP nunca suben. Los proxies móviles comparten IP de operador con teléfonos reales, y un scraper con IPv6 puede recorrer un /64 entero sin tocar una red nueva.

Los navegadores reales son el segundo punto ciego. Un script de Playwright que controla Chrome desde una conexión de oficina o doméstica envía la misma IP, el mismo handshake TLS y los mismos recursos que la persona de la mesa de al lado. Algunas configuraciones headless se delatan solas; las bien ajustadas, no.

Lo que sigue delatando a estos scrapers es el patrón entre solicitudes:

Si pones un enlace oculto, excluye su ruta en robots.txt, para que los rastreadores que respetan el archivo nunca lo toquen. Dos artículos profundizan en las capas que acompañan a la IP. Lee por qué el fingerprinting de dispositivos y la inteligencia IP funcionan mejor juntos, y qué puede y qué no puede mostrar una consulta en la detección de fraude con proxies residenciales.

Scraping, rastreo y abuso de API

El rastreo es declarado y verificable, el scraping se lleva tu contenido o tus datos y a menudo no se declara, y el abuso de API son llamadas automatizadas a tus endpoints que van más allá de tus condiciones o límites. La línea entre ellos es el comportamiento y la identidad, no la tecnología: Googlebot y un scraper de precios pueden usar la misma biblioteca HTTP en la misma nube.

Un rastreador verificado puede hacer scraping, como muestra AhrefsBot, y un scraper puede parecer un rastreador. Por eso la siguiente sección empieza permitiendo solo a los verificados.

Cómo evitar el web scraping sin bloquear a los rastreadores de búsqueda

Para evitar el web scraping sin bloquear a los rastreadores de búsqueda, permite primero a los rastreadores verificados, luego limita la frecuencia por red y desafía a los clientes que no se comportan como navegadores, y bloquea solo lo que hayas confirmado. Los rangos de puntuación de GeoIPHub aportan la parte de la IP: allow hasta 25, review hasta 50, step_up hasta 75 y block por encima de 75. El orden importa. Un bloqueo general de centros de datos aplicado primero habría afectado a Googlebot, CCBot, ClaudeBot y AhrefsBot en nuestra tabla, ya que los cuatro venían de redes de hosting.

1. Permite a los rastreadores verificados cuando threat.crawler.verified sea true y crawler.name coincida con el token del User-Agent. Después aplica tu propia política a cada rastreador. Para los rastreadores de IA, nuestra comparativa de GPTBot, OAI-SearchBot y ChatGPT-User muestra cómo bloquear el entrenamiento sin desaparecer de la búsqueda con IA.
2. Reutiliza las reglas de IP. Los rangos de puntuación, el tratamiento de Tor y los límites de frecuencia por prefijo funcionan igual para los scrapers que para cualquier bot; la guía central los cubre. Trata una IP de centro de datos como una entrada ponderada, no como un bloqueo, ya que el hosting también incluye agentes de IA, proxies corporativos y tus propias herramientas (consulta qué es una dirección IP de centro de datos).
3. Limita la frecuencia por ASN en las páginas que buscan los scrapers. Un pool que rota por un solo proveedor de hosting se mantiene por debajo de cualquier límite por IP, pero un contador por ASN en las páginas de listados, búsqueda y precios lo suma todo. Da a las grandes nubes un techo más alto, ya que muchos clientes sin relación entre sí comparten un mismo ASN.
4. Limita la paginación y pon los listados completos detrás de un inicio de sesión. Sirve un número fijo de páginas de listados a los visitantes anónimos. Un muro de cuentas convierte a cada scraper en cuentas que puedes contar y cerrar.
5. Fija cuotas por clave en los endpoints JSON que llaman tus páginas. Los scrapers a menudo se saltan el HTML y llaman a la API que hay detrás, así que emite claves o tokens de sesión y limita las llamadas por clave.
6. Añade una capa de gestión de bots o un WAF para las señales del cliente que tus logs no recogen, como las huellas TLS y las comprobaciones de JavaScript en el edge.
7. Usa reglas de comportamiento para el tráfico residencial, donde la IP no te aporta nada.

Las respuestas forman una escalera: permitir, limitar la frecuencia, desafiar, bloquear. Algunos sitios añaden un tarpit, que ralentiza las respuestas a un presunto scraper, o sirven contenido señuelo, como precios alterados, al tráfico que ya han clasificado. Ambas cosas te cuestan algo si la clasificación es errónea, así que úsalas solo con tráfico que bloquearías de todos modos.

Para las filas que dependen solo de la IP (Tor, relays, escáneres, prefijos IPv6), usa el mapa de acciones de nuestra guía de detección de bots por IP.

¿Y robots.txt? Pide; no impone. El RFC 9309, el estándar de exclusión de robots, dice que sus reglas "no son una forma de autorización de acceso" (RFC 9309). Mantenlo para los rastreadores que lo respetan y aplica todo lo demás en tu servidor. Nuestra guía para bloquear rastreadores de IA muestra esa capa de control con código de nginx y Express.

Empieza por los logs de ayer. Exporta los 50 clientes más activos que no cargaron ningún recurso, pega cada uno en la consulta de IP gratuita (30 consultas por minuto sin clave, 1.500 al día con una clave gratuita) y clasifícalos según los tipos de la tabla de consultas anterior. Los que queden, muy activos y en redes de consumo, son donde deben ir tus próximas reglas de comportamiento.

Preguntas frecuentes

¿Cómo bloqueo los scrapers de IA como GPTBot o CCBot?

Empieza por robots.txt: GPTBot y CCBot lo respetan, así que una regla Disallow para sus tokens detiene a los rastreadores declarados. robots.txt es una petición, no un control de acceso (el RFC 9309 dice que sus reglas no son una forma de autorización de acceso), así que aplica también el control en tu servidor: verifica cada rastreador por sus rangos de IP publicados y trata como no verificado a cualquier cliente que use ese nombre desde fuera de esos rangos. OpenAI tiene varios bots con funciones distintas; nuestro artículo GPTBot vs OAI-SearchBot vs ChatGPT-User explica cuál bloquear si quieres seguir apareciendo en la búsqueda de ChatGPT.

¿Cuántas solicitudes por minuto indican scraping?

No hay un número universal. Mide tu propia referencia de tráfico humano en un día normal, por /24 en IPv4 y por /64 en IPv6, y luego busca redes que estén muy por encima. La frecuencia por sí sola también marca el NAT de oficinas, el CGNAT y los servicios de monitorización, así que trata una frecuencia alta como scraping solo cuando vaya acompañada de páginas pedidas en orden y sin solicitudes de recursos.

¿Se puede detener por completo el web scraping?

No. Todo lo que un navegador puede renderizar, un scraper decidido puede copiarlo, incluso a través de proxies residenciales y navegadores reales. El objetivo es que el scraping sea lento, caro y visible: verifica los rastreadores, limita la frecuencia por red, desafía a los clientes que no se comportan como navegadores y pon los datos de más valor detrás de un inicio de sesión o de claves de API.

¿Bloquear las IP de centros de datos detiene el scraping?

En parte. Detiene a los scrapers que funcionan en servidores en la nube baratos, pero también bloquea a los rastreadores verificados salvo que los permitas antes: en nuestras consultas del 8/10/2026, CCBot en AWS obtuvo 0 (allow) y el Googlebot real obtuvo 0 (allow), ambos en redes de hosting. Un servidor Linode normal obtuvo 10, también allow, así que la puntuación por sí sola no lo bloqueará. Los scrapers que alquilan proxies residenciales esquivan por completo un bloqueo de centros de datos.

¿Puede una consulta de IP decirme que una IP es un scraper?

No. Una consulta te dice el tipo de red y el riesgo: un rastreador verificado, un servidor de centro de datos, un nodo de salida de Tor o una VPN. Si esa IP te está haciendo scraping lo dicen tus logs: su frecuencia de solicitudes, el orden de las páginas que pide, si carga recursos y si su User-Agent coincide con el rastreador que verifica la consulta.

¿Cómo sé si un scraper usa proxies residenciales?

No puedes saberlo por la IP, y GeoIPHub no detecta proxies residenciales. Busca muchas IP de consumo que comparten un mismo patrón de sesión: el mismo orden de páginas, el mismo intervalo entre solicitudes, los mismos recursos sin cargar y huellas TLS o de dispositivo parecidas. Lo que delata al scraper es el patrón entre direcciones, no una dirección concreta.