llms.txt y Páginas de Manifiesto para Agentes: Un Índice de Sitio Orientado a Máquinas y Mantenido

Una página llms.txt y de manifiesto para agentes es un índice orientado a máquinas que indica a los sistemas de IA qué representa un sitio, qué páginas públicas son autoritativas y —cuando el negocio admite acciones de agentes— qué capacidades y políticas verificadas aplican. Es un mapa hacia fuentes mantenidas, no un sustituto de esas fuentes ni una promesa de que un rastreador en particular lo utilizará.

Su contrato es identidad → alcance → destinos autoritativos → capacidades opcionales → restricciones → actualización. El archivo tiene éxito cuando una máquina puede recuperarlo, interpretarlo sin adivinar, seguir URLs canónicas activas y llegar a hechos que aún coinciden con la realidad de producción.

Preguntas que responde

La pregunta principal es: "¿Qué partes de este sitio debería usar un sistema de IA para entender la organización, su contenido y sus acciones admitidas?" Las preguntas secundarias incluyen:

• ¿Cuál es el nombre canónico, dominio, propósito y audiencia del sitio?
• ¿Qué páginas de producto, servicio, documentación, precios, políticas y soporte son autoritativas?
• ¿Qué páginas deben preferirse frente a archivos, páginas de campaña, parámetros o versiones regionales duplicadas?
• ¿El sitio expone una capacidad real de agente, o solo información legible por humanos?
• ¿Dónde están documentadas la autenticación, límites de tasa, manejo de datos, términos comerciales y soporte?
• ¿Qué afirmaciones son guía descriptiva en lugar de reglas de control de acceso?
• ¿Quién es propietario del archivo, qué evento desencadena una actualización y cómo se detecta la desviación?

Cuándo usar este tipo de publicación

Usa este tipo cuando el sitio tenga suficiente contenido público y duradero como para beneficiarse de un índice curado orientado a máquinas y alguien pueda encargarse de su mantenimiento. La razón para publicarlo es reducir la ambigüedad para los sistemas de recuperación, no crear una URL adicional por sí misma.

No confundas guía con control. robots.txt expresa preferencias de acceso de rastreadores; un sitemap XML ayuda a los rastreadores a descubrir URLs; la autenticación y autorización deciden si una acción puede ocurrir. llms.txt proporciona contexto curado. Una frase en llms.txt no puede conceder acceso, revocar acceso, proteger un secreto ni anular los términos de una página de destino.

Ideal para estos tipos de negocio

1. SaaS . El mejor ajuste porque una empresa de software suele tener fuentes distintas de producto, funcionalidades, precios, integración, API, seguridad, estado y documentación. El índice puede resolver qué página es propietaria de cada hecho, mientras que un manifiesto de capacidades separado puede describir solo las acciones que el producto realmente admite.
2. Ecommerce . Adecuado cuando los productos, envíos, devoluciones, disponibilidad y políticas de atención al cliente son públicos y canónicos. Mantén los datos volátiles de productos en feeds o APIs; usa el índice para señalar esas fuentes mantenidas en lugar de copiar un catálogo en Markdown.
3. Marketplaces . Valioso cuando las políticas de compradores, vendedores, proveedores y plataforma difieren. Etiqueta cada audiencia y jurisdicción para que un agente no aplique reglas de vendedor a un comprador ni infiera inventario de plataforma a partir de un solo listado.
4. Servicios B2B . Útil para aclarar capacidades, industrias, límites de servicio, evidencia, material de adquisición y rutas de contacto. No conviertas un alcance negociado o una promesa específica de un cliente en una afirmación universal orientada a máquinas.
5. Agencias . Útil cuando la firma mantiene muchas páginas de servicios, metodologías, casos de estudio y experiencia. Los portales de clientes, credenciales, informes privados y manuales internos se quedan fuera del archivo público.
6. Fabricantes y negocios industriales . Útil para dirigir sistemas a familias de productos, especificaciones, certificaciones, manuales, distribuidores y documentos de seguridad. El índice nunca debe parafrasear instrucciones críticas de seguridad cuando el documento controlado es la autoridad.

Los sitios pequeños tipo folleto con cinco páginas estables pueden ganar poco con otro artefacto mantenido. Los sitios sin un propietario de contenido claro deberían arreglar la canonización, navegación y calidad de fuentes antes de publicar un archivo que se desviará de inmediato.

Intención de búsqueda

La intención de búsqueda es el resultado esperado de una consulta. Este tipo tiene dos audiencias con intenciones diferentes. Una máquina obtiene una ruta raíz predecible y espera Markdown conciso, encabezados estables, enlaces canónicos y sin ruido decorativo. Un buscador humano generalmente quiere guía de implementación: “ejemplo de llms.txt”, “qué va en llms.txt” o “formato de manifiesto para agente”. La página explicativa pública puede responder esas preguntas, mientras que el /llms.txt desplegado permanece optimizado para recuperación por máquinas.

