Cómo verificar rastreadores y agentes de IA por IP: DNS inverso, rangos CIDR y Web Bot Auth

Ves GPTBot, ClaudeBot o PerplexityBot en tus logs y tienes que decidir: permitirlo, limitarlo por tasa o bloquearlo. Pero antes de todo eso tienes que responder a una pregunta más básica: ¿es realmente ese bot? Porque una cabecera User-Agent es una afirmación, no una prueba. Cualquiera puede ejecutar curl -A "GPTBot/1.3" https://your-site.com y tus logs registrarán obedientemente "GPTBot".

No es algo teórico. El equipo Satori de HUMAN Security descubrió que el 5,7 % de todo el tráfico que decía ser un rastreador de IA conocido estaba suplantado, con picos del 7,7 % algunos días (~2 millones de solicitudes al día), y con el agente ChatGPT-User suplantado en aproximadamente una de cada seis solicitudes. Esta guía cubre las tres formas reales de verificar un rastreador en las capas IP y criptográfica (DNS inverso confirmado hacia delante, listas de permitidos CIDR publicadas por el operador y Web Bot Auth), además de los fallos en los que tropiezan casi todas las demás guías.

Por qué un User-Agent "GPTBot" no demuestra nada

El User-Agent son metadatos autodeclarados. No contiene ninguna autenticación, nada firmado, nada que un servidor de origen pueda comprobar. Verificar un rastreador significa vincular la solicitud a una infraestructura o a una clave que el operador controla realmente. Hay exactamente tres regímenes que lo hacen:

1. DNS inverso confirmado hacia delante (FCrDNS): demostrar que la IP resuelve hacia y desde el dominio del operador.
2. Listas de permitidos CIDR publicadas: comparar la IP con los rangos que publica el operador.
3. Web Bot Auth (RFC 9421): verificar una firma criptográfica en la propia solicitud.

Todo lo que sigue trata de hacer esto correctamente y de saber qué puede demostrar cada método y qué no.

Lo que está en juego en 2026: los bots son la mayoría de la web

La verificación de rastreadores dejó de ser un nicho de SEO en el momento en que el tráfico automatizado pasó a ser el grueso de internet. El Bad Bot Report 2026 de Imperva encontró que el tráfico automatizado supuso el 53 % del tráfico web que observó en 2025, y que los bots maliciosos por sí solos supusieron el 40 %. Cuando la mayoría de las solicitudes son automatizadas y el volumen de los rastreadores de IA no deja de crecer, "¿este bot es real?" pasa a ser una pregunta en tus endpoints de inicio de sesión, registro y checkout, no solo en tu robots.txt. En el checkout es ahora también una cuestión de fraude: consulta cómo frenar el fraude de agentes de compra con IA sin bloquear las ventas reales de agentes. Para saber qué señal de IP responde a cada pregunta sobre bots, desde los rangos de rastreadores hasta los indicadores de escáner, consulta nuestra guía central sobre detección de bots por IP.

Método 1: DNS inverso confirmado hacia delante, bien hecho

FCrDNS es el método canónico que Google documenta para verificar Googlebot. Cuatro pasos:

Por qué el paso directo es el que sostiene todo: un atacante controla el registro inverso (PTR) de su propia IP, así que puede apuntar 1.2.3.4 a crawl-fake.googlebot.com. Lo que no puede hacer es falsificar el DNS directo autoritativo de googlebot.com para que ese hostname resuelva de vuelta a 1.2.3.4. Una comprobación que solo compara la cadena del registro PTR con "googlebot.com" (algo que sugiere un número sorprendente de tutoriales) se puede suplantar. La confirmación directa es lo esencial. Para Google en concreto, con sus tres tipos de rastreador y sus archivos de rangos separados, consulta nuestra guía para verificar Googlebot por IP y detectar Googlebots falsos.

El techo de precisión que conviene señalar: los registros PTR son opcionales y a menudo no existen, sobre todo en los proveedores de IA más nuevos. Cuando no hay PTR, FCrDNS devuelve "no verificable", que no es ni un aprobado ni un suspenso. Ahí entra el método 2.

