Cómo preparar tu sitio web con múltiples ubicaciones para agentes de IA en 2026

Algo ha cambiado en la forma en que las personas encuentran negocios. No es un cambio gradual, sino estructural. Solo ChatGPT recibe ya más de 5.000 millones de visitas mensuales de 900 millones de usuarios activos semanales, y el tráfico mensual de Gemini creció un 647 % hasta los 2.000 millones de visitas en el año cerrado en marzo de 2026. Cada vez más de esas visitas incluyen búsquedas locales: “Encuéntrame un dentista con buenas reseñas cerca de Kungsholmen” o “¿Qué concesionario de coches en Gotemburgo tiene las mejores valoraciones de servicio?”. Dentro de ChatGPT, los prompts con intención local desencadenan ya una búsqueda web en vivo el 59 % de las veces, lo que convierte la pregunta “¿qué devuelve tu sitio cuando un agente lo consulta?” en un motor directo del tráfico de clientes a tus ubicaciones.

El agente de IA no navega por tu sitio web como lo hace una persona. Consulta protocolos, lee datos estructurados e invoca herramientas. Si tu sitio no sabe responder a esas peticiones, el agente recomendará a quien sí pueda hacerlo.

Eso es lo que significa “preparado para agentes”: tu sitio web está construido para que los sistemas de IA puedan descubrirlo, entenderlo e interactuar con él sin intervención humana.

Para las marcas con múltiples ubicaciones, lo que está en juego es todavía mayor. No estás optimizando una sola página ni una sola ubicación. Estás haciendo que cientos o miles de ubicaciones sean visibles para una nueva clase de visitantes digitales que no utilizan los navegadores como lo hacen las personas.

¿En qué se diferencia el descubrimiento por agentes de IA de la búsqueda tradicional?

Los motores de búsqueda rastrean HTML, siguen enlaces y construyen un índice. Los agentes de IA hacen algo fundamentalmente distinto. Ellos:

• Leen datos estructurados como JSON-LD y Markdown en lugar de analizar HTML desordenado
• Consultan protocolos para descubrir qué ofrece un sitio web antes de interactuar con él
• Invocan herramientas para ejecutar acciones (reservar, comparar, buscar) en lugar de limitarse a leer páginas
• Se conectan a servicios mediante protocolos estandarizados como MCP para acceder a datos de negocio en tiempo real

Este cambio implica que las reglas son otras. Un sitio web que posiciona bien en Google puede ser completamente invisible para un agente de IA si no implementa los estándares de descubrimiento en los que esos agentes se apoyan.

La buena noticia: los estándares existen, son abiertos y puedes implementarlos hoy mismo.

¿Qué es el stack de preparación para agentes?

La preparación para agentes no es una única casilla que marcar. Es un stack de estándares complementarios, cada uno enfocado a un aspecto distinto de cómo los agentes de IA interactúan con tu sitio web.

Capa 1: Acceso al contenido

¿Pueden los agentes de IA leer tu contenido de forma eficiente?

robots.txt con reglas explícitas para bots de IA es el punto de partida. Los principales rastreadores de IA anuncian su propio user agent, y lo más sencillo y mejor soportado hoy es nombrarlos explícitamente y decidir si los autorizas (Allow) o los bloqueas (Disallow):

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: Applebot-Extended
Allow: /

Para la mayoría de las marcas con múltiples ubicaciones, permitir a todos es la decisión correcta. Quieres que te citen. Estas reglas son directivas estándar del RFC 9309 que todos los rastreadores nombrados leen, así que esta capa se apoya en bases bien establecidas.

Content Signals es una capa más reciente y granular que se asienta sobre robots.txt. El borrador de Content Signals (un Internet-Draft de IETF de Michael Tremante y Leah Romm en Cloudflare) añade directivas Content-Signal que declaran cómo puede usar la IA tu contenido, no solo si puede acceder a él:

User-agent: *
Content-Signal: ai-train=yes, search=yes, ai-input=yes
Allow: /

Esto indica a los rastreadores de IA: pueden usar nuestro contenido para entrenar modelos (ai-train), construir índices de búsqueda (search) y generar respuestas con IA (ai-input). Cada bloque User-Agent tiene su propio Content-Signal, así que puedes establecer permisos distintos para rastreadores distintos.

La propuesta es prometedora y vale la pena seguirla. Aún es un borrador inicial del IETF, así que la adopción es desigual: Cloudflare lo ha integrado en el robots.txt que gestiona para los sitios de su red, mientras que los grandes laboratorios de IA todavía no han confirmado públicamente si leen la directiva Content-Signal. Añadirlo hoy es más una forma de declarar tu intención que de imponerla, lo cual es una decisión perfectamente razonable.

