Buenas prácticas

Diez reglas

1. Cura. Una lista corta de páginas con señal alta vale más que una lista larga de páginas mediocres. Apunta a entre 10 y 30 enlaces en el archivo raíz.
2. Usa URLs absolutas. Siempre https://tudominio.com/.... Las relativas están técnicamente permitidas, pero son frágiles.
3. Agrupa por superficie de producto. Secciones como Producto, Precios o Desarrolladores reflejan cómo piensa una persona usuaria (y un LLM). Evita los cajones blog/docs/guías salvo que correspondan a tu navegación real.
4. Mantén el resumen factual. El blockquote que sigue al H1 debe leerse como la entradilla de una entrada de Wikipedia, no como el hero de una landing.
5. Una frase por ítem. La nota tras los dos puntos sirve para desambiguar, no para hacer marketing.
6. Usa la sección Optional con moderación. Es el sitio adecuado para prensa, recursos de marca y archivos históricos. No vuelques ahí medio sitemap.
7. Refleja tus URLs estables. Si una página de llms.txt cambia de sitio, actualízala o redirígela. Las URLs muertas envenenan la reputación del archivo.
8. Publica llms-full.txt si tu contenido es sobre todo texto. Documentación, tutoriales y material de referencia se benefician. Galerías, herramientas interactivas y contenido principalmente visual, no.
9. Ejecuta el validador en CI. Una migración de contenido que rompa tu archivo debería tumbar el build.
10. Fecha el archivo. Una nota breve como «Última revisión: 2026-04-01» en el cuerpo ayuda tanto a personas como a rastreadores.

Errores comunes

• Sin H1. El H1 es el único elemento obligatorio. Sin él, el archivo no es válido.
• Varios H1. Usa H2 para las secciones. Debe haber exactamente un H1.
• Front matter propio. Ni YAML ni cabecera JSON. La especificación es estricta y los clientes no parsean añadidos.
• Tablas o imágenes pegadas en Markdown. Limítate a encabezado + blockquote + listas. Las tablas y las imágenes no aportan nada a un LLM.
• Incluir URLs tras login. Si una página exige autenticación, no la listes: el LLM chocará contra un muro.
• Descripciones interminables. «La plataforma más avanzada del mundo impulsada por IA para la transformación sinérgica de nueva generación» no ayuda a nadie. Mantén las notas por debajo de 15 palabras.
• Listar 500 URLs. Si necesitas tantas, lo que necesitas es llms-full.txt, variantes por producto, o ambas cosas.
• Olvidar actualizar robots.txt. Asegúrate de que /llms.txt no está bloqueado.

Sitios multilingües

La especificación no dice nada sobre internacionalización. Dos patrones funcionan en la práctica:

1. Un único archivo en inglés en la raíz. La opción más simple. La mayoría de clientes LLM traducen sobre la marcha. Suficiente para la mayoría de sitios.
2. Variantes por idioma. Sirve /llms.txt (por defecto), /es/llms.txt, /fr/llms.txt. Enlázalas desde el cuerpo del archivo raíz o bajo una sección Optional.

Elijas el patrón que elijas, no dupliques los mismos conjuntos de URLs en todos los idiomas: cada variante debe apuntar a la versión localizada de cada página.

Seguridad y privacidad

• Todo lo que está en llms.txt es público. Trata el archivo como una emisión abierta.
• Nunca listes URLs de staging o preview. Las recogerá cualquier cosa que descargue el archivo.
• Nada de URLs con secretos en la query string. Parece obvio; lo hemos visto en producción.
• Si la página expone datos de usuario tras autenticación, no tiene nada que hacer aquí.
• Audita el archivo en cada release. Una URL de borrador filtrada es el error de seguridad más frecuente.

Hay una segunda razón para tratar el archivo como configuración: los agentes están diseñados para confiar en él. En el análisis de Ahrefs sobre 137 210 dominios, el mayor rastreador de investigación que visitaba estos archivos era un bot llamado prompt-injection-survey. Mantén el contenido en forma de datos, nunca de instrucciones.

Automatización en CI

Trata llms.txt como cualquier otro artefacto: generar, validar y condicionar las releases a su estado.

• Genéralo desde tu fuente de contenido (CMS, colección MDX, base de datos).
• Ejecuta el validador en CI y haz fallar el build ante cualquier error.
• Compara el archivo entre releases y avisa a quien mantiene la documentación si hay borrados grandes.
• Haz una prueba de humo de la URL de producción tras el deploy: curl -fsS https://tudominio.com/llms.txt | head -1.

Siguientes pasos

• Ejemplos reales, copia lo que funciona.
• Crear llms.txt, plantillas y despliegue por stack.
• Validador.