Cómo optimizar tu web para agentes de IA: el checklist técnico (robots.txt, schema y llms.txt)

Última actualización: junio de 2026, tras el Google I/O de mayo.

Si has llegado aquí buscando el “cómo” en lugar del “qué”, asumo que ya tienes claro lo de fondo: que optimizar para agentes va de que tu web sea operable por una máquina, no solo legible por una persona. Si no lo tienes claro, empieza por el pilar qué es el SEO agéntico, porque sin entender el porqué este checklist es una lista de tareas sin alma, y las listas de tareas sin alma se ejecutan mal.

Para los que se quedan, una sola idea ordena todo lo que viene, y conviene tenerla en la cabeza en cada punto: el trabajo técnico aquí no consiste en añadir cosas nuevas y sofisticadas. Consiste en hacer explícito lo que tu web daba por sobreentendido. Una persona infiere lo que falta; una máquina no. Casi cada tarea de esta guía es la misma operación repetida: coger algo que un humano deduciría solo y dejarlo dicho de forma que una máquina no tenga que deducirlo. Si entiendes eso, podrás resolver casos que esta guía ni menciona. Si solo copias los pasos, te quedarás colgado en cuanto tu web no encaje con el ejemplo.

Lo organizo en cuatro capas, de fuera hacia dentro, siguiendo el recorrido de un agente: que pueda llegar, leerte, entenderte y, al final, actuar contigo. Es el mismo orden en el que conviene arreglarlo.

Capa 1. Acceso: que entren los bots correctos, y solo esos

Empezamos por lo más de fuera, porque si el agente no puede ni llegar, lo demás da igual. Y aquí el error más común que me encuentro es de bulto y silencioso a la vez: gente convencida de que tiene “los bots de IA” bien configurados cuando ni siquiera distingue de qué bots habla.

No existe “los bots de IA” como bloque único. Existen dos familias con propósitos opuestos, y confundirlas te puede dejar fuera del escaparate sin que te enteres durante meses.

Bots de entrenamiento. Rastrean para alimentar el modelo base. GPTBot (OpenAI), ClaudeBot (Anthropic), CCBot (Common Crawl), Google-Extended (entrenamiento de Gemini). Dejarlos entrar significa que tu contenido puede acabar dentro del modelo. Bloquearlos es una decisión legítima si no quieres contribuir al entrenamiento, y no afecta a tu visibilidad en las respuestas.

Bots de recuperación en tiempo real. Son los que van a buscar tu página cuando un usuario hace una pregunta, y los que generan la cita y el tráfico. OAI-SearchBot y ChatGPT-User (OpenAI), PerplexityBot y Perplexity-User (Perplexity), Claude-User y Claude-SearchBot (Anthropic). Estos son los que te dan visibilidad. Bloquearlos por error es el equivalente moderno a ponerte en noindex y luego preguntarte por qué la IA no te menciona nunca.

El mecanismo de por qué esto importa tanto: la decisión de entrenamiento y la de visibilidad son independientes. Puedes querer salir citado sin querer alimentar el modelo, y por eso necesitas tratar cada familia por separado. Quien lo gestiona en bloque acaba o regalando todo su contenido al entrenamiento sin pensarlo, o cerrándose el grifo de las citas sin querer.

La postura más habitual para una web de marketing (visibilidad sin contribuir al entrenamiento) es esta como punto de partida en tu robots.txt:

# Bots de recuperacion - PERMITIR (dan visibilidad y citas)
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Claude-User
User-agent: Claude-SearchBot
Allow: /

# Bots de entrenamiento - DECISION TUYA (aquí, bloqueados)
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Google-Extended
Disallow: /

Tres matices que no aparecen en las plantillas que circulan y que de verdad importan:

Primero, Google-Extended no es Googlebot. Bloquear Google-Extended te saca del entrenamiento de Gemini, pero no afecta a tu indexación en Google Search, que sigue siendo cosa de Googlebot. Mucha gente no toca esto por miedo a desaparecer de Google. No va a pasar. Son dos bots distintos con dos trabajos distintos.

Segundo, el lineup caduca cada pocos meses. Anthropic, por ejemplo, separó en 2026 su bot de entrenamiento (ClaudeBot) de los de recuperación (Claude-User, Claude-SearchBot). Antes de copiar cualquier plantilla, incluida la mía, contrasta los user-agents vigentes en la documentación oficial de cada proveedor. Esto es lo más volátil de toda la guía. Una plantilla de hace seis meses puede tener nombres que ya no existen.

