llms.txt no es una varita SEO para aparecer en ChatGPT. Es un índice Markdown barato y útil para que agentes de código, asistentes y herramientas de documentación encuentren las páginas correctas sin rastrear todo tu sitio.
llms.txt es un archivo Markdown servido normalmente en /llms.txt que resume qué hace un sitio o producto y enlaza las páginas que un modelo o agente debería leer primero. La variante /llms-full.txt suele concentrar documentación completa en texto plano para pegarla o recuperarla con menos ruido HTML.
Modo de trabajo
TL;DR
La keyword principal es llms.txt. La intención de búsqueda en español es práctica: saber si merece la pena implementarlo, cómo escribirlo, cómo combinarlo con robots.txt y cómo evitar prometer visibilidad en IA que todavía no está demostrada.
Mi postura: publícalo si tienes documentación técnica, API, SDK, producto developer o base de conocimiento. No lo vendas como ranking factor. Trátalo como infraestructura de contexto para agentes, no como truco de SEO.
Lectura práctica
Qué es llms.txt y qué no es
llms.txt propone un índice legible por modelos: título, resumen corto, notas importantes y listas de enlaces en Markdown. La idea es que un agente pueda leer una puerta de entrada limpia antes de decidir qué documentación recuperar. Eso reduce tokens, ruido de navegación, HTML decorativo y páginas irrelevantes.
No es robots.txt. robots.txt controla permisos de rastreo por user-agent; llms.txt orienta sobre qué contenido es importante. Tampoco es sitemap.xml: el sitemap enumera URLs para buscadores tradicionales; llms.txt curaría una ruta de lectura para asistentes y agentes.
La distinción importa porque muchas guías lo presentan como el sitemap para IA. Es una metáfora útil, pero incompleta. Si publicas basura, thin content o enlaces genéricos, solo estás dando a los agentes una lista ordenada de basura.
llms.txt funciona mejor como capa de contexto: no sustituye permisos de rastreo, sitemap ni documentación buena; los conecta para agentes y asistentes.
Checklist
Por qué vuelve a importar en 2026
El debate cambió cuando los agentes de código dejaron de ser chatbots y empezaron a navegar documentación, invocar MCP, leer repositorios y pedir contexto en formato Markdown. Para un humano, una documentación con navegación bonita es cómoda. Para un agente, muchas veces es ruido.
Cloudflare ya ofrece formatos orientados a agentes, llms.txt, llms-full.txt, vistas Markdown y MCP servers. Anthropic y el sitio de Model Context Protocol también exponen llms.txt. Chrome Lighthouse lo trata como una convención emergente para agentic browsing. Eso no prueba que todos los modelos lo usen, pero sí marca una dirección técnica: la documentación tendrá una capa para máquinas.
El punto honesto es que el valor actual está más cerca de hacer tu documentación fácil de consumir por agentes que de subir posiciones en AI Overviews. Si el KPI es búsqueda orgánica, llms.txt es una pieza secundaria. Si el KPI es que un dev use tu SDK con Claude Code, Cursor, Codex o Copilot sin alucinar endpoints, es mucho más interesante.
/llms.txt mínimo para una documentación técnica
# DevAI API
> Documentacion para integrar la API de DevAI en productos internos.
Usa estas paginas para resolver dudas tecnicas. No uses posts de marketing
como fuente de comportamiento de la API.
## Inicio
- [Quickstart](https://example.com/docs/quickstart): Primer request autenticado.
- [Autenticacion](https://example.com/docs/auth): API keys, scopes y rotacion.
- [Errores](https://example.com/docs/errors): Codigos, retries y rate limits.
## Referencia
- [REST API](https://example.com/docs/api): Endpoints estables.
- [SDK Python](https://example.com/docs/sdk-python): Cliente oficial.
- [Changelog](https://example.com/changelog): Cambios incompatibles.
generador simple desde una lista curada
from pathlib import Path
pages = [
("Quickstart", "https://example.com/docs/quickstart", "Primer request autenticado."),
("Autenticacion", "https://example.com/docs/auth", "API keys, scopes y rotacion."),
("REST API", "https://example.com/docs/api", "Endpoints estables."),
]
lines = [
"# DevAI API",
"",
"> Documentacion tecnica para agentes y asistentes de codigo.",
"",
"## Documentacion principal",
"",
]
for title, url, desc in pages:
lines.append(f"- [{title}]({url}): {desc}")
Path("public/llms.txt").write_text("\n".join(lines) + "\n", encoding="utf-8")
Formato recomendado
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Empieza con un H1 que nombre el producto o sitio. Debajo, añade un blockquote de una frase que explique qué es y para quién. Después incluye notas operativas: versión estable, idioma, límites, páginas que no deben tratarse como API contract y enlaces a changelog o status.
Puntos a revisar
Lo que conviene comprobar
Organiza los enlaces por intención, no por jerarquía interna. Para devs funcionan bien grupos como Inicio, Referencia, SDKs, Arquitectura, Seguridad, Ejemplos, Changelog y Soporte. Cada enlace debe llevar una descripción útil. Un agente necesita saber por qué abrir esa URL.
Evita meter todo. El archivo principal debe ser corto y curado. Si quieres ofrecer el corpus completo, usa /llms-full.txt o archivos por sección. El objetivo de /llms.txt es orientar, no convertirse en un dump de 200.000 tokens.
Lectura práctica
Qué incluir y qué dejar fuera
Incluye documentación estable, quickstarts, API reference, SDKs, tutoriales mantenidos, changelog, límites de rate, política de seguridad, ejemplos oficiales y páginas con decisiones de arquitectura. Si una página cambia cómo se usa tu producto, merece estar.
Deja fuera posts promocionales, landing pages, pricing ambiguo, contenido duplicado, páginas antiguas sin aviso de deprecación y documentación que contradice la versión actual. Para un agente, una página obsoleta no es inocua: puede convertirse en código equivocado.
Cuando haya contenido sensible, no lo escondas en llms.txt. Si no debería ser rastreado o recuperado, arréglalo con autenticación, robots.txt, noindex, permisos o separación de entornos. llms.txt no es una capa de seguridad.
Lectura práctica
robots.txt, sitemap.xml y llms.txt: quién hace qué
robots.txt sigue siendo el contrato práctico para permitir o bloquear crawlers. OpenAI documenta user-agents distintos para búsqueda, entrenamiento y navegación activada por usuario. Si quieres controlar acceso de bots, empieza ahí.
sitemap.xml sigue siendo la pieza para descubrimiento de URLs en buscadores. No lo reemplaces. llms.txt debe enlazar lo importante, no listar cada URL publicable.
La combinación sensata es: robots.txt para permisos, sitemap para descubrimiento, schema para entidades y preguntas, HTML/Markdown limpio para lectura, y llms.txt para curación de rutas de contexto. Si una de esas capas está rota, llms.txt no compensa.
Cómo medir si sirve
Mide logs. Si publicas /llms.txt, añade seguimiento de requests por user-agent, estado HTTP, referer, bytes servidos y destino posterior. La pregunta no es solo lo piden, sino qué hacen después: abren docs, descargan llms-full, consultan API reference o rebotan.
Separa bots reales, herramientas de auditoría, previews de chat y humanos curiosos. El estudio de Ahrefs de junio de 2026 encontró muy poca lectura real de llms.txt en su muestra, así que no debes asumir impacto por publicarlo.
La métrica útil para un producto developer no es visitas a llms.txt; es menos tickets por documentación confusa, mejores respuestas de asistentes internos, más snippets correctos en herramientas de código y más citas a tus páginas canónicas.
Checklist
Implementación en Next.js, Astro o docs estáticas
En un sitio estático, lo más simple es generar public/llms.txt durante build desde un inventario curado. No lo escribas a mano si ya tienes frontmatter, sidebar o catálogo de docs: usa esa fuente y añade una capa editorial para descripciones.
En Next.js puedes servirlo como archivo estático en public/llms.txt o como route handler si necesitas construirlo dinámicamente. Para documentación versionada, prefiero generarlo en build: queda cacheable, revisable en PR y no depende de una base de datos en runtime.
En Astro, Docusaurus, Mintlify, GitBook o Fern revisa primero si la plataforma ya lo genera. Si lo hace, no dupliques. Audita el resultado, elimina páginas irrelevantes y añade descripciones útiles. La automatización sin criterio puede llenar el archivo de rutas que un agente nunca debería priorizar.
Errores comunes
- Prometer que llms.txt aumenta rankings en Google o apariciones en ChatGPT sin evidencia propia.
- Generar el archivo desde sitemap sin curación editorial.
- Meter enlaces a páginas obsoletas porque todavía reciben tráfico.
- Confundir
/llms.txtcon/llms-full.txty publicar un archivo principal enorme. - Olvidar Markdown limpio en las páginas enlazadas; si el destino es ilegible, el índice no salva nada.
- No revisar logs ni user-agents después de publicarlo.
- Publicar enlaces a documentación privada o endpoints internos pensando que
nadie lo mira.
Plantilla operativa para DevRel y equipos de producto
Owner: una persona de documentación o DevRel debe revisar el archivo en cada release importante. Si depende solo de SEO, acabará optimizado para keywords y no para agentes.
Puntos a revisar
Lo que conviene comprobar
Cadencia: actualízalo con cada cambio de API, SDK, onboarding o deprecación. Si tienes changelog semanal, el llms.txt no necesita cambiar cada semana; solo cuando cambian rutas de contexto.
Revisión: añade un check de CI que valide enlaces 200, tamaño razonable, ausencia de rutas privadas y presencia de secciones mínimas. También conviene testearlo con un agente real: lee nuestro llms.txt y escribe un ejemplo de integración. Si inventa, el archivo no está guiando lo suficiente.
Lectura práctica
Conclusión
llms.txt merece una implementación sobria. Es barato, legible, versionable y cada vez más documentación developer ofrece algún formato equivalente para agentes. Pero no arregla contenido débil ni reemplaza rastreo, schema, buen HTML o documentación técnica de verdad.
La decisión madura es publicarlo como una interfaz de contexto: una portada Markdown mantenida, con enlaces canónicos y descripciones precisas. Si además mides logs y pruebas respuestas de agentes, tendrás evidencia. Si solo lo subes esperando tráfico mágico desde IA, estás haciendo SEO performativo.
Preguntas frecuentes
¿Qué es llms.txt?
llms.txt es un archivo Markdown servido normalmente en /llms.txt que resume un sitio y enlaza las páginas más útiles para que modelos y agentes encuentren contexto técnico relevante.
¿llms.txt mejora el SEO en Google?
No hay evidencia sólida de que mejore rankings. Conviene tratarlo como una ayuda para agentes y asistentes, no como un factor SEO.
¿Cuál es la diferencia entre llms.txt y robots.txt?
robots.txt permite o bloquea crawlers; llms.txt orienta sobre qué documentación conviene leer. Son complementarios.
¿Necesito llms-full.txt?
Solo si tiene sentido ofrecer una versión extensa de la documentación en texto plano. El /llms.txt principal debería ser corto y curado.
¿Qué sitios deberían tener llms.txt?
Documentación de APIs, SDKs, productos developer, bases de conocimiento técnicas, herramientas con MCP, librerías open source y sitios donde un agente necesite elegir fuentes canónicas.
¿Cómo sé si mi llms.txt funciona?
Revisa logs, user-agents, requests posteriores, calidad de respuestas de agentes y si las herramientas citan páginas canónicas en vez de contenido viejo o promocional.
Cómo publicar un llms.txt útil sin vender humo SEO
- Inventariar fuentes canonicas. Lista quickstart, API reference, SDKs, seguridad, changelog, limites y tutoriales mantenidos.
- Definir intención. Escribe para agentes que necesitan resolver una tarea tecnica, no para un crawler generico.
- Curar enlaces. Agrupa por necesidad del usuario y añade descripciones que expliquen cuándo abrir cada URL.
-
Separar archivo corto y completo. Mantén
/llms.txtcomo mapa y usa/llms-full.txtsolo para corpus amplio. - Coordinar con robots y sitemap. Verifica permisos de crawlers, sitemap, schema y version Markdown de páginas importantes.
- Validar en CI. Comprueba 200, tamaño, duplicados, enlaces privados y secciones mínimas antes de desplegar.
- Probar con agentes reales. Pide a Claude Code, Codex, Cursor o Copilot que usen el archivo para resolver una tarea y observa errores.
- Medir logs. Segmenta requests por user-agent y revisa si los bots abren después la documentación correcta.
- Actualizar por release. Cambia el archivo cuando cambien rutas canónicas, APIs, SDKs o deprecaciones.
Cierre editorial
Límite sano
Paraleliza investigación y tareas acotadas. No paralelices criterio técnico ni integración final.
Fuentes y referencias
- Especificación llms.txt
- Repositorio answerdotai/llms-txt
- Chrome Lighthouse: llms.txt
- Cloudflare: Docs for agents
- Cloudflare llms.txt
- OpenAI: overview of crawlers
- Mintlify: improved agent experience
- Mintlify: real llms.txt examples
- Ahrefs study: llms.txt requests
- Model Context Protocol llms.txt
- Anthropic developer docs llms.txt
También te puede interesar
AGENTS.md y CLAUDE.md: contexto para agentesMCP en producción: seguridad y permisosMCP outputSchema y structuredContentOpenTelemetry GenAI para agentesEvaluación RAG en producción
Recibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Top comments (0)