Un pequeño aviso: hasta finales de mayo de 2026, añadir líneas Content-Signal generaba un aviso cosmético de “robots.txt no es válido” en PageSpeed Insights, porque el validador solo conocía las directivas del RFC original de robots.txt. El validador de Google se ha actualizado desde entonces y, desde el 26 de mayo de 2026, el aviso ya no aparece. Algunas herramientas SEO más antiguas pueden seguir marcándolo, pero la directiva es segura igualmente: el RFC 9309 indica a los rastreadores que ignoren las líneas que no reconozcan, así que no afectará a tu posicionamiento ni al acceso de la IA.

La negociación de contenido en Markdown ofrece a los agentes de IA contenido limpio y estructurado en lugar de HTML en bruto. Cuando un agente envía Accept: text/markdown en su petición HTTP, el servidor responde con Markdown para la misma URL canónica, mientras que los navegadores siguen recibiendo HTML. El Markdown puede generarse al vuelo en el edge (el enfoque de Cloudflare) o pre-construirse como un archivo .md hermano en el origen (el patrón que utilizan Vercel, Sentry, Sanity y este sitio). En ambos casos hay una sola URL para el contenido y la respuesta varía según la cabecera Accept.

Por qué les importa a los agentes. El argumento a favor de Markdown es sobre todo económico. Cada token que un agente lee o genera cuesta cómputo, y eso se traduce directamente en latencia, gasto de API y ancho de banda. Un encabezado simple en Markdown cuesta unos tres tokens, mientras que el marcado HTML equivalente utiliza entre doce y quince, según el anuncio “Markdown for Agents” de Cloudflare. En el conjunto de una página, el HTML limpio suele costar entre dos y tres veces más que el mismo contenido en Markdown, y el HTML real con CSS, JavaScript y tracking puede dispararse hasta ocho o diez veces más, según el análisis HTML vs Markdown de Beam.ai. Cloudflare midió su propio post de anuncio: 16.180 tokens en HTML y 3.150 en Markdown, una reducción del 80 %. Vercel reportó una historia similar desde el ángulo del ancho de banda: la versión HTML de una página de su sitio pesaba unos 500 KB mientras que la versión Markdown se quedó en 3 KB, una reducción del 99 % del payload sobre el ahorro de tokens. Las dos cifras miden cosas distintas (tokens frente a bytes) y vienen de proveedores distintos con métodos distintos, pero triangulan la misma historia. A los precios de los modelos frontier, esa diferencia se acumula rápidamente a lo largo de una sesión, y el cómputo y el ancho de banda ahorrados pueden invertirse en más razonamiento, más llamadas a herramientas o simplemente en una petición más barata.

El ahorro también va más allá del coste. Menos tokens significa más espacio en la ventana de contexto del agente para la tarea real, un menor tiempo hasta el primer token porque hay menos que recuperar y analizar, y una mejor relación señal-ruido para la recuperación (sin menús, anuncios, modales ni envoltorios de maquetación compitiendo con el contenido). Markdown es también el formato sobre el que se entrenaron en gran medida los LLM (READMEs de GitHub, documentación técnica, salidas generadas), así que tiende a ser su entrada más fluida por defecto. Cloudflare incluso incluye una cabecera de respuesta x-markdown-tokens junto con la salida convertida, documentada en Cloudflare Fundamentals, para que el agente pueda comprobar el recuento de tokens por adelantado y decidir si el documento cabe en su ventana de contexto o si necesita trocearlo.

Quién lo soporta hoy. Según el rastreador de estado acceptmarkdown.com, el soporte del lado del cliente empezó en las herramientas de codificación y se está extendiendo ahora a las superficies de trabajo de propósito general. Claude, de Anthropic, envía Accept: text/markdown desde Claude Code y desde Cowork en la aplicación de escritorio de Claude (verificado en nuestras propias pruebas de logs de peticiones en el momento de escribir esto), lo que significa que la negociación de contenido en Markdown ya no es solo cosa de los agentes de codificación: Cowork es la superficie de investigación, redacción y navegación dentro de la aplicación de escritorio, así que cualquier documento de negocio, búsqueda de competidores o artículo que un usuario de Claude pida a Cowork pasa por este camino. La experiencia normal de chat en la aplicación de escritorio y en claude.ai todavía no envía la cabecera. Cursor, OpenCode y OpenClaw también la envían. El Codex CLI de OpenAI lo soporta parcialmente: recupera primero la URL canónica como HTML y luego busca un <link rel="alternate" type="text/markdown"> en la cabecera antes de pedir el archivo Markdown hermano. Las superficies orientadas al consumidor (ChatGPT browse, Gemini, Perplexity, Copilot browse) generalmente no envían la cabecera hoy, así que por ahora esto se entiende mejor como una optimización para agentes de codificación y para las superficies de trabajo de Claude, con los agentes de consumo probablemente llegando después. Vale la pena hacer tu propia comprobación antes de depender de un cliente concreto, porque estos comportamientos cambian rápido.