Tercero, y es el más importante porque cambia la naturaleza del trabajo: el robots.txt es voluntario. Los bots serios lo respetan. Los agresivos lo ignoran y falsean su identidad (Bytespider es el caso de manual, llegó a ser la mayor parte del tráfico de crawler de IA ignorando las reglas). Y hay un matiz que conviene tener presente incluso con los proveedores serios: algunos fetchers disparados por el propio usuario (ChatGPT-User, Perplexity-User, Claude-User) están documentados como no sujetos al robots.txt del mismo modo que los crawlers automáticos, porque se entienden como una acción que el usuario ha pedido en ese momento, no como un rastreo. Así que, si de verdad quieres controlar el acceso, el robots.txt es la primera línea, no la única. El bloqueo real, cuando hace falta, se hace a nivel de servidor o con un WAF en el edge. El robots.txt declara tu intención; no la impone.

Y una rutina que cuesta cinco minutos al mes y vale oro: audita tus logs de acceso. Filtra por user-agent y mira qué bots te visitan, cada cuánto, y a qué páginas. Si los de entrenamiento te visitan cinco veces más que los de recuperación, estás pagando ancho de banda para alimentar un modelo que no te devuelve nada. Eso es un dato de negocio, no un detalle técnico.

Capa 2. Lectura: contenido que una máquina puede extraer

Una vez que el agente entra, tiene que poder sacar tu respuesta sin cavar. Y aquí está la buena noticia: esto es casi lo mismo que llevas años haciendo (o deberías) para los destacados de Google. La diferencia es que antes era un extra y ahora es condición de supervivencia.

El mecanismo, otra vez, es la no-inferencia. Un humano que llega a un bloque de texto largo localiza la respuesta aunque esté en el párrafo cuatro, porque escanea. Un modelo que tiene que extraer una respuesta penaliza la paja: si tu dato está enterrado, rodeado de introducción y contexto, o lo saca con esfuerzo o se va a una fuente que se lo da masticado. Servírselo no es cosmética; es la diferencia entre que te extraiga o no.

En la práctica:

• Definición o respuesta directa en el primer párrafo de cada página o sección. Si la respuesta está después de la introducción de calentamiento, para una máquina es como si no estuviera.
• Una pregunta por encabezado, una respuesta por sección. Encabezados que digan de qué va el bloque, no titulares creativos que haya que descifrar. El agente usa tus H2 y H3 como índice; si tus encabezados son ingeniosos pero opacos, le rompes el índice.
• Nada crítico atrapado en imágenes o en JavaScript que no renderiza. Si tu precio, tu disponibilidad o tu propuesta de valor solo se entienden viendo un gráfico o ejecutando un script pesado, para muchos agentes no existen. Este es uno de los fallos más caros y más invisibles, porque en tu pantalla se ve perfecto.
• Texto antes que adorno. Un dato concreto, una cifra, una afirmación verificable. Lo vago no se extrae bien; lo preciso, sí.

La prueba casera, que te recomiendo hacer hoy con tu página más importante: copia su texto plano, sin estilos, y léelo. Si ahí dentro está todo lo que alguien necesita para decidir, vas bien. Si falta la mitad, esa mitad tampoco la tiene la máquina, por mucho que en tu navegador se vea completa.

Y hay una capa de lectura que casi nadie del lado SEO menciona, porque viene del lado de la accesibilidad: muchos agentes de navegador no leen tu página por la foto que ves tú, la leen por el árbol de accesibilidad. De hecho, la documentación de Google describe el árbol de accesibilidad como el “modelo de datos primario” de un agente, y comprueba que cada elemento interactivo tenga un nombre programático. Traducido: el HTML semántico y las etiquetas ARIA, que llevan años siendo buena práctica de accesibilidad, han pasado a ser también condición para que un agente entienda qué es cada cosa de tu página. Un botón que para una persona dice “Reservar” pero que en el código es un div sin etiqueta, para un agente no es un botón de reservar. Es un cuadrado mudo. Lo que hiciste por las personas con lectores de pantalla resulta que también te prepara para las máquinas, y al revés: si tu interfaz es un amasijo de div sin nombre, ningún agente la va a saber operar.

Para que el principio de la no-inferencia no se quede en abstracto, un ejemplo de la misma información servida de dos maneras. Así la escribe casi todo el mundo:

En Hotel Costa te espera una experiencia inolvidable frente al mar. Consulta nuestras tarifas y disponibilidad poniéndote en contacto con nuestro equipo, que estará encantado de ayudarte a encontrar la mejor opción para tu estancia.