Método 2: Listas de permitidos CIDR publicadas, por bot

La mayoría de los proveedores de IA prescinden de los registros PTR y publican en su lugar los rangos de IP de sus rastreadores en JSON. Es la comprobación más práctica desde el punto de vista operativo. Descarga el feed de fuente primaria de cada operador:

• OpenAI: archivos por bot: openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json (documentación de rastreadores de OpenAI).
• Google: cinco archivos CIDR en developers.google.com/static/crawling/ipranges/.
• Anthropic: publica un solo archivo para sus bots, claude.com/crawling/bots.json, enlazado desde su página de ayuda sobre rastreadores. La lista de direcciones de su documentación de plataforma es para la API, no para los rastreadores.
• Perplexity: perplexitybot.json y perplexity-user.json.
• Apple iCloud Private Relay: un CSV de salida en mask-api.icloud.com/egress-ip-ranges.csv (documentación de Apple). Nota: son personas en un relay de privacidad, no bots. Añádelas a la lista de permitidos; no las bloquees.

Cargamos 19 archivos de rangos de rastreadores de 10 operadores; la lista de IP de rastreadores verificados incluye cada uno, con su fecha y cómo construir la lista de permitidos.

Tres reglas que separan una implementación correcta de una rota:

• Asocia cada bot a los archivos de su operador, y a su propio archivo solo cuando el operador publique uno por bot. GPTBot está en gptbot.json, no en "algún rango de OpenAI", y comparar con el archivo de OpenAI equivocado confunde un rastreador de entrenamiento con un fetcher iniciado por el usuario. Anthropic publica un único archivo compartido para sus tres bots, y los dos archivos de DuckDuckGo son idénticos, así que ahí el operador es la coincidencia más precisa disponible. Nuestra comparación de GPTBot frente a OAI-SearchBot frente a ChatGPT-User muestra qué hace cada bot de OpenAI, qué cuesta bloquearlo y una consulta real de cada archivo.
• Compara con el prefijo exacto publicado, nunca con el ASN de hosting. Añadir a la lista de permitidos "todo AWS" o "todo Google Cloud" porque un bot se ejecuta ahí dejará pasar a todos los atacantes de esa misma nube.
• Actualiza de forma periódica. Estos rangos cambian; trátalos como un feed, no como una constante.

Asimetría entre proveedores: qué método existe en cada caso

La mayoría de las guías mezclan a los proveedores. Se diferencian tanto en qué método de verificación existe como en los tokens de rastreador que publica cada uno, que tienen implicaciones de política distintas:

El matiz que rompe los pipelines ingenuos: los fetchers dirigidos por usuarios se comportan como visitantes reales y pueden originarse legítimamente fuera de los rangos publicados de los bots. Cuando un usuario pide a un asistente que abra una URL concreta, esa petición puede venir de infraestructura de nube genérica con un User-Agent de navegador normal. Bloquear "lo que no está en el rango de GPTBot" puede, por tanto, bloquear la acción del agente de un usuario real. La política de limitación por tasa y de bloqueo tiene que ser distinta para cada token, no para cada proveedor.

Cómo verificar rastreadores de SEO y analítica: AhrefsBot y compañía

Los mismos dos métodos de la capa IP verifican los rastreadores de SEO y analítica que más se quieren identificar en los logs: AhrefsBot y otros similares como SemrushBot y DataForSeoBot. No son rastreadores de IA, pero la verificación es idéntica:

• AhrefsBot se puede verificar con DNS inverso confirmado hacia delante (sus direcciones resuelven a hostnames bajo los propios dominios de Ahrefs), y Ahrefs publica los rangos de IP de su rastreador para añadirlos a listas de permitidos. Ejecuta la misma comprobación FCrDNS del método 1 o compara con la lista publicada del método 2.
• La trampa es la misma en la que caen los rastreadores de IA: no hagas listas de permitidos por ASN. Un "AhrefsBot" que llega desde un rango de hosting cualquiera que nunca verificaste es exactamente el patrón de suplantación, ya que cualquiera puede enviar User-Agent: AhrefsBot/7.0. Confirma la IP, no la cadena.

