AI agents are starting to use websites the way people do: clicking buttons, filling in forms, booking appointments and buying things on someone’s behalf. For most businesses that sounds like a new site is needed, but these tools were built on current sites not future one, Google has spent the past year building the tools to make that work.
Your LinkedIn feed will make it sound like every business needs to rebuild for the agentic web. For most Perth businesses, that isn’t the case. Building websites for AI agents is mostly something a well-built site has already done, with some caveats.
Content Overview
What Google built for AI agents
In September 2025, Google released Chrome DevTools MCP, an official tool that gives an AI agent a live view of a real Chrome browser. The agent can inspect a page, read its console errors and measure how fast it loads. It clicks through the site the same way a developer does in DevTools, rather than guessing from the code. Google has since matured this into a release and ships updates almost weekly.
At Google I/O in May 2026, the company built its whole keynote around what it calls the agentic web. It means people hand tasks to AI agents that go off and use websites for them. Alongside the developer tooling, Google showed a Gemini agent inside Chrome that can browse and act on your behalf. All of it runs through Chrome, the browser most of your customers already use.
Chrome DevTools MCP is the developer’s side. It gives a coding agent the diagnostics a developer relies on while building and testing a site. For visitors, the Gemini agent in Chrome does the clicking once the site is live. Google is building the agentic web from both ends, but only the build side changes how your own site gets made.
How AI agents read your website
An agent doesn’t look at your website the way you do. It doesn’t see colours, spacing or the hero image you spent a fortnight choosing. It reads the accessibility tree, the stripped-back map of the page that browsers already build for screen readers. That map lists what each element is and what it does: this is a button, this is a link, this one submits the form.
Google’s own guidance for developers confirms that “the best way to build for agents is to build for accessibility”. If your site works well with a screen reader, it will work well with an agent, because they’re reading the same underlying structure. Imagine talking to someone and telling them in simple terms what you’re seeing on the website over the phone, that’s what agents see.
Good user experience and accessibility does more heavy lifting here than any agent-specific feature. If your site is easy to use with a screen reader like VoiceOver or NVDA, an agent will usually cope with it too. Get the foundations right and you’ve covered most of what an agent needs.
Web page beside its accessibility tree of labelled elements an AI agent reads.
Building websites for AI agents
Most of what an agent needs is plain good web building. Use real HTML buttons and links rather than dressed-up div tags. Label every form field clearly. Keep a logical heading structure. Hold the layout steady so things don’t jump around as the page loads. Serve the important content from the server so it is present before any JavaScript runs. Only some agents run scripts today, so anything that appears later can be invisible to the rest.
None of that is new. It’s the same checklist any good developer follows to make a site fast, accessible and easy for Google to crawl. A well-built website already ticks these boxes, which is why a solid site needs far less agent-proofing. If a developer built your site in the last few years to modern standards and you have no extravagant features or forms, you’re likely fine.
It also overlaps almost entirely with SEO. The structure that helps a search engine understand your pages is the structure that helps an agent operate them. Build the site properly once and you’re serving humans, search engines and agents with the same work.
WebMCP: alt text, but for your forms
The one new piece is WebMCP. At I/O 2026, Google proposed it as a web standard, developed with Microsoft. It lets a website declare its actions in a way agents can read directly. Instead of leaving an agent to scrape your HTML and guess which button starts a checkout, you name the actions. This button searches stock, this one books an appointment, this one submits a support request etc.
Think of it as alt text for your forms. Alt text works quietly in the background. A screen reader or a search engine uses it to understand a picture they can’t see, while the visible image stays exactly as it was. WebMCP does that job for the actions on your site. It labels a booking form as a booking form, so an agent knows what the form does without scraping your code to work it out.
Picture a checkout built from custom styled div elements instead of real buttons, with the pay step marked only by an icon. A person reads that layout instantly. An agent sees a box it can’t name and either stalls or clicks the wrong thing, which on a checkout is an expensive guess. WebMCP closes the gap by naming the step. A plain contact page has nothing to name, so the labelling only pays off where there are real actions to point at.
WebMCP is early: still a proposal rather than a finished standard, running as an experimental trial in Chrome 149 with Gemini support to follow. Names like Expedia, Shopify and Target are reportedly already testing it on exactly the kind of pages you’d expect: search, checkout, booking. For an online store with several steps between landing and paying, handing an agent a clean, labelled path is worth having.
Does your site need WebMCP yet?
For most small businesses, the answer is no, not yet. If your website is a handful of pages with one clear contact form, a well-built site already gives an agent everything it needs. Pouring money into agent-specific features would be solving a problem you don’t have, so spend it on the things that would help you today.
The picture changes when your site has several different jobs to do, each giving an agent more than one path to handle:
- an online store with a cart and checkout
- a clinic or trade business with online bookings
- a property or jobs site with search and filtering
- a customer login portal
Once there’s more than a couple of distinct actions a visitor might complete, labelling them could be important. That’s a roadmap item, something to plan for as the site grows.
It’s the same instinct behind optimising for AI search: meet the machines where they’re heading. But only where that lines up with how customers already use your site.
Few actions, build well; several actions like checkout, label them for agents.
What to do now: build well first, add agent tooling later
None of this changes the basic advice. Build your website properly, with clean structure, real buttons, labelled forms, and fast, stable pages that work for everyone, including someone using a screen reader. That covers the vast majority of what AI agents need, and it pays off in accessibility and search at the same time. Treat the agent-specific tooling as a finishing layer you add when your site has enough moving parts to justify it.
If you’re not sure which camp your site falls into, we’re happy to look at how your site is built and tell you what we’d do.
Have a chat with the team and we’ll give you an honest read.
Tom Porter
Studio Lead
