GEO vs ARO: AI reading your website is not the same as AI using it

GEO optimizes your content to be read. ARO exposes what your business can do so it can be used. GEO is a read-only, stateless layer: the end result is a document. ARO is read-write, stateful and has consequences: the end result is an endpoint that does something, like booking a room or scheduling an appointment.

The difference matters because AI assistants no longer just answer questions: they are starting to act on people's behalf. ChatGPT or Gemini knowing that your hotel exists and what it costs is GEO. An agent being able to book it without a human filling out the form is ARO. The first gets you visibility. The second, if it goes wrong, gets you a duplicate booking or a wrong charge.

Key takeaways

• +GEO makes AI understand and cite your website. ARO lets an agent carry out an action in your business. One publishes documents; the other, tools.
• +"ARO" isn't a standard yet: it's a label proposed on September 30, 2026 for "agents that act". What does exist are the protocols underneath it: MCP, OAuth 2.1, WebMCP (in draft) and payment protocols for agents.
• +A GEO mistake costs you visibility. An ARO mistake can cost a duplicate booking, a wrong charge or an action nobody authorized. That's why ARO is backend and security engineering, not technical SEO.
• +Order matters: GEO first, because an agent can't use what it can't find or understand. Then a single read-only action. Only at the end, actions that write, with confirmation.
• +No business needs to "do ARO" tomorrow. It does pay to sort out today what makes it possible: a single live calendar or inventory, clean data and written business rules.

First, a note about the name

If you search for "ARO", you won't find a standard. The acronym (Agent-Readiness Optimization) appears in a proposal published on September 30, 2026, the "Website Intelligence Standard 2026", which defines it with one question: can software retrieve, understand and act on your site without a human translating screenshots into instructions? Others call the same thing "agent readiness" (Cloudflare has a tool by that name) or AAIO, Agentic AI Optimisation, in a 2025 academic paper.

In this article we use "ARO" as shorthand for an idea that is very real: the difference between AI reading you and AI using you. The name may change. The protocols underneath are already documented, and those are what's worth looking at.

GEO vs ARO, side by side

GEO: what you build

• +Server-rendered HTML that doesn't depend on JavaScript to show content, with clean semantic structure (one H1, clear sections, real lists and tables).
• +Structured data in JSON-LD with Schema.org: Organization, Product, LocalBusiness, FAQPage and whichever type fits your industry.
• +A robots.txt that lets in the AI crawlers you care about, up-to-date sitemaps and, as a complement, an llms.txt or markdown versions of key pages.
• +Content written in quotable chunks: direct answers up front, dated facts and real FAQs.

It's all static. What the agent takes away is a document that describes your business. If something is wrong, the consequence is that it doesn't understand you or doesn't cite you.

ARO: what you build

• +APIs or MCP servers with typed tools: functions with clear names and parameters, like search_availability or create_booking.
• +Strict input and output schemas, and errors a machine can read and fix: "the date must be in the future", not "something went wrong".
• +Delegated authentication and authorization: the agent acts on behalf of a person, with permissions limited to what that person approved.
• +Idempotency, confirmations, rate limits and audit logs: the same request sent twice doesn't create two bookings, sensitive actions get confirmed, and there's a record of who did what.
• +Agentic commerce protocols when a payment is involved.

It's dynamic. What the agent uses is an endpoint that changes the state of your business: after the call there's one room fewer, an appointment taken or a charge recorded.

The protocols that already exist

• +MCP (Model Context Protocol): the open protocol a server uses to expose tools to an AI application. Each tool declares an input schema and, optionally, an output schema, and execution errors come back flagged so the model can correct itself and retry. The spec requires validating every input, controlling access and rate-limiting calls, and recommends confirming sensitive operations with the person and logging tool usage for auditing.
• +OAuth 2.1: the basis of MCP authorization for servers reachable over HTTP. The agent receives a permission issued for that specific server, not your password.
• +WebMCP: a draft from the W3C Web Machine Learning Community Group that lets a web page expose JavaScript functions as tools a browser assistant can call. It's a draft, not a standard.
• +Payments: the Agentic Commerce Protocol (ACP), open source and developed by OpenAI and Stripe, coordinates checkout between agent and merchant without exposing card details. AP2 (Agent Payments Protocol), from Google, uses signed "mandates" that prove what the person authorized.