Quién lo impulsa. Es una convención multi-vendor, no un empujón de una sola empresa. No hay un trabajo formal en el IETF, solo un patrón que se apoya en estándares existentes (negociación de contenido del RFC 7231 y el tipo de medio text/markdown del RFC 7763). En el lado de infraestructura y plataforma, el “Markdown for Agents” de Cloudflare convierte HTML a Markdown en el edge para sitios en los planes Pro, Business y Enterprise, mientras que Vercel sirve Markdown con negociación de contenido en sus propias propiedades con una guía de implementación en Next.js. Las implementaciones del lado del origen también se acumulan en el ecosistema de CMS y herramientas de desarrollo: Sentry sirve Markdown vía cabeceras Accept, Sanity ha publicado una guía práctica para servir contenido a agentes, DeployHQ documenta el patrón en Laravel, Express, Django y sitios estáticos y Roots ha publicado un plugin de WordPress que gestiona la negociación de contenido en URLs canónicas. También hay una discusión en GitHub de Next.js donde los usuarios del framework están resolviendo cómo conectarlo, y guías de implementación pensadas explícitamente para el camino sin Cloudflare. En el lado del cliente, Anthropic y Anysphere impulsaron primero la adopción a través de Claude Code y Cursor. Ninguna empresa controla la convención, y la amplitud de stacks que la adoptan de forma independiente es lo que hace que la distribución sea real.

La postura de Google. John Mueller, de Google, se ha mostrado públicamente escéptico con “Markdown para bots” en general, calificando la idea de “una idea estúpida” en Bluesky y preguntando en Reddit por qué los agentes necesitarían una página que ningún usuario ve, dado que los LLM siempre se han entrenado y han analizado HTML. La guía oficial de optimización para IA de Google adopta la misma línea, listando los archivos Markdown específicos para IA entre las cosas que no necesitas añadir para aparecer en sus superficies de IA generativa. Fabrice Canel, de Microsoft, ha expresado una preocupación parecida sobre crear versiones separadas del contenido para los rastreadores, citando la carga adicional de rastreo y el riesgo de que las versiones que no ven los usuarios se descuiden y se queden desactualizadas. Vale la pena leer sus objeciones con atención, porque apuntan a un patrón relacionado pero distinto: servir un Markdown completamente diferente en una URL distinta basada en sniffing del user-agent. La verdadera negociación de contenido, en la que la misma URL sirve HTML o Markdown del mismo contenido subyacente según la cabecera Accept, es un mecanismo HTTP establecido desde hace tiempo (de la misma forma que las imágenes pueden servirse como WebP o JPEG según lo que admita el cliente). Conviene tener en cuenta que la guía de Google trata sobre aparecer en sus propios productos de IA, mientras que el argumento de economía de tokens va sobre eficiencia para cualquier agente que ya haya elegido leer tu contenido. La línea entre ambas cosas importa.

Compromisos a tener en cuenta. El riesgo más comentado es una variante de cloaking. El investigador SEO David McSweeney ha demostrado que la implementación en el edge de Cloudflare reenvía la cabecera Accept: text/markdown al origen, indicándole en la práctica “esta petición viene de un agente de IA”. En su prueba de concepto, el origen devolvía una página a las personas y una página completamente distinta a los agentes, y Cloudflare convertía obedientemente a Markdown el HTML dirigido al agente. La mitigación propuesta es que los proveedores de edge eliminen la cabecera antes de pedir el contenido al origen, aunque eso aún no es el comportamiento por defecto. La misma propiedad abre un vector de prompt injection para los agentes que toman acciones en nombre del usuario, ya que el usuario nunca ve lo que el agente lee. Otras cosas que sopesar: Vary: Accept permite cachear correctamente ambas representaciones pero puede reducir las tasas de acierto y complicar el comportamiento del CDN, y el Markdown convertido en el edge es genérico, así que para páginas de marketing o producto con un diseño rico una versión Markdown escrita en el origen suele leerse mejor que lo que sobrevive a una conversión automática de HTML a MD.

llms.txt es un archivo Markdown en la raíz de tu sitio que ofrece una visión general curada de tu sitio web para los sistemas de IA. La convención se propuso en 2024 y algunos sitios la han adoptado, pero ningún rastreador de IA importante la honra oficialmente todavía como señal de descubrimiento. La guía de optimización para IA de Google agrupa explícitamente llms.txt entre las cosas que no necesitas crear, sobre la base de que los sistemas de IA pueden analizar HTML normal sin problema. Dicho esto, el propio auditor Lighthouse de Google añadió una categoría “Agentic Browsing” en la v13.2 (abril de 2026) y la incorporó a la configuración por defecto en la v13.3 la semana siguiente. La categoría comprueba expresamente si existe un llms.txt en la raíz de tu dominio, así que el panorama es mixto. La categoría no se puntúa de forma ponderada en una escala de 0 a 100 mientras los estándares maduran, lo que convierte la comprobación de llms.txt en una señal informativa y no de posicionamiento. Con la negociación de contenido en Markdown ya en marcha, los agentes reciben Markdown limpio para cualquier página que recuperan, lo que elimina la mayor parte del caso de uso original. llms.txt es probablemente más útil para sitios con documentación técnica densa, donde un mapa curado ayuda a los agentes a encontrar el punto de entrada correcto. Para las marcas con múltiples ubicaciones, donde cada ubicación y cada entrada de blog ya son descubribles de forma independiente a través del sitemap y la negociación de Markdown, el retorno es menor.