Para una persona, simpático. Para un agente, cero datos: ni precio, ni si hay sitio, ni condiciones. Lo mismo, servido para que se extraiga sin deducir:

Habitación doble con vistas al mar: 120 €/noche. Admite mascotas: sí. Cancelación gratuita hasta 48 horas antes.

Misma oferta. La segunda versión la puede leer un agente de un tirón y compararla; la primera le obliga a adivinar lo que no está, y un agente no adivina. Esto es toda la Capa 2 en dos párrafos.

Capa 3. Comprensión: datos estructurados que evitan la deducción

Si la Capa 2 hace que el agente pueda leer tu contenido, el schema hace que lo entienda sin tener que interpretarlo. Es la diferencia entre darle un texto del que tiene que deducir qué es un precio, y darle un dato que dice “esto es un precio, en euros, y vale 49”.

El mecanismo importa aquí más que en ningún sitio: cada deducción que obligas a hacer al agente es una oportunidad de que se equivoque o de que desconfíe y te descarte. El schema elimina la deducción. Le dices exactamente qué es cada cosa en un lenguaje que no admite interpretación. Es la herramienta más directa que tienes para reducir la incertidumbre del agente sobre ti, y reducir su incertidumbre es, literalmente, lo que hace que te elija frente a otra opción igual de buena pero más ambigua.

Los tipos que de verdad mueven la aguja, en orden de prioridad según tu caso:

• Organization y Person. Quién eres como entidad y quién firma el contenido. Esto alimenta el E-E-A-T y la coherencia de entidad de la que depende que la IA sepa quién eres (la capa LLMO). La autoría con Person, con sus credenciales, es de lo más infravalorado y de lo que más peso da a un contenido frente a uno anónimo.
• Article / BlogPosting, con autor y fecha. La frescura visible importa el doble en un tema que cambia cada mes, y el dateModified es la señal que dice “esto está vivo”.
• Product (con offers, price, availability). Innegociable si vendes algo. Es lo que permite que un agente compare tu producto con otro sin equivocarse de precio, y lo que lo conecta con los protocolos de comercio agéntico.
• FAQPage. Convierte tus preguntas frecuentes en bloques de pregunta-respuesta extraíbles uno a uno. Es de lo que mejor se cita, porque ya viene en el formato que el modelo quiere.
• BreadcrumbList. Ayuda a la máquina a entender dónde encaja cada página en tu arquitectura.

Impleméntalo en JSON-LD y pásalo siempre por la prueba de resultados enriquecidos de Google antes de darlo por bueno. Un schema con un error de sintaxis no es medio schema; es ninguno. El agente o lo lee entero y bien, o no se fía y lo ignora.

Para que se vea qué significa “decirle exactamente qué es cada cosa”, este es el Product del ejemplo de arriba (el precio que valía 49) en JSON-LD, listo para pegar en el <head>:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nombre del producto",
  "description": "Descripción breve y concreta, no marketing.",
  "brand": { "@type": "Brand", "name": "Tu marca" },
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://tudominio.com/producto"
  }
}

Fíjate en lo que pasa ahí: el price no es un número suelto que el agente tiene que cazar en la página y cruzar los dedos para que sea el bueno y no el tachado de la oferta vieja. Es un dato etiquetado, con su moneda y su disponibilidad al lado. Eso es exactamente lo que un agente necesita para comparar tu producto con otro sin equivocarse, y lo que lo conecta con los protocolos de comercio de los que hablo más abajo. El mismo patrón se repite con Organization, Person (la autoría) o FAQPage: cambias el tipo y los campos, pero la operación es siempre la misma, etiquetar lo que de otro modo habría que deducir.

Capa 4. llms.txt: qué es y la parte que casi nadie te cuenta sin venderte algo

El llms.txt es un archivo Markdown en la raíz de tu dominio (tudominio.com/llms.txt) que lista, con una línea de descripción, tus contenidos más importantes. La idea es darle al modelo un mapa ya hecho en lugar de obligarle a reconstruirlo rastreando doscientas URLs llenas de menús y ruido.

La idea es buena. Ahora la parte honesta, que es justo la que se saltan las guías que quieren venderte una implementación.

