llms.txt para SEO IA: guía técnica realista - Ighenatt Blog

La tentación con llms.txt es convertirlo en la nueva etiqueta mágica del SEO para IA. Sube un archivo a la raíz, añade tus mejores URLs y espera que ChatGPT, Claude, Perplexity o Google te lean con más cariño. Suena cómodo. También es demasiado bonito.

La realidad es más útil, pero menos espectacular: llms.txt es una propuesta para publicar un mapa Markdown de tu sitio pensado para modelos de lenguaje y herramientas de recuperación. Ayuda a explicar qué contenido importa, qué URLs son canónicas y qué contexto debería acompañarlas. No es una promesa de indexación. No es una directiva de bloqueo. No es un sustituto de una arquitectura web decente.

Jeremy Howard, autor de la propuesta y cofundador de fast.ai, la describe en llmstxt.org como una forma de dar a los LLM información útil en tiempo de inferencia. Esa frase contiene el matiz importante: “propuesta”. No estándar universal. No RFC. No documentación oficial de Google, OpenAI, Anthropic o Perplexity diciendo “dependemos de esto”.

Bien usado, llms.txt es como una mesa de contenidos para máquinas: no cocina el plato, pero evita que el camarero saque primero los cubiertos, luego la carta antigua y al final el plato principal. Ordena.

Qué es llms.txt y por qué no es una varita mágica

llms.txt es un archivo de texto en Markdown que se publica normalmente en https://tudominio.com/llms.txt. La propuesta original plantea una estructura simple: título del sitio, breve descripción, secciones temáticas y enlaces a recursos importantes, idealmente en versiones legibles para modelos de lenguaje. La idea nace de un problema real: muchas páginas web modernas mezclan navegación, banners, JavaScript, componentes repetidos, menús y contenido principal en un HTML difícil de procesar sin ruido.

El punto contrarian: el mejor llms.txt no es el más largo. Es el más selectivo.

Si metes 900 URLs porque “más cobertura es mejor”, acabas con un sitemap disfrazado de Markdown. Un modelo, una herramienta de documentación o un agente que consulte ese archivo necesita saber por dónde empezar. La prioridad editorial es la señal. Por eso conviene incluir guías pilar, recursos evergreen, páginas de servicio, documentación de producto y contenidos que respondan preguntas recurrentes, no cada noticia, etiqueta o página paginada.

También conviene separar expectativa de utilidad. Google afirma en su documentación de funciones de IA que no necesitas crear archivos de texto IA ni markup especial para aparecer en AI Overviews o AI Mode. OpenAI documenta sus crawlers y permite distinguir entre GPTBot, OAI-SearchBot y ChatGPT-User, pero no declara que llms.txt sea una señal de ranking, entrenamiento o recuperación. Perplexity sí publica un llms.txt para su propia documentación, pero eso demuestra adopción como formato de docs, no dependencia universal del ecosistema.

En una estrategia de GEO y optimización para motores generativos, el archivo tiene sentido como capa de claridad. Reduce ambigüedad, facilita auditorías y obliga a decidir qué páginas representan mejor tu experiencia. Pero si el contenido no tiene autoridad, fuentes, estructura y utilidad real, llms.txt no lo arregla.

Diferencias reales con robots.txt y sitemap.xml

La confusión viene de la ruta: robots.txt, sitemap.xml y llms.txt viven cerca de la raíz del dominio. Ahí se acaba la similitud. Cumplen funciones distintas, se validan de formas distintas y fallan de formas distintas.

robots.txt es un mecanismo de control de rastreo. Según Google Search Central, sirve principalmente para gestionar a qué URLs pueden acceder los crawlers y para evitar sobrecarga, no para mantener una página fuera del índice. Si necesitas bloquear indexación, usas noindex, controles de snippet, autenticación o cabeceras adecuadas. Para decisiones sobre bots IA, revisa primero la configuración de robots.txt y sus errores SEO, porque ahí sí puedes permitir o bloquear agentes concretos como GPTBot, ClaudeBot o PerplexityBot.