Capa 2: Datos estructurados

¿Pueden los agentes de IA entender qué significa tu contenido?

Los datos estructurados JSON-LD proporcionan a los agentes de IA descripciones explícitas y estandarizadas de tu negocio. Para marcas con múltiples ubicaciones, el esquema LocalBusiness en cada página de ubicación indica a los agentes el nombre, la dirección, el teléfono, el horario, las valoraciones y los servicios en un formato que pueden procesar sin tener que deducirlo.

Añade los esquemas FAQPage, Product, Article y BreadcrumbList donde proceda. Cuantos más datos estructurados aportes, con mayor seguridad podrá un agente de IA citarte y recomendarte.

Capa 3: Descubrimiento de protocolos

¿Pueden los agentes de IA encontrar tus herramientas y capacidades?

Esta es la capa más nueva y la que avanza más rápido. Tres estándares emergentes cubren distintos aspectos del descubrimiento de herramientas:

MCP Server Cards (SEP-2127, propuesta del equipo de MCP liderado por David Soria Parra en Anthropic) permite anunciar tu servidor Model Context Protocol en /.well-known/mcp-server-card. Si tu negocio dispone de un servidor MCP, esto indica a los clientes de IA exactamente cómo encontrarlo y conectarse a él.

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "com.example/my-location-mcp",
  "version": "1.0.0",
  "description": "Query location data across all business locations"
}

Agent Skills (RFC de Cloudflare) publica un catálogo de las capacidades de tu sitio en /.well-known/skills/index.json. Cada skill es un archivo Markdown que describe qué pueden hacer los agentes con tu sitio, desde buscar en tu base de conocimiento hasta comparar tus productos con los de la competencia.

WebMCP (una especificación del W3C Community Group editada por ingenieros de Google y Microsoft) registra herramientas mediante navigator.modelContext.registerTool() que los agentes de IA basados en navegador pueden invocar directamente. En lugar de que un agente tenga que adivinar que existe un botón “Solicitar demo” en algún punto de tu página, tú registras una herramienta request_demo con su descripción, sus parámetros y una función de ejecución.

navigator.modelContext.registerTool({
  name: "request_demo",
  description: "Book a personalized demo of the platform",
  execute: async () => {
    window.location.href = "/requestademo/";
    return { navigated: "/requestademo/" };
  }
});

Google describe WebMCP como “un canal de comunicación directo” que “elimina la ambigüedad y permite flujos de trabajo de agentes más rápidos y robustos”.

Capa 4: Control de acceso

¿Qué pueden hacer los distintos agentes?

Content Signals (cubierto en la Capa 1) está pensado para gestionar los permisos de uso del contenido. Puedes expresar que se permite la indexación de búsqueda pero no el entrenamiento, o permitirlo todo. La adopción aún es temprana, así que conviene entenderlo como una declaración de preferencias y no como una garantía de cumplimiento.

Las reglas para bots de IA en robots.txt te permiten permitir o bloquear explícitamente rastreadores concretos: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended y otros. Para la mayoría de las marcas, lo lógico es permitir a todos los rastreadores de IA. Quieres ser detectable.

¿Por qué las marcas con múltiples ubicaciones son las que más se benefician de la preparación para agentes?

Una cafetería con una sola ubicación puede hacerse encontrar solo con Google Maps. Pero una marca con 500 ubicaciones en 12 países se enfrenta a un reto radicalmente distinto. Cada ubicación debe ser detectable individualmente por agentes de IA, y los datos de todas las ubicaciones deben ser consistentes, estructurados y legibles por máquinas.

La escala amplifica la ventaja. Si una ubicación de la competencia está preparada para agentes y la tuya no, pierdes esa recomendación. Si tienes 500 ubicaciones preparadas para agentes y tu competidor tiene cero, ganas 500 recomendaciones.

Las búsquedas locales están adoptando primero el modelo agéntico. “Encuéntrame un … cerca de …” es una de las consultas más habituales que las personas hacen a los asistentes de IA. Son las consultas que impulsan directamente las visitas a tiendas, y exigen datos estructurados de las ubicaciones, reseñas e información de negocio a los que los agentes puedan acceder de forma programática.

Los agentes de IA necesitan datos en tiempo real. Un servidor MCP puede ofrecer puntuaciones de reseñas actualizadas, horarios de apertura actuales y listados de servicios al día. Las páginas HTML estáticas no. Las marcas que conectan sus datos en vivo mediante MCP dan a los agentes la información más fresca y precisa, lo que aumenta la probabilidad de que los agentes las recomienden.

Prioridades de implementación para marcas con múltiples ubicaciones

