Dos personas nos hicieron la misma pregunta durante nuestro evento en directo sobre la realidad del tráfico de bots, y no llegamos a responder a ninguna de ellas en directo: ¿el archivo llms.txt realmente evita que la IA sature tu sitio?

Nos hemos quedado dándole vueltas a esa pregunta porque la respuesta sincera no es un simple sí o no. La verdad es que llms.txt nunca se creó para hacer ninguna de las dos cosas que la gente esperaba que hiciera, y gran parte de lo que se ha publicado al respecto este año ha llevado, sin que nadie se diera cuenta, a la gente a creer lo contrario.

Esa confusión no es un caso aislado. En todas las preguntas que nos han llegado, se seguía hablando de robots.txt, llms.txt, los «rastreadores de IA» y la protección contra bots como si fueran cuatro opciones en un mismo dial, en el que al girar cualquiera de ellas obtendrías el mismo resultado. Pero no es así. Se sitúan en puntos totalmente distintos de la ruta de la solicitud, se aplican mediante mecanismos totalmente diferentes (o, en un caso, no se aplican en absoluto), y confundirlos es precisamente lo que hace que el propietario de una web acabe haciéndolo todo «bien» y, aun así, siga teniendo problemas.

Y esto no es solo teoría. En nuestro Informe sobre Tráfico de Bots e IA, hemos descubierto que el tráfico de bots de IA en las webs alojadas en Kinsta ha pasado de ser 1 de cada 200 visitas hace un año a 1 de cada 31 en la actualidad. Significa que un cartel en la puerta no sirve de mucho cuando hay tanta gente intentando abrir la puerta.

TL;DR

  • El archivo robots.txt es una sugerencia, no una restricción. Los rastreadores de IA de confianza, como los de OpenAI, Anthropic, Google y Perplexity, suelen leerlo y respetarlo. Otros, como ha ocurrido históricamente con el Bytespider de ByteDance, no lo han hecho.
  • El archivo llms.txt no controla el acceso. Es un índice de contenido para las herramientas de IA que decidan leerlo, no un archivo de permisos. Su uso ronda el 9-10 % de los sitios web y, de todos modos, los principales rastreadores de IA casi nunca lo recogen.
  • La protección contra bots es la única capa que realmente impone restricciones. Los archivos robots.txt y llms.txt funcionan pidiendo las cosas amablemente. La protección contra bots de Kinsta y el AI Crawl Control de Cloudflare son los que realmente bloquean, desafían o limitan la frecuencia de un rastreador que ignora tus preferencias.

Cuatro capas, cuatro funciones y una duda recurrente

Capa Qué hace realmente ¿Puede detener a un actor malintencionado?
robots.txt Indica tus preferencias a cualquier rastreador que se moleste en leerlo No
llms.txt Proporciona a las herramientas de IA un índice limpio de tu contenido No
Rastreadores de IA Los bots que realizan las solicitudes N/A (estos son los que gestionas, no un control)
Protección contra bots (Kinsta / Cloudflare) Detecta, clasifica y actúa sobre las solicitudes a nivel de infraestructura

Una vez que lo ves presentado así, la mayoría de las preguntas de los asistentes se responden solas. Así que vamos a ir paso a paso, empezando por lo que todo el mundo ya entiende más o menos.

robots.txt

El archivo robots.txt, oficialmente RFC 9309, indica a los rastreadores qué partes de tu sitio prefieres que se salten. No tiene ningún mecanismo técnico de cumplimiento, así que funciona simplemente porque los rastreadores que lo leen han decidido, como política, respetarlo.

Lo bueno es que los rastreadores que más te interesan, como OpenAI, Anthropic, Google y Perplexity, publican todos sus user-agents documentados y respetan las directivas estándar.