A junio de 2026, ningún gran proveedor (OpenAI, Google, Anthropic, Meta) se ha comprometido a usarlo en producción. Y Google ha sido especialmente claro: en su guía de Search Central del 15 de mayo de 2026 lo metió en la lista de cosas que no necesitas, Gary Illyes confirmó que Search no lo soporta y no piensa hacerlo, y John Mueller lo comparó con la vieja meta keywords, esa etiqueta que acabó sin que nadie la usara. El razonamiento de Google es simple: Googlebot ya renderiza y lee tu HTML real, no necesita un mapa aparte. Y los datos acompañan: un análisis lo encontró en menos del 1% de los sitios citados por IA. Si tuviera el efecto que le atribuyen, aparecería mucho más. Si alguien te lo vende como tu billete para salir en ChatGPT, te vende humo.

Y aun así, lo implementaría. Por tres razones concretas, y conviene que sean estas y no otras:

Primero, cuesta media tarde. El coste de oportunidad es ridículo, no hay que justificarlo ante nadie.

Segundo, el mundo de los agentes de desarrollo ya lo usa. Si tu negocio toca documentación técnica, APIs o herramientas para developers, ahí sí aporta hoy, no en un futuro hipotético. Es, de hecho, para lo que se inventó.

Tercero, y es el dato que casi nadie conecta: Chrome ha añadido a Lighthouse una auditoría de “navegación agéntica” que comprueba el llms.txt. Search dice que pases; Chrome lo mira para preparación ante agentes. Dos equipos de la misma empresa apuntando en direcciones distintas. En un tema que va precisamente de preparar tu web para agentes, esa señal de Chrome es una pista de hacia dónde puede ir esto. No es garantía. Es optionality barata: el día que un proveedor grande decida respetarlo, te alegrarás de haberlo tenido ya.

Si lo haces, hazlo bien, porque un llms.txt mal hecho es peor que ninguno: entre 20 y 50 enlaces curados, agrupados por secciones lógicas, con descripciones que digan qué encuentra ahí el modelo, no que vendan. No es un volcado del sitemap. Revísalo cada trimestre. Y trátalo como lo que es: una apuesta barata, no la columna de tu estrategia. El trabajo de verdad lo hacen tu robots.txt y tu contenido extraíble, no este archivo.

Capa emergente: WebMCP y lo que Chrome ya está auditando

El llms.txt no venía solo en esa auditoría de Chrome. Venía acompañado, y lo que lo acompaña pesa más que él. Merece sección propia porque es la pista más clara que tenemos de hacia dónde va el trabajo técnico el año que viene, aunque todavía sea pronto para tratarlo como obligatorio.

La categoría Agentic Browsing de Lighthouse, que llegó en la versión 13.3 a primeros de mayo de 2026, no puntúa de 0 a 100 como las demás: te da una proporción de comprobaciones superadas, porque el estándar todavía se está cociendo. Y comprueba cuatro cosas. El llms.txt es solo una, y la menos importante. Las otras tres son las que conviene mirar.

La primera ya la has visto en la Capa 2: la accesibilidad. Si el árbol de accesibilidad es el modelo de datos primario del agente, tener los elementos interactivos bien etiquetados deja de ser un tema de cumplimiento y pasa a ser de visibilidad. La segunda es la estabilidad del layout, el viejo CLS: una página que se recoloca sola mientras carga es tan confusa para un agente que intenta operar como lo es para una persona que va a pulsar un botón que se ha movido. Buenas noticias: las dos las llevas trabajando años si haces SEO técnico decente.

La tercera es la nueva de verdad, y la que yo vigilaría: WebMCP. La idea es dejar de obligar al agente a parsear capturas de pantalla y simular clics, y en su lugar exponerle “herramientas” que pueda llamar directamente: buscar, filtrar, añadir al carrito. Es decir, tu web deja de ser solo un documento que el agente lee y pasa a ofrecerle funciones que puede ejecutar. El equipo de Chrome confirmó en mayo de 2026 que WebMCP entra en origin trial público en Chrome 149, y es, de las señales nuevas de preparación para agentes, la más sustancial. Hoy no te urge salvo que tu producto sea una aplicación web con la que un agente tendría que interactuar. Pero la dirección está clara: si la capa de acción de la que hablo ahora va de que un agente pueda comprar, WebMCP va de que pueda hacer cualquier cosa en tu interfaz sin adivinar dónde están los botones. Lo dejo apuntado para que, cuando esto madure, no te pille reaprendiendo desde cero.

La capa que lo convierte en agéntico de verdad: que puedan actuar