Si buscas "direcciones IP de AhrefsBot" para crear una regla de firewall, la versión duradera es una comprobación de DNS inverso confirmado hacia delante más el rango publicado por el operador, actualizado de forma periódica, no una lista de IP codificada a mano que se pudre la primera vez que el rastreador amplía su capacidad.

Método 3: Web Bot Auth y verificación criptográfica

La solución estructural a la suplantación es dejar de fiarse de la posición en la red y verificar una firma. Web Bot Auth hace que el agente firme cada solicitud con una clave Ed25519 usando las firmas de mensajes HTTP del RFC 9421 (un Proposed Standard, febrero de 2024). La solicitud lleva:

• Signature: el valor de la firma
• Signature-Input: los componentes cubiertos, created/expires, keyid y tag="web-bot-auth"
• Signature-Agent: opcional, nombra al agente que firma

Las claves se descubren como un JWKS en /.well-known/http-message-signatures-directory (basado en el mecanismo de URI well-known del RFC 8615). La verificación: descarga el directorio, busca la huella keyid y verifica la firma y la ventana created/expires. La ventaja sobre los métodos basados en IP es decisiva: se sostiene en direcciones compartidas, rotativas y de CGNAT, porque la identidad viaja con la solicitud, no con la ruta.

Baño de realidad: es experimental, no un estándar

Sé honesto con tu arquitectura en este punto. Web Bot Auth está especificado en Internet-Drafts del IETF (draft-meunier-web-bot-auth-architecture, 2 de marzo de 2026, con autores de Cloudflare y Google) que llevan el texto estándar "no avalado por el IETF y sin ningún estatus formal" y caducan el 3 de septiembre de 2026. El soporte del propio Google es explícitamente experimental. "Todavía no firma todas las solicitudes" y pide a los operadores que sigan usando la verificación por IP, DNS inverso y User-Agent. En la capa de infraestructura está más avanzado: Cloudflare incorporó las firmas de mensajes a su Verified Bots Program (julio de 2025) y AWS WAF añadió soporte (noviembre de 2025). Veredicto: prefiere las firmas cuando estén presentes, pero no dependas de ellas todavía.

El pipeline de decisión por capas (cópialo)

Combina los tres métodos en un orden de precedencia y después enriquece y clasifica. Una vez verificado un bot, decide qué hacer con cada rastreador de IA verificado con la política de tres niveles de esa guía:

El paso 5 es donde encaja GeoIPHub: cuando la IP de un bot autoidentificado no está en un rango publicado y no tiene PTR, el propietario del ASN, el indicador de datacenter/hosting, los indicadores de VPN, proxy y Tor y una puntuación de riesgo son lo que te permite puntuar los casos no concluyentes en el inicio de sesión, el registro y el checkout en lugar de adivinar. Si limitas por tasa el grupo de bots declarados pero no verificados, agrupa las fuentes IPv6 por prefijo y no por dirección; nuestra guía para limitar por tasa y bloquear IPv6 por prefijo /64 explica por qué.

Mismo ASN de Google, un Googlebot verificado y otro no

Dos direcciones de la misma red de Google reciben veredictos de rastreador opuestos, porque la comprobación usa el prefijo publicado, no el ASN. Consultamos dos IP de Google el 5 de octubre de 2026 (los resultados cambian a medida que se mueven los rangos): 192.178.4.0, la primera dirección del primer prefijo IPv4 del archivo de rangos de Googlebot que publica Google, y 8.8.8.8, el DNS público de Google.