sitemap.xml es un inventario de descubrimiento. Google recomienda incluir URLs absolutas, canónicas, con respuesta 200 y relevantes para aparecer en búsqueda. El sitemap puede declarar lastmod, segmentarse por tipo de contenido y enviarse desde Search Console o declararse con Sitemap: en robots.txt. Si mezclas URLs bloqueadas, noindex, redirigidas o duplicadas, envías señales contradictorias. La guía de sitemap y robots para auditoría SEO entra justo en esa coherencia.

llms.txt es un mapa interpretativo. No dice “puedes rastrear esto” ni “esta URL debe indexarse”. Dice: “si quieres entender este sitio, empieza por aquí y lee estas piezas en este orden”. Su función se parece más a un índice editorial o a un README de producto que a un protocolo de exclusión.

La tabla mental es sencilla: robots.txt gestiona acceso, sitemap.xml gestiona descubrimiento, llms.txt gestiona contexto. El error caro es pedirle a uno que haga el trabajo del otro. Bloquear GPTBot en llms.txt no bloquea GPTBot. Listar una URL en llms.txt no la convierte en canónica. Y añadir una página privada al archivo puede exponer una ruta que preferías no destacar.

Qué puede hacer y qué no puede hacer

Lo que sí puede hacer llms.txt: mejorar tu gobernanza de contenido para IA. Obliga a responder preguntas que muchos sitios posponen: qué páginas son fuentes de verdad, qué recursos están actualizados, qué versión idiomática debe priorizarse, qué contenidos no deberían aparecer como referencia principal y qué URLs explican mejor la propuesta de valor.

También puede ayudar a herramientas compatibles. Algunas plataformas de documentación, asistentes de desarrollo y flujos internos pueden leer llms.txt para descubrir páginas relevantes antes de profundizar. Perplexity, por ejemplo, enlaza su propio índice llms.txt desde la documentación para que se puedan descubrir páginas disponibles. Esa es una señal práctica de utilidad: como índice controlado, no como garantía algorítmica.

Además, sirve para auditar brechas. Si tu llms.txt incluye una guía pilar de 2024 que no se ha actualizado, mientras el blog tiene una versión mejor de 2026 que no aparece, acabas de descubrir un problema editorial. Si el archivo recomienda una URL que devuelve 301, tienes un problema técnico. Si el mismo tema aparece en tres URLs sin jerarquía, tienes una señal de canibalización.

Lo que no puede hacer es más importante. No puede forzar a Google a usar tu contenido en AI Overviews. No puede ordenar a OpenAI que entrene o no entrene con tus páginas. No puede sustituir controles documentados por cada crawler. No puede mejorar un contenido flojo. No puede resolver problemas de renderizado, arquitectura, duplicidad o autoridad.

Piensa en llms.txt como una portada de dossier. Ayuda a que alguien entienda qué contiene el dossier, pero si las páginas de dentro están vacías, desordenadas o sin fuentes, la portada no salva el trabajo. Para medir qué bots llegan realmente al sitio, cruza esta capa con el análisis de logs de GPTBot, ClaudeBot y otros bots IA. Ahí verás visitas, user-agents, frecuencia y URLs solicitadas. llms.txt no te da esa evidencia.

Ejemplo práctico de llms.txt para un sitio SEO

Un buen archivo empieza pequeño. Para una agencia SEO, la primera versión podría tener entre 20 y 60 enlaces: páginas de servicio, guías pilar, recursos GEO, casos de estudio y contacto. Cada enlace debería tener una descripción breve que explique por qué importa, no repetir el title tag.

Ejemplo simplificado:

# Ighenatt

> Agencia SEO especializada en SEO tecnico, estrategia de contenidos y visibilidad en motores generativos para empresas en Espana.

## Prioridad alta