El archivo en sí no es una página de aterrizaje de palabras clave. No añadas definiciones genéricas, términos de categoría repetidos ni cientos de enlaces a blogs para hacerlo “posicionar”. Cada línea extra consume atención y crea otra obligación de mantenimiento. Prefiere diez enlaces deliberados con descripciones claras antes que un volcado de diez mil URLs.

Debido a que las convenciones y el soporte de los consumidores pueden cambiar, indica en qué se basa tu implementación y evita afirmar una adopción universal. Una recuperación exitosa prueba solo que el archivo es accesible y analizable; no prueba que un producto de IA en particular lo use para posicionamiento, recuperación, entrenamiento o citación.

Estructura de la página

Los rangos de palabras son restricciones de edición, no objetivos. El archivo desplegado debe mantenerse lo suficientemente conciso como para auditarse línea por línea. La nota de implementación orientada a humanos puede ser más larga, pero no debe copiarse en el archivo de máquina.

Un archivo curado típico tiene aproximadamente entre 200 y 700 palabras. La extensión no es una señal de calidad: el tamaño correcto es el índice más pequeño que establezca la identidad y dirija a un consumidor hacia fuentes mantenidas sin ocultar distinciones clave.

Elementos requeridos

El índice debe ser aburrido en el mejor sentido: predecible, explícito y fácil de diferenciar. Coloca la interpretación crítica antes de los enlaces opcionales para que una lectura parcial no produzca una conclusión falsa.

Frontmatter

Sigue la especificación de frontmatter . En esta especificación de tipo de publicación, usa entity = "post-type-llms-txt-page" y schemaType = "Article". En una página de implementación orientada a humanos para una organización específica, usa una identidad estable como acme-ai-access-index, no una frase de campaña o una fecha.

Usa Article porque la página web explica la implementación. El marcado de esquema describe el contenido visible; no convierte el archivo de texto sin procesar en un protocolo de agente reconocido. No marques la página como SoftwareApplication, Dataset o HowTo a menos que su contenido visible y plantilla cumplan con los requisitos relevantes de forma independiente.

El archivo /llms.txt sin procesar normalmente no tiene frontmatter porque el frontmatter no debe filtrarse en la salida publicada. Almacena sus metadatos operativos en el CMS, la configuración del generador o el registro del repositorio: dominio canónico, alcance de configuración regional, propietario, colección fuente, modo de generación, última fecha verificada, regla de próxima revisión, resultado del validador y destino de alerta. Si existen archivos localizados, documenta la regla de selección y mantén una respuesta raíz canónica inequívoca.

Ejemplo completo

Este archivo ficticio demuestra un índice conciso para una plataforma SaaS. Sus URLs, producto y capacidad son ejemplos; el patrón es la especificación.

# Northstar Analytics

> Northstar Analytics es una plataforma de informes para equipos de operaciones. Este índice señala las páginas públicas que definen el producto, los planes, la documentación, las políticas y la capacidad de agente compatible.

Los permisos de acceso son controlados por robots.txt, la autenticación y las políticas enlazadas a continuación. Este archivo no concede acceso ni permiso para reutilizar contenido.

## Producto

