Saltar al contenido
Volver

llms.txt v2 ya está aquí: qué ha cambiado y qué deberías actualizar

Publicado:  at  10:00 a. m.

llms.txt v2 ya está aquí: qué ha cambiado y qué deberías actualizar

El 10 de agosto de 2026, Jeremy Howard publicó la v2 de la propuesta llms.txt, la primera revisión desde que el formato apareció en septiembre de 2024. Dos años de adopción dejaron una lista clara de lo que faltaba, lo que era ambiguo y lo que sencillamente no se usaba como la especificación suponía.

Empecemos por la parte tranquilizadora: tu archivo llms.txt actual sigue siendo válido. El formato del archivo no ha cambiado. Lo que cambió es todo lo que lo rodea, sobre todo la respuesta a una pregunta que miles de adoptantes repetían.

El problema que resuelve la v2

La v1 te decía que publicaras un llms.txt lleno de enlaces y que sirvieras versiones limpias en Markdown de tus páginas en page.html.md. Pero nunca conectó los dos extremos.

Como lo expresó Howard, el archivo “señalaba a los agentes hacia las páginas, pero nada en la especificación les decía dónde estaban realmente las versiones en Markdown”.

Así que un agente que aterrizaba en https://ejemplo.com/docs/auth no tenía forma fiable de responder a dos preguntas básicas:

  1. ¿Existe una versión en Markdown de esta página? ¿Dónde?
  2. ¿Existe un llms.txt que cubra esta página? ¿Dónde?

Le tocaba adivinar: probar a añadir .md, probar /llms.txt en la raíz y cruzar los dedos. La v2 sustituye la adivinanza por una declaración.

Este es el cambio principal. La v2 recomienda dos link relations estándar de HTML:

Puedes servirlas como elementos <link> en tu <head>:

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

O, mejor para la mayoría de equipos, como cabecera de respuesta HTTP Link::

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

Por qué importa la versión en cabecera: puedes añadirla en la configuración de tu servidor web o CDN sin tocar una sola plantilla. También funciona para recursos que no son HTML, incluidos los propios archivos Markdown. Si usas Cloudflare, Netlify, Vercel o nginx, esto es un cambio de configuración, no una migración.

Y no son convenciones inventadas: alternate y describedby son link relations ya registradas en la IANA. La v2 eligió reutilizar la fontanería de la web en lugar de inventar una nueva.

Cambio 2: ahora se aceptan dos patrones de URL para Markdown

La v1 especificaba una única convención: añadir .md a la URL completa, de modo que /docs/tutorial.html pasaba a ser /docs/tutorial.html.md.

En la práctica, muchas herramientas de publicación hicieron la otra cosa evidente y sustituyeron la extensión: /docs/tutorial.md. La v2 acepta ambas.

PatrónOriginalVersión en Markdown
Añadir .md/docs/tutorial.html/docs/tutorial.html.md
Sustituir la extensión/docs/tutorial.html/docs/tutorial.md
URL sin extensión/docs/tutorial//docs/tutorial/index.html.md o /docs/tutorial/index.md

La nota de la propia especificación: la práctica “se desvió de la v1 de formas que merece la pena bendecir”. Es una manera sana de llevar un estándar. Ninguno de los dos patrones es preferible, así que usa el que tu stack produzca de forma natural y luego decláralo con rel="alternate".

Cambio 3: la cobertura por subruta ahora está definida con precisión

Un archivo llms.txt cubre las URLs por debajo de su propia ruta, y cuando aplican varios archivos, los agentes deben usar el más específico. Así, /docs/llms.txt cubre todo lo que hay en /docs/ y tiene prioridad sobre el /llms.txt de la raíz para esas páginas.

Esto es más que una aclaración. Es la razón por la que llms.txt vive en una ruta y no bajo /.well-known/ (RFC 8615). Los URI well-known solo existen en la raíz del origen, y mucha gente controla únicamente un subdirectorio: el sitio de un proyecto en GitHub Pages, una carpeta de documentación en un host compartido, la sección de un equipo dentro de un dominio corporativo. Con la v2, quien pueda publicar un archivo en una ruta puede publicar un llms.txt para ella.

