Auditoría de crawlers de IA: cómo comprobar acceso con logs, robots.txt y llms.txt
Tu robots.txt permite un crawler de IA. La prueba manual devuelve 200. Aun así, el bot puede estar chocando con una regla del WAF, recibiendo un HTML sin contenido o usando otro token para la función que te interesa. También puede ocurrir lo contrario: un user-agent con nombre oficial aparece en los logs, pero su IP no pertenece al proveedor.
Una auditoría de crawlers de IA no consiste en copiar una lista de bots. Su trabajo es reconstruir una cadena de evidencia: qué política declaraste, quién hizo la petición, qué respondió cada capa, qué contenido recibió y qué efecto se observó después. Cada eslabón responde una pregunta distinta.
Permitir acceso tampoco garantiza una cita. Solo elimina una posible barrera técnica. Después hay que medir presencia, fuentes y variación con un rastreador de visibilidad en IA. Y no encontrar un bot en 30 días de logs no demuestra que esté bloqueado: quizá no eligió rastrear ninguna URL durante esa ventana.
Fuentes y tokens verificados el 2026-08-06. Mantén un registro fechado por proveedor: los nombres, rangos IP y políticas pueden cambiar.
Las seis capas que no debes mezclar
Una conclusión útil necesita distinguir estos estados:
| Capa | Pregunta | Evidencia mínima |
|---|---|---|
| Política declarada | ¿Qué permites o rechazas? | Copia fechada de robots.txt, meta robots y reglas del edge |
| Identidad | ¿La petición pertenece al proveedor? | User-agent más IP, DNS o firma verificada |
| Acceso observado | ¿Hubo una petición real? | Evento de CDN, WAF u origen con timestamp y request ID |
| Respuesta técnica | ¿Qué pasó con la petición? | Estado, bytes, latencia, cache y acción del WAF |
| Payload | ¿Qué recibió el bot? | HTML o recurso capturado, contenido principal y headers |
| Resultado | ¿Cambió la visibilidad? | Muestra comparable de menciones, citas y URLs después |
Allow en robots.txt solo cubre la primera fila. Un 200 solo cubre parte de la cuarta. Ninguno demuestra por sí mismo que la página haya sido comprendida, indexada, recuperada o citada.
Paso 1: inventaría bots por propósito, no solo por proveedor
Los principales proveedores separan funciones. Una matriz de control evita aplicar una decisión de entrenamiento a búsqueda o a una visita iniciada por una persona.
| Proveedor | Búsqueda o recuperación | Entrenamiento o uso ampliado | Petición de usuario | Verificación oficial |
|---|---|---|---|---|
| OpenAI | OAI-SearchBot |
GPTBot |
ChatGPT-User |
Rangos IP JSON por token |
| Anthropic | Claude-SearchBot |
ClaudeBot |
Claude-User |
Política e IPs oficiales |
Googlebot controla Search |
Google-Extended es token de producto, no user-agent separado |
Fetchers iniciados por usuario | CIDR o DNS directo/inverso | |
| Perplexity | PerplexityBot |
Consulta la política vigente del proveedor | Perplexity-User |
IPs oficiales más user-agent |
| Apple | Applebot para búsqueda y contexto |
Applebot-Extended es token de control, no crawler separado |
Según producto y solicitud | CIDR o DNS oficial |
Consulta las fuentes primarias antes de cambiar reglas: crawlers de OpenAI, bots de Anthropic, crawlers comunes de Google, crawlers de Perplexity y Applebot.
Hay dos matices importantes. Google-Extended controla determinados usos de Gemini sin afectar a la inclusión o ranking en Google Search, y no emite un user-agent independiente. ChatGPT-User, Claude-User y Perplexity-User responden a acciones de usuarios; el tratamiento de robots.txt no siempre coincide entre proveedores. No extrapoles una regla universal.
Paso 2: captura la política efectiva por host
Descarga https://host/robots.txt desde cada host público: dominio principal, www, subdominios de documentación, centros de ayuda y assets si tienen contenido indexable. Registra fecha, estado, Content-Type, redirecciones y cuerpo exacto. La política de un host no se hereda automáticamente por otro.
Según el estándar Robots Exclusion Protocol, RFC 9309, el archivo vive en /robots.txt, la regla más específica prevalece y, con coincidencias equivalentes, Allow gana frente a Disallow. Un 4xx puede interpretarse como archivo no disponible y permitir rastreo; un 5xx puede hacer que un crawler conforme trate el sitio como no accesible. La implementación concreta puede variar, así que valida además la documentación del proveedor.
Ejemplo de una política empresarial que permite recuperación y rechaza entrenamiento donde los tokens lo soportan:
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Googlebot
Allow: /
User-agent: Google-Extended
Disallow: /
No copies este ejemplo sin decidir tu política y comprobar la semántica vigente. robots.txt es una preferencia pública, no autorización ni seguridad. Protege contenido privado con autenticación y controles de acceso reales.
Paso 3: prueba rutas representativas y conflictos
No basta con evaluar /. Incluye:
- una URL editorial canónica;
- una página de producto o pricing;
- una URL con parámetros;
- una ruta bloqueada deliberadamente;
- una página renderizada en cliente;
- un PDF o feed relevante;
- una URL redirigida y una 404 real.
Calcula la regla más específica por bot. Revisa comodines, finales con $, grupos duplicados y reglas generadas. Incluye X-Robots-Tag, meta robots, canonical y autenticación.
Paso 4: exporta logs de edge y origen
La ventana inicial suele ser de 30 a 60 días. Reúne CDN, WAF, balanceador y origen cuando estén disponibles: una petición bloqueada en el edge nunca aparecerá en el servidor de aplicación.
Campos mínimos:
| Campo | Por qué importa |
|---|---|
| Timestamp y zona horaria | Reconstruir secuencia y cambios de configuración |
| Host, método, ruta y query | Identificar exactamente qué recurso se pidió |
| User-agent y dirección IP | Candidato a bot y base de verificación |
| Estado y bytes enviados | Distinguir 200 útil, shell vacío, redirección o bloqueo |
| Latencia y timeout | Detectar respuestas demasiado lentas o cortadas |
| Cache status y acción WAF | Saber qué capa respondió o bloqueó |
| Request ID | Cruzar edge, aplicación y captura del payload |
Content-Type y referrer |
Validar formato y contexto de la petición |
| Resultado de identidad | Separar bot verificado de user-agent suplantado |
Normaliza variantes y rotación de IP, pero conserva el evento bruto. Agrupa por proveedor, propósito, host, plantilla, estado y día. No mezcles tráfico no verificado con tráfico oficial.
Paso 5: verifica la identidad antes de permitir excepciones
Un user-agent es texto controlado por quien envía la petición. No lo uses como único criterio para abrir el WAF.
Sigue el mecanismo oficial de cada proveedor:
- compara la IP con rangos publicados y actualizados;
- cuando se indique, ejecuta DNS inverso y confirma el resultado con DNS directo;
- usa firmas de bot verificadas si tu CDN las ofrece;
- exige además que el user-agent coincida con la función declarada;
- guarda método, versión del registro y resultado junto al evento.
Google documenta verificación mediante rangos o DNS confirmado. OpenAI y Perplexity publican listas separadas para sus tokens. Si creas una excepción, combina identidad verificada, propósito, método, rutas y límites razonables. Nunca permitas globalmente solo porque el nombre contiene bot o una marca conocida.
Paso 6: clasifica el acceso con estados operativos
Una tabla binaria permitido/bloqueado oculta problemas. Usa estados que conduzcan a una acción:
| Estado | Significado | Siguiente paso |
|---|---|---|
| No observado | No hubo petición en la ventana | Ampliar ventana o esperar; no inferir bloqueo |
| Observado sin verificar | El user-agent coincide, la identidad no | Verificar IP/DNS/firma antes de actuar |
| Verificado y permitido | Petición oficial, respuesta útil | Revisar payload y monitorizar |
| Bloqueado por política | robots.txt lo rechaza según lo previsto |
Confirmar decisión empresarial |
| Bloqueado por edge/WAF | Política permite, infraestructura rechaza | Corregir regla con identidad y alcance |
| Limitado o con error | 429, 5xx, timeout o bucle | Ajustar capacidad, cache, límites o aplicación |
| Fetch incompleto | 200 con shell, contenido ausente o formato erróneo | Servir HTML completo o recurso accesible |
Mide peticiones y URLs únicas, pero también tasa de éxito, distribución de estados, bytes medianos y plantillas afectadas. Cien respuestas 200 de 900 bytes pueden ser cien shells vacíos, no cien páginas útiles.
Paso 7: inspecciona el payload, no solo el código 200
Captura la respuesta que recibe un cliente sin sesión y compárala con el navegador. Busca:
- title, H1 y contenido principal en el HTML inicial;
- canonical y hreflang coherentes;
Article,BreadcrumbListy otros datos estructurados pertinentes;- enlaces internos rastreables con
href; - ausencia de challenges, consent walls o mensajes de error;
- recursos clave sin autenticación ni URLs temporales;
- estado real para 404 y redirecciones, no una SPA 200 genérica.
Un schema correcto ayuda a expresar entidades, pero no repara un bloqueo. Si necesitas revisar esa capa por separado, usa la guía de schema markup y datos estructurados para IA.
Paso 8: ejecuta pruebas controladas y cruza capas
El objetivo no es imitar todo el comportamiento del proveedor, sino aislar tu infraestructura. Para una URL de prueba:
- solicita sin cookies desde fuera de tu red;
- usa un user-agent de control y otro candidato, sin afirmar identidad oficial;
- registra timestamp y request ID;
- confirma el evento en CDN/WAF y origen;
- captura estado, headers, bytes y cuerpo;
- compara con la regla esperada de
robots.txt; - repite tras la corrección y conserva ambas evidencias.
No falsifiques una IP ni presentes el test como visita real del proveedor. Sirve para detectar reglas condicionadas por user-agent, geografía, cache o sesión. La evidencia definitiva de un bot oficial sigue requiriendo una petición observada y verificada.
Dónde encaja llms.txt y dónde no
La propuesta llms.txt define un archivo Markdown que puede orientar a sistemas de lenguaje hacia documentación y páginas útiles. En esta auditoría puedes comprobar:
- respuesta 200 y
Content-Typerazonable; - título y resumen claros;
- enlaces absolutos o resolubles;
- ausencia de URLs privadas, rotas o no canónicas;
- coherencia con navegación, sitemap y contenidos actuales.
No lo uses para conceder permisos, bloquear entrenamiento o demostrar adopción. La propia propuesta no define cómo deben procesarlo todos los sistemas. llms.txt no sustituye robots.txt, sitemap, canonical, seguridad ni HTML accesible; tampoco es evidencia de ranking o citación.
Remedia con un criterio de aceptación
Cada corrección debe declarar estado inicial, cambio, alcance y prueba de cierre. Ejemplo:
Cambiar la regla WAF `managed-bot-14` para permitir `OAI-SearchBot` únicamente cuando IP y user-agent pasen la verificación oficial, en rutas públicas GET/HEAD, manteniendo límites y bloqueos de autenticación. Se acepta cuando una prueba controlada devuelve HTML completo y una petición oficial posterior aparece como verificada y 200.
Prioriza en este orden:
- errores que bloquean todo el host o sirven respuestas falsas;
- políticas que contradicen la decisión empresarial;
- WAF, CDN, rate limiting y autenticación accidental;
- HTML incompleto, redirecciones y estados incorrectos;
- consistencia de canonical, hreflang, enlaces y schema;
- archivos opcionales de descubrimiento.
Lleva cada hallazgo al backlog de acciones de visibilidad en IA con propietario, evidencia y fecha de revisión. No cierres en el momento del cambio: observa logs durante una ventana suficiente y conserva una muestra comparable.
Checklist de auditoría
- [ ] Inventario de proveedores, tokens, propósito y fuente oficial fechado.
- [ ]
robots.txtcapturado por host con estado, headers y cuerpo. - [ ] Rutas representativas evaluadas con la regla más específica.
- [ ] Logs de CDN, WAF y origen cruzados con request ID.
- [ ] Identidad separada entre verificada y no verificada.
- [ ] Estados, bytes, latencia, cache y acciones del edge clasificados.
- [ ] HTML inicial y recursos clave inspeccionados sin sesión.
- [ ] 404, redirecciones, canonical, hreflang y schema comprobados.
- [ ]
llms.txttratado como mapa opcional, no como permiso. - [ ] Correcciones con criterio de aceptación y reobservación programada.
- [ ] Medición posterior de menciones y citas separada del acceso técnico.
FAQ
¿Cómo sé si un crawler de IA ha accedido realmente a mi web?
Busca la petición en logs de CDN, WAF u origen y verifica la identidad con el método oficial del proveedor. Después revisa host, ruta, estado, bytes, latencia y contenido servido. Un user-agent por sí solo se puede falsificar, y la ausencia de peticiones no demuestra bloqueo si el bot no intentó rastrear durante la ventana.
¿Basta con permitir el user-agent en robots.txt?
No. robots.txt expresa una política para crawlers que la respetan, pero una petición permitida aún puede quedar bloqueada por CDN, WAF, autenticación, rate limiting o errores de aplicación. También puede recibir un HTML vacío o incompleto. La auditoría debe contrastar política, acceso observado y payload.
¿Qué diferencia hay entre bots de búsqueda, entrenamiento y petición de usuario?
Cumplen finalidades distintas y suelen usar tokens diferentes. Por ejemplo, OpenAI separa OAI-SearchBot, GPTBot y ChatGPT-User; Anthropic separa Claude-SearchBot, ClaudeBot y Claude-User. Una regla sobre el bot de entrenamiento no debe interpretarse automáticamente como una regla sobre búsqueda o una visita iniciada por una persona.
¿Debo permitir un bot de IA solo porque su user-agent parece oficial?
No. Combina el user-agent con el mecanismo oficial disponible: rangos IP publicados, DNS directo e inverso confirmado o firma de bot. Conserva el resultado de verificación en el log. Permitir por nombre de user-agent facilita que un actor no autorizado suplante al crawler.
¿Para qué sirve llms.txt en una auditoría?
Puede funcionar como un mapa Markdown opcional hacia contenido útil para sistemas de lenguaje. La auditoría comprueba que responde, que sus enlaces son válidos y que no contradice la arquitectura. No es control de acceso, no sustituye robots.txt o el sitemap y, por sí solo, no prueba que un proveedor lo use ni mejora ranking.
¿Permitir crawlers de IA garantiza aparecer citado?
No. El acceso elimina una posible barrera técnica, pero la selección de fuentes depende de relevancia, calidad, corroboración, frescura y del sistema concreto. Tras corregir un bloqueo, conserva la fecha y repite una medición comparable de menciones y citas para observar si cambia el resultado.
Convierte acceso técnico en evidencia, no en suposiciones
La pregunta útil no es "¿tenemos permitido GPTBot?", sino "¿qué función queremos habilitar, qué identidad verificamos, qué respuesta recibió y qué observamos después?". Una auditoría bien cerrada deja una política deliberada, logs clasificables, excepciones seguras y pruebas repetibles.
Cuando la barrera técnica esté resuelta, mide por separado si cambian las menciones, fuentes y citas. Así podrás distinguir una corrección necesaria de un resultado que todavía depende de relevancia y selección.
¿Quieres saber si la IA menciona tu marca?
Descubre tu visibilidad en ChatGPT, Claude y Gemini en minutos.
Artículos relacionados
SEO para IA: guía completa para posicionar tu marca en ChatGPT, Gemini y Perplexity
Optimiza tu marca para aparecer en ChatGPT, Gemini y Perplexity. Guía completa de SEO para IA con estrategias GEO, AEO y LLMO en 2026.
Guías prácticasRastreador de visibilidad en IA: qué debe medir una herramienta seria (2026)
Un rastreador de visibilidad en IA no solo cuenta menciones: mide posición, framing, competidores, fuentes y cambios por modelo. Guía para elegir bien.
Estrategia GEOSchema markup y datos estructurados para IA: guía técnica para que los LLMs entiendan y citen tu marca
El 65-71% de páginas citadas por ChatGPT y Google AI usan schema. Aprende qué datos estructurados implementar para que la IA entienda y cite tu marca.