llms.txt: qué es, cómo implementarlo y qué dice la evidencia sobre su eficacia

Si has leído algo sobre posicionamiento en IA durante el último año, es probable que te hayas encontrado con llms.txt presentado como requisito imprescindible. Algunas auditorías SEO lo marcan como incidencia, ciertas listas de tareas de GEO lo sitúan entre las primeras acciones y varias herramientas generan el archivo automáticamente.

Y luego están los datos.

En un estudio publicado por Ahrefs en junio de 2026, el 97 % de los 38.360 archivos válidos observados no recibió ninguna petición durante mayo. El dato no demuestra que llms.txt carezca de utilidad, pero sí obliga a separar su uso documental de las promesas de visibilidad en búsqueda generativa.

Esta guía separa la propuesta técnica de la evidencia disponible: explica qué es llms.txt, cómo se implementa y qué permiten concluir los datos publicados hasta ahora. La evidencia muestra cierto consumo en flujos documentales y agénticos, pero no demuestra que mejore la visibilidad en motores de búsqueda generativa. El caso de uso documental y la hipótesis de posicionamiento deben evaluarse por separado.

Es el primer artículo del silo temático que acompaña a nuestra guía técnica de GEO y AEO, donde tratamos el panorama completo del posicionamiento en motores generativos. Si llegas aquí sin ese contexto, el pilar ofrece el marco general; este artículo entra en el detalle de una pieza concreta.

Qué es llms.txt y qué problema intenta resolver

llms.txt es un archivo de texto en formato Markdown que se publica en la raíz del dominio, siguiendo la misma lógica de ubicación que robots.txt:

https://tudominio.com/llms.txt

Su contenido es un índice curado: una lista de los recursos más importantes del sitio, cada uno con su enlace y una descripción breve. No es el contenido en sí, sino un mapa de dónde está lo que importa.

El problema que intenta resolver es real y conocido por cualquiera que haya trabajado con modelos de lenguaje. Una página web moderna es, desde el punto de vista de un modelo, un documento con mucho ruido: menús de navegación, banners de cookies, anuncios, bloques de artículos relacionados, pies de página extensos y JavaScript que a veces determina qué se muestra. Extraer de ahí la información útil consume tokens y admite errores de interpretación. A eso se suma que las ventanas de contexto, aunque hayan crecido mucho, siguen siendo menores que la mayoría de sitios completos.

La propuesta de llms.txt es directa: en lugar de que cada sistema resuelva ese problema por su cuenta con resultados desiguales, que el propio sitio publique una versión limpia y jerarquizada de lo que considera importante.

Algunas plataformas de documentación han popularizado una extensión denominada llms-full.txt, que reúne en un único archivo Markdown el texto completo de las páginas relevantes. No debe confundirse con el núcleo mínimo de la propuesta original, que define principalmente llms.txt, versiones .md de las páginas y herramientas para generar contextos expandidos. llms-full.txt puede considerarse actualmente una convención complementaria del ecosistema.

Conviene señalar desde el principio un matiz que se pierde con frecuencia: Jeremy Howard, autor de la propuesta, la planteó para el momento de la inferencia —cuando un modelo necesita información concreta para responder ahora mismo— y no para el entrenamiento. No es un mecanismo para influir en lo que un modelo aprende, sino para facilitarle el trabajo cuando consulta un sitio en tiempo real.

Origen y estado real del estándar

La propuesta se publicó el 3 de septiembre de 2024 por Jeremy Howard, cofundador de Answer.AI y de fast.ai. La especificación completa está disponible en llmstxt.org.

Aquí hay un punto que conviene fijar bien, porque determina cómo interpretar todo lo demás: llms.txt es una propuesta de convención comunitaria, no un estándar web formal. No es una Recomendación del W3C ni un RFC del IETF. Dispone de una especificación pública, un repositorio y canales de discusión, pero no está sometida a un proceso normativo formal ni establece requisitos de conformidad obligatorios para los proveedores.

Esto no la descalifica. El protocolo robots.txt surgió como una convención comunitaria en 1994 y operó durante casi tres décadas como estándar de facto antes de formalizarse mediante el RFC 9309, publicado en septiembre de 2022. La diferencia es que robots.txt alcanzó una adopción generalizada entre los principales buscadores antes de su formalización, algo que todavía no ha sucedido con llms.txt. Por eso importa distinguir entre un estándar normativo y una propuesta de convención cuando se presenta el archivo como requisito técnico.