Ambas están en AS15169 y ambas son de hosting, así que una lista de permitidos por ASN las trataría igual. Solo la primera está dentro del archivo de Googlebot, y threat.crawler.verification_method: "ip_range_list" muestra que el veredicto vino del método 2. La señal verified_crawler lleva su fraud_score a 0, mientras que 8.8.8.8 conserva la puntuación de datacenter corriente de 15. El método no_ptr_datacenter se activa en ambas porque nuestro registro no tiene PTR para ellas, y sin embargo un dig -x 192.178.4.0 en vivo devuelve crawl-192-178-4-0.googlebot.com. Es un ejemplo pequeño y real de por qué la comprobación de rangos es la que hay que automatizar: no depende de que una consulta de PTR tenga éxito.

Fallos y falsos positivos

Esto es lo que los artículos mejor posicionados hacen mal:

• Fuera de rango ≠ falso. El caso de Perplexity (Cloudflare, agosto de 2025) mostró un rastreador que usaba un UA genérico de Chrome, IP fuera de su rango publicado y ASN rotativos a 3-6 millones de solicitudes al día. Dentro del rango es un verdadero positivo; fuera del rango es no concluyente, no una prueba de falsificación.
• Sesgo geográfico del CGNAT. Una investigación de Cloudflare de finales de 2025 (vía The Register) encontró que las IP de CGNAT se limitaban por tasa ~3 veces más a menudo a pesar de tener menos señales de bot. Cientos de usuarios comparten una sola IPv4, con concentración en África y Asia. El bloqueo ingenuo por IP es un problema de equidad.
• iCloud Private Relay. IP de salida compartidas y rotativas que transportan a personas reales; añádelas a la lista de permitidos con el CSV de Apple.
• Proxies residenciales. Anulan por completo las listas de permitidos por ASN (el informe de 2025 de Imperva encontró que el 21 % de los ataques de bots los usaban), y precisamente por eso detectar tráfico anonimizado sin bloquear a clientes reales es un problema de comportamiento, no una consulta a una lista.

La regla: reserva los bloqueos estrictos para el comportamiento más la procedencia, nunca solo para la ausencia en una lista.

Los bots verificados son GIVT, los suplantados son SIVT

En la taxonomía del Media Rating Council, los rastreadores declarados y las IP de datacenter conocidas son tráfico no válido general (GIVT), filtrable mediante listas, mientras que los bots que "se hacen pasar por usuarios legítimos" son tráfico no válido sofisticado (SIVT), que requiere análisis y revisión. Verificar un rastreador por IP es lo que hace que una solicitud pase del segundo grupo al primero. Las listas completas de categorías, las nueve categorías propias de Google y cuáles de ellas puede ver una consulta de IP están en GIVT frente a SIVT: las categorías de tráfico no válido de Google.

Verifica rastreadores y agentes de IA con GeoIPHub

GeoIPHub aporta el enriquecimiento del paso 5 que los proveedores tradicionales de geo-IP dejan fuera de sus guías prácticas: ASN y tipo de conexión, detección de hosting/datacenter, indicadores de VPN / proxy / Tor, indicadores de rastreador verificado a partir de 19 feeds de rangos oficiales (incluidos GPTBot, ClaudeBot, PerplexityBot y AhrefsBot) y una puntuación de riesgo de fraude de la IP. No detectamos proxies residenciales; para eso hacen falta señales de comportamiento. Esto te permite confirmar que un bot autoidentificado procede realmente de la infraestructura del proveedor y puntuar los casos no concluyentes en lugar de bloquearlos a ciegas. Combínalo con los métodos de verificación anteriores y con las guías relacionadas sobre detección de robo de cuentas y credential stuffing y sobre qué tan precisa es realmente la geolocalización IP.

Preguntas frecuentes

¿Cómo verifico que una solicitud viene realmente de GPTBot y no es una suplantación?

No te fíes de la cabecera User-Agent; falsificarla es trivial. Compara la IP de origen con el archivo de rangos por bot que publica OpenAI (openai.com/gptbot.json), fijando la comprobación específicamente a GPTBot y no a un rango genérico de OpenAI. Si hay una firma Web Bot Auth válida, verifícala primero contra el directorio de claves de OpenAI, ya que no depende de la IP. Trata una IP que no está en el rango publicado como no concluyente, no como una falsificación demostrada, porque el tráfico de agentes dirigido por usuarios puede originarse en otra infraestructura. Nuestra comparación GPTBot frente a OAI-SearchBot frente a ChatGPT-User muestra una consulta real de cada archivo de rangos de OpenAI.

