Qué es el archivo llms.txt y cómo se implementa

La propuesta es de Jeremy Howard (Answer.AI) y se publicó en septiembre de 2024. Sigue siendo una convención abierta, no un estándar aprobado por ningún organismo, y ningún buscador ha confirmado que lo utilice como señal de posicionamiento. Lo que sí ha cambiado en los últimos meses es que Chrome empezó a auditarlo, y eso ha reabierto una discusión que parecía cerrada.

Conviene que sepas de dónde viene este artículo: Estudi Zeta presta servicios de posicionamiento y de visibilidad en modelos generativos, así que tenemos interés comercial en que este tema te parezca importante. Por eso el texto incluye también los argumentos en contra y la posición pública de Google Search, que es la de que este archivo no hace falta.

Un llms.txt es un índice legible por máquina. Cuando un agente llega a un dominio que no conoce, tiene dos opciones: rastrear páginas hasta hacerse una idea del conjunto, o leer un único fichero que se lo explique. La segunda le cuesta unos pocos cientos de tokens en lugar de varios miles.

La especificación pide una estructura mínima:

• Un encabezado H1 con el nombre del sitio o del proyecto. Es el único elemento obligatorio.
• Una cita en bloque con un resumen corto de qué es el sitio.
• Uno o varios párrafos con contexto adicional o instrucciones de interpretación.
• Encabezados H2 que agrupan listas de enlaces en sintaxis Markdown, con la forma [nombre](url): descripción breve.
• Una sección final titulada Optional, cuyos enlaces el agente puede omitir si va justo de contexto.

La sintaxis de enlace importa más de lo que parece, y más adelante verás por qué.

El error habitual es tratarlo como un sitemap en texto. Un sitemap lista URLs para que un rastreador las visite todas. Un llms.txt selecciona y jerarquiza para que un agente sepa cuáles importan.

Lo que aporta valor:

• Una descripción del sitio que diga a qué se dedica la empresa, a quién se dirige y dónde opera. Sin adjetivos de marketing, porque el lector es una máquina que va a resumirte.
• Los enlaces a las páginas que responden preguntas reales: servicios, precios, documentación, casos, contacto.
• Una descripción breve por enlace que explique qué encontrará el agente allí.
• Datos identificativos verificables: nombre legal, ubicación, ámbito de servicio.

Lo que sobra: enlaces de aviso legal y cookies, paginación de blog, categorías vacías, cualquier página que no responda a nada. Todo lo que incluyas consume contexto del agente y compite con lo que sí quieres que lea.

Mantener este archivo a mano funciona durante dos semanas. A la tercera publicación queda desactualizado y pasa a describir un sitio que ya no existe, que es peor que no tenerlo.

La implementación que tiene sentido es una ruta de servidor que construya el fichero a partir del contenido publicado en el CMS y lo devuelva con el tipo MIME correcto. En un stack con Nuxt y Strapi, la forma habitual es una ruta de servidor en Nitro que consulta la API del CMS, filtra por estado publicado, ordena por tipo de contenido y devuelve el Markdown ya montado.

Los puntos que hay que resolver, sea cual sea el stack:

1. Filtrar por estado de publicación. Solo contenido publicado, nunca borradores.
2. Cachear el resultado. Reconstruirlo en cada petición es innecesario, con revalidación diaria o al publicar es suficiente.
3. Devolver text/plain con codificación UTF-8. El fichero es Markdown, pero se sirve como texto.
4. Escapar los caracteres que rompen la sintaxis Markdown en títulos y descripciones que vengan del CMS.
5. Servirlo en la raíz del dominio, en /llms.txt. Una ruta distinta no la busca nadie.

Ese último punto es el que más veces se incumple, y es el que determina si la auditoría de Chrome encuentra el archivo o no.

Se confunden porque los dos son ficheros de texto en la raíz, pero hacen cosas opuestas.

robots.txt es un archivo de permisos: dice qué rutas puede o no puede rastrear un bot. Es restrictivo y lleva casi treinta años en uso, con soporte real y comprobable en todos los rastreadores relevantes.

llms.txt es un archivo de orientación: no prohíbe nada, propone por dónde empezar. Es descriptivo y su adopción real todavía está por demostrar.