El contexto de origen también ayuda a entender el resto de esta guía. La propuesta surgió con un fuerte foco en documentación técnica y asistentes de programación, y utilizó la documentación de FastHTML —un proyecto del propio Howard— como ejemplo inicial. No obstante, el autor contempló también otros ámbitos, como sitios corporativos, investigación, legislación, comercio electrónico y educación. El objetivo inicial era facilitar la construcción de contexto durante la inferencia, no funcionar como una señal de posicionamiento o citación en buscadores generativos.

La distancia entre el propósito original y los usos de posicionamiento que posteriormente se le han atribuido explica buena parte de la confusión que rodea al archivo. Volveremos sobre ello cuando revisemos los datos.

La sintaxis: qué define exactamente la especificación

La especificación es deliberadamente mínima. Define un documento Markdown con una estructura fija, sin introducir sintaxis nueva ni esquemas propios. Estos son sus elementos, en el orden en que deben aparecer:

Un encabezado H1 con el nombre del proyecto o del sitio. Es la única sección obligatoria de toda la especificación.

Opcionalmente, una cita en bloque con un resumen breve. Cuando se incluye, contiene la información esencial para interpretar el resto del archivo y funciona como contexto inicial sobre el sitio.

Cero o más secciones Markdown de cualquier tipo excepto encabezados. Párrafos, listas o bloques de código donde ampliar el contexto: a qué se dedica la organización, cómo interpretar los recursos enlazados, qué convenciones sigue el contenido.

Secciones H2 con listas de enlaces. Estas secciones constituyen normalmente el cuerpo principal del archivo. Cada elemento sigue el formato [nombre del recurso](url): descripción, donde la descripción es opcional pero recomendable. Los H2 agrupan los recursos por categoría según convenga a cada sitio: documentación, servicios, artículos, referencias de API.

Una sección H2 titulada Optional, con un significado reservado. Los recursos que aparezcan bajo ese encabezado se consideran secundarios: un sistema que necesite un contexto más breve puede omitirlos sin perder lo esencial. Es el único encabezado con semántica definida por la especificación.

Un ejemplo mínimo completo:

# Nombre del proyecto

> Resumen breve del proyecto con la información necesaria
> para interpretar el resto del archivo.

Contexto adicional en formato libre: a qué se dedica la
organización, qué tipo de contenido publica, cómo están
organizados los recursos que siguen.

## Documentación