No todos los estándares tienen hoy la misma importancia. Este es el orden que te da mayor visibilidad con el menor esfuerzo:

Empieza por aquí

1. Actualiza robots.txt con reglas explícitas para bots de IA (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Applebot-Extended)
2. Verifica los datos estructurados JSON-LD en todos los tipos de página (LocalBusiness para ubicaciones, Product, FAQPage, Article)

Siguientes pasos

3. Implementa la negociación de contenido en Markdown para que los agentes de IA reciban contenido limpio

Avanzado

4. Publica un MCP Server Card si dispones de un servidor MCP
5. Implementa herramientas WebMCP para acciones clave (solicitudes de demo, búsqueda de ubicaciones, navegación por productos)
6. Publica Agent Skills con la lista de capacidades de tu sitio

Si dispones de tiempo y recursos, esto puede ayudar

7. Añade llms.txt y llms-full.txt solo si mantienes documentación técnica densa. Para la mayoría de las marcas con múltiples ubicaciones, sáltatelo. La adopción es desigual entre los principales rastreadores de IA, la guía de optimización para IA de Google dice explícitamente que no es necesario, y la negociación de contenido en Markdown ya cubre el mismo terreno para cualquier página que un agente recupere. El patrón de visión general curada es más útil cuando los agentes necesitan ayuda para encontrar el punto de entrada correcto en documentación de desarrollo profunda, no cuando cada ubicación y cada entrada de blog ya son descubribles de forma independiente a través de tu sitemap.
8. Añade directivas Content Signals a robots.txt para declarar cómo puede usar la IA tu contenido. El borrador del IETF está avanzando y vale la pena seguirlo. La adopción entre los principales rastreadores de IA aún es temprana, pero la directiva es segura de añadir (los rastreadores ignoran las líneas que no reconocen) y es una buena forma de dejar marcada tu posición de cara al futuro.

Prueba todo

Pasa tu sitio por isitagentready.com, el escáner oficial de preparación para agentes de Cloudflare (lanzado en abril de 2026), para ver qué comprobaciones pasa. Evalúa el mismo stack de cuatro capas con el que se organiza este artículo (descubribilidad, accesibilidad del contenido, control de acceso de bots y capacidades), y señala exactamente qué falta.

Para una segunda opinión, el Agent Readiness Score de GEO Metrics también es gratuito y cubre las mismas cuatro dimensiones, con un eje editorial adicional para datos estructurados, autoría y otras señales de citación por IA. Es una verificación cruzada útil cuando quieres ver si tus puntuaciones se sostienen con una metodología distinta.

Además, Lighthouse añadió una nueva categoría “Agentic Browsing” en la v13.2 (abril de 2026), activada por defecto en la v13.3, con auditorías para el registro de herramientas WebMCP, validez del esquema, un llms.txt en la raíz de tu dominio y señales de accesibilidad para agentes. La categoría no se puntúa de forma ponderada en una escala de 0 a 100 (“los estándares para la web agéntica todavía están emergiendo”), así que trátala como una lista de verificación y no como un número que optimizar. Las auditorías se ejecutan dentro de Chrome DevTools, lo que las convierte en un complemento rápido a los escáneres dedicados de agent readiness mencionados arriba.

Los estándares (mayo de 2026)

Estos estándares evolucionan a gran velocidad. Este es el panorama actual:

El denominador común: todos son estándares abiertos respaldados por las principales empresas tecnológicas. Ninguno depende de un único proveedor. Implementarlos hoy significa construir sobre unas bases a las que todo el sector está convergiendo.

¿Qué estándares de preparación para agentes están por llegar?

Los estándares en torno a la preparación para agentes siguen evolucionando a gran velocidad. Algunas cosas que conviene vigilar:

Agent Card (del proyecto AI Card) aspira a ser un formato de descubrimiento independiente del protocolo en /.well-known/ai-catalog.json. Se puede pensar como una guía telefónica de los servicios de IA disponibles en un dominio.

Los protocolos de comercio han pasado de “emergentes” a “en producción”. El 11 de enero de 2026, Google lanzó el Universal Commerce Protocol (UCP), un estándar abierto para el comercio agéntico co-desarrollado con Shopify, Etsy, Wayfair, Target y Walmart, y respaldado por más de 20 empresas más, entre ellas Best Buy, The Home Depot, Macy’s, Adyen, Stripe, Visa, Mastercard, Flipkart y Zalando. UCP es explícitamente compatible con MCP, A2A y AP2, así que los datos estructurados y el trabajo de protocolo que se cubre antes en este artículo son reutilizables, no descartables. El Agentic Commerce Protocol (ACP) de Stripe y OpenAI cubre el mismo problema desde el lado de pagos, y x402 sigue siendo una opción para los micropagos. Si vendes por internet, el comercio agéntico es el siguiente hito de implementación tras el stack de descubrimiento, no un punto de “monitorizar y esperar”.