- [Auditoria SEO tecnica](https://ighenatt.es/recursos/auditoria-seo/auditoria-seo-tecnica/): metodologia para detectar problemas de rastreo, indexacion, arquitectura y rendimiento.
- [GEO para motores generativos](https://ighenatt.es/recursos/geo/geo-optimizacion-motores-generativos/): guia pilar sobre visibilidad en ChatGPT, Perplexity y AI Overviews.
- [Analisis de logs de bots IA](https://ighenatt.es/blog/analisis-logs-bots-ia-gptbot-claudebot/): proceso para identificar GPTBot, ClaudeBot, PerplexityBot y otros crawlers.

## Control de rastreo

- [Robots.txt y errores SEO](https://ighenatt.es/blog/robots-txt-configuracion-errores-seo/): diferencias entre bloqueo de rastreo, indexacion y gestion de bots.
- [Sitemap XML y robots.txt](https://ighenatt.es/recursos/auditoria-seo/sitemap-robots-configuracion/): configuracion coordinada de descubrimiento y acceso.

## Contacto comercial

- [Consultoria SEO tecnica](https://ighenatt.es/servicios/consultoria-seo-tecnica/): servicio para auditorias tecnicas, migraciones y arquitectura SEO.

Hay varias decisiones intencionales en el ejemplo. Las URLs son absolutas, no relativas. Las secciones separan intención, no formato. Las descripciones dicen qué encontrará un lector o agente, no frases promocionales. Y la prioridad alta está limitada a piezas que explican el sitio mejor que una home.

Para sitios multiidioma, no mezcles idiomas sin criterio. Puedes crear un llms.txt principal con secciones por idioma o publicar archivos auxiliares enlazados desde el principal. Lo importante es declarar el idioma de cada recurso y no hacer que una guía en catalán apunte a una versión española si existe una alternativa equivalente.

Una práctica útil: cada URL incluida debe superar tres pruebas antes de entrar. Responde 200, es canónica y tiene una fecha de revisión. Si falla una de las tres, no va al archivo. Parece estricto, pero evita que llms.txt se convierta en un escaparate de deuda técnica.

Cómo mantener llms-full.txt sin crear deuda técnica

La propuesta original de llmstxt.org menciona archivos expandidos derivados del índice principal, como versiones que contienen el texto completo de las URLs enlazadas. En la práctica, muchos equipos llaman a esa idea llms-full.txt: un Markdown grande que reúne contenido prioritario para que un sistema no tenga que visitar cada URL individual. Útil, sí. Peligroso si se automatiza sin control.

El problema de llms-full.txt no es generarlo. Es mantenerlo limpio. Un CMS puede exportar HTML convertido a Markdown, pero también arrastra menús, CTAs, bloques repetidos, breadcrumbs, textos legales, formularios y módulos de artículos relacionados. Eso consume tokens y confunde el contexto. El valor está en extraer contenido principal, conservar jerarquía H2-H3, mantener tablas, incluir fuentes y eliminar todo lo que no aporta comprensión.

La cadencia recomendada depende del sitio. Para un blog técnico activo, regenera llms-full.txt semanalmente o cada vez que publiques una guía pilar. Para una web corporativa estable, mensual suele bastar. Para documentación de producto, vincula la regeneración al despliegue de docs. En todos los casos, guarda una huella de control: fecha de generación, número de URLs, tamaño del archivo, idioma, commit o versión del CMS.

También necesitas límites. Si el archivo supera unos pocos megabytes, divídelo por tema o idioma. Si una URL aporta solo 150 palabras superficiales, probablemente no merece estar. Si una página cambia a diario, quizá convenga enlazarla desde llms.txt pero no incorporarla al full hasta que sea estable.

La regla operativa: llms.txt decide qué entra; llms-full.txt empaqueta lo que ya fue aprobado. Nunca al revés. Si el full se genera rastreando todo el sitio sin gobernanza, solo has creado una copia pesada del desorden original.

Gobernanza de URLs prioritarias: quién decide qué entra

El archivo parece técnico, pero la decisión es editorial y de negocio. En un sitio serio, no debería ser el desarrollador quien decida solo qué URLs representan a la empresa ante asistentes IA. SEO, contenido, legal, producto y ventas pueden tener prioridades distintas. La solución no es meterlas todas. La solución es un criterio de entrada.

Un modelo simple funciona bien. Cada URL candidata recibe propietario, objetivo, idioma, estado, prioridad y fecha de próxima revisión. Prioridad 1 son páginas que explican la entidad: home, servicios estratégicos, guías pilar, recursos con fuentes, casos de estudio sólidos. Prioridad 2 son artículos de apoyo, comparativas y FAQs. Prioridad 3 son piezas tácticas que pueden rotar o salir del archivo.

La pregunta clave no es “¿queremos que esta página la vea una IA?”. La pregunta buena es: “si una IA solo pudiera leer 30 URLs nuestras, ¿esta debería estar?”. Ese límite fuerza claridad.

También hay que documentar exclusiones. Contenido legal sensible, páginas con precios desactualizados, ofertas temporales, landings de campañas, resultados internos de búsqueda, etiquetas y paginaciones casi nunca deberían entrar. Si necesitas bloquear crawlers, eso vive en robots.txt o en controles de acceso, no en llms.txt. Pero si solo quieres no promocionar una URL como fuente principal, basta con no incluirla.

La gobernanza se vuelve más importante en GEO, donde la citabilidad depende de fuentes claras y entidades consistentes. Una guía pilar sobre IA generativa debería enlazar a recursos relacionados, tener autoría visible, fuentes reales y una respuesta directa. llms.txt puede señalarla, pero la página tiene que merecerlo. El archivo no crea autoridad; la ordena.

Checklist de validación, cadencia y señales a medir

Antes de publicar, valida el archivo como si fuera parte de un despliegue técnico. No basta con abrirlo en el navegador y ver texto.

Checklist mínimo:

• El archivo está disponible en https://dominio.com/llms.txt con estado 200.
• Usa Content-Type: text/plain o un tipo compatible que no fuerce descarga extraña.
• Está codificado en UTF-8 y se lee correctamente con acentos.
• Todas las URLs incluidas son absolutas, canónicas, rastreables y devuelven 200.
• Todas las rutas internas terminan con barra final si el sitio usa trailing slash.
• No incluye páginas noindex, bloqueadas por robots.txt, redirigidas o privadas.
• Cada enlace tiene una descripción específica, no una repetición del título.
• Las secciones reflejan prioridad editorial, no solo categorías del CMS.
• La versión llms-full.txt, si existe, se genera desde la misma lista aprobada.
• El archivo tiene propietario, fecha de revisión y changelog interno.

Después, mide con humildad. No busques “subida por llms.txt” en rankings, porque no vas a aislar esa variable. Mide cosas verificables: bots IA en logs, peticiones a /llms.txt, URLs más rastreadas por user-agent, citas en respuestas de IA, tráfico referido desde Perplexity o ChatGPT, y coherencia entre páginas prioritarias y contenidos que realmente reciben rastreo.

La cadencia razonable es mensual para sitios con publicación frecuente, trimestral para sitios estables y obligatoria después de migraciones, cambios de robots.txt, nuevas guías pilar o reestructuraciones de servicios. El responsable debería revisar tres columnas: altas, bajas y cambios de prioridad.

llms.txt no merece ni cinismo automático ni fe ciega. Es barato, legible, fácil de auditar y útil para ordenar una estrategia de contenido orientada a IA. Pero su fuerza está en la disciplina que exige: elegir, explicar, mantener y verificar. Dicho de otra forma: no optimiza por ti. Te obliga a mostrar qué habrías optimizado si tuvieras que explicárselo a una máquina con poco tiempo.