The hotel example

GEO: the hotel's page has a JSON-LD block of type Hotel, with name, address, amenities and a price range (for example, "@type": "Hotel", "priceRange": "$$"). With that, the agent knows the hotel exists, where it is and roughly what it costs. It can recommend it. It can't book it.

ARO: the hotel runs an MCP server on its domain with two tools. The first, search_availability(date, nights, guests), is read-only and returns available rooms with their price. The second, book(date, nights, guests, room), creates the booking and returns a confirmation number. The agent calls the first, shows the options to the person, and when they confirm, calls the second.

The difference isn't one of degree, it's one of kind. In the first case the agent reads a document. In the second it performs an operation that holds a room and, sooner or later, moves money.

And for a small business: a dental office that already books by chat

GEO, for a dental office: hours, treatments, accepted insurance, address and FAQs in visible HTML, with the Dentist schema and a complete Google Business Profile. That way, when someone asks an assistant for a nearby dentist open on Saturdays, the assistant has something to answer with.

ARO, for the same office: a search_open_slots(treatment, date) tool that reads the real calendar, and a book_appointment(...) tool that writes to it after a confirmation. If the office already has a chatbot that books appointments on WhatsApp connected to its calendar, the hard part is done: a single live calendar, rules for duration and lead time, and handoff to a person when something doesn't fit. Exposing that to an outside agent is another door into the same backend.

Why an ARO mistake costs so much more

A badly built JSON-LD block doesn't break anything: the agent understands less and cites you less. A badly built booking tool does break things, and it does so on behalf of a customer:

• +Duplicate booking: the network fails, the agent retries and, without idempotency, the system creates two bookings. The fix is giving each request a unique key, so if the server receives it twice it returns the booking it already created.
• +Wrong charge: an amount, currency or quantity misread. Agentic payment protocols exist precisely for this: they keep a signed record of what purchase the person authorized and never hand the agent the card details.
• +An action nobody authorized: an agent with too many permissions, or one that follows instructions hidden in text it read. That's why the MCP spec treats tool descriptions as untrusted unless they come from a trusted server, and recommends that a person be able to deny each call.
• +Exposed data: a tool that returns more than it should, like other patients' information. Every response has to filter by what the requester is allowed to see.

You fix GEO by editing a page. You fix ARO by issuing a refund or apologizing to a customer.

What to do today, in order

• +One: GEO done right. An agent can't use what it can't find or understand. HTML content, structured data and a complete Google Business Profile are the foundation for everything else.
• +Two: get your backend in order. One calendar, one inventory and one price list, all live. If your availability lives in a notebook today, no protocol will fix it.
• +Three: write down your business rules. Durations, minimum lead time, cancellations, capacity, which cases go to a person. They're the same rules a chatbot needs and the same an agent will need.
• +Four: a first read-only tool, like checking availability. It changes nothing and teaches you how agents use it.
• +Five: only then, an action that writes, with the person's confirmation, idempotency, rate limits and a log of every call.
• +Six: payments last, and through your payment processor. Before promising anything, check which protocols it supports today.

What not to believe yet

That "ARO" is a standard: today it's a proposed label. That WebMCP is production-ready: it's a draft. That any assistant can already book on any website: it depends on each assistant, each protocol and each market. And that an agency can sell you turnkey "ARO": what needs to be built is a secure API on top of your real systems, and that's designed case by case.

At loco22 we work on the first half every day: websites AI can read and cite, and chatbots that book appointments on a real calendar. If you want to know how ready your site is for an agent to read it, and what it would take for one to use it, get in touch and we'll review it with your specific case.