A woman in Abbotsford needs a dentist. She does not open Google.
She opens the assistant on her phone and says: "Book me a cleaning next Tuesday morning, somewhere close to home."
Something then arrives at a dental clinic's website and tries to do that. It is not a person. It is software, sent by a customer, holding her calendar and her preferences.
Right now it will probably fail. It will squint at the booking page, guess which box is the date, pick the wrong one, and give up. The clinic never finds out it happened.
That is the problem Google and Microsoft are trying to fix. And the fix has a name.
What is actually changing on the web right now?
For thirty years, websites had two audiences: people reading them, and search engines crawling them. A third one is arriving. It is software sent by a customer to do something. Book the slot. Request the quote. Check whether you are open Saturday.
Google shipped Gemini in Chrome to Canada on 13 March 2026. What Canadians got was the reading half: summarise this page, explain this, draft that.
The half that presses buttons is called auto browse. Google says it is "currently rolling out in preview in the U.S. for Google AI Pro and Google AI Ultra subscribers". Not Canada. Not yet.
So take the pressure off straight away. Nobody in Abbotsford is losing bookings to this today.
But read what Google says auto browse is for. Scheduling appointments. Filling out forms. And, in Google's own words, "getting quotes for plumbers and electricians."
That is not a tech-industry example. That is a trade.
Microsoft is doing the same thing inside Edge. Its assistant clicks and types on your behalf while you watch each step.
Both of the companies building this see local service businesses as the destination.
What is WebMCP, in plain English?
WebMCP lets a website tell an AI what its buttons do. The AI no longer has to guess. Chrome describes it as "a proposed web standard to help you build and expose structured tools for AI agents". Your booking form stops being a puzzle and becomes a labelled control.
Think of it like a menu in a restaurant. Today an AI walks into the kitchen and tries to work out what everything does. WebMCP hands it a menu at the door.
Chrome puts the difference like this: "Instead of an agent reviewing the element, such as a button or a field, to understand its purpose, the website declares the element's purpose, so it's used correctly."
Four facts are worth holding on to.
It was written jointly by Microsoft and Google, with three named engineers from each. It was first published in August 2025.
It lives in a W3C community group. That is the early stage where ideas get argued over, not the finished-standard stage.
Chrome opened a public trial on 19 May 2026, announced at Google I/O, running from Chrome 149. Before that it sat behind a developer flag.
That date matters. Several articles ranking for this topic still describe the older flag stage and call it Chrome 146.
There are two ways to do it. You can add labels to an ordinary HTML form, or you can write JavaScript. Chrome calls those the declarative and imperative approaches. For most small business sites, labelling the form you already have is the route that will apply.
And Chrome is honest about how early it is: "WebMCP is under active discussion and subject to change in the future."
How does an AI use a website today, and why does it keep failing?
Today an AI operates your site the way a person would, only worse. It looks at the screen, guesses which thing is the date picker, clicks, reads what happened, and tries again. Every guess is a chance to get it wrong.
The failure rate is not a rumour. It has been measured.
Researchers tested leading agents on real, live websites and published the results in a paper called "An Illusion of Progress?". Judged by humans, the best performer finished 61.3% of tasks. The next best managed 56.3%.
On an older, easier lab test the same class of software looked like it scored around 90%. The lab test was flattering it. A basic search-only bot could already pass 51% of that older test without doing anything clever.
The breakdown is the useful part. For the top agent, 57.7% of failures came from filters and sorting. That means picking the wrong option from a list. Another 19.6% were plain navigation mistakes.
Read that again with your own booking page in mind. Filters and sorting is a date picker. It is a "choose your service" dropdown. It is a time-slot grid.
This is why building websites for AI agents means labelling the controls, not restyling them. The people writing the standard describe the same problem. An agent that has to work the screen loses track of what it was doing, and the site owner ends up patching around it.
What is the difference between MCP and WebMCP?
MCP connects an AI to a system in the background. WebMCP works inside the web page the customer is already looking at. WebMCP vs MCP is a question of where the work happens. Behind the scenes, or on the screen in front of the person.
MCP, the Model Context Protocol, is the older idea. A business connects its booking software to an AI through a server. The AI talks to that server directly and never touches the website.
That works well for a large company with a development team and an API to hand. It works badly for a dental clinic whose booking system is a form on a page.
WebMCP puts the labels on the page itself. The customer's own browser, already signed in as them, already showing their history, is where the action happens. Chrome makes a point of this: "Tools execute on your webpage visibly, so users gain trust that tasks are completed as expected."
The two are not rivals. A big retailer will likely use both. A local service business will only ever need the second one.
Where does this sit next to SEO and AI search?
It sits on top, as a fourth stage. It does not replace anything underneath it. A website an AI cannot find is not helped by being easy for an AI to operate.
We use a four-rung ladder for this, and it is worth reading in full on our website redesign guide:
Working
Pages open, forms send, and links go somewhere.
Search-ready
Google can crawl it, index it, and understand it.
AI-search-ready
The answers are specific enough to be quoted.
Agent-ready
The controls are named clearly enough to be operated.
Most local businesses we look at are sitting on rung one or two. Skipping to rung four would be like installing a drive-through window on a restaurant with no sign out front.
The order matters. An AI has to find you before it can do anything for you. Finding you is still search, and Google says its AI features are rooted in core Search ranking.
Our AI search optimisation work is about rung three. This post is about rung four.
If you have searched "agent ready website" and found nothing useful, there is a reason. Almost every page written about it so far was written for developers.
Which buttons should you hand out, and which should you keep?
This is the actual decision, and nobody is writing about it. Handing an AI a "check availability" button is safe and useful. Handing it a "cancel appointment" button, with no confirmation step, is how the wrong appointment gets cancelled.
Switching WebMCP on is the easy part. Deciding what it is allowed to touch is the work.
Chrome flags the same concern in its documentation: "Some actions may be sensitive, such as making a purchase. You can include a command to request user interaction with a confirmation dialog."
We work it out by business type.
Which actions to expose, by business type
| Business type | Safe to hand out | Keep human-only | Why |
|---|---|---|---|
| Dental clinic | Check availability, opening hours, services and prices | Book, reschedule, cancel | A slot held by software is a chair nobody sits in. Let the AI find the time, let the person confirm it |
| Renovation contractor | Service area check, project types, when you are next free | Full quote, price list, calendar hold | A quote button is a price list. Overnight, a rival's AI can pull every number you have |
| Mortgage broker | Rate enquiry start, document checklist, book a callback | Application submit, anything with income or SIN | Once personal financial data enters a form, a human should be the one typing it |
| Veterinary clinic | Check availability, emergency hours, services | Book, cancel, prescription refill | A held slot is a wasted appointment, and a refill is a medical decision, not a button |
| Electrician | Service area check, callout availability, service list | Emergency dispatch, quote | An emergency call sends a van. That decision needs a voice on the phone |
| Online store | Product search, stock check, add to cart | Complete the purchase | Search and cart are low risk. Payment is where you want a human pressing the last button |
The pattern is the same every time. Reading is safe. Doing is where you put a limit.
Drawing that line for a specific booking or quote flow is the job, and it is the part we do as AI automation services work rather than a plugin you switch on.
Anything that takes up your time, spends your money, or gives away your pricing stays behind a person. Anything that answers a question a customer would have phoned to ask can be handed out safely.
The default helps you here. The standard is closed unless you open it. A page exposes only what it declares, and another website cannot reach in and use your tools.
Every exposed action also needs a ceiling. A booking tool with no limit is an open invitation for nine speculative slots to be taken and eight cancelled. That is not a security failure. That is a button being pressed faster than a human ever would.
Is it safe to let an AI use your website?
Yes, and the reason surprises most owners. The AI never receives your customer's password. The customer signs in themselves, in their own browser, exactly as they always have. The AI can only do what that person could already do at that moment.
Sign out, and it loses those abilities.
This is not our claim. It is how the companies building it describe their own products. Microsoft states plainly that its browser assistant "cannot access autofill data, saved passwords, or wallet information". When sensitive details are needed, it asks the person to take over the tab and type them.
Google says the same about auto browse. It "is designed to pause and explicitly ask for your confirmation" before something like a purchase.
A US appeals court has now looked at this too. In August 2026 the Ninth Circuit ruled in a case between Amazon and Perplexity that when a customer directs an AI to act for them, "it was the user who 'accessed' Amazon's computers." Not the AI company.
That is a US ruling, and a narrow one. It decides nothing for a Canadian business. But it points at the right way to think about this. Your customer's AI is your customer.
There is a genuine risk, and it deserves to be named honestly. Security researchers at Brave showed that hidden instructions on a web page can hijack an AI browser. It gets turned against its own user. Their warning is blunt: the AI "operates with the user's full privileges across authenticated sessions."
OpenAI has said this problem is "unlikely to ever be fully solved".
Notice where that risk sits, though. It threatens the person using the AI, not your website. Your exposure is different and simpler. How many times can a stranger's software press your buttons, and which buttons did you leave out?
What should a local business owner do about this now?
Nothing urgent, and that is the honest answer. The button-pressing layer is not in Canada. The standard is still being argued over. Anyone telling you to rebuild your website this month is selling you something.
The people writing the specification agree. An open issue on the standard's own tracker records the W3C's technical group saying it is "too early to port any specific protocol directly to the web platform." That issue is still open.
Statistics Canada found that 19.2% of Canadian businesses used AI in the year to mid-2026. Two years earlier it was 6.1%. Among businesses with one to four staff, the figure was 19.9%.
The smallest businesses are not behind on this. They are level. A one-person shop can get ahead of this as easily as a chain can.
The sensible order goes like this.
First, get rung one right. Pages that open, forms that send, buttons with real names.
Second, write down your list. One page. Which three actions on your site would you happily let a customer's AI do? Which three would you never let it touch?
That list is the whole decision. You can make it today without touching a line of code.
Third, wait. When the trial reaches Canada, the businesses that already know their own list will switch it on in an afternoon. The rest will start the conversation from zero.
I am writing about this before there is any real search demand for it. That is deliberate. I would rather be early and already know how it works than wait until every agency in the Lower Mainland is selling it.
What we have tested ourselves
During our redesign work for Mortgage in Ottawa, I ran the finished build through Google's PageSpeed Insights. The desktop lab snapshot returned 97 Performance, 97 Accessibility, 100 Best Practices and 100 SEO. It also passed 3 of 3 applicable Agentic Browsing checks.
The full screenshot is published on our redesign guide.
Here is the caveat, and it matters more than the numbers. That is a point-in-time desktop lab result from one run. It shows a clean technical baseline. It does not prove rankings, calls, leads, or AI citations. Those need Search Console, analytics and call data, and we do not have them for this yet.
There is no conversion data for agent-ready websites anywhere, from anyone. No business has enough agent traffic to produce any. Any agency quoting you a percentage lift on this today is guessing.
Frequently asked questions
How do I use WebMCP in Chrome?
You need Chrome 149 or later. The site also has to join Google’s public testing program, called the origin trial. Your developer registers the site and adds labels to your forms. The tools then become visible to agents in that browser. It is a developer task, not a settings toggle.
Do I need to rebuild my website for this?
Almost certainly not. The simplest version is labelling forms you already have. Chrome does note that if a site is highly complex, you likely need to refactor or add JavaScript. A booking form or a quote request usually is not.
Will this replace SEO?
No. An AI has to find your business before it can do anything on your site. Finding you is still search. This sits on top of SEO as a fourth stage, not in place of it.
Does an AI agent get my customer’s password?
No. The customer is already signed in, in their own browser. Microsoft’s documentation says its assistant cannot reach saved passwords or wallet information. It asks the person to type sensitive details themselves. The AI inherits the session, never the credentials.
What does it cost to make a website agent ready?
There is no market rate yet, and anyone quoting one is inventing it. The technical work is small. The thinking is the real cost, because deciding which actions to expose and what limits go on them is the actual job. We would rather scope that against your real booking or quote flow than publish a number that means nothing.
Can WordPress, Wix or Shopify sites do this?
Shopify is furthest ahead. It announced its agentic commerce platform in January 2026, connecting stores to ChatGPT, Copilot and Gemini through an open standard it built with Google. WordPress and Wix sites will get there through plugins and platform updates as the standard settles. Nothing about this is limited to one platform.
Free readiness check
Send us your website address.
We will tell you which of the four rungs your site is on, and give you a one-page list of the actions that would be safe to expose when this reaches Canada. That is the whole deliverable. No rebuild, no pressure, and no percentage promises we cannot back.
We build and look after websites for local service businesses across the Lower Mainland. Dental clinics, contractors, brokers and trades. Rung four is the one we test on the sites we build, before we sell it to anyone. See our AI agent development work.