Lo que suele confundir a la gente es dar por hecho que cada empresa utiliza un único «bot de IA». Pero no es así. La mayoría separa ahora el entrenamiento de la búsqueda, y esa separación es la clave más útil de todo este artículo:

  • GPTBot (OpenAI): entrena modelos base. Si lo bloqueas, tu contenido dejará de alimentar futuras sesiones de entrenamiento.
  • OAI-SearchBot (OpenAI): indexa páginas para que aparezcan como referencias en las búsquedas de ChatGPT. Si lo desactivas, perderás esas referencias, pero el entrenamiento no se ve afectado.
  • ClaudeBot (Anthropic): entrenamiento.
  • Claude-SearchBot (Anthropic): indexación de búsqueda para Claude.
  • Google-Extended: regula el uso en el entrenamiento de IA y, concretamente, en los resúmenes de IA. Si lo bloqueas, no afecta a la indexación habitual de Googlebot ni a tu posicionamiento normal en los resultados de búsqueda.
  • PerplexityBot: el rastreador del motor de respuestas de Perplexity.

Así que la verdadera decisión nunca fue «dejar entrar la IA o rechazarla». La cuestión es: ¿quieres que tu contenido sirva para entrenar un modelo, que se cite en una respuesta de IA, ambas cosas o ninguna? El archivo robots.txt ya te permite responder a esa pregunta con precisión. Es solo que la mayoría de los propietarios de sitios web no se la han planteado en esos términos.

Así es como se ve esa precisión en un archivo robots.txt. Imagina que quieres salirte del proceso de entrenamiento por completo, pero aún así quieres aparecer cuando alguien le haga una pregunta a ChatGPT o a Claude que tu contenido podría responder:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

Si prefieres excluir una sección concreta de todo, tanto del entrenamiento como de la búsqueda, puedes limitar la exclusión a una ruta en lugar de a todo el sitio:

User-agent: GPTBot
Disallow: /premium-reports/

User-agent: ClaudeBot
Disallow: /premium-reports/

El problema es que el cumplimiento es una cortesía, no una obligación. Hay unos cuantos rastreadores que, según se sabe, suelen ignorar por completo las reglas de restricción (disallow). Además, hay una novedad: cuando alguien le pide a ChatGPT o a un asistente similar que lea una página concreta en su nombre en ese mismo momento, esa única consulta no siempre se comporta como un rastreo, y la lógica de robots.txt no se aplica claramente a ese caso.

llms.txt

En muchos artículos de 2026 se ha descrito el archivo llms.txt como una herramienta de control de acceso o como un truco de SEO. La respuesta sincera es más sencilla y menos útil de lo que la mayoría de los artículos han dado a entender.

llms.txt es un archivo Markdown sin formato en tu directorio raíz que funciona como una tabla de contenidos para las herramientas de IA, dirigiéndolas a tus páginas más importantes para que un modelo no tenga que analizar una página renderizada completa para entender a qué te dedicas. Esa es toda la especificación. No dice nada sobre lo que un rastreador puede o no puede hacer.

El aspecto que tiene más o menos es este:

# Acme Analytics

> Acme Analytics is a WordPress plugin for tracking site performance and uptime.

## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation

## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparison

Fíjate en que no hay ningún Allow, ni Disallow, ni segmentación por user-agent, nada que le diga a un rastreador lo que puede o no puede hacer.

Esto es lo que indican los datos actuales:

  • La adopción es escasa. Aproximadamente entre el 9 % y el 10 % de las páginas web lo tienen, incluso entre los dominios más grandes de la red, después de más de un año en el que la gente se ha estado diciendo unos a otros que lo añadieran.
  • Los bots que más importan no lo están leyendo. El análisis del tráfico de cientos de millones de solicitudes de IA muestra que GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot y Google-Extended se saltan el archivo de forma abrumadora y pasan directamente a rastrear el HTML.
  • Google lo ha desmentido oficialmente. Los propios expertos en búsqueda de Google han afirmado rotundamente que el archivo llms.txt no se utiliza como señal para el posicionamiento ni para el rastreo, y lo han comparado, de forma desfavorable, con la metaetiqueta de palabras clave, que hace tiempo que quedó obsoleta.
  • Ningún laboratorio importante de IA se ha comprometido a tratarlo como una señal de acceso, ni para el entrenamiento ni para la búsqueda.