- [Guía de inicio](https://ejemplo.com/inicio): primeros pasos y conceptos básicos.
- [Referencia de API](https://ejemplo.com/api): documentación completa de endpoints.

## Optional

- [Notas de versión](https://ejemplo.com/changelog): historial de cambios.

Dos observaciones sobre la construcción del archivo.

La primera es que el valor está en la curaduría, no en la exhaustividad. Un archivo que enumere las doscientas URL del sitio reproduce el problema que la propuesta intentaba resolver. La utilidad aparece cuando alguien decide qué diez o quince recursos representan realmente al sitio y los describe con precisión.

La segunda es que las descripciones importan tanto como los enlaces. Un listado de URL sin contexto obliga a seguir cada enlace para saber qué contiene. Una descripción de una línea permite decidir cuáles son relevantes antes de recuperarlas, que es justamente el ahorro que la propuesta persigue.

Un ejemplo real: nuestro propio archivo, y lo que encontramos al auditarlo

Muchos de los ejemplos publicados sobre llms.txt proceden de empresas de producto técnico con documentación extensa, como Stripe, Anthropic o FastHTML. Para una consultora, un despacho o una pyme industrial, la pregunta práctica es distinta: qué debe incluir el archivo cuando no existe una referencia de API que ofrecer.

Nuestro archivo está en medranet.es/llms.txt y puedes abrirlo mientras lees esto. Estas son las decisiones que hay detrás.

El encabezado y el resumen definen la entidad. El H1 es el nombre de la organización y la cita en bloque describe a qué se dedica, con qué especialidades y sobre qué tecnologías. Al aparecer al inicio, ofrece contexto antes de que un consumidor decida seguir los enlaces. No puede asumirse que todos los sistemas lo procesen del mismo modo, pero nombrar áreas concretas —agentes IA, GEO/AEO, Django— resulta más informativo que una descripción genérica de «soluciones digitales».

Los H2 agrupan por tipo de relación con el lector, no por estructura del menú. Hay un bloque de servicios principales, uno de servicio complementario y otro de recursos. El archivo no reproduce la navegación: presenta la jerarquía de lo que alguien necesitaría saber para entender qué hacemos y dónde ampliar información.

Cada enlace lleva una descripción, salvo en Optional. Los recursos secundarios pueden omitirse si un consumidor necesita un contexto breve, por lo que la descripción detallada se concentra en los recursos principales.

Diez enlaces, no cuarenta. El sitio tiene más páginas, pero incluirlas todas convertiría el archivo en un sitemap en Markdown y eliminaría su función de curaduría.

Al preparar este artículo auditamos el archivo y encontramos dos incidencias de distinta gravedad. La primera era sustantiva: dos enlaces apuntaban a páginas eliminadas meses antes. La segunda era una ineficiencia técnica: las URL no incluían la barra final de sus versiones canónicas, por lo que generaban una redirección antes de llegar al contenido.

Ninguna había sido detectada por las comprobaciones que utilizábamos hasta ese momento. La lección es concreta: verificar que el archivo existe no basta; también hay que comprobar periódicamente sus destinos, sus URL canónicas y su coherencia con el sitio. Un llms.txt con enlaces muertos puede perjudicar a cualquier consumidor que confíe en él y reduce la utilidad del archivo.

Si mantienes uno, trátalo como contenido publicado y revísalo cuando cambie la arquitectura del sitio. No es un archivo que se genera una vez y se olvida.

Qué dice la evidencia disponible

Conviene empezar por la adopción. En noviembre de 2025, SE Ranking analizó cerca de 300.000 dominios y encontró que el 10,13 % publicaba llms.txt. En los sitios con más de 100.000 visitas mensuales, la adopción descendía al 8,27 %. Su análisis estadístico y su modelo predictivo no encontraron una relación medible entre la presencia del archivo y la frecuencia de citación; al retirar esa variable, el modelo mejoró su precisión.

En un estudio separado, ALLMO revisó distintas muestras de dominios con alta visibilidad en sistemas generativos. Entre los cincuenta dominios más citados de una de sus clasificaciones, solo uno publicaba llms.txt. ALLMO también encontró una única URL llms.txt entre 94.614 URL citadas en 11.867 respuestas. Estos datos describen sus muestras y no permiten aislar causalidad, pero tampoco muestran una preferencia observable por el formato.

El bloque de evidencia más amplio sobre consumo procede de Ahrefs. La empresa analizó los registros y el tráfico de 137.210 dominios que habían recibido visitas durante mayo de 2026 y utilizaban Ahrefs Web Analytics. El 28 % —38.360 dominios— publicaba un archivo válido, pero el 97 % de esos archivos no recibió ninguna petición durante todo el mes.

Entre el 3 % que sí registró tráfico, el 96 % de las solicitudes procedía de bots. Aproximadamente un 12 % correspondía al propio ecosistema que analizaba la convención: herramientas GEO/AEO (5,8 %), verificadores o bots de descubrimiento (3,6 %) y bots de investigación (2,7 %). Una petición HTTP solo acredita que el archivo se descargó; no demuestra que se utilizara después para generar una respuesta, seleccionar una fuente o producir una cita.

Otros estudios apuntan en la misma dirección. Limy.AI analizó 515.382.577 eventos de bots durante noventa días y registró 408 peticiones directas a llms.txt. OtterlyAI observó 62.100 visitas de bots, de las cuales 84 —alrededor del 0,1 %— solicitaron el archivo; una página media del mismo sitio recibió unas 265 visitas. OtterlyAI retiró posteriormente esta comprobación de su auditoría GEO al considerar que desviaba atención de verificaciones que la empresa juzgaba más relevantes para la visibilidad.

Un ensayo observacional publicado por Search Engine Land siguió diez sitios durante noventa días antes y después de implementar el archivo. Dos aumentaron su tráfico procedente de sistemas de IA, pero habían realizado otros trabajos durante el mismo periodo; de los ocho restantes, siete no mostraron cambios medibles y uno descendió un 19,7 %. La muestra es pequeña y no permite atribuir los resultados a llms.txt, pero tampoco aporta evidencia de un efecto consistente.

Ahrefs comprobó además las solicitudes a /llms.txt que devolvían 404. En su muestra, los bots clasificados como herramientas de IA no solicitaron esa ruta en dominios donde el archivo no existía. Esto sugiere que no estaban sondeándola sistemáticamente durante el periodo analizado, aunque no permite descartar otros mecanismos de descubrimiento, como enlaces, sitemaps, documentación o instrucciones explícitas del usuario.

La postura de Google es inequívoca para su buscador. La documentación oficial de Google Search indica que no utiliza llms.txt y que mantenerlo no beneficia ni perjudica la visibilidad o el posicionamiento, incluidas sus funciones generativas. En julio de 2025, Gary Illyes ya había expresado la misma posición en un evento de Search Central, según la crónica de Search Engine Land. A fecha de actualización, no hemos encontrado documentación pública de Google, OpenAI, Anthropic, Microsoft o Perplexity que presente el archivo como señal de selección o citación.

Hay dos cautelas metodológicas. La primera es que los estudios de registros miden descargas, no el uso posterior del contenido. La segunda es que varias muestras proceden de clientes de herramientas SEO o de dominios monitorizados por sus autores, por lo que no representan necesariamente la web en su conjunto.

También existe un contrapunto relevante. Mintlify publicó un análisis basado en datos de Profound sobre 25 empresas durante siete días. En esa muestra se observaron peticiones atribuidas a sistemas de OpenAI y Microsoft, con mayor actividad sobre llms-full.txt que sobre llms.txt. El estudio confirma que algunos sistemas solicitan estos archivos en determinados entornos, pero no demuestra que las descargas influyeran en la selección de fuentes, las citas o la visibilidad.

El balance es, por tanto, específico: existe consumo observable, pero la evidencia disponible no muestra que publicar llms.txt mejore la presencia en buscadores generativos.

Dónde tiene un uso más documentado

El uso más coherente con la propuesta original aparece en documentación técnica y en flujos donde un usuario o una integración proporciona el archivo como contexto. En este escenario no se espera que un rastreador descubra el archivo y decida citarlo: un consumidor concreto lo carga porque necesita documentación limpia para completar una tarea.

El ejemplo oficial más claro procede de Google. En una guía sobre ADK y Gemini CLI, el usuario descarga llms-full.txt y lo incorpora explícitamente a la sesión para que el asistente trabaje con la documentación del framework. El beneficio potencial es concreto y comprobable dentro de ese flujo: reducir ruido, limitar tokens y utilizar una referencia actualizada.

Otros asistentes de programación, integraciones MCP y pipelines RAG pueden consumir llms.txt, llms-full.txt o exportaciones Markdown cuando el usuario o la integración estén configurados para ello. No debe confundirse esta posibilidad con soporte nativo universal ni con descubrimiento automático por parte de todas las herramientas.

Este uso coincide con el problema documental descrito en la propuesta original. Es el ámbito con ejemplos más claros, pero todavía conviene distinguir entre tres resultados diferentes: que una herramienta solicite el archivo, que utilice correctamente su contenido y que esa información mejore de forma medible la respuesta.

Entre los bots de investigación observados por Ahrefs, el más activo se identificaba como prompt-injection-survey/1.0. El nombre sugiere un análisis de llms.txt como posible superficie para inyecciones indirectas de instrucciones, aunque el identificador por sí solo no permite conocer la identidad, el alcance o la metodología del operador. En cualquier caso, el archivo debe tratarse como contenido público susceptible de ser incorporado al contexto de un agente.

En qué se diferencia de robots.txt y del sitemap

Los tres archivos viven en la raíz del dominio y los tres tienen que ver con cómo las máquinas leen un sitio, pero resuelven problemas distintos y no se sustituyen entre sí.

De esa tabla se derivan los dos errores más frecuentes.

El primero es intentar usar llms.txt para restringir accesos. No sirve para eso: no concede ni deniega nada, y no existe ningún mecanismo que obligue a respetarlo. Si el objetivo es controlar qué rastreadores de IA acceden al contenido, la herramienta es robots.txt, con reglas explícitas por agente. Y conviene recordar que robots.txt también es un protocolo voluntario: no es un control de acceso ni una medida de seguridad. Impedir el acceso técnicamente requiere autenticación, reglas en el servidor, CDN o WAF.

El segundo es tratarlo como un sustituto del sitemap. El sitemap declara todas las URL que quieres que se rastreen; llms.txt selecciona unas pocas para dar contexto. Uno busca cobertura, el otro busca síntesis. Un llms.txt que enumere todo el sitio ha dejado de cumplir su función y no hace mejor el trabajo que ya hace el sitemap.

Por qué mantenemos el nuestro

Publicar un artículo que cuestiona la eficacia de llms.txt teniendo uno propio exige explicar el criterio.

Lo mantenemos por tres razones, ninguna relacionada con el posicionamiento.

El coste es bajo y conserva opcionalidad. El archivo principal tiene unas treinta líneas. Mantenerlo no garantiza un retorno, pero deja disponible un recurso que una futura integración agéntica podría utilizar. La condición es asumir el coste editorial de revisarlo cuando cambie el sitio.

El ejercicio de escribirlo tiene valor por sí mismo. Obliga a decidir qué recursos representan realmente a la organización y a describirlos con precisión. Ese trabajo de síntesis resulta útil para la arquitectura del sitio y para la propuesta comercial, aunque ningún sistema llegue a leer el archivo.

Funciona como control de coherencia. Cuando cambian los servicios, los contenidos o las rutas, el archivo debe reflejarlo. La auditoría realizada para este artículo mostró precisamente esa necesidad.

Lo que no hacemos es presentarlo como factor de posicionamiento ni situarlo entre las primeras acciones recomendadas a un cliente. Tampoco lo vendemos como un servicio aislado. Su prioridad depende del tipo de sitio y de que exista un consumidor plausible.

Tras la auditoría, mantendremos llms.txt como índice curado y editorial. Automatizaremos la construcción de las URL canónicas y añadiremos una validación en el proceso de compilación para detectar rutas inexistentes. llms-full.txt, que en nuestro caso reúne de forma exhaustiva el contenido publicado, se generará automáticamente.

También registramos accesos por agente de usuario. Cuando exista una serie temporal suficiente, podremos publicar qué sistemas han solicitado realmente los archivos y con qué frecuencia.

Checklist: cuándo tiene sentido y cuándo no

Puede tener sentido si publicas documentación técnica. Referencias de API, guías de integración y documentación de producto son el caso de uso más documentado. Publicar llms.txt o llms-full.txt resulta razonable cuando los usuarios o las integraciones pueden incorporarlos de forma explícita a sus herramientas.

Puede tener sentido si existe un caso agéntico plausible en tu categoría. Comercio con integraciones, comparación de proveedores, consulta de normativa o reservas son ejemplos posibles. Debe plantearse como preparación de bajo coste, no como una mejora demostrada de visibilidad.

Suele ser secundario para sitios corporativos y de marketing. Si el coste de creación y mantenimiento es pequeño, puede publicarse como experimento. Si existen problemas de rastreo, indexación, contenido o autoridad, esas tareas tienen una prioridad mucho más clara.

No lo priorices si el sitio tiene problemas de indexación sin resolver, robots.txt bloquea rastreadores que necesitas permitir o no existe ninguna forma de comprobar su consumo.

Si decides mantenerlo, aplica cuatro reglas:

• Revísalo cuando cambie la arquitectura del sitio. Una comprobación superficial puede confirmar que el archivo existe sin detectar enlaces rotos.
• Usa las URL canónicas para evitar redirecciones innecesarias.
• Cura, no inventaríes: una selección breve y descrita aporta más contexto que un listado exhaustivo.
• Trátalo como contenido público. Si una herramienta lo incorpora como contexto, su contenido puede influir en la representación que genere.

Conclusión: una convención documental, no una palanca de citación

La evidencia disponible no muestra que publicar llms.txt mejore la probabilidad de ser citado en motores generativos. Google declara que no lo utiliza y los estudios disponibles observan un consumo muy limitado por parte de los rastreadores asociados a búsqueda. Una descarga ocasional tampoco demuestra que el contenido se haya utilizado o que haya influido en una respuesta.

Su utilidad potencial se concentra en otro ámbito: documentación y flujos donde un usuario o una integración proporciona el archivo como contexto. En esos casos puede reducir ruido y facilitar el acceso a una selección actualizada de recursos. Por eso conviene evaluarlo como una convención documental experimental, no como un factor de posicionamiento.

En los próximos meses habrá que vigilar si algún proveedor documenta su uso en producción, si aumenta la adopción fuera de la documentación para desarrolladores y cómo evoluciona el consumo agéntico de la web. Actualizaremos este artículo cuando cambien los datos.

Este artículo forma parte del silo sobre posicionamiento en motores generativos que acompaña a nuestra guía técnica de GEO y AEO. En las próximas semanas publicaremos los análisis dedicados a Schema.org aplicado a GEO y a cada plataforma.

Si estás decidiendo dónde invertir el esfuerzo de posicionamiento de tu empresa y necesitas criterio técnico para separar prioridades de experimentos, escríbenos y cuéntanos tu caso.