Guía

llms.txt v2: qué ha cambiado

Publicado: 2026-08-31

La propuesta llms.txt se revisó en agosto de 2026, casi dos años después de la original. El formato del archivo no cambió — un archivo v1 sigue siendo un archivo v2 válido. Lo que cambió es todo lo que rodea al archivo: cómo lo encuentran los agentes y qué utillaje espera la especificación.

El formato no cambia

La estructura requerida es exactamente la de antes: un BOM opcional, un H1 con el nombre del proyecto (sigue siendo el único elemento obligatorio), un resumen en blockquote, prosa opcional sin encabezados y después cero o más secciones H2 con listas de enlaces Markdown. Si tu archivo puntuaba 100 con la v1, sigue puntuando 100.

1. Relaciones de enlace, para que los agentes dejen de adivinar

Esta es la incorporación sustancial, y responde a la petición más repetida en dos años de adopción: dada una página, ¿cómo encuentra un agente su versión Markdown, o el llms.txt que la cubre, sin adivinar URLs?

La v2 responde con dos relaciones de enlace estándar:

• rel="describedby" — apunta al llms.txt que cubre esta página.
• rel="alternate" type="text/markdown" — apunta a la versión Markdown de esta página.

Cualquiera de las dos puede ser un elemento HTML <link>:

<link rel="describedby" href="/llms.txt">
<link rel="alternate" type="text/markdown" href="/docs/page.html.md">

… o una cabecera de respuesta HTTP, la única opción para recursos que no son HTML, como los propios archivos Markdown, y que puede configurarse en el servidor web o el CDN sin tocar ni una página:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Si antes seguiste el consejo de anunciar el archivo con rel="alternate" type="text/plain" — incluidas versiones anteriores de nuestras propias guías —, cámbialo por rel="describedby". Era una convención razonable cuando la especificación no tenía ninguna; ahora la tiene.

2. Ahora se permiten ambas formas de URL .md

La v1 fijaba una única forma de URL para el gemelo Markdown de una página: .md añadido a la URL completa, de modo que page.html pasaba a ser page.html.md. En la práctica, varias herramientas de publicación sustituían la extensión y producían page.md. La v2 acepta ambas. Para URLs sin nombre de archivo, añade index.html.md o index.md.

Aquí no hay nada que migrar: la forma que ya emites es ahora correcta.

3. Los archivos en subrutas quedan bien definidos

La v1 permitía un llms.txt fuera de la raíz, pero nunca dijo qué significaba. La v2 lo define: un archivo cubre las páginas bajo su ruta y, cuando aplica más de uno, los agentes usan el más específico. Así, /docs/llms.txt cubre todo lo que hay bajo /docs/, y un agente que lee una página de documentación lo prefiere al archivo raíz.

Esto importa a quien controla una ruta pero no un host — un sitio de proyecto en GitHub Pages, una sección de documentación en un dominio compartido — y es la razón por la que la especificación mantiene un nombre de archivo convencional en lugar de /.well-known/, que solo existe en la raíz del origen.

Consecuencia práctica: si tu documentación es la parte que interesa a los agentes, un /docs/llms.txt dedicado es ahora una opción de primera clase, no una zona gris.

4. Fuera el utillaje de expansión de contexto (y «Optional» pierde su mecánica)

La v1 describía llms_txt2ctx, una herramienta que expandía un llms.txt en un único contexto para el LLM. La v2 la descarta y expresa la expectativa directamente: los agentes consultan o buscan en el llms.txt y después siguen los enlaces que necesitan — así que los enlaces deben apuntar a contenido apto para LLM, y el archivo se mantiene lo bastante pequeño para caber en el contexto.

Con ese utillaje desaparece el significado mecánico de la sección ## Optional, que existía para indicar a esas herramientas qué omitir. Las secciones Optional siguen permitidas y siguen siendo una convención útil para enlaces secundarios que un agente puede saltarse — simplemente ya no accionan nada automático.

Ten en cuenta que llms-full.txt nunca formó parte de la especificación, en ninguna de las dos versiones. Es una práctica del sector muy adoptada, y buena para documentaciones extensas — solo no la trates como un requisito.

Qué hacer esta semana

1. Añade rel="describedby" apuntando a tu llms.txt — una línea en tu plantilla, o una regla de cabecera en el CDN.
2. Si publicas gemelos Markdown, anúncialos con rel="alternate" type="text/markdown".
3. Sustituye cualquier pista rel="alternate" type="text/plain" por rel="describedby".
4. Si tu documentación es la parte valiosa, considera un /docs/llms.txt dedicado.
5. Vuelve a pasar el validador — ahora informa de si tus páginas anuncian las relaciones v2 y sigue los archivos en subrutas como la v2 indica que deben hacer los agentes.

Por qué hubo revisión

Porque la premisa dejó de ser especulativa. Cuando llms.txt se propuso en septiembre de 2024, «los agentes leerán tu sitio web» era una predicción. Hoy las plataformas de documentación generan el archivo automáticamente, Lighthouse de Chrome audita los sitios buscándolo dentro de sus comprobaciones de navegación agéntica, y los laboratorios de IA publican llms.txt para su propia documentación de desarrollo. La v2 es el aspecto que tiene una propuesta después de que la adopción real haya puesto a prueba sus supuestos.

Seguir leyendo

• Cómo crear un archivo llms.txtUna guía práctica y paso a paso para escribir un archivo llms.txt conforme a la especificación: el título H1, el resumen, las secciones, los enlaces y dónde alojarlo.
• Cómo probar tu llms.txtAntes de publicar, confirma que tu llms.txt cumple la especificación y que todos los enlaces resuelven. Esto es lo que debes comprobar —estructura, accesibilidad de los enlaces, buenas prácticas— y la forma rápida de hacerlo.

Valida tu llms.txt →