Online search used to end with a list of links you’d manually choose between. Now, it often ends with an answer. And (increasingly) with an agent that completes the task.

Alongside the wider use of assistants like ChatGPT and growing confidence in Google AI Overviews and AI Mode results, we’re also starting to see a more delegative form of online interaction.

We are transitioning from a web where humans browse pages and click buttons to a system where automated software agents perform these tasks.

Browser agents such as agent mode in ChatGPT, Auto Browse in Gemini in Chrome, and Perplexity’s Comet do more than summarise text. They open pages, fill in forms, and click through multi-step journeys for a user, going as far as booking travel, buying products, or comparing services.

This raises a question every brand should now ask: is your website ready for AI agents? If not, your business may quietly drop off the shortlists agents show human buyers.

Human and machine interfaces

To a human, a website is a visual presentation with specific layouts, fonts, and colours. To an AI agent, a website is a functional interface. Agentic readiness means that the code of a website is structured so that an automated tool can understand the context, navigate the layout, and complete actions without human assistance.

Google recently introduced agent-oriented checks into its developer tooling. In May 2026, Lighthouse 13.3, which is the auditing tool built into Chrome DevTools, added an experimental Agentic Browsing category.

This tool doesn’t evaluate websites for classic search ranking signals. Instead, it runs functional infrastructure tests to determine whether an automated browser can understand and operate the page. One check looks for an llms.txt file in the root directory, a machine-readable summary that explains what the website does. While a useful signal, it’s not a fix. The format is still an emerging convention and no substitute for HTML an agent can operate.

It also looks for WebMCP, a proposed standard that lets a site expose its forms and actions so an agent can submit them directly. It checks if the accessibility tree is well-formed and measures layout stability to ensure elements do not shift during loading, which can cause an agent to select the wrong button.

If a site fails to meet these standards, an agent may abandon the task and move to a competitor site it can parse and complete. Weak infrastructure doesn’t show up as a visible ranking drop, but as quiet exclusion.

How the accessibility tree enables machine navigation

Building an agent-ready site requires technical work, but at its core it uses something most sites already have: the accessibility tree. Agents can read a page in three ways:

  • Raw code in the Document Object Model (DOM)
  • Screenshots
  • The accessibility tree.

Full visual reasoning is slow and costly, and raw markup is noisy, so many agents lean on the tree as a fast structural model.

Google’s Lighthouse documentation goes further and describes the tree as agents’ primary data model. As such, having a clean accessibility tree is some of the highest-leverage readiness work a business can do.

When a browser loads a page, it builds the DOM then derives a simpler structure from it: the accessibility tree. It strips out styles, colours, and layout. What’s left is a map of every meaningful element – its role, accessible name, and current state — built for assistive technologies like screen readers. When an AI agent reads a page, it reads this same map.

An agent uses this structure systematically to complete tasks. If an agent needs to purchase an item, it follows the path defined by the accessibility tree.

Method Positive aspects Negative aspects
Semantic HTML It is naturally accessible, it requires less code, and it is universally supported by browsers and agents. It cannot cover complex custom components, and it is limited to standard default elements.
ARIA attributes It allows developers to make custom elements accessible, and it provides rich descriptions for dynamic states. It is easy to implement incorrectly, and it can conflict with native browser behaviours if used poorly.
Visually hidden text It allows custom descriptions without affecting the visual layout for sighted human users. It can clutter the accessibility tree, and it requires careful style management.

Roles tell an agent what an element is

The agent identifies interactive elements through their assigned roles. If a developer builds a button using generic code and styles it to look like a button, a human user can see it. The element will not have a functional role in the accessibility tree, and the agent will ignore it. Using correct semantic code — a native <button> element rather than a <div> with a click handler — gives it the role “button”, which informs the agent it’s clickable.

Names tell an agent what an element does

The agent needs clear element names, as it can’t reliably interpret a bare icon. If a button only contains an image, the agent can’t identify its purpose.

Visible text, or an attribute such as aria-label=”Search” on an icon-only button, gives the element an accessible and readable name.

States tell an agent what just happened

The agent then monitors changes in state. When an agent interacts with a menu, it checks the tree for state attributes such as aria-expanded to confirm whether the menu opened and which options are now visible.

Any improvements you make for human accessibility also make the site easier for AI agents to read, so you don’t need to rebuild the website or invest in expensive new software.

In our agentic readiness work, the practical path is still standard accessibility hygiene: semantic tags, working form labels, honest roles and states, and a clear accessibility tree. Many agents rely on the same tree that supports assistive technologies, so businesses achieve two goals.

First, they create an inclusive website for visually impaired human users. Second, they ensure their digital services are accessible to automated agents increasingly used for research, shortlisting, and multi-step preparation before a human-confirmed purchase.

The immediate agentic impact

Travel brands and ecommerce businesses may feel agentic delegation first through itinerary research, price tracking, and product comparison before fully autonomous checkout becomes common.

It’s unlikely that consumers will immediately grant full autonomy to machines for final purchases, as people still prefer to maintain control over financial transactions.

Users will regularly delegate preparatory tasks such as researching hotel options, tracking product prices over time, and comparing service features.

Those initial automated searches help determine which brands the final human buyer sees. For travel and ecommerce brands, agentic readiness keeps you present for the selection process.

Getting considered vs getting the task done

Agentic readiness has two layers for travel and ecommerce brands. The first gets you considered by ensuring your product data is agent-ready with clean feeds and structured data. This puts your products and prices in front of the systems doing the research.

The second layer gets the task done. Once an agent lands on your site, it needs to find the right button, read the correct label, and confirm that a menu opened or a basket updated. That’s runtime operability (roles, names, and states in the accessibility tree), and structured data can’t fix a checkout an agent can’t operate.

It also shapes what you can measure. You can track how often AI Mode mentions your brand, but agent journeys only show up in your data if agents can complete them on your site.

Where to start with agentic readiness

Start with commercial journeys that lead to a conversion: search, product selection, basket, and booking or checkout forms. Run Lighthouse’s Agentic Browsing audit on each, then walk the same steps with a screen reader.

To check what an agent sees, turn on the full-page accessibility tree view in the Elements panel of Chrome DevTools. Alternatively, capture a snapshot with Playwright’s ariaSnapshot() in a test script. A thin or unlabelled checkout step will appear the same to an agent.

An agent may give up on any unlabelled icon, fake button, or menu that doesn’t announce its state, so fix those first. This improves the site for people using assistive technology and makes it easier for agents to complete journeys.

Find out where agents get stuck on your site

Ensure your site is agent-ready and see where they get stuck with an expert audit from our technical SEO team. We can review your most valuable journeys – search, product pages, basket, and booking – how an agent reads them and provide your developers with a prioritised fix list.

Get in touch to discuss your site and see how it currently holds up.