La autenticación de bots verificados se está explorando: los agentes de IA podrían demostrar su identidad y obtener distintos niveles de acceso. Esto permitiría dar a los agentes verificados acceso a datos más ricos y limitar a los bots desconocidos.

Agentes de marca en Search: Google Business Agent

En enero de 2026, Google lanzó Business Agent, un asistente comercial virtual configurable que las marcas activan desde Merchant Center y que aparece directamente dentro de Google Search. Según el anuncio de Google, minoristas estadounidenses elegibles como Lowe’s, Michael’s, Poshmark y Reebok se incorporaron en el despliegue inicial, con entrenamiento específico por minorista sobre sus propios datos, ofertas de productos relacionados y checkout agéntico planteados como capacidades posteriores. Las funciones de entrenamiento, ofertas relacionadas y checkout dependen del calendario de despliegue de Google, así que revisa Merchant Center para ver qué está disponible actualmente en tu cuenta antes de comprometer fechas concretas con tus stakeholders.

Junto con Business Agent, Google introdujo decenas de nuevos atributos de datos de Merchant Center diseñados para las superficies de AI Mode, Gemini y Business Agent. Estos atributos van más allá de las palabras clave e incluyen respuestas a preguntas habituales sobre productos, accesorios compatibles y sustitutos.

Para las marcas con múltiples ubicaciones la implicación es directa. Los mismos datos estructurados, esquema FAQ y feeds de ubicación en vivo que publicas para el stack de preparación para agentes alimentan la superficie conversacional donde los compradores empiezan cada vez más su recorrido. Si un competidor publica atributos FAQ en Merchant Center y tú no, es más probable que el Business Agent que responde a la pregunta de un comprador presente la marca de ese competidor en lugar de la tuya.

¿Cómo se implementa la preparación para agentes en cientos de ubicaciones?

Implementar estos estándares en un único sitio web es sencillo. Hacerlo en cientos o miles de ubicaciones es un reto completamente distinto. Cada ubicación necesita datos estructurados coherentes, horarios de apertura precisos, puntuaciones de reseñas actualizadas y un marcado de esquemas bien formado. Cuando esos datos se desvían (y se desviarán), los agentes de IA reciben señales contradictorias y pierden confianza en tu marca.

Aquí es donde las plataformas de gestión de ubicaciones se vuelven imprescindibles. PLACES AI de PinMeTo gestiona los datos estructurados en más de 100 redes de directorios y conecta los datos de ubicación en vivo a los asistentes de IA a través del PinMeTo Location MCP, ofreciendo a los agentes un flujo directo y en tiempo real de la información de tu negocio en lugar de HTML desactualizado.

Si quieres profundizar en cómo la búsqueda con IA está reconfigurando el descubrimiento local, consulta nuestra guía completa de GEO para marcas con múltiples ubicaciones y nuestras entradas del glosario sobre AI Overviews y Generative Engine Optimization.

Actualizaciones

Este es un tema que avanza rápido, así que volvemos a este artículo a medida que los estándares se consolidan. Cambios recientes:

• 2026-05-27: Se añadió una nota sobre la nueva categoría “Agentic Browsing” de Lighthouse (WebMCP, llms.txt, accesibilidad para agentes, estabilidad del diseño). La puntuación todavía no es una escala ponderada de 0 a 100 mientras los estándares maduran, así que las comprobaciones son informativas hoy. Añadida en la sección de llms.txt y en la lista de herramientas de prueba.
• 2026-05-26: El validador de PageSpeed Insights de Google ya reconoce la directiva Content-Signal, así que añadir Content Signals a robots.txt ya no dispara la advertencia “robots.txt no es válido”. Se actualizaron la sección de acceso al contenido y la lista de prioridades de implementación.
• 2026-05-22: Se añadió contexto sobre Google Business Agent y una entrada de preguntas frecuentes sobre el Universal Commerce Protocol (UCP) tras los anuncios de Google de enero de 2026.

Preguntas frecuentes

¿Cómo puedo comprobar si mi sitio está preparado para agentes?

Visita isitagentready.com, el escáner oficial de preparación para agentes de Cloudflare, e introduce tu URL. Revisa todos los estándares actuales y te devuelve un informe de aprobado/suspendido con recomendaciones accionables. Para una segunda opinión que añade una dimensión adicional de señales editoriales, el Agent Readiness Score de GEO Metrics también es gratuito y vale la pena ejecutarlo en paralelo.

¿Implementar los estándares de preparación para agentes afectará a mi SEO actual?

No. La preparación para agentes se apoya en las mejores prácticas de SEO ya existentes. robots.txt, datos estructurados y sitemaps ya forman parte del SEO. Los nuevos estándares (Content Signals, MCP Server Cards, WebMCP) son complementarios. No cambian la forma en que los motores de búsqueda interactúan con tu sitio.

¿Necesito un desarrollador para implementarlo?

