SEO & IA

La verdad sobre el archivo llms.txt

Todos los grandes actores de la IA publican un llms.txt en sus sitios de documentación. Ninguno se compromete a leer el suyo. He probado las URL una a una, he repasado las declaraciones oficiales y los estudios de registros. Esto es lo que sale, separando estrictamente hechos, declaraciones e hipótesis.

Fred Gaveau4 de agosto de 2026~11 min de lectura

El punto de partida es una rareza. Desde hace dos años se presenta llms.txt como el archivo que habla con las inteligencias artificiales. Y en efecto, todas publican uno: Anthropic, OpenAI, Mistral, Perplexity, xAI, Google en parte. Si alguien sabe para qué sirve este archivo, son ellos.

Solo que ninguno ha escrito nunca que sus propios robots lo lean en su sitio. Y la única empresa que se ha pronunciado con claridad sobre el asunto — Google — ha dicho que no.

De ahí parte esta investigación. He probado cada URL a mano, he localizado las declaraciones oficiales donde existen y he leído los estudios de registros publicados. El texto está deliberadamente dividido en tres: lo que está probado, lo que se declara y lo que sigue siendo especulación — la mía incluida.

Lo que he verificado yo mismo

He consultado diecisiete URL desde la línea de comandos el 4 de agosto de 2026 a las 13:24 UTC, siguiendo las redirecciones y anotando el código HTTP y el peso del cuerpo devuelto. Todos los enlaces de la tabla están activos: compruébelo usted mismo, de eso se trata.

Instantánea del 4 de agosto de 2026, 13:24 UTC. Un archivo puede aparecer o desaparecer mañana — es exactamente lo que le pasó a Google.

De esta tabla saltan tres cosas.

Una: el archivo vive en los subdominios de documentación, nunca en el sitio para el gran público. docs., developers., platform. responden 200. Las raíces anthropic.com y google.com responden 404. Una sola excepción en el panel: Vercel, cuyo /docs/llms.txt redirige a vercel.com/llms.txt, realmente servido en la raíz como pide la especificación.

Dos: Google está fragmentado. Firebase tiene uno, Google Cloud no, y el sitio de los modelos Gemini tampoco. No es una política, es un accidente — vuelvo a ello enseguida.

Tres: el formato ha estallado en vuelo. La especificación describe un índice corto. Firebase sirve 1,7 MB, xAI 1,3 MB, la variante completa de Vercel 7,4 MB. Un índice de 1,7 MB ya no es un índice: es el corpus que debía resumir.

De dónde viene este archivo

HECHO llms.txt es una propuesta publicada el 3 de septiembre de 2024 por Jeremy Howard (Answer.AI, cofundador de fast.ai) en llmstxt.org. La idea: un archivo Markdown estructurado en la raíz del sitio — un título #, un resumen en cita, secciones ## de enlaces anotados — para ofrecer a los modelos un mapa limpio del contenido en lugar de hacerles adivinar la estructura de un sitio moderno saturado de JavaScript.

La analogía con robots.txt y sitemap.xml es deliberada, y es lo que vendió la idea. Pero engaña en un punto decisivo: robots.txt y sitemap.xml fueron adoptados por los buscadores antes de popularizarse. Aquí es al revés.

HECHO La página de la especificación no reivindica ninguna adhesión de un proveedor de IA, no menciona ningún proceso de normalización (ni IETF, ni W3C, ni WHATWG) y se describe como abierta a las aportaciones de la comunidad mediante un repositorio de GitHub. Detalle rara vez señalado: llms-full.txt no figura en la especificación. Es una convención nacida del uso, y cada cual la aplica a su manera.

El meollo: ¿alguien lee de verdad este archivo?

Es la única pregunta que importa, y tiene respuestas con cifras.

Lo que dicen los registros de servidor

HECHO El 5 de marzo de 2026, Dries Buytaert — creador de Drupal y director técnico de Acquia — publicó el análisis de un mes de registros de Cloudflare. Su sitio recibió 52 peticiones a /llms.txt en un mes. Todas procedían de herramientas de auditoría SEO. Ninguna venía de un motor de respuesta ni de un rastreador de IA. En toda la infraestructura de alojamiento de Acquia: unas 5 000 peticiones de 400 millones, es decir el 0,001 %, casi exclusivamente de herramientas SEO.

