BLOQUE 2 · ACCESO TÉCNICO A MOTORES IA
Los rastreadores de IA son agentes automatizados o de recuperación que algunas plataformas utilizan para descubrir, consultar o procesar páginas web. No todos cumplen la misma función: existen bots de búsqueda, agentes de acceso por petición del usuario y robots vinculados al desarrollo de modelos. Saber distinguirlos es más útil que permitir o bloquearlos todos indiscriminadamente.
OpenAI documenta OAI-SearchBot para búsqueda, GPTBot para rastreo destinado a posibles usos en entrenamiento y ChatGPT-User para ciertas acciones iniciadas por usuarios. Anthropic y Perplexity también publican descripciones de distintos agentes. Las políticas pueden evolucionar, por lo que debemos revisar la documentación oficial antes de modificar robots.txt.
Qué diferencia a los bots de búsqueda, entrenamiento y usuario
| Plataforma | Agente documentado | Función principal |
|---|---|---|
| OpenAI | OAI-SearchBot | Descubrimiento para funciones de búsqueda de ChatGPT |
| OpenAI | GPTBot | Rastreo de contenido que puede utilizarse para entrenar modelos |
| OpenAI | ChatGPT-User | Acceso relacionado con una petición concreta del usuario |
| Anthropic | Claude-SearchBot | Descubrimiento asociado a búsqueda |
| Anthropic | ClaudeBot | Obtención de contenido potencialmente útil para entrenamiento |
| Anthropic | Claude-User | Recuperación relacionada con tareas de usuarios |
| Perplexity | PerplexityBot | Rastreo para su índice y experiencias de búsqueda |
| Perplexity | Perplexity-User | Obtención de contenidos asociada a solicitudes del usuario |
La tabla recoge las categorías funcionales descritas por cada proveedor; no afirma que todos obedezcan exactamente las mismas reglas o se ejecuten con idéntica frecuencia. Para OpenAI revisamos su documentación de bots, para Anthropic su guía de rastreadores y para Perplexity su documentación de crawlers.
La primera decisión no es técnica: debemos establecer la política editorial y de acceso que desea el propietario del sitio. Puede querer facilitar aparición en búsqueda sin autorizar por la misma vía el rastreo vinculado al entrenamiento, por ejemplo. OpenAI documenta ajustes independientes para esos usos.
Cómo leemos un robots.txt sin asumir que todo está permitido
El archivo robots.txt suele encontrarse en la raíz del dominio. Contiene grupos de instrucciones para agentes que interpretan ese estándar. Un ejemplo sencillo y ficticio, pensado solo para ilustrar políticas separadas, sería:
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /
User-agent: *
Allow: /En ese ejemplo se expresa una intención de permitir el rastreo de búsqueda de OpenAI y de restringir el bot de entrenamiento. No es una configuración universal recomendada: la decisión corresponde al propietario del sitio, debemos analizar las reglas existentes y verificar cómo el proveedor aplica sus políticas.
No añadimos automáticamente bloques para todos los agentes. Las reglas de un sitio pueden contener excepciones necesarias, rutas privadas, políticas corporativas y particularidades del CMS. Copiar fragmentos de Internet sin revisar el archivo completo puede cambiar más de lo previsto.
Robots.txt no equivale a una autorización real de acceso
Un Allow en robots.txt no vence por sí mismo un bloqueo del servidor o de un firewall. Un agente puede recibir HTTP 403, un desafío antibot, una redirección equivocada, una página vacía o un error de conexión. Esos problemas se investigan en la respuesta real del servidor y, cuando hay acceso autorizado, en registros de solicitudes.
Tampoco interpretamos robots.txt como un sistema de autenticación o protección de documentos privados. Es un mecanismo de política de rastreo para agentes que decidan respetarlo, no una barrera de seguridad. Si un recurso no debe ser público, necesita controles adecuados de acceso y publicación.
El estado de indexación en Google también es una cuestión distinta del acceso de otro crawler. Una URL puede ser accesible para un robot y no aparecer como resultado relevante. Para comprender la base técnica consulta nuestra guía SEO para GEO.
Caso específico: OpenAI y la separación entre búsqueda y entrenamiento
Según la documentación oficial de OpenAI, OAI-SearchBot sirve para el descubrimiento en funcionalidades de búsqueda. GPTBot identifica rastreo que puede utilizarse en entrenamiento de modelos fundacionales, y ChatGPT-User interviene en determinados accesos por petición del usuario. La propia plataforma señala que los controles de búsqueda y entrenamiento son independientes.
El documento también explica que una página excluida del rastreo de búsqueda puede seguir apareciendo en determinados contextos como enlace de navegación. Por tanto, no deberíamos resumir una política compleja diciendo «bloquear OAI-SearchBot impide que ChatGPT conozca nuestra marca en cualquier circunstancia». Eso sería exagerado.
Además, permitir OAI-SearchBot no garantiza aparecer en una respuesta, ser citado o ser recomendado. El acceso es una condición técnica que debe evaluarse junto con contenido, pertinencia, fuentes y medición real. Documentación oficial.
Claude y Perplexity: decisiones por plataforma
Anthropic separa ClaudeBot, Claude-SearchBot y Claude-User. El uso indicado para cada uno es diferente. No transferimos automáticamente una regla establecida para OpenAI a los robots de Claude. También revisamos si hay necesidades de recuperación iniciadas por usuarios que deban considerarse por separado.
Perplexity documenta PerplexityBot y Perplexity-User. Su guía de crawlers incluye información para administradores sobre identificación y configuración. Debemos consultar la documentación vigente al tomar decisiones sobre robots y WAF, porque los distintos agentes pueden operar bajo supuestos técnicos y políticas de acceso diferentes.
En todos los casos evitamos repetir como regla universal información de blogs de terceros sobre si un bot ejecuta JavaScript, con qué frecuencia accede o cómo trata cada instrucción. Si un proveedor no documenta cierto comportamiento, lo registramos como no verificado.
Auditoría práctica de seis capas
1. Verificación de las URLs y el sitio
Comprobamos respuesta HTTP, canonical, acceso público, indexabilidad cuando corresponda y navegación. En un sitio que tiene problemas para cargar para una persona, no comenzamos prometiendo beneficios mediante cambios de user-agent.
2. Revisión del robots.txt vigente
Descargamos el contenido completo del archivo y anotamos los grupos relevantes. Antes de sugerir una edición buscamos reglas anteriores de rutas privadas, staging o medios. Los subdominios y hosts pueden exigir revisiones separadas.
3. Revisión de las políticas del propietario
Clasificamos las necesidades del proyecto: descubrimiento de búsqueda, acceso por petición de usuarios, tratamiento de entrenamiento y protección de recursos privados. No cambiamos configuraciones de entrenamiento sin que exista una decisión explícita sobre ese uso.
4. Revisión del firewall y CDN
Una política robots permisiva puede coexistir con un WAF que impide solicitudes legítimas. Revisamos errores 403, desafíos, rate limiting y configuraciones de seguridad del CDN sin desactivar protecciones globales de forma imprudente.
5. Verificación de solicitudes reales
Si disponemos de logs autorizados, verificamos solicitudes por URL, hora, código HTTP y señales de identidad del agente. Un User-Agent se puede falsificar; cuando el proveedor publica rangos de IP u otros mecanismos de verificación, los utilizamos antes de atribuir visitas a un robot oficial.
6. Revisión editorial y medición
Después de solucionar brechas técnicas medimos por separado la preparación del sitio y las apariciones observadas de la marca. Una solicitud HTTP exitosa no significa que el contenido haya sido utilizado como fuente en una respuesta. Para esa distinción está nuestra página de medición de visibilidad en IA.
Errores comunes al intentar «habilitar GEO» desde robots.txt
- Permitir todos los bots sin analizar primero la política de la organización.
- Bloquear entrenamiento creyendo que también se está controlando cualquier respuesta de búsqueda.
- Asumir que un
Allow: /supera reglas de acceso de WordPress, servidor o Cloudflare. - Publicar información privada pensando que
Disallowimpedirá su lectura por cualquier persona o sistema. - Atribuir un acceso a un robot oficial solo porque la petición contiene su nombre en el User-Agent.
- Reportar «100 % de visibilidad IA» porque la web respondió HTTP 200 a un crawler.
- Modificar reglas de rutas sensibles sin conservar una copia y realizar pruebas posteriores.
Estos errores muestran por qué el trabajo técnico debe integrarse con el marco de factores GEO: acceso, contenido y visibilidad real tienen funciones distintas.
Preguntas frecuentes
¿Debemos permitir GPTBot para aparecer en las búsquedas de ChatGPT?
OpenAI documenta controles independientes para GPTBot y OAI-SearchBot. Conviene decidir la política de cada uno por separado, sin confundir búsqueda y entrenamiento.
¿Si permitimos OAI-SearchBot apareceremos citados?
No. La documentación describe acceso y rastreo, pero eso no garantiza citas ni recomendaciones.
¿Robots.txt protege una carpeta privada?
No. No es una medida de autenticación; las carpetas privadas necesitan controles de acceso adecuados.
¿Cómo sabemos si un bot ha entrado realmente?
Necesitamos evidencias técnicas: registros, códigos HTTP y verificación razonable de la identidad del agente. La ausencia de una cita visible no prueba que un crawler no haya accedido.
Fuentes oficiales consultadas
- OpenAI: Overview of OpenAI Crawlers.
- Anthropic: Web crawlers y controles del propietario.
- Perplexity: Perplexity Crawlers.
- Google: funciones de IA y requisitos SEO.
Conclusión: una auditoría de rastreadores de IA empieza por comprender políticas y funciones diferentes. Comprobar acceso es importante, pero ni el rastreo ni la configuración de robots prueban visibilidad, recomendación o citación.
2 comentarios