Donde realmente resulta útil es como mapa para los agentes de programación y las herramientas de desarrollo, como Claude Code o Cursor, que se benefician de un índice claro y estructurado de un sitio de documentación.

Así que llms.txt no evitará que tu sitio web sea rastreado una y otra vez. Es una ayuda para el descubrimiento, no un limitador de frecuencia ni una barrera.

Rastreadores de IA

El término «rastreador de IA» se usa como un término genérico para referirse al menos a tres comportamientos distintos, y mezclarlos es precisamente donde empiezan muchas decisiones equivocadas:

  1. Rastreadores de entrenamiento que recopilan contenido periódicamente para el conjunto de entrenamiento de un modelo: GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot.
  2. Los rastreadores de búsqueda y respuestas que crean el índice del que realmente extrae la información el motor de respuestas de IA: OAI-SearchBot, Claude-SearchBot y PerplexityBot.
  3. Búsquedas en tiempo real por parte del asistente, en las que alguien le pide a un asistente que vaya a leer una página concreta ahora mismo, y este lo hace al instante.

Los dos primeros se comportan como los rastreadores clásicos y, por lo general, se identifican con un user-agent documentado, que es precisamente lo que hace posible el control basado en el archivo robots.txt. El tercero se parece mucho más a una persona que hace clic en un enlace que a un rastreo, lo cual explica en parte por qué algunas herramientas de navegación basadas en IA aparecen ahora en los registros del servidor sin que se puedan distinguir de los visitantes normales, y también por qué el bloqueo indiscriminado de bots a veces acaba incluyendo actividades legítimas realizadas por humanos que se ven atrapadas en la misma red.

Esto también es lo que quería decir Daniel Pataki durante el seminario web: la mayor parte del tráfico de rastreadores de IA hoy en día no es malicioso, simplemente es implacable. Sigue todos los enlaces que encuentra, incluidas todas las variaciones redundantes de URLs que puede generar una página dinámica de WordPress o WooCommerce, y acaba entrando en un bucle que parece un ataque, pero que en realidad no es más que un bot que no sabe que ya ha visto esa página nueve mil veces.

Vamos a profundizar en por qué eso, precisamente, afecta tanto a la infraestructura de WooCommerce en Por qué los sitios de WooCommerce son especialmente vulnerables al tráfico de bots.

La capa que realmente funciona: la protección contra bots

Una vez que aceptes que el archivo robots.txt es opcional y que llms.txt en realidad no sirve para controlar nada, solo queda una medida que puede funcionar con un rastreador que se niega a cooperar: la protección contra bots, ya sea la de Kinsta, las herramientas de Cloudflare o cualquier otra solución.

Cloudflare ha actuado con rapidez en este tema, pero en Kinsta adoptamos un enfoque más específico para WordPress a la hora de abordar el mismo problema: un botón dedicado para bloquear rastreadores de IA que detiene a los rastreadores de IA, incluidos los verificados, sin afectar a Googlebot ni a Bing, además de una clasificación de rastreadores de IA con frecuencia excesiva que detecta a los bots que, aunque estén técnicamente verificados, están sobrecargando tu sitio mucho más de lo que lo haría un rastreo normal.

Herramienta de protección contra bots de Kinsta
Herramienta de protección contra bots de Kinsta

Laszlo Farkas, nuestro director de ingeniería, explicó así la disyuntiva subyacente cuando le pedimos que comparara una herramienta administrada con crear tus propias reglas desde cero:

Si tienes los conocimientos y el tiempo para ajustarlo tú mismo, probablemente esa sea la mejor opción para ti. Si no es así, creo que es mejor usar Kinsta, porque es un servicio administrado, optimizado para WordPress y mantenido por ellos.

Si quieres ver una comparación más detallada de las diferencias entre la herramienta de Kinsta y la de Cloudflare, échale un vistazo a nuestra guía sobre Protección contra Bots de Kinsta frente a Cloudflare.

