Websites built for agentic browsing
Agents now browse on people's behalf. Olivia on the build details that decide whether one can read and act on your site: the accessibility tree, low CLS, llms.txt and WebMCP.
What agentic browsing actually asks of a website
For most of the web's life, the visitor was a person and, occasionally, a crawler indexing pages for later. Agentic browsing adds a third kind of visitor: software acting on someone's behalf, opening your site to complete a task rather than to read it. It might be an assistant pulling a fact to answer a question, or an agent stepping through a booking, a quote request or a comparison. The important shift is that this visitor does not look at your page. It parses a representation of it, decides what the elements are, and acts. Everything that a human eye resolves from context, that this bold text is a heading, that this coloured box is the primary action, that this is a price and not a phone number, the agent has to get from your markup or it does not get it at all. That is the whole design problem in one sentence. A site built to look right on a screen leaves its meaning to be inferred from styling, and a person fills those gaps effortlessly. A machine cannot. So building for agentic browsing is not a new aesthetic or a plugin you switch on. It is the discipline of making the structure carry the meaning, so that the same page serves a reader, a crawler and an agent without any of them having to guess. Done well it is invisible to your human visitors and decisive for the machine ones.
The accessibility tree is the page an agent reads
When an assistant or agent reads your page, it does not work from the pixels. It works from the accessibility tree: the structured model the browser builds from your HTML, describing every region, role, name and control. This is the same tree a screen reader uses, which is why accessibility and agentic readiness are, in practice, the same engineering. If a button is really a styled div with no role, the tree does not know it is a button. If your headings skip from H1 to H4 because that looked right, the tree reports a broken outline. If an input has no associated label, the agent sees a field it cannot name. The machine is not being obtuse; it is reading exactly what you shipped. So the first job in building for agents is to make that tree accurate. Meaningful elements, correct heading order, real labels on every control, roles and names intact, landmarks that name each region of the page. None of it shows on screen, and all of it is what lets a machine parse your page without reverse-engineering your CSS. This is the part cheap template builds are silent on, because the template was drawn for appearance and the semantic layer was never the point. It is also the part that is genuinely hard to retrofit onto a heavy build, which is why we settle the structure and the accessibility tree first, before the visible design is locked, and treat the tree as a first-class output of the work rather than a happy accident of it.
Why low CLS matters more when a machine is clicking
Cumulative Layout Shift measures how much your content jumps around as the page settles. For a human it is an irritation: you go to tap a link and an ad loads above it, so you tap the wrong thing. For an agent it can be the difference between completing a task and failing it. An agent reads the page, decides on a target, and acts on it. If the layout is still shifting, a late-loading banner pushing the form down, a web font reflowing a paragraph, an image with no reserved space snapping into place, the target the agent chose may no longer be where it was when the decision was made. The click lands on the wrong element, or on nothing. The fix is the same one that serves human visitors and Core Web Vitals, which is the useful part: reserve space for images and embeds with explicit dimensions, avoid injecting content above what is already rendered, load fonts so they do not reflow the page, and keep the layout stable from first paint. A site that holds still is one an agent can act on reliably, and it is also, not coincidentally, a fast, well-built site that passes its vitals. You are not paying for a separate piece of agent-proofing here. You are being rewarded twice for building the page properly the first time.
llms.txt and a machine-readable content layer
Assistants that answer from the web have to find the substance of your site quickly and cleanly, and most sites make that harder than it needs to be by burying the content in interface. An llms.txt manifest is a simple, emerging convention: a plain file that points to the pages and content that actually matter, in a form a model can read without wading through navigation, cookie prompts and decoration. It is not a magic ranking signal and we would not sell it as one. It is a courtesy that makes your site legible, in the same spirit as a sitemap, and it costs little to ship and keep current. The manifest is only worth as much as the content behind it, though, which is where rendering matters. If the substance of a page only appears after heavy client-side JavaScript has run, an assistant or agent may never see it, because it read the markup that arrived and moved on. Building for agents means the meaning is present in the delivered HTML, cleanly rendered and crawlable, not assembled in the browser after the fact. That is a build decision made early, and it is one more reason the machine-readable layer has to be designed in rather than bolted on: you cannot manifest content that was never legibly there.
WebMCP-ready: designing for agents that act, not just read
Reading is the near-term reality; acting is the direction of travel. WebMCP is an early proposal for letting a website expose its own actions to an agent in a structured way, so that instead of an agent guessing which button submits a form, the site declares the tools it offers and how to use them. It is genuinely early, standards are still moving, and we will not pretend it is a channel with traffic behind it today. What we can say is that being ready for it is not speculative work, because the groundwork is identical to the work that makes a site accessible and testable now: clearly named actions, controls that mean what they say, stable and predictable interaction, and a clean separation between what a control is and how it looks. So we do not build against a spec that may still change. We build the substrate it will rest on. A page where every action is a real, labelled, single-purpose control, where the flow is legible and the state is honest, is a page an agent can already navigate more reliably, and it is the page that adopts WebMCP cheaply if and when it settles. This is the honest version of future-proofing: not betting the build on a young standard, but making the structural choices that pay off immediately in accessibility and quality and leave the door open. If the standard arrives, you are ready. If it changes shape, you have lost nothing, because everything you did was worth doing on its own terms.
Using Lighthouse as an agentic-readiness check
There is no single score for how well an agent can use your site, and you should be wary of anyone who offers you one. What you do have is Lighthouse, built into Chrome, and it happens to audit most of the faults that break an agent. Its accessibility checks flag the unlabelled controls, the broken heading order, the missing roles and names, the elements the tree cannot resolve, which is precisely the map an agent reads. Its performance checks surface Cumulative Layout Shift and the loading behaviour that makes a page move under a machine's cursor. Run it as a first pass and you will catch a large share of what would trip an agent, before you ever reach for anything more specialised. We use it as a floor, not a finish line, and we are careful about the numbers. A clean accessibility audit means the obvious barriers are gone, not that every real assistive-technology or agent journey works, so we still read the rendered tree by hand and walk the key flows the way a machine would. Chasing a perfect headline figure is the wrong instinct; a page can score well and still read badly to a machine in the places that matter. The right use of Lighthouse is diagnostic: it tells you where the structural faults are so you can fix the page, verify it properly, and move on. It is a good, cheap way to see your site the way an agent is about to.
Building it in, not bolting it on
The thread running through all of this is that agentic readiness is not a feature you add to a finished site. It is a property of how the site was built: whether the structure carries the meaning, whether the tree is accurate, whether the layout holds still, whether the content is legibly there in the markup. Each of those is a decision made early and cheaply, or a retrofit made late and expensively onto a build that was never designed for it. That is why we settle the information architecture, the semantic structure and the machine-readable layer before the visible design is locked, and why the person who plans it is the one who writes the markup and verifies it. And we will be straight about what this buys you, because the honest account is more useful than the hyped one. Building for agents does not guarantee that any assistant will cite you or that an agent will choose your site over another; no one can control that, and we will not claim to. What it does is make your site as legible to a machine as it is to a person, which is the foundation every citation, ranking and successful agent journey rests on in the first place. The reassuring part is that none of this is exotic. It is careful, semantic, fast, well-structured web development, the kind that was always the right way to build, now with a second audience that makes the discipline pay.