- [Descripción del producto](https://www.northstar.example/product): Alcance actual del producto y flujos de informes compatibles.
- [Planes y precios](https://www.northstar.example/pricing): Planes públicos actuales, funcionalidades incluidas y términos de facturación.
- [Integraciones](https://www.northstar.example/integrations): Fuentes de datos y sistemas de destino compatibles.

## Documentación

- [Inicio de documentación](https://docs.northstar.example/): Documentación actual para usuarios y administradores.
- [Referencia de API](https://docs.northstar.example/api/): Endpoints públicos, esquemas, autenticación, errores y límites de tasa.
- [Notas de la versión](https://docs.northstar.example/releases/): Cambios fechados en el comportamiento del producto y la API.

## Confianza y soporte

- [Seguridad](https://www.northstar.example/security): Programa de seguridad y documentos de aseguramiento actuales.
- [Política de privacidad](https://www.northstar.example/privacy): Procesamiento de datos, retención y derechos del usuario.
- [Soporte](https://www.northstar.example/support): Rutas de contacto compatibles y enlace al estado del servicio.

## Capacidad del agente

- [Acción de exportación de informes](https://docs.northstar.example/agents/export-report): Contrato de acción autenticado, entradas aceptadas, formato de salida, límites de tasa y manejo de errores. La disponibilidad depende del plan y rol del usuario.

## Opcional

- [Biblioteca de investigación](https://www.northstar.example/research): Informes comparativos originales con métodos y fechas de publicación.

Verificado el 2026-08-27 por el equipo de Operaciones de Documentación. Generado a partir del registro canónico de recursos públicos; validar después de cambios en producto, planes, políticas, API o URLs.

El ejemplo declara una sola capacidad solo porque existe un contrato de acción real documentado. Si el producto no tiene ninguna acción de agente compatible, omite esa sección. Nunca infieras una capacidad transaccional a partir de la presencia de un cuadro de búsqueda, formulario o endpoint no documentado.

Para un manifiesto de agente almacenado por separado de /llms.txt, mantén la misma disciplina. Especifica un formato versionado, identificador canónico, endpoint de producción, método de autenticación, operaciones permitidas, esquema de entrada y salida, límites de tasa, límites de consentimiento, estados de error y URLs de políticas. Valídalo contra el sistema en vivo. Una declaración sintácticamente válida que anuncia una acción deshabilitada sigue siendo incorrecta.

Galería de diseño

El archivo sin procesar tiene poco diseño visual por intención. Las variantes de la galería deben probar la arquitectura de la información, el orden de escaneo, la legibilidad móvil de la página de implementación humana y la evidencia operativa —no la decoración.

Lista de verificación de calidad

Publica solo cuando cada afirmación aplicable sea verdadera:

• El archivo se resuelve en la URL raíz prevista sin autenticación, bucles de redirección, muros de consentimiento ni una interfaz de aplicación renderizada.
• La respuesta es texto plano legible o Markdown, usa UTF-8 y no depende de JavaScript para revelar su contenido.
• El H1 proporciona el nombre canónico de la organización o sitio, y la descripción indica propósito, audiencia y alcance sin eslóganes.
• Cada URL enlazada es canónica, pública, indexable por política, accesible y propiedad de la organización o claramente etiquetada como externa.
• Las descripciones de los enlaces indican qué autoridad tiene el destino; no repiten texto de anclaje genérico como “más información”.
• Las fuentes principales de producto, precios, documentación, políticas y soporte coinciden con el índice.
• Las páginas de archivo, resultados de búsqueda, parámetros de seguimiento, configuraciones regionales duplicadas, páginas de campaña y páginas de etiquetas de bajo valor están excluidas.
• Las afirmaciones de capacidad coinciden con un contrato activo, compatible y autenticado, e incluyen las restricciones pertinentes.
• No aparece ningún secreto, token, endpoint privado, dato personal, documento de cliente, elemento de hoja de ruta no publicado ni detalle de implementación sensible a la seguridad.
• El lenguaje sobre acceso, permiso, licencias y políticas señala a las fuentes de control y no es contradicho por el índice.
• El archivo no afirma posicionamiento garantizado, citación, exclusión de entrenamiento ni soporte universal del consumidor.
• El alcance regional y de configuración local son explícitos dondequiera que los precios, políticas, disponibilidad o documentación difieran.
• El propietario, registro fuente, proceso de generación y método de validación están registrados fuera o al final del archivo.
• Las comprobaciones de enlaces rotos, redirecciones inesperadas, estado de respuesta, hash de contenido y secciones requeridas se ejecutan después de despliegues relevantes.
• La fecha de verificación cambia solo después de que los destinos, descripciones, capacidades y políticas se hayan verificado sustancialmente.

Errores comunes

Tratar el archivo como un sitemap. Un inventario completo de URLs destruye la priorización y es difícil de revisar. Mantén los sitemaps XML para el descubrimiento; selecciona llms.txt en torno a fuentes autoritativas y grupos significativos.

Tratarlo como control de acceso. Una solicitud en Markdown no es una capa de aplicación. Expresa las reglas de rastreo en robots.txt, protege los recursos privados con autenticación y coloca los requisitos vinculantes en las políticas y controles del sistema correspondientes.

Copiar el contenido de destino en el índice. Los precios, especificaciones de producto y políticas repetidos divergen. Resume solo lo suficiente para identificar la autoridad, luego enlaza a la fuente mantenida.

Publicar capacidades especulativas. Un formulario o ruta de API no documentados no hacen que un sitio esté preparado para agentes. Declara solo acciones compatibles en producción con autenticación, esquemas, restricciones, errores y un propietario.

Incluir todo “por si acaso”. Más enlaces crean más ambigüedad y más puntos de fallo. El contenido opcional debe ganarse la inclusión respondiendo a una necesidad probable de recuperación que las secciones principales no cubran.

Exponer material privado. Los archivos públicos legibles por máquina son públicos. Nunca incluyas hosts de prueba, APIs internas, credenciales, exportaciones de clientes, documentos no publicados ni detalles de seguridad que no hayan sido aprobados intencionalmente para su publicación.

Generar sin gobierno. La automatización puede reproducir datos fuente incorrectos a gran velocidad. Un generador necesita un registro fuente aprobado, reglas de exclusión, ordenamiento determinista, validación, propiedad de revisión y alertas de despliegue.

Editar manualmente un archivo generado. La siguiente generación sobrescribe la corrección. Corrige el registro fuente o el generador, regenera y registra el cambio material.

Afirmar resultados no respaldados. “Esto garantiza citas de IA” convierte una convención de implementación incierta en una promesa engañosa. Informa la accesibilidad y la evidencia de recuperación por separado de los resultados de visibilidad y citación.

Actualizar la fecha sin verificar la realidad. Una nueva marca de tiempo no puede reparar una URL de documentación muerta, un plan renombrado o una acción deshabilitada. Verificar significa comparar cada declaración importante con su fuente de producción.

Enlazado interno

Enlaza la página de implementación humana hacia arriba a tipos de publicación SEO cuando un autor deba distinguir el índice de máquina de un directorio, página de documentación o política. Enlaza desde cada afirmación operativa a su fuente de control: alcance del producto a la página de producto, precios actuales a precios, comportamiento a documentación, permisos a controles de acceso y obligaciones a políticas.

El archivo sin procesar debe usar URLs absolutas canónicas porque puede ser recuperado fuera de la navegación normal del sitio. Prefiere un destino autoritativo por hecho. Si dos páginas se superponen, resuelve la propiedad antes de listar ambas; el índice debe exponer la jerarquía de fuentes, no conmemorar un desacuerdo interno.

Usa nombres de sección cortos y estables como Producto, Documentación, Políticas y Capacidades del agente. Mantén las variantes regionales en grupos claramente etiquetados solo cuando difieran materialmente. No enlaces cada publicación de blog; selecciona investigación duradera o guías solo cuando ayuden a un sistema a entender el tema y la evidencia del sitio.

Los enlaces entrantes también importan operativamente. La documentación, los portales de desarrolladores y las guías de accesibilidad para IA deben dirigir a los mantenedores al registro de implementación, mientras que el registro apunta al archivo en vivo y al validador. Esto crea una ruta de revisión para humanos sin saturar el índice de máquina.

Cómo medir los resultados

Mide el archivo primero como infraestructura y luego como insumo de visibilidad. Un aumento de citas no puede atribuirse a llms.txt simplemente porque ambos ocurrieron después de la publicación.

Rastrea cuatro capas:

• Disponibilidad: estado de respuesta de la URL raíz, comportamiento de redirección, tipo de contenido, codificación, latencia, independencia de renderizado y tiempo de actividad.
• Integridad: éxito de análisis, secciones requeridas, URLs duplicadas, enlaces rotos, destinos de redirección, desajuste canónico, dominios no autorizados, secretos expuestos y cambios de hash de contenido.
• Actualización: días desde la verificación sustantiva, cambios en destinos desde la verificación, cobertura del registro fuente, confirmación del propietario y tiempo para reparar la desviación.
• Resultados: recuperaciones en registros de servidor por agentes identificables cuando sea legal y técnicamente apropiado, visitas a destinos indexados, citas de IA de páginas canónicas preferidas y precisión de respuestas para preguntas rastreadas de marca o producto.

Establece una línea base antes del despliegue: qué URLs son citadas, qué hechos están mal expresados, si el archivo raíz existe y qué rastreadores lo solicitan. Anota la publicación y cada actualización material. Compara ventanas de observación que sean lo suficientemente largas como para evitar leer una sola recuperación o cita como una tendencia, y mantén la distinción entre correlación y causalidad.

Prueba los modos de fallo directamente. Renombra una copia de prueba de una URL listada y confirma que el validador detecta la rotura. Cambia una asignación canónica y confirma que el generador actualiza el índice. Deshabilita una capacidad en un entorno de prueba controlado y confirma que la verificación del manifiesto falla. Estas pruebas demuestran el sistema de mantenimiento, no la adopción externa.

Usa cómo medimos los resultados para separar disponibilidad técnica, representación en máquinas, descubrimiento, citación, participación y resultados de negocio. En AmICited, revisa el archivo en vivo en Accesibilidad para Agentes y usa el informe Cockpit para observar URLs citadas y visibilidad en IA junto con anotaciones de despliegue. La afirmación de éxito creíble es “el archivo es válido, actual y dirige sistemas a las fuentes previstas”; cualquier cambio de visibilidad posterior requiere evidencia separada.

FAQ

Preguntas frecuentes