Durante años aprendimos a preparar una web para dos lectores: las personas y los buscadores. Ahora llms.txt y GEO ponen sobre la mesa una tercera necesidad: que una IA pueda entender, recuperar y, a veces, citar nuestro contenido.

TL;DR
robots.txt, sitemap.xml y SEO no desaparecen con la IA. Se les añade una nueva capa. llms.txt intenta facilitar el consumo de contenido por modelos de lenguaje y GEO busca aumentar la probabilidad de que ese contenido sea comprendido, recuperado y utilizado como fuente. El error es tratarlos como sustitutos: robots.txt no es SEO y llms.txt tampoco es GEO.
Hubo un tiempo en que diseñar una web era bastante más simple de explicar.
Pensábamos en el usuario humano, que llega, navega, lee y decide. Y pensábamos en el buscador, que rastrea, indexa y decide si merecemos aparecer en resultados.
Ese contrato modeló una parte enorme de Internet. Para el humano construimos navegación, diseño, accesibilidad y experiencia de usuario. Para el buscador fuimos creando una capa más silenciosa: robots.txt, sitemap.xml, metadatos, datos estructurados y, por supuesto, SEO.
La lógica era clara: el contenido se publica, el crawler lo rastrea, el índice lo organiza, el buscador lo muestra y la persona hace clic.
Durante años esa cadena bastó.
Pero la web ya no solo se consulta. Ahora también se pregunta.
Y cuando alguien pregunta a un sistema generativo, lo que importa ya no es solo si una página puede ser encontrada. Empieza a importar si además puede ser entendida, recuperada y utilizada como fuente.
La web clásica tenía dos capas
La web tradicional convivía con dos necesidades distintas. La primera era visible: crear páginas útiles para personas. La segunda era más técnica: facilitar que las máquinas las encontraran.
robots.txt: un archivo para comunicar preferencias de rastreo.sitemap.xml: un inventario de URLs para facilitar el descubrimiento.- SEO: el conjunto de prácticas para mejorar visibilidad, relevancia y posicionamiento en buscadores.
| Pieza | Pregunta que responde |
|---|---|
robots.txt | ¿Qué puede rastrear un crawler? |
sitemap.xml | ¿Qué páginas o recursos existen? |
| SEO | ¿Cómo aumento mis posibilidades de aparecer y posicionar? |
Ese ecosistema no estaba pensado para que una máquina razonara sobre nuestro contenido, sino para que pudiera descubrirlo e indexarlo. Y esa diferencia importa mucho.
El cambio no es solo técnico: cambia la pregunta
Cuando una persona busca en Google, la pregunta implícita suele ser: «¿qué páginas pueden responder a esto?».
Cuando una persona pregunta a un sistema generativo, la pregunta se parece más a: «¿qué información fiable puedes recuperar, resumir y usar para responderme?».
Un buscador ordena documentos. Un sistema generativo compone respuestas. El buscador necesita descubrirte; el motor generativo necesita, además, entenderte lo suficiente como para reutilizarte.
Por eso empieza a hablarse de GEO (Generative Engine Optimization): una disciplina orientada a mejorar la visibilidad del contenido dentro de motores generativos y experiencias de respuesta sintetizada. El término fue formalizado en el trabajo GEO: Generative Engine Optimization, publicado posteriormente en KDD 2024.
Timeline: de robots.txt a llms.txt
La historia se entiende mejor como una acumulación de capas. Cada etapa añade una pregunta nueva sin invalidar la anterior.

La lectura útil de la timeline no es «robots.txt → llms.txt». Es «rastrear → descubrir → posicionar → interpretar». Cada capa resuelve un problema diferente.
robots.txt y llms.txt se parecen menos de lo que parece
Sin embargo, la comparación entre ambos es útil, pero si la estiramos demasiado se vuelve engañosa.
Aun así, hay una analogía válida: robots.txt nace cuando la web necesita convivir con máquinas que la recorren; llms.txt aparece cuando la web necesita convivir con máquinas que consumen y sintetizan contenido.
Qué hace robots.txt
robots.txt sirve para comunicar preferencias de rastreo. No describe tu contenido, no resume tus secciones y no jerarquiza tus mejores páginas para un modelo de lenguaje. Su función es mucho más básica: orientar a crawlers sobre qué rutas deberían o no deberían rastrear.
Qué intenta hacer llms.txt
llms.txt, en cambio, propone una interfaz editorial para máquinas: un archivo Markdown en la raíz del sitio que ayuda a un LLM o a un agente a identificar las partes del contenido que el editor considera relevantes y, cuando existen, localizar versiones más limpias para consumo automático.
La propuesta original fue publicada por Jeremy Howard y Answer.AI en septiembre de 2024 y se mantiene en llmstxt.org y en su repositorio de referencia.

