Cómo preparar robots.txt para buscadores, crawlers de IA y agentes

El rastreo web está entrando en una etapa multibot. Durante años, la conversación se centró en controlar el acceso de Googlebot y otros rastreadores de buscadores. Hoy, los sitios reciben también solicitudes de crawlers de IA, agentes capaces de ejecutar acciones, herramientas de validación publicitaria, analizadores de seguridad y servicios que recopilan información para generar respuestas.

Para los desarrolladores web, el reto ya no consiste únicamente en decidir si una URL debe rastrearse. Ahora es necesario definir qué bot puede acceder, con qué finalidad, a qué áreas del sitio y bajo qué condiciones. Una configuración genérica de robots.txt puede ser insuficiente o incluso contraproducente para la visibilidad orgánica.

Del robots.txt genérico a una política de acceso por propósito

El estándar de referencia sigue siendo el Robots Exclusion Protocol, formalizado en la RFC 9309 del IETF. La especificación establece que las reglas se publican en /robots.txt, que los grupos se organizan mediante directivas User-agent y que las reglas más específicas prevalecen sobre las más generales. También recuerda que robots.txt es una indicación para los rastreadores, no un mecanismo de autenticación ni una medida de seguridad.

La documentación de Google Search Central insiste en que robots.txt sirve principalmente para gestionar el rastreo y evitar solicitudes innecesarias; no debe confundirse con noindex ni utilizarse para proteger información privada. Una URL bloqueada puede seguir apareciendo en los resultados si Google la descubre por otros medios.

Qué bots conviene distinguir

Una primera capa debe separar los rastreadores de buscadores de los utilizados por sistemas de inteligencia artificial. Por ejemplo, OpenAI identifica de forma independiente OAI-SearchBot, orientado a la aparición en resultados de búsqueda de ChatGPT, y GPTBot, relacionado con el rastreo que puede contribuir al entrenamiento de modelos. También diferencia ChatGPT-User, asociado a determinadas acciones iniciadas por usuarios y no al rastreo automático general.

Esta separación permite adoptar decisiones más precisas: permitir OAI-SearchBot para favorecer la descubribilidad, bloquear GPTBot en determinados contenidos o aplicar políticas específicas a agentes y servicios de validación. OpenAI indica, además, que los cambios en robots.txt pueden tardar aproximadamente 24 horas en reflejarse en sus sistemas.

Ejemplo de estructura para un robots.txt multibot

Una configuración inicial podría organizarse de la siguiente manera, siempre después de revisar los objetivos comerciales, legales y técnicos del proyecto:

User-agent: Googlebot
Allow: /
Disallow: /admin/
Disallow: /privado/

User-agent: OAI-SearchBot
Allow: /servicios/
Allow: /recursos/
Disallow: /admin/

User-agent: GPTBot
Disallow: /contenido-premium/
Disallow: /datos-clientes/

User-agent: *
Disallow: /admin/
Disallow: /login/
Disallow: /carrito/
Sitemap: https://www.ejemplo.com/sitemap.xml

El ejemplo no debe copiarse sin análisis. Las rutas, los nombres de los agentes y la estrategia deben corresponder al sitio real. Además, es importante evitar reglas demasiado amplias que bloqueen recursos necesarios para renderizar páginas, como hojas de estilo, JavaScript o imágenes.

Robots.txt no sustituye al firewall

Uno de los errores más frecuentes es interpretar robots.txt como una barrera técnica. La RFC 9309 señala expresamente que sus reglas no constituyen autorización de acceso y que las rutas incluidas quedan expuestas públicamente. Para proteger información sensible se necesitan autenticación, controles de permisos, límites de velocidad, reglas WAF y monitorización de logs.

La experiencia reciente del sector refuerza esta precaución. Cloudflare ha documentado que algunos crawlers pueden identificarse de forma inconsistente o no respetar las directivas publicadas. Por eso, una estrategia sólida combina robots.txt con verificación de IP, análisis del encabezado User-Agent, control de frecuencia y respuestas diferenciadas para tráfico automatizado sospechoso.

Checklist de SEO técnico para desarrolladores

• Inventariar los bots que acceden al sitio a partir de los logs del servidor.
• Clasificar cada crawler por finalidad: búsqueda, entrenamiento, agente, publicidad, auditoría o abuso.
• Definir reglas específicas antes de utilizar User-agent: *.
• Comprobar que robots.txt devuelve una respuesta correcta, está en la raíz y utiliza texto plano codificado en UTF-8.
• Validar que las páginas estratégicas, recursos críticos y sitemaps siguen siendo accesibles.
• Usar noindex, autenticación o controles WAF cuando el objetivo sea impedir indexación o acceso real.
• Revisar periódicamente cambios en los nombres, IP y políticas de los crawlers.

La tendencia del rastreo web multibot convierte robots.txt en una pieza de gobierno técnico del sitio. No se trata de abrir la puerta a todos los agentes ni de bloquearlos indiscriminadamente, sino de relacionar cada permiso con un objetivo: visibilidad, rendimiento, protección de contenidos o control operativo.

En las funcionalidades de genSEO puedes centralizar procesos de análisis y optimización para detectar oportunidades de mejora en tu presencia digital. Si necesitas revisar la arquitectura de rastreo, las reglas de acceso o la salud técnica de tu web, visita genSEO y contacta con nuestro equipo para preparar una estrategia adaptada a tus crawlers y objetivos de negocio.

Preguntas frecuentes

¿Robots.txt puede impedir que una página aparezca en Google?

No siempre. Robots.txt puede impedir el rastreo, pero una URL bloqueada puede aparecer como resultado si Google la conoce por enlaces externos u otras señales. Para solicitar que una página no se indexe, normalmente es necesario permitir el rastreo y utilizar una directiva noindex o aplicar controles de acceso.

¿Debo bloquear todos los crawlers de IA?

No existe una respuesta universal. Algunos crawlers se utilizan para búsqueda y descubrimiento, mientras que otros tienen finalidades distintas. Lo recomendable es clasificarlos y decidir caso por caso si interesa permitir, limitar o bloquear su acceso.

¿Es suficiente con modificar robots.txt?

No. Robots.txt expresa una política de rastreo, pero no protege datos privados frente a clientes que no respeten la directiva. Para contenidos sensibles deben utilizarse autenticación, permisos, WAF, rate limiting y monitorización de accesos.