Lo básico (reglas de robots.txt, datos estructurados JSON-LD y directivas Content Signals) lo puede hacer cualquier persona con soltura editando archivos de texto y configuración. La negociación de contenido en Markdown es un interruptor de un solo clic si tu sitio está detrás de Cloudflare Pro o superior, pero en caso contrario necesita que un desarrollador conecte la generación de archivos .md hermanos en el build o una reescritura en el origen. WebMCP y MCP Server Cards requieren algún conocimiento de JavaScript y JSON. Para implementaciones empresariales en cientos de ubicaciones, conviene que tu equipo de desarrollo o tu socio tecnológico se encargue.

¿Qué es Google Business Agent y necesito hacer algo nuevo por él?

Business Agent es un asistente comercial virtual configurable que Google lanzó en enero de 2026. Las marcas lo activan desde Merchant Center y aparece dentro de Google Search para responder a las preguntas de los compradores en nombre de la marca. Minoristas estadounidenses elegibles como Lowe’s, Michael’s, Poshmark y Reebok estuvieron activos desde el lanzamiento. Para las marcas con múltiples ubicaciones, el paso práctico es completar los nuevos atributos de datos de Merchant Center que Google publicó junto con la función (respuestas a preguntas habituales sobre productos, accesorios compatibles, sustitutos), porque esos atributos alimentan Business Agent, AI Mode y Gemini. El trabajo de preparación para agentes que cubre el resto de esta guía (datos estructurados, esquema FAQ, feeds de ubicación en vivo) es el mismo conjunto de entradas, así que la mayor parte del esfuerzo se transfiere directamente.

¿Qué pasa si estos estándares cambian?

Cambiarán. Es la naturaleza de las especificaciones emergentes. Pero los principios fundamentales (datos estructurados, contenido legible por máquinas, descubrimiento estandarizado) están bien establecidos. Cualquier cambio será iterativo, no una reescritura completa. Construir sobre estas bases ahora significa que las actualizaciones futuras serán trabajo incremental, no una reconstrucción desde cero.

¿La preparación para agentes solo se aplica a sitios web, o también a aplicaciones y otras plataformas?

Los estándares que cubrimos aquí están enfocados a la web, diseñados para contenido servido por HTTP. Las aplicaciones móviles, los asistentes de voz y los dispositivos IoT tienen sus propios mecanismos de descubrimiento. Dicho esto, MCP como protocolo funciona con cualquier cliente compatible, así que los datos que estructuras para tu sitio web también pueden servir a agentes de IA no web que se conecten a través de servidores MCP.

¿Cómo encaja el Universal Commerce Protocol (UCP) de Google en la preparación para agentes?

UCP es la capa transaccional que se asienta sobre la capa de descubrimiento en la que se centra esta guía. Es un estándar abierto lanzado por Google en enero de 2026 con Shopify, Etsy, Wayfair, Target y Walmart entre sus co-desarrolladores, y es compatible con MCP, A2A y AP2. Si ya publicas datos estructurados de producto y de ubicación, expones herramientas a través de MCP y sigues el stack de preparación para agentes, estás en buena posición para conectarte con UCP. En el lanzamiento Google indicó que UCP impulsaría el checkout de las fichas de producto elegibles en AI Mode y Gemini para minoristas estadounidenses, con expansión internacional posterior. Consulta el estado actual del despliegue de Google antes de dar por hecho que está disponible en tu mercado.

¿Buscas formas de hacer que tus ubicaciones sean visibles para los agentes de IA? Solicitar demo y descubre cómo PLACES AI ayuda a las marcas con múltiples ubicaciones a mantenerse detectables tanto en la búsqueda tradicional como en el descubrimiento impulsado por IA.

Fuentes y referencias