¿Qué es el DNS inverso confirmado hacia delante (FCrDNS)?

FCrDNS es una comprobación en cuatro pasos: resolver por DNS inverso la IP de origen a un hostname, confirmar que el hostname termina en el dominio del operador, resolver por DNS directo ese hostname y confirmar que vuelve a la IP original. El paso directo es lo que derrota la suplantación: un atacante puede poner un registro PTR falso en su propia IP, pero no puede falsificar el DNS directo autoritativo del operador. Una comprobación que solo inspecciona la cadena del PTR se puede suplantar.

¿Por qué no puedo bloquear sin más los rastreadores de IA por su cadena User-Agent?

Porque el User-Agent es una afirmación que cualquiera puede enviar. HUMAN Security descubrió que el 5,7 % de todo el tráfico etiquetado como un rastreador de IA conocido era falso, con picos de cerca de una de cada seis solicitudes para el agente ChatGPT-User. Bloquear solo por la cabecera deja pasar a los bots suplantados y no hace nada contra un operador que simplemente deja de identificarse.

¿Qué es Web Bot Auth y es ya un estándar terminado?

Web Bot Auth es un método emergente en el que un bot firma criptográficamente cada solicitud HTTP con una clave Ed25519 usando las firmas de mensajes HTTP del RFC 9421, y el origen la verifica con las claves publicadas en /.well-known/http-message-signatures-directory. El RFC 9421 en sí es un Proposed Standard (febrero de 2024), pero Web Bot Auth sigue siendo un Internet-Draft del IETF sin ningún estatus formal a mediados de 2026. Trátalo como experimental: verifica las firmas cuando estén presentes, pero mantén la verificación por IP y por DNS inverso como base.

¿Dónde publican los proveedores de IA los rangos de IP de sus rastreadores?

OpenAI publica JSON por bot en openai.com/gptbot.json, searchbot.json y chatgpt-user.json; Google publica JSON con CIDR en developers.google.com/static/crawling/ipranges/; Anthropic publica un solo archivo para sus bots en claude.com/crawling/bots.json; Perplexity publica perplexitybot.json y perplexity-user.json. Fija cada comprobación al archivo del bot concreto, compara con los prefijos exactos publicados y no con el ASN de hosting, y actualiza los archivos de forma periódica. Para los tres archivos de OpenAI y su número actual de prefijos, consulta los rangos de IP de GPTBot, OAI-SearchBot y ChatGPT-User.

Si una IP no está en el rango publicado por el proveedor, ¿significa que la solicitud es falsa?

No. Una IP dentro del rango, un FCrDNS superado o una firma válida son un verdadero positivo de alta confianza, pero una IP fuera del rango no es concluyente. Podría ser tráfico legítimo de agentes dirigido por usuarios desde otra infraestructura, una dirección compartida por CGNAT, una salida de iCloud Private Relay, un proveedor que no publica registros PTR o un archivo de rangos desactualizado por tu parte. Reserva los bloqueos estrictos para señales de comportamiento y de procedencia, no solo para la ausencia en una lista.

¿Bloquear rangos de IP de rastreadores no afectará a usuarios reales en direcciones compartidas?

Sí, y por eso la ausencia de la IP en una lista no debería disparar bloqueos estrictos. Una investigación de Cloudflare de finales de 2025 encontró que las direcciones de CGNAT se limitaban por tasa unas tres veces más a menudo que las que no son de CGNAT, a pesar de mostrar menos indicadores de bot, porque cientos o miles de usuarios comparten una sola dirección IPv4, y el CGNAT se concentra en partes de África y Asia, lo que crea un sesgo geográfico. Las IP de salida de iCloud Private Relay también transportan a personas reales y deberían añadirse a la lista de permitidos usando el CSV que publica Apple.