For about a year, the AI question in SEO meetings had one answer: GEO. Generative engine optimization. Make sure ChatGPT, Claude, and Google’s AI answers find you, understand you, and cite you. Agencies renamed their SEO packages to include better AI search.
GEO is not wrong. But it’s no longer what will matter the most. Something changed in the past few weeks, and it moves the question for us from “can AI find us” to “can AI use us”.
What changed in September
The launch of Muse (by META), a personal agent that can search retail sites, fill a cart, and check out once you approve, with Walmart, Sephora, and Best Buy among the first retailers. Not only buy, but also compare different products and stores at ease. Three weeks later, OpenAI announced Dots: agents with their own cloud computer that browse the web on your behalf, and that can also buy things, with rules for when they have to ask you first.
The demos are about dinner orders and shopping carts. The mechanism is the same for a quote request, a permit, or an appointment with the city.
Muse is US only. Dots are not available to individual Pro users in the European Economic Area. But the agents will be coming from Europe & Asia soon as well, and the sites they meet do need to adapt.
Being found is the first half (GEO), and it still counts
Being found by AI is the same job as being found by search. Clear content that answers real questions, a logical structure, structured data, authority scores, and a plain-text summary of what you do. This way a model can read without guessing. If you have done SEO properly, GEO is mostly a small touch-up.
GEO matters even more now, not less. An agent that cannot find your opening hours, your pricings, address or your conditions will not get far with the task it was sent to do.
AI Usability is the new kid in town
Here is a comparison we find useful. Search engines taught us findability: SEO. Accessibility standards taught us usability for people who do not browse with eyes and a mouse: WCAG. AI is now asking both questions at once, so is it actually a new kid in town?
The point got sharp for us at an AI conference in Ghent. One talk made a simple case: we are heading toward a personal assistant for everyone. Not a chatbot you visit, but an agent that works for you. “Book me a table.” “File the report.” “Find out whether this street floods and, if it does, tell the city.” Muse and Dots are the first versions of making that assistant mainstream (we had Clawdbot/OpenClaw before).
The things that stop an agent are ordinary:
- Content that only appears after JavaScript runs, so a plain read of the page shows nothing.
- Forms with fields that have no readable labels
- Errors that are only a red outline
- Steps that exist only visually
- Logins, because even the newest agents hand sign-in back to you, and in Belgium that means eID and itsme flows, which need your card or your phone, not an agent’s
- CAPTCHAs can currently be bypassed by AI agents but needs monitoring
- Procedures and terms that live only in a PDF
- Consent walls that cover the content before anything else loads.
None of this is new technology, none of this hurts your ranking or your citations. But it stops an agent from completing its task. A site can be quoted by every AI tool on the market and still turn down the assistant that was there to buy something. Search Engine Journal put it plainly this week too: when an agent compares ten stores, it can only buy from the ones it can interact with. Ranking got you into the top ten.
Amazon, for what it is worth, chose to block Muse rather than let it shop, saying the agent did not identify itself and appeared to store customer credentials.
The WCAG parallel
A lot of websites still do not comply. Unfortunately we think that websites will actually start to care now, when AI agents need it as well. We hope it is a win-win for people with disabilities.
Readable labels, clear errors instructions, logical order, no steps that exist only on screen: that is what WCAG has asked of websites for years. Most browsing agents read the same page structure a screen reader does, the accessibility tree. The ones that work from screenshots instead still depend on visible labels and clear state.
The sobering part is that the web is getting worse at this, not better. WebAIM’s 2026 scan of the top million homepages found detectable WCAG failures on 95.9% of them. That is good news for anyone who has already done the accessibility work. Public organizations have been held to WCAG for a while. Since June 28, 2025, the European Accessibility Act applies the same standard to e-commerce, banking, passenger transport, telecom, and a few other sectors. If your site meets it, the agent benefits for free.
We do want to make one thing very clear: Accessibility for people is a right and a legal duty. Accessibility for agents is a commercial choice. We build to WCAG because people need it; that agents profit from the same work is a welcome side effect, not the reason.
What the agent actually sees
Meta has described already how Muse reads a page. The part of Muse that drives the browser sees an accessibility tree snapshot, not the raw page, and it cannot run JavaScript inside the page. The same structure a screen reader uses: headings, links, buttons, and fields, each with a name and a state. What is not in the tree does not exist for this visitor.
Three things follow:
- Script blocks are not in the tree, so your structured data is invisible to the agent that came to buy: keep the JSON-LD for Google and the citation layer, and put the same facts in visible text.
- A markdown version of your site or an llms.txt file serves the reading layer and does nothing for the buying one, because they strip out the buttons and forms the agent came for
- State has to live in the tree, not only in your CSS -> Search Engine Journal’s own test makes this clear: a large store showed sizes as sold out through styling, while the accessibility tree listed all “Select size” buttons. The agent would pick a size that is not available and stops or moves somewhere else.
This is Meta’s description of Muse. OpenAI has not said how Dots read a page, although its Atlas browser uses ARIA roles and labels, and the computer-use model behind Operator works from screenshots. So build for all: a complete tree, and visible labels and state on screen.
Invisible agents in your web analytics
An agent can reach your business in two ways. Through a connector, if you have one: Like Muse with access to the entire Shopify catalog, and Dots connect to over 4,000 apps. Or, for everyone else, through a real Chromium browser on a cloud machine that behaves like a person. There are more of those machines than you think: Early June, Cloudflare counted more HTML requests from bots than from people, 57.2 percent. (Most of those are crawlers rather than agents, but it’s increasing)
In the connector case the checkout happens directly inside the AI app; Shopify confirms that the checkout never loads your pages, so your analytics and pixels never fire and the order appears only in your back office. In the browser case there is nothing to recognize: neither Meta nor OpenAI publishes a user agent, referrer, or IP range for these browsers, so there is no name to put in robots.txt and nothing to filter in analytics by default.
So nobody can measure browser-tier agent revenue today (October 2026). The Information reports that more than 3 million people prompt Muse at least once a week; that counts prompts, not visits to your site.
One important note: Shopify’s “Agentic” sales channel is on by default and already shares your products with Meta through Shopify Catalog.
How to test this? Easy!
Pick a few things a client or citizen comes to your site to do. Hand each one to an AI agent that can browse. Watch how it goes and where it stops.
That is the whole audit. The output is a short list of blockers in order of damage, and most of them are fixable in the normal course of building and maintaining a site.
We ran it on our own site before writing this. Find out what we do with AI, ask us for a quote, find the Brussels office and its hours. The agent got through all three. It also showed us two things we had not looked at: the service page keeps its content in a place a reader does not expect, and our contact form sits behind a bot check that exists to stop exactly the kind of visitor we are writing about. Both are on the list now. That is what the test is for.
This control used to live in robots.txt, a file you control; it now lives in your bot protection, usually someone else’s system, where a rule written for scrapers may be blocking your customers’ agents today.
How to prepare?
For us it feels kind of the same as GEO & SEO. If your SEO is done right, GEO is automatically also improving. Same here in terms of accessibility. Build accessibility for people and agents will access it easier too. A form with proper labels, readable errors, and a logical order is better for a screen reader, better for a tired person on a phone, and better for an agent.
That is the direction we think this goes: not a special chatbot per website, but websites and services that an assistant can simply use.