HECHO Un análisis de registros de Ahrefs sobre 137 000 dominios (junio de 2026, recogido por PPC Land) concluye que el 97 % de los archivos llms.txt no recibió ninguna petición en mayo de 2026. Los robots de recuperación de IA representaban el 1,1 % de las peticiones observadas.

HECHO Por último, un estudio de SE Ranking del 7 de noviembre de 2025 sobre 300 000 dominios no encuentra ningún efecto medible de llms.txt en las citas de las IA. Retirar la variable del modelo predictivo incluso mejoraba su precisión.

Lo que declara Google

DECLARACIÓN Google es el único gran actor que se ha pronunciado formalmente. Su documentación oficial sobre las funciones de IA en la búsqueda (developers.google.com, actualizada el 10 de diciembre de 2025) lo escribe sin rodeos:

DECLARACIÓN En Reddit, John Mueller comparó llms.txt con la etiqueta meta keywords — abandonada precisamente porque es el propio sitio quien la rellena — y después, según se recogió en junio de 2026: «I don't think anyone knows – it's purely speculative for now (the file has existed for years, yet none of the AI systems use it — what does it mean?)». Añade un criterio de decisión que me parece honesto: el día en que una plataforma de IA que le trae clientes reclame el archivo, hágalo. Hasta entonces, no.

DECLARACIÓN Gary Illyes, del equipo de Search, indicó en un Search Central Live de julio de 2025 que Google no admite llms.txt ni prevé hacerlo — postura recogida por Search Engine Roundtable.

Lo que los demás no dicen

NO VERIFICADO En el caso de OpenAI, Anthropic, Perplexity y Mistral, no he encontrado ninguna declaración pública que afirme que sus robots consumen el llms.txt de un sitio ajeno — ni ninguna que lo descarte. El silencio no es prueba de ausencia, pero tampoco es un compromiso. Publicar un archivo en la propia documentación no dice nada sobre lo que hace el propio rastreador en su sitio: dos equipos, dos productos, dos problemas.

La contradicción de Google, documentada

Es el episodio más revelador, y es comprobable.

SEGÚN LO PUBLICADO El 3 de diciembre de 2025 apareció un llms.txt en developers.google.com/search/docs/. Lo detectó la consultora SEO Lidia Infante. Se retiró el mismo día. Según las crónicas, el archivo no fue una decisión del equipo de Search: el gestor de contenidos interno de Google, común a varias propiedades para desarrolladores, había empezado a generarlos automáticamente. Algunos equipos lo retiraron, otros no.

HECHO — verificado el 4 de agosto de 2026 El estado actual del terreno confirma esa lectura. developers.google.com/search/docs/llms.txt, developer.chrome.com/llms.txt, web.dev/llms.txt, cloud.google.com/llms.txt, ai.google.dev/llms.txt: 404 en todas partes. Y firebase.google.com/docs/llms.txt: 200, 1,7 MB. Un equipo se olvidó de limpiar. El «llms.txt de Google» que se cita por todas partes como prueba de adopción es el residuo de un despliegue automático.

HECHO Y sin embargo, al mismo tiempo, otra parte de Google va en sentido contrario. Lighthouse 13.3, la herramienta de auditoría integrada en Chrome, incorpora una categoría experimental «Agentic Browsing» que contiene una comprobación de llms.txt (documentación actualizada el 5 de mayo de 2026). Allí se describe como «an emerging convention used to provide a machine-readable summary of a website's content, specifically designed for LLMs and AI agents», y la comprobación señala que sin el archivo los agentes tardan más en explorar el sitio.

MI INTERPRETACIÓN No es hipocresía, y no lo presentaré como tal. Es que «Google» no es una entidad única y los dos equipos no hablan del mismo uso: Search habla de posicionamiento y cita en un motor de respuesta; Chrome habla de eficiencia de un agente que navega. Ambas posturas son defendibles por separado. Sencillamente son incompatibles para quien intenta averiguar si «Google» recomienda o no el archivo. Y esa confusión no la despeja nadie. Search Engine Journal lo resumió bien: la recomendación de Google depende del producto al que se pregunte.