Si tienes documentación, blog y sitio de marketing bajo un mismo dominio, ahora puedes dar a cada uno su propio archivo acotado, sabiendo cuál gana.

Cambio 4: fuera llms_txt2ctx, y fuera la mecánica de “Optional”

La v1 incluía una herramienta de línea de comandos, llms_txt2ctx, que expandía un llms.txt en un gran bloque de contexto, con la sección ## Optional cargando un significado mecánico (sáltatela cuando el contexto se quede corto).

La v2 elimina ambas cosas de la especificación. No porque expandir contexto sea malo, sino porque no es así como se comportan los agentes. Los agentes reales ven o buscan en el llms.txt y luego siguen solo los enlaces que necesitan. El archivo se mantiene lo bastante pequeño para caber en el contexto; el detalle vive detrás de los enlaces y se descarga bajo demanda.

## Optional sigue existiendo, pero ahora puramente por convención: enlaces secundarios que un agente puede saltarse cuando quiere un contexto más corto. Sin semántica de herramienta asociada.

Cambio 5: el planteamiento se puso al día con la realidad

La sección de contexto de 2024 era una predicción: que los agentes leerían sitios web de forma rutinaria. La v2 la reescribe como descripción, porque hoy eso es simplemente un martes cualquiera.

La especificación ahora cita las pruebas: miles de sitios publican el archivo, las plataformas de documentación lo generan automáticamente, Lighthouse de Chrome audita su presencia dentro de sus comprobaciones de navegación agéntica, y los propios laboratorios de IA publican el suyo: OpenAI, Anthropic y el equipo de Gemini de Google sirven llms.txt para su documentación para desarrolladores.

Lo que el formato sigue exigiendo (sin cambios)

Merece la pena repetirlo, porque es la parte que la gente hace mal y nada de esto se movió en la v2:

Cada lista de archivos es una lista Markdown en la que cada elemento lleva un enlace obligatorio y, opcionalmente, un : y notas:

# Título

> La descripción opcional va aquí

Los detalles opcionales van aquí

## Nombre de la sección

- [Título del enlace](https://link_url): Detalles opcionales del enlace

## Optional

- [Título del enlace](https://link_url)

Tu checklist para la v2

  1. Conserva tu archivo actual. Sigue cumpliendo la especificación. No lo reescribas.
  2. Sirve versiones en Markdown de tus páginas importantes, con cualquiera de los dos patrones de URL.
  3. Añade las dos link relations, idealmente como cabecera HTTP Link: en el CDN o el servidor, para evitar por completo editar plantillas.
  4. Acota tus archivos por ruta si un dominio aloja varias áreas distintas.
  5. Apunta tus enlaces a Markdown, no a HTML. Los enlaces dentro del llms.txt deben llevar a contenido apto para LLM. Ya era así en la v1 y es el error más frecuente.
  6. Valida antes de publicar, para que el archivo que subes se pueda analizar de verdad.

Algo que la v2 no cambió

llms.txt sigue siendo una propuesta, no un estándar web ratificado, y sigue sin ser un factor de posicionamiento de Google. Google ha dicho con claridad que no usa el archivo. La v2 hace el formato más útil para los agentes que lo leen, un conjunto real y creciente, pero no lo convierte en una palanca de SEO.

Si alguien te vende la v2 como una mejora de posicionamiento, lee primero ¿Es llms.txt un factor de posicionamiento de Google?.

En resumen

La v2 es una revisión pequeña y sensata que arregla el único hueco estructural de la v1: los agentes podían leer tu archivo, pero no podían encontrarlo ni encontrar el Markdown al que apuntaba. Dos link relations cierran ese hueco, y una de ellas es una línea de configuración en el CDN.

¿Listo para actualizar? Genera un archivo conforme a la especificación con nuestro generador de llms.txt y luego compruébalo con el validador de llms.txt. Si aún estás decidiendo si el archivo merece la pena para tu sitio, empieza por Cuándo tiene sentido llms.txt.



Artículo siguiente
¿Es llms.txt un factor de clasificación de Google? No. Esto es para lo que realmente sirve