• Content Signals for Automated Processing - Internet-Draft de IETF por Michael Tremante y Leah Romm sobre directivas de permisos de contenido para IA
• SEP-2127: MCP Server Cards - Propuesta de Model Context Protocol para anunciar servidores MCP mediante URIs well-known
• WebMCP Specification - Especificación del W3C Web Machine Learning Community Group para herramientas de agentes de IA en el navegador
• WebMCP: An API for the Agentic Web - Presentación de WebMCP en Chrome for Developers y su papel en los flujos de trabajo de agentes
• Agent Skills Discovery RFC - Estándar propuesto por Cloudflare para publicar las capacidades de un sitio web a los agentes de IA
• Introducing the Model Context Protocol - Anuncio de Anthropic de MCP como estándar abierto para la integración de herramientas de IA
• Introducing Markdown for Agents - Anuncio principal de Cloudflare, incluido el benchmark de 16.180 frente a 3.150 tokens y la comparación de coste por elemento
• Markdown for Agents (Cloudflare Fundamentals docs) - Documentación oficial, incluida la cabecera de respuesta x-markdown-tokens
• HTML vs Markdown for AI Agents (Beam.ai) - Comparación que muestra el HTML limpio entre 2 y 3 veces más caro y el HTML real entre 8 y 10 veces más caro en tokens que el Markdown equivalente
• Cloudflare Markdown for Agents: Complete Technical Guide (ALM Corp) - Recorrido técnico secundario sobre el benchmark de reducción del 80 % de tokens y sus implicaciones SEO
• Making agent-friendly pages with content negotiation (Vercel) - Post principal de Vercel sobre servir Markdown vía cabeceras Accept, incluida la reducción de payload de 500 KB a 3 KB en su propio sitio
• Make your documentation readable by AI agents (Vercel) - Guía de la base de conocimiento de Vercel sobre negociación de contenido para sitios de documentación
• Allow pages to be served in markdown for AI Agents (Next.js Discussion #90579) - Discusión comunitaria sobre cómo implementar la negociación de contenido en Markdown en Next.js
• How to serve content to agents: a field guide (Sanity) - Guía de Sanity para entregar contenido directamente a agentes de IA
• Content Negotiation for AI Agents: Why Sentry Serves Markdown Over HTML - Caso de estudio sobre la implementación de la negociación de contenido en Markdown de Sentry
• How to Make Your Documentation AI-Friendly (DeployHQ) - Guía de implementación que cubre la negociación de contenido en Laravel, Express, Django y sitios estáticos
• Serve Your WordPress Posts as Markdown (Roots) - Recorrido de Roots para servir Markdown desde WordPress vía la cabecera Accept
• post-content-to-markdown WordPress plugin (Roots, GitHub) - Plugin de WordPress de código abierto que sirve el contenido de los posts como Markdown vía cabeceras Accept y URLs .md
• Implementing Markdown for Agents Without Cloudflare (Pragmate) - Guía de implementación pensada explícitamente para el camino sin Cloudflare
• AI Statistics and Trends - Datos de uso sobre el crecimiento y la adopción de chatbots de IA (2024-2025), mantenido como contexto histórico
• Generative AI Statistics for 2026 (Similarweb) - Cifras actuales de visitas mensuales y usuarios activos semanales para ChatGPT y otros chatbots líderes
• AI Search Market Share 2026: ChatGPT, Gemini & Perplexity Stats (Stackmatix) - Crecimiento interanual del 647 % de Gemini y redistribución de cuota de mercado hasta marzo de 2026
• New Data Study: What Queries Is ChatGPT Using Behind The Scenes? (Nectiv) - Análisis de Nectiv de más de 8.500 prompts de ChatGPT realizado en octubre de 2025, fuente primaria de la tasa del 59 % a la que los prompts con intención local activan una búsqueda web en vivo dentro de ChatGPT
• Is Your Site Agent Ready? - Escáner oficial de preparación para agentes de Cloudflare para comprobar tu sitio frente a los estándares actuales
• Introducing the Agent Readiness Score (Cloudflare) - Anuncio de Cloudflare del escáner isitagentready.com (abril de 2026), incluido el modelo de puntuación de cuatro dimensiones
• Agent Readiness Score (GEO Metrics) - Escáner gratuito independiente que añade señales editoriales y de citación por IA sobre el mismo stack técnico de cuatro capas
• Model Context Protocol - Documentación oficial y especificación de MCP
• robots.txt RFC 9309 - Estándar IETF para el protocolo de exclusión de robots
• New tech and tools for retailers to succeed in an agentic shopping era - Blog de Google Ads & Commerce, 11 de enero de 2026, sobre UCP, Business Agent, los nuevos atributos de Merchant Center y Direct Offers
• Universal Commerce Protocol - Especificación oficial de UCP y directorio de partners
• Business Agent in Merchant Center - Documentación de Google Merchant Center para activar y configurar Business Agent
• Agent Payments Protocol (AP2) - Protocolo abierto de Google Cloud para pagos dirigidos por agentes, referenciado por UCP
• Agent2Agent Protocol (A2A) - Protocolo abierto para la interoperabilidad entre agentes de IA, referenciado por UCP
• Agentic checkout for the holiday shopping season - Anuncio anterior de Google sobre compras agénticas sobre el que se construye UCP
• acceptmarkdown.com Status - Rastreador mantenido por la comunidad sobre qué clientes de IA envían Accept: text/markdown
• AI features and your website (Google Search Central) - Guía oficial de optimización para IA de Google, incluida la sección Mythbusting que dice explícitamente que no necesitas llms.txt, archivos de texto para IA ni Markdown para aparecer en sus superficies de búsqueda con IA generativa
• Google’s Mueller Calls Markdown-For-Bots Idea ‘A Stupid Idea’ - Cobertura de Search Engine Journal sobre la crítica pública de John Mueller a las páginas Markdown específicas para bots
• Google & Bing don’t recommend separate markdown pages for LLMs - Search Engine Land sobre el debate más amplio del sector, incluidas las preocupaciones sobre sniffing de user-agent y cloaking
• HTTP Content Negotiation (RFC 7231) - Base normativa para la negociación de la cabecera Accept entre cliente y servidor
• text/markdown media type (RFC 7763) - Registro IETF del tipo de medio text/markdown utilizado en la negociación de contenido