Las preguntas que nos han llegado, respondidas sin rodeos

«Queremos utilizar rastreadores de modelos de lenguaje grande (LLM), pero evitar que se abuse de ellos. ¿Hay alguna forma fiable de hacerlo?» Sí, se trata de la distinción entre «entrenamiento» y «búsqueda», aplicada deliberadamente. Deja que los rastreadores de búsqueda y respuesta hagan su trabajo si quieres que te encuentren y te citen. Usa el archivo robots.txt para excluir específicamente a los rastreadores de entrenamiento, si es eso lo que te molesta. Después, deja que la protección contra bots detecte los abusos por volumen, vengan de donde vengan, verificados o no, que rastreen más de lo que deberían.

«No queremos bloquear el tráfico, ya que queremos que la IA dé visibilidad a nuestra empresa. ¿Qué podemos hacer realmente La misma respuesta, pero con un enfoque diferente. Ser visible en las respuestas de la IA y controlar la sobrecarga de recursos no son objetivos contradictorios, porque cada tarea la gestionan bots diferentes. Desafía o bloquea los rastreadores de entrenamiento y de alto volumen si eso te preocupa, y deja explícitamente abiertos los rastreadores de búsqueda y respuesta.

«¿Los muros de pago del contenido impiden que los bots de IA extraigan ese contenido?» En parte, y solo frente a los rastreadores que se comportan como tales. Un muro de inicio de sesión detiene a un bot que respeta la estructura normal de la página y carece de credenciales válidas, igual que detiene a cualquier persona anónima. No sirve de nada contra las herramientas de IA que navegan más bien como un usuario real que no ha iniciado sesión, o que acceden al mismo contenido a través de una copia en caché, un feed RSS o alguna otra vía alternativa que no pasa por la lógica del muro de pago en absoluto. Es útil y complementario, pero no sustituye a la protección contra bots.

«¿Podemos evitar que los rastreadores de IA se pasen el día recorriendo los filtros de nuestra tienda de WooCommerce?» Esto es un problema de almacenamiento en caché y de estructura de URL disfrazado de protección contra bots. Los rastreadores siguen todos los enlaces que encuentran, y los parámetros dinámicos de filtrado y ordenación generan un número casi infinito de URL distintas para algo que un humano percibe como la misma página. Bloquear esos patrones de parámetros en el archivo robots.txt es un primer paso sensato:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=

Aunque haya algún rastreador que lo ignore de todos modos, y habrá algunos que lo hagan, las reglas basadas en la frecuencia de la protección contra bots son las que realmente rompen el bucle.

En qué situación te deja esto

Deja de pensar en estas cuatro opciones como alternativas que compiten entre sí y empieza a considerarlas como un stack que se aplica en orden:

  1. El archivo robots.txt refleja tus intenciones, separando los rastreadores de entrenamiento de los de búsqueda y respuesta en función de lo que realmente esperas de cada uno.
  2. El archivo llms.txt, si te molestas en crearlo, es un detalle para las herramientas que lo leen, no una herramienta para reducir o controlar el volumen de rastreo.
  3. El término «rastreadores de IA» abarca los bots de formación, los bots de búsqueda y las consultas a agentes en directo, y puede que cada uno de ellos merezca una respuesta diferente.
  4. La protección contra bots es donde realmente se aplica la política, porque es la única capa que puede actuar ante una solicitud que ignora todo lo que has pedido.

Si lo que te preocupa no es tanto «¿cómo controlo esto?» sino más bien «¿cómo consigo que me encuentre?», nuestras guías sobre AEO para WordPress y GEO vs. AEO vs. SEO retoman el tema donde lo deja esta. Para conocer las opciones de control que se tratan aquí, echa un vistazo a la Protección contra Bots de Kinsta.

Joel Olawanle Kinsta

Joel es un desarrollador Frontend que trabaja en Kinsta como Editor Técnico. Es un formador apasionado enamorado del código abierto y ha escrito más de 200 artículos técnicos, principalmente sobre JavaScript y sus frameworks.