Qué es llms.txt: cómo crearlo y qué límites tiene

Qué es llms.txt

Un archivo llms.txt presenta información esencial de un sitio en texto simple. En lugar de enumerar cada URL, identifica el proyecto, explica qué ofrece y agrupa enlaces relevantes: documentación, servicios, productos, políticas o recursos.

Una web puede tener navegación, scripts y cientos de páginas, mientras que un agente necesita ubicar rápido las fuentes útiles para una tarea. llms.txt añade una capa editorial: el propietario elige qué páginas representan mejor al sitio y las describe brevemente.

No es una API, una instrucción obligatoria ni un permiso de rastreo. Una aplicación puede consultarlo o ignorarlo; su valor depende de URLs correctas, un resumen factual y un consumidor que decida descubrirlo.

Origen y estado de la propuesta

Jeremy Howard publicó la propuesta original de llms.txt el 3 de septiembre de 2024. El documento plantea usar /llms.txt para facilitar información durante la inferencia y sugiere ofrecer versiones Markdown de páginas importantes. También deja un límite central muy claro: la propuesta no prescribe cómo debe procesarse el archivo, porque esa decisión depende de cada aplicación.

Conviene describirlo como propuesta o convención emergente, no como estándar web obligatorio. Su existencia no fuerza a crawlers, modelos ni agentes a consultarlo ni ofrece compatibilidad universal.

Crear el archivo no “activa” la visibilidad en Claude, Perplexity o ChatGPT. No hay que presentar esos productos como consumidores garantizados ni a llms.txt como señal de citas. Puede servir a flujos compatibles, agentes propios o personas que lo abren directamente.

Formato recomendado de llms.txt

El archivo usa Markdown y suele vivir en https://ejemplo.com/llms.txt. Según la especificación de formato, el único elemento obligatorio es un H1 con el nombre del sitio o proyecto. Después puede incluir un resumen en blockquote, notas sin encabezados y secciones H2 con listas de enlaces.

Un ejemplo mínimo sería:

# Nombre del sitio

> Resumen factual del propósito y del contenido disponible.