No se sustituyen. Si quieres impedir que un rastreador de IA acceda a una sección, la herramienta es robots.txt (o el bloqueo por agente de usuario en el servidor, que es más fiable). Si quieres facilitar la comprensión a los agentes que sí quieres que entren, la herramienta es llms.txt.

Aquí toca ser preciso, porque es donde más se exagera.

Ningún proveedor grande de modelos ha confirmado públicamente que use llms.txt como fuente en sus productos de búsqueda o de chat. Los registros de servidor de la mayoría de sitios muestran pocas peticiones a ese fichero. La adopción, a día de hoy, es limitada.

Lo que sí ocurre es que agentes específicos y herramientas de desarrollo lo consultan cuando existe, y que el ecosistema de agentes autónomos (los que navegan y ejecutan tareas, no los que responden preguntas) es donde tiene una utilidad más clara: un agente con ventana de contexto limitada que tiene que decidir a qué página ir se beneficia de un índice.

Google Search ha sido explícito en la dirección contraria. Su guía sobre optimización para funciones generativas incluye llms.txt entre las cosas que no hacen falta, junto con el troceado de contenido y el marcado específico para IA. John Mueller ha comparado la propuesta con la etiqueta meta keywords y ha señalado que los bots no piden el archivo.

En mayo de 2026, Chrome incorporó a Lighthouse una categoría llamada Agentic Browsing, todavía marcada como en desarrollo. Evalúa cuatro cosas: la presencia del archivo llms.txt, el protocolo WebMCP, la calidad del árbol de accesibilidad y el desplazamiento acumulado del diseño (CLS).

Cómo se comporta la auditoría de llms.txt:

• Si el archivo no existe y el servidor devuelve un 404, la auditoría se marca como No Aplicable. No es un suspenso, porque publicarlo sigue siendo opcional.
• Si el servidor devuelve un error al intentar recuperarlo, la página queda marcada.
• Si el archivo existe, se comprueba su estructura: que tenga un H1, que contenga enlaces y que no sea sospechosamente corto.
• Los enlaces deben estar en sintaxis Markdown. Un fichero con los enlaces escritos como texto plano falla la auditoría, aunque el contenido sea correcto y el archivo se sirva bien.

Esa última condición produce una situación llamativa: un archivo mal formado puntúa peor que la ausencia de archivo. Si vas a publicarlo, la sintaxis de enlace no es un detalle de estilo.

La categoría no devuelve una puntuación de 0 a 100 como la de rendimiento. Devuelve una proporción de auditorías superadas, y no penaliza a un sitio por no haber adoptado todavía estas convenciones.

Dos de las cuatro auditorías (árbol de accesibilidad y CLS) llevan años en las prácticas de accesibilidad y rendimiento. Quien haya trabajado esas dos áreas parte con ventaja en esta categoría sin haber tocado nada específico de IA.

Merece la pena detenerse en la contradicción, porque explica buena parte del ruido que rodea al tema.

Google Search dice que no hace falta el archivo para aparecer en sus funciones generativas. Chrome lo audita como señal de preparación para la navegación agéntica. Las dos afirmaciones son compatibles si se entiende que hablan de cosas distintas: una de visibilidad en un buscador, otra de si un agente automatizado puede usar tu web con eficacia.

Lo que se deduce de ahí, y es la conclusión práctica de este artículo, es que llms.txt no es una táctica de posicionamiento. Es infraestructura de legibilidad para agentes. Si lo implementas esperando subir posiciones en Google, la evidencia disponible dice que no va a pasar. Si lo implementas porque los agentes automatizados forman parte de cómo se consulta tu web, tiene sentido, cuesta poco y no rompe nada.

La respuesta es que sí, con dos condiciones: que se genere de forma automática desde el CMS y que la sintaxis de enlace sea correcta. Un archivo generado a mano que se queda obsoleto, o uno con los enlaces mal formados, produce un resultado peor que no tener ninguno.

El coste de una implementación automatizada se mide en horas, no en días, y el archivo resultante se mantiene solo. Con ese coste, la pregunta de si los modelos lo leen hoy pierde parte de su peso: se implementa una vez y queda listo para cuando lo lean.

Lo que no conviene es tratarlo como sustituto de nada. Un sitio con arquitectura confusa, contenido sin estructura semántica y encabezados que no dicen de qué trata cada sección no mejora por publicar un índice en la raíz. El archivo orienta al agente hacia páginas que luego tiene que poder entender.