GEO vs ARO: que la IA te lea no es lo mismo que la IA te use

GEO optimiza tu contenido para ser leído. ARO expone lo que tu negocio sabe hacer para que lo usen. GEO es una capa de solo lectura y sin estado: el resultado final es un documento. ARO es de lectura y escritura, con estado y con consecuencias: el resultado final es un punto de acceso que hace algo, como reservar una habitación o agendar un turno.

La diferencia importa porque los asistentes de IA ya no solo responden preguntas: empiezan a actuar en nombre de las personas. Que ChatGPT o Gemini sepan que tu hotel existe y cuánto cuesta es GEO. Que un agente pueda reservarlo sin que un humano llene el formulario es ARO. Lo primero te da visibilidad. Lo segundo, si sale mal, te da una reserva duplicada o un cobro equivocado.

Puntos clave

• +GEO hace que la IA entienda y cite tu web. ARO hace que un agente pueda ejecutar una acción en tu negocio. Uno publica documentos; el otro, herramientas.
• +«ARO» todavía no es un estándar: es una etiqueta propuesta el 30-09-2026 para hablar de «agentes que actúan». Lo que sí existe son los protocolos sobre los que se construye: MCP, OAuth 2.1, WebMCP (en borrador) y los protocolos de pago para agentes.
• +Un error de GEO te cuesta visibilidad. Un error de ARO puede costar una reserva duplicada, un cobro mal hecho o una acción que nadie autorizó. Por eso ARO es ingeniería de backend y seguridad, no SEO técnico.
• +El orden importa: primero GEO, porque un agente no puede usar lo que no encuentra ni entiende. Después, una sola acción de solo lectura. Recién al final, acciones que escriben, con confirmación.
• +Ningún negocio necesita «hacer ARO» mañana. Sí conviene ordenar hoy lo que lo hace posible: una sola agenda o un solo stock en vivo, datos limpios y reglas de negocio escritas.

Primero, una aclaración sobre el nombre

Si buscás «ARO», no vas a encontrar un estándar. La sigla (Agent-Readiness Optimization) aparece en una propuesta publicada el 30 de septiembre de 2026, el «Website Intelligence Standard 2026», que la define con una pregunta: ¿puede un software recuperar, entender y actuar sobre tu sitio sin que un humano traduzca capturas de pantalla en instrucciones? Otros llaman a lo mismo «agent readiness» (Cloudflare tiene una herramienta con ese nombre) o AAIO, Agentic AI Optimisation, en un trabajo académico de 2025.

En este artículo usamos «ARO» como nombre corto para una idea que sí es real: la diferencia entre que la IA te lea y que la IA te use. El nombre puede cambiar. Los protocolos que hay debajo ya están documentados, y son los que conviene mirar.

GEO vs ARO, lado a lado

GEO: lo que se programa

• +HTML renderizado en el servidor, que no dependa de JavaScript para mostrar el contenido, con una jerarquía semántica limpia (un H1, secciones claras, listas y tablas de verdad).
• +Datos estructurados en JSON-LD con Schema.org: Organization, Product, LocalBusiness, FAQPage y el tipo que corresponda a tu rubro.
• +Un robots.txt que deje entrar a los rastreadores de IA que te interesan, sitemaps al día y, como complemento, un llms.txt o versiones en markdown de las páginas clave.
• +Contenido escrito en fragmentos citables: respuestas directas al principio, datos con fecha y preguntas frecuentes reales.

Todo es estático. Lo que el agente se lleva es un documento que describe tu negocio. Si algo está mal, la consecuencia es que no te entiende o no te cita.

ARO: lo que se programa

• +APIs o servidores MCP con herramientas tipadas: funciones con nombre y parámetros claros, como buscar_disponibilidad o crear_reserva.
• +Esquemas de entrada y salida estrictos, y errores que una máquina pueda leer y corregir: «la fecha tiene que ser futura», no un «algo salió mal».
• +Autenticación y autorización delegadas: el agente actúa en nombre de una persona, con permisos acotados a lo que esa persona aprobó.
• +Idempotencia, confirmaciones, límites de uso y registros de auditoría: que el mismo pedido enviado dos veces no cree dos reservas, que las acciones sensibles se confirmen y que quede constancia de quién hizo qué.
• +Protocolos de comercio para agentes cuando hay un pago de por medio.

Es dinámico. Lo que el agente usa es un punto de acceso que cambia el estado de tu negocio: después de la llamada hay una habitación menos, un turno ocupado o un cobro registrado.

Los protocolos que ya existen

• +MCP (Model Context Protocol): el protocolo abierto con el que un servidor expone herramientas a una aplicación de IA. Cada herramienta declara un esquema de entrada y, opcionalmente, uno de salida, y los errores de ejecución vuelven marcados para que el modelo pueda corregir y reintentar. La especificación pide validar todas las entradas, controlar accesos y limitar la frecuencia de uso, y recomienda confirmar con la persona las operaciones sensibles y registrar el uso de herramientas para auditoría.
• +OAuth 2.1: la base de la autorización de MCP para servidores accesibles por HTTP. El agente recibe un permiso emitido para ese servidor en particular, no tu contraseña.
• +WebMCP: un borrador del grupo comunitario Web Machine Learning del W3C para que una página exponga funciones de JavaScript como herramientas que un asistente del navegador puede llamar. Es un borrador, no un estándar.
• +Pagos: el Agentic Commerce Protocol (ACP), de código abierto y desarrollado por OpenAI y Stripe, coordina el checkout entre el agente y el comercio sin exponer los datos de la tarjeta. AP2 (Agent Payments Protocol), de Google, usa «mandatos» firmados que prueban qué autorizó la persona.

