AI crawlers, robots.txt, llms.txt y protección contra bots: qué controla realmente el acceso
robots.txt es voluntario, llms.txt solo es un mapa y la protección contra bots es lo único que realmente frena a los que no cooperan. Desglosamos capa por capa cómo funciona cada uno en la práctica.
Durante un evento en vivo sobre tráfico de bots, dos consultas quedaron sin responder: ¿realmente un archivo llms.txt detiene a las IA que martillean tu sitio? La respuesta honesta es que no. Y esa confusión se repite cuando se mezclan robots.txt, llms.txt, crawlers de IA y herramientas de protección contra bots como si fueran lo mismo.
Estos cuatro elementos operan en puntos distintos del flujo de una solicitud HTTP y se aplican de formas completamente diferentes. Confundirlos lleva a que un administrador haga todo “correcto” y termine igual con el servidor saturado.
Según el Informe de Tráfico de IA y Bots de Kinsta, el tráfico de bots de IA en sitios alojados allí pasó de 1 cada 200 visitas hace un año a 1 cada 31 en la actualidad. Un cartel en la puerta sirve de poco cuando hay tantos intentando abrirla.
robots.txt: cortesía, no obligación
El archivo robots.txt, formalizado en el RFC 9309, indica a los crawlers qué rutas preferís que no visiten. No tiene ningún mecanismo técnico de enforcement: funciona solo porque los principales actores (OpenAI, Anthropic, Google, Perplexity) decidieron respetarlo por política.
La clave que muchos pasan por alto es que las empresas ya no usan un solo “bot de IA”. Separaron claramente los crawlers de entrenamiento (que alimentan los modelos) de los de búsqueda/respuesta (que citan contenido en tiempo real). Esa distinción es el mayor punto de control disponible hoy.
Si querés salir completamente del entrenamiento pero seguir apareciendo en respuestas de ChatGPT o Claude, podés configurar algo así:
User-agent: GPTBot
Disallow: /
User-agent: Anthropic-Claude
Disallow: /
User-agent: Google-Extended
Disallow: /
Y dejar libres los user-agents de búsqueda. Si preferís bloquear una sección específica (por ejemplo, /admin o /precios), aplicás el Disallow solo a esa ruta.
El límite siempre es el mismo: es una cortesía. Algunos crawlers tienen historial de ignorar las directivas, y las consultas puntuales que un usuario le pide a una IA (“leé esta página”) a veces no siguen el mismo comportamiento que un crawl sistemático.
llms.txt: un índice, no un control de acceso
El archivo llms.txt surgió como una propuesta para dar a las herramientas de IA un resumen estructurado de tu sitio. Es un archivo Markdown ubicado en la raíz que funciona como tabla de contenidos: lista las páginas más importantes, describe brevemente qué contiene cada una y facilita que un modelo entienda tu proyecto sin tener que scrapear todo.
No contiene directivas Allow, Disallow ni targeting por user-agent. No es un mecanismo de permiso ni de bloqueo. Es simplemente una ayuda para el descubrimiento.
La evidencia actual muestra que su adopción es baja y que no detiene el scraping repetitivo. Donde sí resulta útil es para agentes de código y herramientas de desarrollo (como Claude Code o Cursor) que necesitan un índice limpio de documentación.
En resumen: llms.txt no es un rate limiter ni una puerta. Es un mapa.
Los tres tipos de “AI crawler” que se confunden
El término “AI crawler” agrupa al menos tres comportamientos distintos:
- Crawlers de entrenamiento: recorren el sitio para mejorar modelos futuros.
- Crawlers de búsqueda/respuesta: generan citas y respuestas en tiempo real.
- Herramientas de navegación de IA: actúan como un usuario que abre enlaces en el momento, muchas veces sin identificarse claramente como bot.
Los dos primeros suelen identificarse con user-agents documentados, lo que permite controlarlos con robots.txt. El tercero se parece más a tráfico humano y por eso puede pasar desapercibido o activar falsos positivos en reglas demasiado agresivas.
En sitios WordPress y especialmente WooCommerce, el problema se agrava porque los crawlers siguen cada variación de URL generada por filtros, ordenamientos y parámetros dinámicos. Eso crea bucles que parecen ataques pero son solo bots que no saben que ya visitaron la misma página miles de veces.
La única capa que realmente bloquea: protección contra bots
Cuando un crawler ignora robots.txt o no se identifica, la única herramienta que puede actuar es la protección contra bots. En Kinsta existe un toggle específico “Block AI crawlers” que detiene crawlers verificados de IA sin afectar Googlebot ni Bingbot, además de una clasificación de “excessive-rate AI crawlers” para aquellos que, aunque verificados, generan tráfico excesivo.
Laszlo Farkas, Director de Ingeniería de Kinsta, lo resume así: si tenés el tiempo y expertise para mantener reglas propias, es ideal. Si no, una solución gestionada y afinada para WordPress ahorra dolores de cabeza.
Para comparar enfoques, existe la guía Kinsta Bot Protection vs Cloudflare.
Cómo combinar las capas según tu objetivo
- Querés permitir que te citen pero evitar el entrenamiento: usá robots.txt para bloquear solo los user-agents de entrenamiento y dejá libres los de búsqueda. Agregá reglas de rate limiting para evitar abuso.
- Querés visibilidad en IA sin que te saturen: permití los crawlers de respuesta y bloqueá los de entrenamiento y alto volumen.
- Tenés paywall: sirve contra crawlers clásicos que respetan la estructura, pero no contra herramientas que navegan como usuarios o acceden por RSS o caché.
- Problemas con filtros de WooCommerce: bloqueá patrones de parámetros en robots.txt y sumá reglas de velocidad en la protección contra bots.
La conclusión es clara: dejá de pensar en estos cuatro elementos como opciones alternativas. Tratáalos como una pila que se aplica en orden: robots.txt (voluntario), llms.txt (solo descubrimiento), protección contra bots (enforcement real) y, cuando corresponde, medidas de caché y estructura de URLs.
Adaptado de Kinsta.