Cómo funciona llms.txt

Visión general

Un llms.txt válido es un archivo Markdown con una estructura fija y predecible. Está pensado para que lo lean tanto personas como máquinas: el mismo archivo sirve de documentación y de contrato parseable.

La especificación en llmstxt.org define una gramática pequeña y determinista, parseable con unas pocas líneas de regex. Sin YAML, sin JSON, sin cabeceras adicionales.

Anatomía de un archivo válido

La estructura, de arriba abajo:

1. Un H1 con el nombre del sitio o del proyecto. Es el único elemento estrictamente obligatorio.
2. Un resumen en blockquote corto, normalmente de una o dos frases.
3. Markdown libre opcional: párrafos y listas, pero ningún otro encabezado antes del primer H2.
4. Cero o más secciones H2 con listas de enlaces. Cada una contiene una lista Markdown: - [name](url), opcionalmente seguido de : notas.
5. Una sección H2 opcional llamada exactamente Optional: los clientes con contexto corto pueden saltarse sus ítems.

# Acme

> Acme es una plataforma de analítica alojada para equipos de producto. Las páginas siguientes cubren producto, precios, la API y las guías de integración.

Acme procesa más de 1.000 millones de eventos al día. Este mapa está curado para asistentes, no es exhaustivo. Úsalo para responder a preguntas sobre capacidades de producto, precios, integraciones, SDK y migración desde otras herramientas.

## Producto

- [Visión general](https://acme.example/product): capacidades y capturas.
- [Casos de uso](https://acme.example/use-cases): escenarios para equipos de producto, marketing y soporte.
- [Changelog](https://acme.example/changelog): actualizaciones mensuales.

## Precios

- [Planes](https://acme.example/pricing): planes, límites y reglas de exceso de consumo.
- [FAQ de facturación](https://acme.example/billing-faq): facturas, recibos, IVA.

## Desarrolladores

- [Referencia de la API REST](https://docs.acme.example/api): catálogo completo de endpoints.
- [SDK de JavaScript](https://docs.acme.example/sdk/js): instalación, init, envío de eventos.
- [SDK de Python](https://docs.acme.example/sdk/python): instalación, init, envío de eventos.
- [Webhooks](https://docs.acme.example/webhooks): eventos, firmas, reintentos.

## Optional

- [Recursos de marca](https://acme.example/brand): logos, paleta.
- [Notas de prensa](https://acme.example/press): histórico de anuncios.

Sección por sección

El H1

Exactamente un H1, en la primera línea no vacía del archivo. Sin prefijos ni metadatos delante. Si tu proyecto tiene un lema, va en el blockquote siguiente, no en el título.

El resumen en blockquote

Opcional pero muy recomendable. Apunta a un resumen de una o dos frases que un LLM pueda citar literalmente para presentar tu proyecto. Factual, en voz activa, sin promesas de marketing que no puedas sostener.

Markdown libre

Párrafos, listas y fragmentos cortos de código que ayuden a un LLM a entender el contexto. No introduzcas ningún encabezado aquí: el siguiente debe ser el primer H2 de sección.

Secciones de lista H2

Cada sección empieza con su propio H2 (## Nombre de sección) y contiene una lista Markdown. Cada ítem debe ser un enlace (- [name](url)), opcionalmente seguido de : y una nota breve. Las URLs absolutas son muy recomendables: las relativas están técnicamente permitidas, pero la mayoría de validadores (incluido el nuestro) las marcan como aviso, porque vuelven el archivo ambiguo fuera de su contexto.

La sección «Optional»

Una sección titulada exactamente Optional tiene un significado especial: los clientes con contexto corto pueden omitirla sin perder el hilo principal. Úsala para lo prescindible (recursos de marca, archivos históricos, anexos técnicos muy profundos).

Cómo lo leen los parsers

El parser de referencia recorre el archivo de forma lineal con cuatro reglas:

1. Buscar la primera línea # : ese es el título.
2. Si el siguiente bloque no vacío es un blockquote, ese es el resumen.
3. Todo lo anterior al primer ## es el cuerpo libre.
4. Cada ## abre una sección; hasta el siguiente ## , los ítems de lista se parsean como [name](url) con notas opcionales tras los dos puntos.

Nuestro validador implementa exactamente esas reglas, más algunas comprobaciones de seguridad: H1 vacío, enlaces mal formados, contenido fuera de sección y avisos de tamaño (a partir de unos 50 kB conviene mover contenido a llms-full.txt).

llms.txt vs llms-full.txt

llms.txt es un mapa. llms-full.txt es el territorio: el contenido real de las páginas enlazadas, concatenado como Markdown en un solo archivo. La convención la popularizó Mintlify en colaboración con Anthropic y hoy forma parte del ecosistema llms.txt en sentido amplio.

Son hermanos y se sirven desde la raíz: /llms.txt y /llms-full.txt. Puedes publicar uno, otro, los dos o ninguno. La mayoría de plataformas de documentación publican ambos.

Límites prácticos

• Tamaño. No hay tope estricto, pero a partir de unos 50 kB los clientes con contexto corto empiezan a sufrir. Mueve volumen a llms-full.txt o a variantes por producto.
• Número de enlaces. La especificación no fija un límite, pero una lista de más de 200 ítems se ojea, no se lee. Cura.
• Idiomas. La especificación no dice nada sobre internacionalización. Dos patrones habituales: un único archivo en inglés, o variantes por idioma bajo una ruta (/en/llms.txt, /es/llms.txt).
• Autenticación y personalización. Fuera del alcance. El archivo es público.

Seguir leyendo

• Cómo crear tu llms.txt, plantillas y despliegue por stack.
• FAQ, respuestas directas a las dudas más habituales.
• Validar un archivo.