El ejemplo del hotel

GEO: en la página del hotel hay un bloque JSON-LD del tipo Hotel, con nombre, dirección, servicios y un rango de precio (por ejemplo, "@type": "Hotel", "priceRange": "$$"). Con eso, el agente sabe que el hotel existe, dónde está y en qué franja de precio se mueve. Puede recomendarlo. No puede reservarlo.

ARO: el hotel tiene un servidor MCP en su dominio con dos herramientas. La primera, buscar_disponibilidad(fecha, noches, huéspedes), es de solo lectura y devuelve las habitaciones libres con su precio. La segunda, reservar(fecha, noches, huéspedes, habitación), crea la reserva y devuelve un número de confirmación. El agente llama a la primera, le muestra las opciones a la persona, y cuando esta confirma, llama a la segunda.

La diferencia no es de grado, es de naturaleza. En el primer caso el agente lee un documento. En el segundo hace una operación que bloquea una habitación y, tarde o temprano, mueve plata.

Y en una pyme: un consultorio que ya agenda por WhatsApp

GEO, para un consultorio odontológico: los horarios, los tratamientos, las coberturas que acepta, la dirección y las preguntas frecuentes en HTML visible, con el schema Dentist y una ficha de Google al día. Así, cuando alguien le pregunta a un asistente por un dentista cerca que atienda los sábados, el asistente tiene de dónde sacar la respuesta.

ARO, para el mismo consultorio: una herramienta buscar_turnos_libres(tratamiento, fecha) que lee la agenda real, y otra reservar_turno(...) que escribe en ella después de una confirmación. Si el consultorio ya tiene un chatbot que agenda turnos por WhatsApp conectado a su calendario, tiene resuelta la parte difícil: una sola agenda en vivo, reglas de duración y anticipación, y la derivación a una persona cuando algo no encaja. Exponer eso a un agente externo es otra puerta al mismo backend.

Por qué un error de ARO cuesta mucho más

Un JSON-LD mal armado no rompe nada: el agente entiende menos y te cita menos. Una herramienta de reserva mal armada sí rompe cosas, y lo hace en nombre de un cliente:

• +Reserva duplicada: la red falla, el agente reintenta y, sin idempotencia, el sistema crea dos reservas. La solución es que cada pedido lleve una clave única y que el servidor, si la recibe dos veces, devuelva la reserva que ya creó.
• +Cobro mal hecho: un monto, una moneda o una cantidad mal interpretados. Los protocolos de pago para agentes existen justamente para esto: dejan constancia firmada de qué compra autorizó la persona y no le entregan al agente los datos de la tarjeta.
• +Acción que nadie autorizó: un agente con permisos de más, o uno que obedece instrucciones escondidas en un texto que leyó. Por eso la especificación de MCP trata las descripciones de las herramientas como no confiables si no vienen de un servidor de confianza, y recomienda que una persona pueda negarse a cada llamada.
• +Datos expuestos: una herramienta que devuelve más de lo necesario, como los datos de otros pacientes. Cada respuesta tiene que filtrar por lo que el que pregunta puede ver.

GEO se arregla editando una página. ARO se arregla devolviendo una plata o pidiendo disculpas a un cliente.

Qué conviene hacer hoy, en orden

• +Uno: GEO bien hecho. Un agente no puede usar lo que no encuentra ni entiende. Contenido en HTML, datos estructurados y una ficha de Google completa son la base de todo lo demás.
• +Dos: ordenar el backend. Una sola agenda, un solo stock y un solo listado de precios, en vivo. Si hoy tu disponibilidad vive en un cuaderno, ningún protocolo la va a arreglar.
• +Tres: escribir las reglas de negocio. Duraciones, anticipación mínima, cancelaciones, capacidad, qué casos se derivan a una persona. Son las mismas que necesita un chatbot y las mismas que necesitará un agente.
• +Cuatro: una primera herramienta de solo lectura, como consultar disponibilidad. No cambia nada, y sirve para aprender cómo la usan los agentes.
• +Cinco: recién después, una acción que escriba, con confirmación de la persona, idempotencia, límites de uso y registro de cada llamada.
• +Seis: los pagos, al final, y a través de tu procesador de pagos. Antes de prometer nada, comprobá qué protocolos soporta hoy en tu país.

Lo que todavía no conviene creer

Que «ARO» sea un estándar: hoy es una etiqueta propuesta. Que WebMCP esté listo para producción: es un borrador. Que cualquier asistente ya pueda reservar en cualquier web: depende de cada asistente, de cada protocolo y de cada mercado. Y que una agencia te venda «ARO» llave en mano: lo que hay que construir es una API segura sobre tus sistemas reales, y eso se diseña caso por caso.

En loco22 trabajamos la primera mitad todos los días: webs que la IA puede leer y citar, y chatbots que agendan turnos sobre una agenda real. Si querés saber qué tan lista está tu web para que un agente la lea, y qué haría falta para que la use, escribinos por WhatsApp y lo revisamos con tu caso concreto.