Entonces, ¿por qué lo publica todo el mundo?

Esta es la hipótesis que defiendo, y los propios archivos la sostienen: llms.txt nunca fue un archivo de SEO. Es un archivo de documentación para desarrolladores. El lector al que apunta no es GPTBot indexando la web para un motor de respuesta. Es una desarrolladora con Cursor, Claude Code o Copilot abierto, cuyo agente necesita cargar documentación de API actualizada en vez de recitar una versión caduca aprendida en el entrenamiento.

HECHO Los archivos lo dicen sin rodeos. El de Cohere contiene una sección titulada «Instructions for AI Agents» que recomienda añadir .md a cualquier URL para obtener Markdown limpio, y conectar un servidor MCP «for AI client integration (Claude Code, Cursor, etc.)». El de Cloudflare precisa que cada producto tiene su propio llms.txt, «the recommended way to explore a specific product's content». Esas frases no se dirigen a un buscador.

HECHO Los registros de Buytaert apuntan en la misma dirección: los agentes integrados en los IDE sí recuperan estos recursos, a diferencia de los rastreadores de los motores de respuesta.

Si esa lectura es correcta, todo el debate «¿mejora llms.txt mi visibilidad en IA?» descansa sobre un error de reparto. Se juzga una herramienta de documentación técnica con criterios de posicionamiento. Fracasa, evidentemente. Eso no significa que no sirva para nada — significa que no sirve para eso.

Lo que sí funciona, y que nadie vende: el Markdown

HECHO Es el dato más útil de toda la investigación, y ha pasado casi inadvertido. De nuevo en los registros de Buytaert, cuando una página está disponible en Markdown en una URL previsible:

Dicho de otro modo: los rastreadores de OpenAI van a buscar Markdown cuando existe en una URL adivinable — normalmente /mi-pagina.md. Un tercio de sus recuperaciones, en el caso de GPTBot. Es infinitamente más que el 0,001 % del llms.txt.

HECHO Y el corolario es brutal: «No AI crawler uses content negotiation. Not one.» Ningún robot de IA usa la cabecera Accept para pedir Markdown. La negociación de contenido, el método limpio y normalizado desde hace treinta años, la ignora todo el mundo. Lo que funciona es el sufijo en la URL, la solución más tonta.

Es exactamente el patrón que usan Stripe, Cohere, Perplexity y Anthropic en sus archivos: cada entrada apunta a un gemelo .md. El llms.txt es el directorio; los gemelos Markdown son lo que realmente se consume.

El caso Stripe: cuando el índice se convierte en una orden

HECHO El llms.txt de Stripe no empieza con una descripción. Empieza con imperativos dirigidos a la máquina que lo lee. Extracto verificado, primeras líneas del archivo:

# Stripe Documentation

When installing Stripe packages, always check the npm registry for the latest
version rather than relying on memorized version numbers. Run `npm view stripe
version` [...] Never hardcode an old version number from training data — always
install with `@latest` or verify the current version first.

HIPÓTESIS Esta desviación plantea una cuestión de seguridad que formulo sin poder zanjarla: si un archivo público y sin firmar puede contener instrucciones, y un agente lo carga en su contexto sin distinguir «descripción del sitio» de «orden que ejecutar», estamos en el terreno de la inyección de prompt. No he encontrado ningún incidente público documentado que explote un llms.txt. El riesgo es estructural, no constatado. Pero hoy el formato no ofrece ningún modo de separar ambas cosas — y Stripe, de buena fe, acaba de demostrar que la puerta está abierta.

Ocho propuestas para arreglar el formato

Criticar es fácil. Esto es lo que, a mi juicio, convertiría llms.txt de artículo de fe en herramienta útil. Cada propuesta se apoya en un mecanismo que ya existe en otro sitio.

1. Dejar de escribirlo a mano. Generarlo.

Un llms.txt escrito a mano se pudre en tres meses: las páginas se mueven, el archivo no. Debe producirse en la compilación, desde la misma fuente que el sitemap o el CMS. La ironía: es exactamente lo que hacía el sistema interno de Google — y el accidente de diciembre de 2025 se produjo porque la generación era automática y la decisión no. Automatice la generación, no la decisión.