Todo lo anterior hace que te lean y te entiendan, y WebMCP empieza a abrir que te operen. La capa de acción comercial es la que cierra el círculo cuando lo que hay que ejecutar es una transacción: comparar tu producto, comprobar disponibilidad real, ejecutar la compra o la reserva. La fontanería ya está montada y con nombres propios: Google empuja su Universal Commerce Protocol (UCP) y su Agent Payments Protocol, los amplió en mayo de 2026 con Universal Cart y un nuevo esquema de Merchant Center (las Conversational Attributes), y Walmart, Target y Shopify están entre los primeros vendiendo dentro del AI Mode.

Aquí entran los feeds de producto legibles por máquina, la disponibilidad expuesta como dato y los atributos conversacionales. Es donde está el grueso del trabajo para ecommerce, y merece su propia guía, así que lo desarrollo entero en el artículo de comercio agéntico el comercio agéntico. El principio que vale para todos: si un agente no puede completar la acción contigo sin fricción, no te elige, por muy bien que te lea.

Cómo saber si algo de esto funciona

Si no lo mides, no sabes si has ganado o solo has tocado archivos. Cuatro frentes, de menos a más esfuerzo:

• Logs de acceso. Filtra por user-agent: qué bots de IA te visitan, cada cuánto, a qué páginas. Es el diagnóstico más barato y el primero que hago siempre.
• Schema. La prueba de resultados enriquecidos cada vez que tocas una plantilla. No negociable.
• GA4. Aísla el tráfico referido por IA. Requiere configuración y todavía es imperfecto, pero te da la conversión de ese tráfico, que es donde está el valor, porque llega más caliente que el orgánico clásico.
• Citas. Pregunta por tu categoría en el AI Mode de Google, ChatGPT y Perplexity, y registra si apareces. Dentro del AI Mode esto es crítico: no hay enlaces azules debajo, la cita es toda tu visibilidad.

La métrica que lo resume todo: rentabilidad del rastreo, entendida como (citas + tráfico referido) dividido entre (coste de ancho de banda y servidor). Si un bot te cuesta mucho y no te devuelve nada, bloquéalo sin remordimientos. Si uno te trae citas, mímalo.

Predica con el ejemplo

Cierro como empecé. Todo este checklist está implementado en este mismo sitio: el robots.txt con la familia correcta de bots, el schema de autoría, la estructura extraíble por subpreguntas, el llms.txt con sus matices. No por coherencia estética, sino porque la mejor demostración de que sabes hacer esto es que tu propia web lo aguante cuando la mira una máquina. Si un consultor de SEO agéntico tiene la web ilegible para un agente, ya sabes lo que vale su consejo.

Preguntas frecuentes

¿Tengo que bloquear los bots de IA o dejarlos entrar? Depende de qué bot. A los de recuperación (OAI-SearchBot, PerplexityBot, Claude-User) conviene dejarlos entrar casi siempre, porque son los que te dan citas y tráfico. A los de entrenamiento (GPTBot, ClaudeBot, CCBot, Google-Extended) es una decisión tuya: bloquéalos si no quieres alimentar los modelos, déjalos si no te importa. Lo que no debes hacer es tratarlos a todos igual sin pensarlo.

¿El llms.txt me ayuda a posicionar en Google? No. Google Search ha confirmado que no lo lee ni lo usa como señal. Impleméntalo por las otras razones (coste mínimo, uso en agentes de desarrollo, la señal de Chrome/Lighthouse), pero no esperes efecto en tu ranking ni construyas tu estrategia sobre él.

¿Qué schema es el más importante para agentes? Si vendes, Product con precio y disponibilidad, sin discusión. Para todos, Organization y Person (autoría) por la coherencia de entidad, y FAQPage porque se extrae muy bien. Pásalo siempre por la prueba de resultados enriquecidos.

¿Bloquear Google-Extended me saca de Google? No. Google-Extended controla el entrenamiento de Gemini; Googlebot controla tu indexación en Search. Son bots distintos. Puedes bloquear el primero y seguir apareciendo en Google con normalidad.

¿Cada cuánto reviso todo esto? Cada trimestre como mínimo, y siempre contrastando los user-agents en la documentación oficial antes de copiar cualquier plantilla. Es la parte más volátil del SEO ahora mismo: los nombres de bots y la postura de cada plataforma cambian cada pocos meses.

Si quieres que alguien audite cómo te ven hoy los agentes de IA, de arriba abajo (acceso, schema, estructura y la capa de acción) y te deje el orden de prioridades para arreglarlo según impacto en tu negocio, es justo lo que hago como consultor SEO y SEO Product Manager. Hablamos.