## Contenido principal
- [Guía de inicio](https://ejemplo.com/guia/): explica cómo empezar.
- [Documentación](https://ejemplo.com/docs/): referencia técnica actualizada.

No agregues metadatos inventados, prompts ocultos ni instrucciones promocionales. El archivo debe orientar hacia fuentes públicas, no intentar controlar respuestas.

llms.txt, robots.txt y sitemap.xml no hacen lo mismo

Los tres archivos pueden coexistir porque resuelven problemas diferentes. Sustituir uno por otro genera huecos técnicos.

Cloudflare también distingue orientación de acceso y bloqueo efectivo: su guía para controlar crawlers de IA recomienda usar robots.txt para comunicar qué rutas pueden rastrearse y controles de seguridad cuando se necesita impedir el acceso. llms.txt no reemplaza ninguna de esas capas.

Impacto real en SEO y citas de IA

Para Google Search, el impacto directo es ninguno. La guía oficial de Google sobre funciones de IA dice que Search no usa llms.txt, que el archivo no ayuda ni perjudica la visibilidad y que tampoco modifica los rankings. Google puede llegar a descubrir o indexar distintos tipos de archivo, pero eso no les concede un tratamiento especial.

Las citas tampoco están garantizadas. Dependen de que el sistema acceda a la página, la recupere para una consulta, la considere relevante y muestre una atribución. Un mapa correcto puede reducir fricción, pero no controla esas etapas.

El beneficio es operativo: mantener fuentes canónicas seleccionadas, explicar la estructura y probar agentes propios. Es accesibilidad documental para ciertos consumidores, no un atajo de GEO.

En el caso de ChatGPT Search, OpenAI ofrece una vía documentada diferente. Su FAQ para publishers y developers indica que no se debe bloquear a OAI-SearchBot en robots.txt si se quiere que el contenido pueda incluirse en resúmenes y fragmentos. Permitirlo mejora la posibilidad de acceso, pero no promete una cita.

GPTBot cumple otra función vinculada al posible entrenamiento. No es lo mismo que OAI-SearchBot y habilitarlo no debe presentarse como requisito para aparecer citado en ChatGPT Search. Separar descubrimiento para búsqueda, controles de entrenamiento y archivos editoriales evita recomendaciones engañosas.

Google Search y Lighthouse Agentic Browsing: por qué parecen contradecirse

No hay contradicción: son productos y objetivos diferentes. Google Search ignora llms.txt para visibilidad y ranking. Lighthouse, en cambio, incorporó una auditoría dentro de Agentic Browsing para comprobar el comportamiento técnico del archivo en escenarios de navegación por agentes.

La documentación de Lighthouse sobre llms.txt explica que la auditoría marca un problema si el servidor responde con un error al solicitarlo. Si no existe y devuelve 404, el resultado es Not Applicable (N/A) porque ofrecerlo sigue siendo opcional. Un 404 no prueba una falla SEO; un 500, 502 o 503 sí revela un problema de servidor que conviene investigar.

Pasar esa auditoría solo confirma que el recurso está disponible con una respuesta válida. No demuestra que Google Search lo consuma, que un modelo lo haya incorporado ni que aumenten las menciones de una marca.

Cuándo puede servir y cuándo no es prioritario

Puede tener sentido en sitios con documentación extensa, catálogos complejos, varias áreas de servicio, APIs, centros de ayuda o muchos recursos con jerarquías claras. También es útil si el equipo construye un agente propio que consulta explícitamente /llms.txt, o si quiere mantener un índice Markdown legible y versionable.

En un portafolio puede resumir perfil, servicios, proyectos y artículos destacados, siempre que se mantenga breve.

No es prioritario cuando existen problemas de indexación, contenido duplicado, enlaces rotos, páginas lentas o información superficial. Antes conviene resolver rastreo, arquitectura, contenido people-first y medición. Si necesitás ordenar esas bases, el servicio de SEO técnico y GEO parte del diagnóstico, no de asumir que todos los sitios necesitan el mismo archivo.

Cómo crear llms.txt paso a paso

1. Definí el propósito

Definí qué debe entender un lector: qué hace el sitio, para quién y dónde están sus fuentes principales. Si no podés resumirlo, primero ordená la arquitectura.

2. Inventariá las URLs canónicas

Elegí páginas públicas, vigentes y representativas. Excluí parámetros, búsquedas internas, entornos de prueba, duplicados, redirecciones y recursos bloqueados. Nunca incluyas secretos ni endpoints privados.

3. Redactá un H1 y un resumen factual

Usá el nombre real como H1. En el blockquote, explicá propósito y alcance sin superlativos. Una descripción verificable reduce ambigüedad.

4. Agrupá enlaces por intención

Creá secciones que reflejen el sitio. Cada elemento puede incluir título, URL canónica y una frase descriptiva. Priorizá calidad antes que cantidad.

5. Separá lo secundario

Agregá material secundario bajo ## Optional: la propuesta reserva ese nombre para URLs que pueden omitirse con un contexto corto. No acumules enlaces viejos.

6. Publicalo en la raíz

En Astro, public/llms.txt se publica como /llms.txt. Verificá que Cloudflare o el proxy no lo redirijan a una página HTML de error.

7. Revisá rastreo y seguridad por separado

Revisá robots.txt para los crawlers relevantes y protegé lo que no deba ser público. Añadir una URL no concede permisos; omitirla no bloquea el recurso.

8. Asigná mantenimiento

Actualizalo cuando cambien rutas o contenido importante. Incluí la revisión en el flujo que controla sitemap, canonicals y redirects.

Caso real: nicolaspirello.com

Este portafolio publica su archivo llms.txt en la raíz. La estructura empieza con una identificación y un resumen breve, continúa con notas introductorias sobre idioma, ubicación profesional y temas principales, y después agrupa enlaces canónicos bajo Perfil, Servicios, Proyectos y Recursos sin copiar el contenido completo de cada página.

La selección funciona como índice editorial. El caso de Portafolio Astro conserva el detalle técnico; llms.txt solo indica por qué la URL es relevante. Así no se crea una segunda versión del sitio.

Publicarlo facilita un mapa compacto, pero no se registra como “optimización de ranking” ni como prueba de compatibilidad con una IA. Ante un cambio, corresponde actualizar y validar el enlace, no agregar claims.

Cómo validar el archivo

La validación útil combina formato, HTTP y calidad editorial:

1. Abrí https://tudominio.com/llms.txt en una sesión sin autenticar y confirmá un estado 200.
2. Revisá que el contenido visible sea texto Markdown y no la plantilla HTML de una página 404.
3. Confirmá un solo H1, secciones H2 coherentes y listas con sintaxis [título](URL).
4. Probá cada enlace y corregí redirecciones, errores, URLs no canónicas o entornos temporales.
5. Compará el archivo con el sitio actual: nombres, productos, políticas y versiones deben coincidir.
6. Verificá que no exponga rutas privadas, datos personales innecesarios, tokens ni instrucciones internas.
7. Si usás Lighthouse Agentic Browsing, interpretá N/A como ausencia opcional y los errores de servidor como fallas técnicas, no como evaluación de contenido.
8. Probalo en el agente o parser configurado para consumirlo; no extrapoles el resultado a otros productos.

Podés inspeccionar cabeceras con curl -I https://tudominio.com/llms.txt y el cuerpo con curl https://tudominio.com/llms.txt. La plantilla de llms.txt ofrece una base genérica para empezar sin copiar datos de este caso.

Errores frecuentes al implementarlo

• Prometer mejoras de ranking. Google declara que ignora el archivo; medirlo como tarea SEO ganada crea una expectativa falsa.
• Afirmar adopción universal. Que una herramienta pueda abrir Markdown no significa que consulte automáticamente /llms.txt ni que lo use como señal.
• Copiar el sitemap completo. Una lista masiva elimina la curaduría y vuelve a crear el problema de exceso de contexto.
• Confundir crawlers. OAI-SearchBot, GPTBot y otros agentes pueden tener finalidades distintas; documentá cada regla de robots.txt.
• Incluir información sensible. Todo lo enlazado o escrito debe considerarse público. Para bloquear acceso se necesitan controles de seguridad.
• Dejar URLs obsoletas. Redirecciones y errores reducen la utilidad del mapa y pueden enviar al consumidor hacia una fuente incorrecta.
• Interpretar Lighthouse como ranking. La auditoría comprueba disponibilidad técnica dentro de un escenario agentic, no visibilidad en Search.
• Generarlo sin revisión humana. Una persona debe decidir qué es principal, opcional y fiel al sitio.

Preguntas frecuentes sobre llms.txt