2. Servir los gemelos Markdown antes que el índice.

Es la propuesta más rentable, e invierte el orden de prioridades habitual. Puesto que los rastreadores de OpenAI recuperan Markdown en cerca de un tercio de sus peticiones pero ignoran la negociación de contenido, sirva /mi-pagina.md junto a /mi-pagina, en una URL previsible, y declárelo en el HTML con <link rel="alternate" type="text/markdown" href="/mi-pagina.md">. Funciona hoy, de forma medible, a diferencia de llms.txt. Si de este artículo solo se lleva una cosa, llévese esta.

3. Mudarse a /.well-known/.

El RFC 8615 define desde 2019 un espacio de nombres estándar para exactamente este tipo de archivos, con un registro de la IANA detrás. /.well-known/llms.txt resolvería de un golpe la cuestión de la ubicación — la misma que explica que todos los archivos de la tabla vivan en subdominios de documentación en lugar de en la raíz — y abriría la única vía de normalización creíble.

4. Declararlo en robots.txt.

Una línea, Llms: https://ejemplo.com/llms.txt, calcada de la directiva Sitemap: — que tampoco se normalizó nunca y que todos los buscadores respetan igualmente. Coste cero, descubrimiento garantizado, y un mecanismo cuya adopción avalan veinte años de uso.

5. Fechar cada entrada.

Un índice sin frescura es inservible: frente a una página renderizada en directo, un modelo no tiene motivo para preferir una línea de índice que puede tener dos años. Una fecha por entrada — - [Página](url) (2026-07-12): descripción — más un Last-Modified honesto en el propio archivo dan por fin con qué arbitrar.

6. Separar índice y corpus, formalmente.

El formato necesita un techo duro — digamos 50 KB — para llms.txt, y remitir todo lo demás a un llms-full.txt definido explícitamente en la especificación (donde sigue sin figurar). Los 1,7 MB de Firebase y los 1,3 MB de xAI no son abusos: son los síntomas de un formato que nunca dijo dónde parar.

7. Firmar, o asumir que no vale nada.

El reproche de John Mueller — «lo rellena el propio sitio, como meta keywords» — es irrebatible mientras no exista firma. Las herramientas están ahí: firmas de mensajes HTTP (RFC 9421), clave publicada en un registro DNS TXT. Un archivo autodeclarado y sin firmar tendrá siempre exactamente el valor probatorio de un meta keywords de 2003.

8. Prohibir el imperativo — o acotarlo.

Mientras ningún mecanismo distinga una descripción de una instrucción, el formato debería prohibir las órdenes o imponer una sección ## Agent instructions claramente delimitada que los agentes traten como datos no fiables. El caso Stripe no es un abuso aislado: es el primer síntoma.

Y para terminar: mídalo.

Ninguna de estas propuestas le exime del gesto más sencillo. Un acceso a /llms.txt es una línea en sus registros de servidor. Filtre por los user-agent de los robots de IA, compare con sus páginas HTML, y en una semana sabrá si ese archivo sirve de algo en su caso. Es el único dato que realmente le concierne. Todos los demás, incluidos los míos, son la media de otro.

Veredicto: ¿hay que poner uno en 2026?

No hay una respuesta. Hay cuatro.

Y una regla válida para todos: no pague a nadie por escribir su llms.txt. Son veinte minutos de trabajo, o cero si lo genera. Lo único que merece presupuesto es comprobar después si los robots pasan de verdad — y eso lo dicen sus registros, no un proveedor.

Por lo demás, mi postura no ha cambiado desde nuestro primer artículo sobre el tema: el archivo no perjudica, cuesta casi nada y, si el uso despega algún día, usted ya estará colocado. Lo que ha cambiado son los datos. Ahora sabemos, con cifras, que no es una palanca de visibilidad en IA — y empezamos a entender qué es en realidad: una herramienta para agentes de código, mal nombrada y mal repartida.

Nota de transparencia: Snorklee publica su propio llms.txt, en la raíz, con una advertencia escrita dentro. Aplicamos por tanto exactamente lo que recomendamos: ponerlo, no creer en él y medirlo.