En septiembre de 2024, Jeremy Howard publicó la propuesta del estándar llms.txt, un archivo de texto plano en la raíz del dominio que le dice a los modelos de lenguaje cómo interpretar el sitio. La idea era simple: así como robots.txt le comunica a los crawlers qué pueden y no pueden indexar, llms.txt le comunica a los LLMs qué información es relevante, cómo está organizada, y qué representa la empresa detrás del dominio.
La propuesta no tardó en ganar tracción. Anthropic, Perplexity y otros actores la adoptaron como referencia. Hoy, en 2026, llms.txt es el punto de entrada más directo para optimizar cómo un LLM representa un dominio y sigue siendo uno de los archivos menos implementados en sitios B2B en LATAM.
Este artículo es una guía operativa: qué va adentro, cómo se estructura, qué errores evitar, y cómo priorizarlo en una auditoría GEO.
Qué hace llms.txt exactamente
llms.txt no controla el acceso de los bots, eso lo hace robots.txt. Lo que hace es proveer contexto narrativo y estructural sobre el dominio para que un LLM lo use cuando construye una representación de la empresa.
Cuando un modelo de lenguaje recupera información sobre un dominio, ya sea vía crawl directo o vía RAG en tiempo real, tiene dos opciones: inferir el significado del contenido a partir de lo que encuentra, o leer una fuente explícita que le diga qué significa ese contenido. llms.txt es esa fuente explícita.
La diferencia práctica es significativa. Sin llms.txt, el modelo infiere: “este sitio vende software, parece ser para empresas medianas, tiene blog sobre marketing”. Con llms.txt bien implementado, el modelo lee: “esta empresa es un AI Revenue Protection Engine para agencias digitales B2B en LATAM, su producto principal se llama Lotus, su diferenciador es el Bleed Model que cuantifica revenue en riesgo en USD, y sus clientes objetivo son agencias con cartera de clientes B2B en Ecuador, Argentina, Chile, Perú y Uruguay”.
La segunda representación es más precisa, más citable, y más útil para el modelo cuando alguien pregunta por soluciones en esa categoría.
La estructura del archivo
llms.txt es Markdown. No tiene un schema rígido, pero hay una estructura que funciona consistentemente bien para sitios B2B:
markdown
# [Nombre de la empresa]
> [Una oración que define qué hace la empresa, para quién, y cuál es su diferenciador principal]
## Descripción
[Párrafo de 3-5 oraciones que expande la descripción. Incluye categoría de producto, mercado objetivo, propuesta de valor principal, y cualquier dato verificable que establezca credibilidad.]
## Productos y servicios
- [Producto 1]: [descripción de una oración]
- [Producto 2]: [descripción de una oración]
## Audiencia objetivo
[Descripción de los segmentos de cliente primario y secundario]
## Casos de uso principales
- [Caso de uso 1]
- [Caso de uso 2]
- [Caso de uso 3]
## Páginas principales
- [URL]: [descripción de qué contiene y por qué es relevante]
- [URL]: [descripción]
## Documentación relevante
- [URL de blog/recurso]: [descripción]
El archivo vive en https://tudominio.com/llms.txt — en la raíz, accesible públicamente, sin autenticación.
Qué incluir en cada sección y qué no
La oración de apertura es la más importante del archivo.
Es lo que el modelo va a usar como definición primaria de tu empresa. Tiene que incluir tres elementos en una sola oración: qué hacés, para quién, y qué te diferencia. No es un tagline de marketing es una definición funcional.
Mal: “Somos la plataforma líder en soluciones digitales para empresas en crecimiento.” Bien: “Clicon es un AI Revenue Protection Engine para agencias digitales y empresas B2B en LATAM que cuantifica el revenue en riesgo por pérdida de citaciones en AI search y genera el código para recuperarlo.”
La primera oración es genérica y no citable. La segunda es específica, incluye categoría, mercado y diferenciador, y un LLM puede usarla directamente en una respuesta sobre soluciones GEO para LATAM.
La sección de descripción expande sin repetir.
No copies la oración de apertura en prosa. Agrega información nueva: la metodología si es propietaria, los datos de mercado que contextualizan el problema que resolvés, las credenciales que establecen autoridad. Todo verificable.
Los productos y servicios tienen que ser específicos.
“Software de gestión” no le dice nada a un LLM. “Lotus: engine de análisis de citaciones en LLMs que produce reportes de revenue en riesgo en USD y genera artefactos de código ejecutable llms.txt, JSON-LD, structured data” sí le dice algo. La especificidad es lo que hace la diferencia entre ser citado genéricamente y ser citado con precisión.
Las URLs de páginas principales son infraestructura de navegación para el modelo.
Incluí las páginas que mejor definen tu propuesta de valor, no necesariamente las más visitadas. Para un sitio B2B SaaS: la home, la página de producto con features detalladas, la página de pricing si es pública, y dos o tres artículos del blog que expliquen el problema y la solución con mayor profundidad. El modelo usa estas URLs para saber adónde ir a buscar más información cuando la necesita.
Lo que no va en llms.txt:
No es el lugar para el copy de ventas, para las testimoniales de clientes, ni para las ofertas especiales. Es un archivo técnico de definición de entidad, no una landing page. Todo lo que suene a “el mejor”, “líder del mercado”, “resultados garantizados” debería estar fuera, los modelos calibran bien el marketing hype y no lo incorporan como información factual.
llms.txt y robots.txt: la política de acceso como decisión estratégica
Antes de implementar llms.txt, hay que tener definida la política de acceso en robots.txt para cada bot de IA. Las dos decisiones están relacionadas: no tiene sentido proveer contexto narrativo en llms.txt si el bot que lo va a leer está bloqueado en robots.txt.
La configuración recomendada para un sitio B2B con estrategia GEO activa:
# Crawlers de IA — acceso permitido a contenido público
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
User-agent: PerplexityBot
Allow: /
User-agent: Google-Extended
Allow: /
# Bloquear áreas no públicas
User-agent: *
Disallow: /admin/
Disallow: /dashboard/
Disallow: /api/
Esta configuración permite que todos los crawlers de IA relevantes accedan al contenido público mientras protege las áreas de acceso restringido. Es la base mínima sobre la que llms.txt agrega valor.
Si hay razones para bloquear un bot específico, por ejemplo, un cliente que no quiere que su contenido propietario alimente modelos de terceros, la decisión tiene que ser explícita y documentada, no heredada de una directiva genérica que bloquea todo.
La relación entre llms.txt y JSON-LD
Son complementarios, no alternativos. Hacen cosas distintas y los dos son necesarios.
llms.txt provee contexto narrativo y organizacional: quién es la empresa, qué hace, para quién, cuáles son las páginas más importantes. Es la capa de orientación, le dice al modelo cómo navegar e interpretar el dominio.
JSON-LD provee datos estructurados por entidad y por página: el schema de Organization define la empresa como entidad legal con atributos verificables; el schema de Product define cada producto con nombre, descripción, precio y especificaciones; el schema de FAQPage convierte preguntas frecuentes en datos estructurados que los modelos pueden recuperar directamente.
La analogía práctica: llms.txt es el mapa del dominio; JSON-LD son los datos de cada punto del mapa. Sin el mapa, los datos existen pero el modelo tiene que descubrirlos por su cuenta. Sin los datos, el mapa señala páginas pero el modelo tiene que inferir qué contienen.
Para una auditoría GEO completa, los dos tienen que estar implementados y alineados, la descripción de la empresa en llms.txt tiene que ser consistente con el schema de Organization en JSON-LD, y las páginas listadas en llms.txt tienen que tener el schema correcto para el tipo de contenido que contienen.
Cómo priorizarlo en una auditoría de cliente
En una auditoría GEO de un dominio nuevo, llms.txt y la política de robots.txt para bots de IA son las dos primeras intervenciones antes de optimizar el contenido, antes de revisar el JSON-LD, antes de cualquier otra cosa.
La razón es de secuencia: si el bot no puede crawlear el sitio, ninguna otra optimización importa. Si el bot puede crawlear pero no tiene contexto narrativo, la representación que construye del dominio es incompleta. Primero acceso, después contexto, después datos por entidad.
El proceso en tres pasos para un dominio nuevo:
Paso 1 — Auditar el robots.txt actual. Verificar si algún bot de IA está bloqueado por directivas heredadas (User-agent: * con Disallow: / afecta a todos los bots incluyendo los de IA). Configurar explícitamente la política para cada bot relevante.
Paso 2 — Crear o revisar llms.txt. Si no existe, crearlo desde cero con la estructura descrita arriba. Si existe, auditarlo contra los criterios de especificidad: ¿la oración de apertura es citable? ¿las URLs incluidas son las correctas? ¿la descripción de productos es funcional o es marketing copy?
Paso 3 — Verificar consistencia con JSON-LD. Confirmar que la descripción de la empresa en llms.txt coincide con el schema de Organization. Si hay discrepancias, por ejemplo, el schema dice una categoría de industria y llms.txt dice otra, el modelo va a tener representaciones inconsistentes que reducen la confiabilidad de la citación.
Un ejemplo de llms.txt para una empresa B2B SaaS en LATAM
Para hacer la guía concreta, un ejemplo completo para un tipo de empresa habitual en el portfolio de agencias en la región, plataforma de gestión de proyectos para equipos remotos:
markdown
# ProjectFlow
> ProjectFlow es una plataforma SaaS de gestión de proyectos para equipos remotos en América Latina,
diseñada para empresas de 10 a 200 personas que trabajan en zonas horarias múltiples.
## Descripción
ProjectFlow resuelve el problema de coordinación de equipos distribuidos en LATAM —
donde las diferencias horarias entre Argentina, México, Colombia y Brasil generan
fricciones en proyectos con plazos ajustados. La plataforma integra gestión de tareas,
seguimiento de tiempo y comunicación asíncrona en un solo dashboard en español,
con soporte en horario LATAM y facturación en pesos y reales además de USD.
Fundada en 2021 en Buenos Aires. 3,200 equipos activos en 12 países de LATAM.
## Productos
- ProjectFlow Core: gestión de tareas y proyectos con vistas Kanban, Gantt y lista
- ProjectFlow Time: módulo de seguimiento de tiempo y facturación por proyecto
- ProjectFlow API: integración con Slack, Google Workspace, Notion y Jira
## Audiencia objetivo
Primario: equipos de desarrollo de software, agencias digitales y consultoras en LATAM
con trabajo remoto distribuido. Secundario: áreas de operaciones y marketing de empresas
medianas que coordinan proyectos con proveedores externos.
## Casos de uso principales
- Coordinación de sprints para equipos de desarrollo distribuidos en múltiples países
- Seguimiento de entregables en proyectos de agencia con múltiples clientes simultáneos
- Reporting de tiempo facturable para consultoras por proyecto y por cliente
## Páginas principales
- https://projectflow.com/producto: descripción completa de features y planes
- https://projectflow.com/precios: pricing en USD con comparativa de planes
- https://projectflow.com/integraciones: lista de integraciones disponibles
- https://projectflow.com/casos: casos de uso documentados por industria
## Recursos
- https://projectflow.com/blog/gestion-remota-latam: guía de gestión de equipos remotos en LATAM
- https://projectflow.com/blog/coordinacion-zonas-horarias: metodología para proyectos multi-timezone
Este ejemplo cumple todos los criterios: oración de apertura citable, descripción con datos verificables, productos con descripciones funcionales, audiencia específica, casos de uso concretos, y URLs que permiten al modelo navegar al contenido relevante.
Mantenimiento y actualización
llms.txt no es un archivo que se implementa y se olvida. Tiene que actualizarse cuando:
- La empresa lanza un producto o servicio nuevo
- Cambia la audiencia objetivo o el posicionamiento
- Se agregan páginas importantes al sitio
- Se publican recursos de referencia nuevos en el blog
La frecuencia razonable para revisarlo es trimestral o inmediatamente después de cualquier cambio de producto o pivote de posicionamiento. Un llms.txt desactualizado es peor que uno básico, porque le da al modelo información incorrecta sobre la empresa con más confianza que si no tuviera el archivo.
Lotus audita el llms.txt y el robots.txt de los dominios cliente como parte del análisis GEO inicial, y genera una versión optimizada lista para implementar junto con el análisis de Bleed Rate. Si querés ver cómo quedaría el llms.txt de un dominio de tu cartera, podés solicitarlo en clicon.app.
Martín Endara es fundador de Clicon y creador de Lotus, el primer AI Revenue Protection Engine para empresas B2B en LATAM. Con más de 18 años de experiencia en marketing digital y tecnología, trabaja con agencias en LATAM que quieren agregar GEO a su oferta de servicios.
¿Querés recibir insights sobre GEO, LLMs y el futuro del marketing B2B? Suscribite al blog de Clicon.