robots.txt y llms.txt se parecen más por el momento histórico que representan que por lo que técnicamente hacen. Uno regula preferencias de rastreo. El otro intenta orientar el consumo de contenido por modelos.
SEO vs GEO: tampoco son equivalentes
Además, con SEO y GEO ocurre el mismo problema. Resumirlo como «SEO para buscadores, GEO para IA» es cómodo, pero demasiado pobre.
Qué persigue el SEO
SEO busca mejorar la visibilidad de un contenido dentro de buscadores. Eso incluye rastreabilidad, indexación, contenido útil, enlazado interno, rendimiento, autoridad, semántica e intención de búsqueda.
La pregunta central es: ¿cómo aumento las probabilidades de que un buscador me encuentre, me entienda como documento relevante y me posicione?
Qué persigue el GEO
En cambio, GEO se mueve en otra capa. La página deja de ser únicamente un destino y pasa a ser también una fuente reutilizable dentro de una respuesta generada.
La pregunta cambia: ¿cómo aumento las probabilidades de que un motor generativo recupere, entienda, utilice y cite mi contenido?

| Dimensión | SEO | GEO |
|---|---|---|
| Objetivo principal | Visibilidad y ranking | Recuperación, síntesis y citación |
| Intermediario | Buscador | Motor generativo |
| Resultado visible | Posición y clic | Inclusión en una respuesta |
| Unidad habitual | Página o documento | Fragmento, entidad, hecho o fuente |
| Dependencias | Rastreo, indexación, relevancia, autoridad | Claridad, recuperación, estructura, autoridad y atribución |
Por tanto, no compiten. Se acumulan. Un buen contenido puede necesitar ser rastreable, posicionable e interpretable a la vez.
llms.txt no es GEO, igual que robots.txt no es SEO
Esta es probablemente la confusión que más conviene desmontar.
Tener un robots.txt no significa tener una estrategia SEO. Del mismo modo, tener un llms.txt no significa «estar haciendo GEO».

Un archivo no es una estrategia. Reducir GEO a publicar llms.txt sería como reducir SEO a subir un robots.txt: confunde una herramienta con todo el sistema que la rodea.
Por eso, un llms.txt puede ser una pieza útil dentro de una estrategia orientada al consumo por IA, igual que un sitemap puede ser útil dentro del SEO técnico. Sin embargo, el resultado depende también de la calidad del contenido, su estructura, su autoridad, la claridad factual y la capacidad de recuperación.
Qué aporta realmente llms.txt
Lo interesante de llms.txt no es el nombre, sino la intención: ofrecer a sistemas no humanos un punto de entrada editorial más limpio.
- Señalar secciones importantes del sitio.
- Priorizar documentación, artículos o recursos útiles.
- Apuntar a versiones Markdown o limpias cuando existan.
- Reducir el ruido de navegación, banners, sidebars y elementos accesorios.
- Ofrecer un índice editorial para sistemas que necesitan consumir contenido de forma estructurada.
Dicho de forma menos técnica: llms.txt intenta actuar como un índice editorial pensado para lectores no humanos.
Lo que llms.txt no hace

- No mejora por sí solo tu ranking en Google.
- No sustituye a robots.txt. Uno trata preferencias de rastreo; el otro orienta sobre contenido.
- No sustituye al sitemap. El sitemap sigue siendo una ayuda de descubrimiento de URLs.
- No garantiza que una IA vaya a citarte. Puede facilitar el consumo, pero no impone el comportamiento del modelo.
- No arregla un mal contenido. Si el contenido es ambiguo, superficial o poco fiable, el archivo de la raíz no lo convierte en una buena fuente.
La práctica sensata: tratar llms.txt como una capa adicional y barata de experimentar, sin dejar de invertir en contenido claro, semántica, arquitectura de información, datos estructurados y autoridad.
Una web, tres interfaces de lectura
La arquitectura conceptual que empieza a aparecer no exige construir tres webs. Exige que el mismo contenido pueda funcionar bien para tres consumidores con necesidades distintas.
En el fondo, es el mismo problema que aparece en cualquier arquitectura conectada: cada consumidor necesita un contrato claro y una representación adecuada del mismo dominio. Ese patrón también aparece en mi análisis sobre interoperabilidad y plataformas conectadas.

