- [ Inicio ](/es/) / - Cómo funciona # Cómo funciona llms.txt Un recorrido preciso por la especificación, con un ejemplo comentado que puedes copiar. Última actualización: 31 de julio de 2026 ## 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](https://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: - **Un H1** con el nombre del sitio o del proyecto. Es el único elemento estrictamente obligatorio. - Un **resumen en blockquote** corto, normalmente de una o dos frases. - **Markdown libre** opcional: párrafos y listas, pero ningún otro encabezado antes del primer H2. - Cero o más **secciones H2 con listas de enlaces**. Cada una contiene una lista Markdown: `- [name](url)`, opcionalmente seguido de `: notas`. - Una sección H2 opcional llamada exactamente **`Optional`**: los clientes con contexto corto pueden saltarse sus ítems. llms.txt, ejemplo completo comentado Copy ``` # 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 Referencia completa de campos. Solo el H1 es estrictamente obligatorio. Campo ¿Obligatorio? Cardinalidad Sintaxis H1, nombre del sitio o proyecto Sí Exactamente uno # Nombre del proyecto Resumen en blockquote Recomendado Como mucho un bloque > Resumen de una o dos frases. Markdown libre Opcional Cualquier número de párrafos o listas Ningún otro encabezado antes del primer H2 Sección H2 con lista de enlaces Opcional Cualquier número ## Nombre de sección seguido de una lista Ítem, enlace Sí (dentro de una sección) Un enlace por ítem - [name](url) Ítem, notas Opcional Tras dos puntos - [name](url): nota aquí Sección «Optional» Opcional Como mucho una H2 titulado exactamente Optional ; sus ítems pueden omitirse cuando el contexto es corto ### 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](/es/validador/)) 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: - Buscar la primera línea `# `: ese es el título. - Si el siguiente bloque no vacío es un blockquote, ese es el resumen. - Todo lo anterior al primer `## ` es el cuerpo libre. - 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](/es/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`). ℹ Consejo: mantén el formato estricto Todo el sentido de llms.txt es que se pueda parsear de forma determinista. Resiste la tentación de añadir front matter, HTML propio o extensiones exóticas de Markdown: los clientes no las leerán y arriesgas romper parsers más estrictos que el nuestro. ## 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](https://www.mintlify.com/blog/simplifying-docs-with-llms-txt) 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](/es/crear-llms-txt/), plantillas y despliegue por stack. - [FAQ](/es/faq/), respuestas directas a las dudas más habituales. - [Validar un archivo](/es/validador/). ## Fuentes - [ llmstxt.org, especificación completa ](https://llmstxt.org/) - [ llmstxt.org, the parsing core ](https://llmstxt.org/core.html) En esta página - [ Visión general ](#vision-general) - [ Anatomía de un archivo válido ](#anatomia) - [ Sección por sección ](#secciones) - [ Cómo lo leen los parsers ](#parsing) - [ llms.txt vs llms-full.txt ](#vs-full) - [ Límites prácticos ](#limites)