Your site has a second front door now: pages and APIs

Rebuilding a website this year means deciding, line by line, what a person reads on a page and what a machine asks your site for. Google's chief executive said this month that AI agents will reach websites two ways — by browsing pages roughly the way you do, and through protocols built for them — and that while protocols will ultimately scale better, browser-based agents are not going away. The first door has been in every rebuild quote you have ever been sent. The second is not — and that gap is the difference between a site an agent can read and one it can act on.

The two-door statement, on the record

On October 22, Search Engine Journal reported comments Sundar Pichai made in an interview with Alex Heath of the Sources podcast. Pichai said he expects two methods for how AI agents access website content: one similar to how humans browse the internet, and one through protocols specifically created for agents. He expects both to grow, believes protocols will ultimately scale much better, and noted they will take longer to develop.

He was candid about the transition. He called it "a complex moment," predicted "a chaotic evolution there" before things settle toward "more interoperable standards," and defended the browsing route as "a very elegant way to work too, because that's what you as a user would do," because it keeps a person in the loop.

Read that as a buyer, not an observer. A search company is telling you the traffic reaching your site in three years will include software that reads pages the way a person does, and software that calls your site the way one system calls another. Only one of them is looking for a page.

Cloudflare already shipped the other door

The same week, Cloudflare published how it turned on agent-ready storefront tooling across roughly 100,000 domains belonging to one commerce platform, using WebMCP — a proposed browser standard from Google that gives AI agents structured tools on a page instead of leaving them to guess at the layout.

"AI can write code and pass the bar exam," the post opens, "but it still struggles to buy a pair of shoes online. That's because websites were built for humans, not agents." Most shopping agents today work from a site's HTML: they look at the page and guess which element does what. WebMCP replaces the guessing with named tools — search products, check details, build a cart, get a checkout link.

Two details belong in a budget conversation. First, Cloudflare notes WebMCP is "still an experimental proposed browser standard in early preview" — you are building toward a direction, not onto a finished platform. Second, the rollout was on by default with a per-merchant opt-out, and Cloudflare proxies the tool definitions so merchants keep control of their own logic. The merchant quoted gave the reason: they want their store in the answer, to keep the customer, to control the checkout — "without rebuilding their site."

That last clause is why this is a scope question, not a trend piece: the industry is pushing this work toward your existing site rather than asking you to stand up a parallel one. So it lands on your next rebuild, whether or not the proposal names it.

Why the two doors cost differently

Making a page readable to an agent is ordinary, well-understood web work: clear HTML text instead of text baked into images, headings that describe structure, specifications in a table a machine can parse, page speed, internal links. If your team has shipped a competent site in the last five years, the first door is mostly already open.

Making a site actionable is a different product. It introduces a surface with permissions, failure states, and consequences: an agent can attempt something, and be wrong. That is not a plug-in you switch on at launch. It is a small application with its own authorization rules, limits, audit trail, and an owner. No amount of on-page optimization produces it, and it is the line item no website quote has historically contained.

The inventory: what survives the trip

Before you price anything, take an inventory. For each element of your site, ask what a person gets from it, what a machine needs to get the same thing, and what happens if a machine gets it wrong.

The pattern is worth internalizing: facts are safe to expose, actions need a decision. Most fear about agents sits on the catalog when it belongs on the transaction.

The teardown: our own page, in public

Frameworks are cheap. Here is the method, run on a page anyone can open: our own web design and development service page. View source, find the structured data, inventory what survives.

The structured layer declares the organization and its contact points, the services offered, and the offers attached to them as real machine-readable entities. Breadcrumbs, addresses, and the catalog of services are all legible without rendering a pixel. That half travels well: it is the result of deciding years ago that a service is an entity with a name and a scope, not a paragraph.

Now the other half. The page's conversion action is not on the page at all — it is a link to a contact route one click away. An agent reading the structured layer can tell you what the service is and who offers it, but it cannot complete the action without following that link and reading a second page. The benefit cards, the parts written to persuade a skeptical owner: those exist as styled text a human reads and a machine flattens. Nothing there is broken. It is simply built for one audience.

That is the whole finding, and the same one you will get on your own site in an afternoon: the facts are already mostly legible, the persuasion is not, and the actions live somewhere else. You do not need a rebuild for the first part. You need a decision about the third.

The five decisions that move the number

If you are taking quotes, these five questions separate a site an agent can read from one it can act on. Vague answers become change orders later.

1. Which content stays human-rendered, on purpose. Positioning, argument, brand voice — anything whose job is to move a person. Decide it explicitly: "we'll figure it out in the build" means someone will try to make your manifesto machine-readable, and you will pay for the privilege.

2. Which facts need a machine-readable equivalent, and who keeps it true. Prices, availability, specifications, eligibility, scope. Building them is cheap; maintenance is the real number. If nobody owns keeping the structured version true, it will lie within a quarter — and a stale fact quoted by an agent costs you the buyer who checked.

3. Which actions you expose, and which you refuse in writing. Reading a catalog is cheap; booking, quoting and cart-building are decisions with limits. Bulk export, account changes, and anything that spends money or commits you contractually should be refused deliberately, not discovered as a gap.

4. Who owns the failure when an agent completes the wrong action. The question nobody asks and everybody inherits. If an agent books the wrong slot, holds the wrong inventory, or quotes a price nobody approved, there must be an answer before launch: what is reversible, what needs a human checkpoint, who may reverse it. We covered this boundary from the operations side in what an agent should be allowed to change on your booking system; the build-side version is deciding it in the contract, not in the incident.

5. How the second door changes the estimate — and the retainer. Ask directly: is the machine-readable layer and its actions inside this number, or are they a phase two? Both answers are legitimate. A quote that never mentions them isn't cheaper — it's unfinished, and you'll be comparing it against quotes that did.

What this is not

It is not a reason to rebuild early — if your site is two years old and readable, the page door is open and agents can already find your facts. It is not a reason to fear agents, either: the rollout Cloudflare describes shipped with a per-merchant opt-out, and refusing is a legitimate choice you should make on purpose.

It is a reason to make sure the question gets asked in the room where scope is set. Every rebuild already budgets for the door people walk through. The one software walks through is now a line you can name, price, and decide on. A proposal that has never mentioned it hasn't been thorough. It's been quiet.

That is the conversation we have before any rebuild: which facts travel, which actions you expose, who owns the failure, and what it costs to keep the machine-readable half true. It is part of how we scope web design and development, and it is cheaper before the quote than after the launch. When the second door needs product rather than pages — an action surface, an internal tool, a defined integration — that is custom software.

The reading half is already covered on this site: why a crawler can fetch you and still never cite you, and what an agent-driven checkout already demands of a storefront. The second door is new. The discipline for opening it is not.