| Consumidor | Qué necesita | Capas principales |
|---|---|---|
| Humano | Leer, comprender, decidir | UX, accesibilidad, navegación, contenido |
| Buscador | Rastrear, indexar, ordenar | robots.txt, sitemap.xml, SEO, Schema.org |
| IA / motor generativo | Recuperar, interpretar, sintetizar, atribuir | Contenido estructurado, autoridad, GEO, llms.txt como posible ayuda |
Qué haría hoy con llms.txt en una web real
Si quitamos el humo, la agenda real se parece bastante a una buena práctica web de siempre, con una capa adicional para sistemas generativos.
- 1. Mantener una base técnica limpia: robots.txt correcto, sitemap actualizado, URLs estables, indexación resuelta y rendimiento razonable.
- 2. Seguir haciendo buen SEO: contenido alineado con intención real, enlazado interno, semántica HTML, metadatos y datos estructurados cuando aporten valor.
- 3. Hacer el contenido más reutilizable: definiciones claras, hechos separados de opinión, títulos informativos, tablas, listas y respuestas autocontenidas.
- 4. Explorar llms.txt: como índice editorial y no como truco de posicionamiento.
- 5. Medir: comprobar qué sistemas realmente consumen esas rutas antes de convertir una propuesta emergente en una dependencia de arquitectura.
La web no deja de escribirse para personas
Ahora bien, nada de esto significa que ahora debamos escribir «para máquinas» y olvidarnos del lector.
De hecho, suele ocurrir lo contrario: cuanto mejor explicas algo para una persona, más fácil resulta después para un sistema que intenta extraer estructura, relaciones y significado.
Ese mismo principio aparece cuando usamos IA para desarrollar software: cuanto más explícitos son el contexto, las reglas y las decisiones, menos tiene que inventar el modelo. Lo desarrollé con más detalle en qué documentar antes de desarrollar una aplicación con IA.
Sin embargo, la diferencia es que durante años bastaba con ser comprensible para humanos y mínimamente rastreable para buscadores. Ahora empezamos a necesitar una tercera propiedad: ser también interpretable para sistemas que no solo indexan, sino que sintetizan.
La idea importante no es el archivo. Es la nueva capa
robots.txt representó una etapa de la web: establecer reglas mínimas con los crawlers. sitemap.xml consolidó otra: ayudar a descubrir el contenido. SEO profesionalizó la batalla por la visibilidad.
llms.txt y GEO apuntan a otra etapa: una web que ya no solo quiere ser encontrada, sino también entendida y reutilizada por sistemas generativos.

Si quieres seguir por esta línea, en la ruta de artículos sobre ingeniería de software, arquitectura e IA he agrupado contenidos sobre agentes, RAG, automatización, arquitectura e integración.
Conclusiones: dónde encaja llms.txt
Durante décadas hicimos la web legible para buscadores sin dejar de escribir para personas.
Ahora, en cambio, estamos empezando a hacer algo parecido con los modelos generativos.
robots.txt fue una de las primeras convenciones de la web legible por máquinas. llms.txt intenta abrir una nueva etapa: la de una web legible no solo para ser rastreada, sino también para ser comprendida.
Y SEO y GEO probablemente convivirán durante bastante tiempo porque responden a dos preguntas distintas:
¿Puede encontrarme un buscador?
¿Puede entenderme y utilizarme una IA?
Por supuesto, la primera sigue importando muchísimo.
La segunda acaba de empezar a importar de verdad.
Una prueba pequeña antes de convertirlo en estrategia
Si gestionas una web técnica o documental, revisaría primero tres cosas: qué contenido quieres que encuentren los buscadores, qué contenido quieres que una IA pueda reutilizar y si ambas rutas cuentan la misma historia. Después probaría llms.txt como una capa adicional, no como sustituto del SEO.
Preguntas frecuentes
¿llms.txt sustituye a robots.txt?
No. robots.txt comunica preferencias de rastreo a crawlers. llms.txt intenta orientar a modelos y agentes hacia contenido relevante o versiones más fáciles de consumir.
¿Tener llms.txt mejora el SEO?
No debe tratarse como una señal de ranking SEO. Su objetivo es facilitar el consumo del contenido por sistemas de IA que decidan utilizarlo.
¿GEO sustituirá al SEO?
No parece una sustitución directa. SEO trabaja sobre descubrimiento, indexación y ranking; GEO añade la necesidad de que el contenido pueda recuperarse, comprenderse y utilizarse dentro de respuestas generativas.
¿llms.txt es obligatorio para hacer GEO?
No. Es una herramienta posible dentro de una estrategia mucho más amplia. La claridad del contenido, la autoridad, la estructura, la semántica y la capacidad de recuperación siguen siendo más fundamentales.
¿Qué debería optimizar primero: SEO o GEO?
Primero conviene resolver los fundamentos: contenido útil, arquitectura de información, rastreo, indexación, semántica y autoridad. GEO se construye mejor encima de esa base que como una estrategia aislada.
Referencias y para saber más
- RFC 9309 — Robots Exclusion Protocol
- Sitemaps.org — protocolo Sitemaps
- Aggarwal et al. — GEO: Generative Engine Optimization
- KDD 2024 — GEO: Generative Engine Optimization
- Answer.AI — propuesta original de llms.txt
- Repositorio de llms.txt
- llmstxt.org — especificación
- llmstxt.org — registro de cambios
- Cloudflare — Docs for agents
- X Developer Platform — llms.txt y llms-full.txt
- Search Engine Land — Meet llms.txt


Deja una respuesta