If Humans Are a Rounding Error, Who Is Your Website For?

A single firmware download page on a platform I work with exists at thirteen different locale URLs. Same file, same product, thirteen addresses. That’s not a defect — it’s the correct output of a localization strategy built for humans, where a UK visitor should land on UK-scoped content and a Finnish visitor shouldn’t get American English.

Now watch what happens when the visitor is a model. Someone asks an assistant “what firmware is available for this instrument in the UK?” The model scrapes whichever locale URL it happened to index. It has no way to know the other twelve exist. It cannot distinguish a genuinely missing localization from one it simply failed to find. And it answers confidently anyway.

That last part is the problem. The failure isn’t a 404 — it’s a fluent, plausible, wrong answer with no signal that anything was missed. The information architecture is doing exactly what it was designed to do, and the result is that machines misrepresent us. Across a catalog spanning more than fifty locales, that isn’t an edge case. It’s the default.

The rounding error

On Cloudflare’s Q2 earnings call yesterday, CFO Thomas Seifert put a number on the trend:

In five years, non-human traffic will be as much as 1,000 times as much as human traffic. Humans will be a rounding error on the internet.

Not because human traffic is falling — it isn’t — but because machine traffic is growing so much faster that the ratio stops mattering.

Worth noting the company had previously forecast the crossover at 2027 and was wrong; their own measurements put it in May 2026. The direction was right, the timeline conservative. Seifert said as much himself on the call: “I have called it wrong at every point along the way.” That is a more honest framing than most forecasts get, and it’s the right way to hold this one — as a direction, not a date.

But volume isn’t really the argument, and I want to be careful not to overclaim it. A thousand bot requests for every human doesn’t prove bots deserve a better interface. It might just prove you need caching and rate limiting — which is, not coincidentally, what Cloudflare sells.

The argument is that the bug was always there. Humans landing on the wrong locale page got the same wrong answer, silently, for years. They just didn’t complain in a way that reached anyone who could fix it. I’ve hit the miniature version of this on my own site, where duplicate trailing-slash URLs were quietly splitting a single page’s authority in two — same shape, several orders of magnitude smaller, and equally invisible until something machine-readable went looking. Agents didn’t introduce this failure. They industrialized it, and in doing so made it legible.

What we built, and why it doesn’t help here

We have spent twenty years building web presence for a reader who is becoming statistically irrelevant to how our information actually gets distributed. Deep taxonomies. Faceted navigation. Breadcrumb hierarchies. Hundreds of pages per product line, each translated into dozens of locales, each designed, reviewed, and governed by a workflow that assumes a human will eventually land on it and scroll.

Most of that structure exists to help a person find something. Information architecture is a wayfinding discipline — it compensates for the fact that people can’t hold a catalog in their heads.

Machines don’t have that problem. An agent gets nothing from a breadcrumb trail, nothing from a curated landing page, and nothing from the fifth locale variant of a datasheet that could have been one record with a language field. What it needs is the underlying fact — this product, this spec, this firmware version, this availability — retrievable in one call, structured, current, and attributable.

And you can’t close the gap with better markup. Schema.org, an llms.txt, cleaner headings — those make an individual page more legible. They do nothing about the fact that the page is one of thirteen and the model can only see one. Bolting structured data onto thirteen duplicate pages is automating the Rube Goldberg machine: the dysfunction runs faster and cleaner, and every part of it survives.

What I intend to build

So that’s the project I’m taking on: not a better site, but a second interface onto the same data. An MCP server that answers product and support questions with explicit locale semantics, sitting alongside the website rather than replacing it.

It’s a design position, not an announcement — it goes through brand and legal review like any other public-facing surface, and the first phase is a go/no-go gate on an assumption about our own data layer that I haven’t verified yet. If that assumption fails, the architecture changes. I’d rather say that plainly than write this as though it’s already running.

But the requirements are clear enough to state now, and I think they generalize past my particular stack:

Locale provenance travels with every response. What was requested, what was actually served, and why: exact match, documented fallback, or default. Including the fallback chain when one was consulted. This is the whole game. A model handed a silently-substituted result will assert that Canadian French content exists. A model told explicitly that it received a fallback can say “there is no fr-ca version; here’s the fr-fr one.” Silent substitution is the bug. Any design that preserves it has failed, however clean the API looks.

Unrecognized input fails loudly. An unknown locale returns an error with the valid list — never a quiet fall back to US English, which reintroduces exactly the failure the whole thing exists to prevent. This sounds obvious and is the easiest thing to get wrong under deadline pressure, because silent fallback always looks like it’s working.

Absence is expressible. “Not published in this locale” is a different fact from “I couldn’t find it,” and the data layer has to be able to say the first one. Most retrieval APIs can only ever say the second, which is precisely why models fill the gap with confident invention.

One logic layer, however many transports. Whatever answers the agent should be the same code that answers the website and any on-site assistant. Otherwise the public answer and the owned answer drift, and you’ve relocated your content governance problem rather than solved it.

It’s read-only, and it’s boring on purpose. No session state, no write path, no clever inference. Every response is a function of its arguments. A public data interface should be the least interesting component you own.

None of that is exotic. It’s a different center of gravity: the record is canonical, the page is a rendering of it.

The argument that actually travels

“Agents are coming, adapt” is not a business case. It’s a forecast, and I just spent several paragraphs explaining why I don’t fully trust forecasts. The version that survives a budget conversation is about cost structure, and it doesn’t depend on the traffic prediction at all.

Pages and locales multiply. Every page in every locale is a discrete artifact — authored, translated, reviewed, approved, published, governed, and eventually retired. Add a locale and you don’t add one thing, you add one thing per page. Add a product line and you add one page per locale. The unit of work is a cell in an M × N grid, and both M and N only ever grow.

A record with locale fields adds instead. One canonical record per product, with a language field and a publication status per locale. Adding a locale becomes a data operation. The content still has to exist — nobody is translating less — but the grid stops being the unit of review, which is where the cost actually accumulates.

And the cost that hurts most isn’t authoring, it’s drift. When a spec changes, someone has to find and correct every artifact asserting the old value. Miss one and you haven’t just left a stale page — you’ve produced exactly the failure this post is about: a fluent, confident, wrong answer, now with your name on it. The maintenance burden and the correctness bug are the same problem viewed from two directions. That’s why the economics argument and the agent argument converge, and why the first one lands with people who don’t care about the second.

There’s also a return nobody asks for. If the record knows which locales actually publish a given asset, then “which locales are missing this datasheet?” stops being a research project and becomes a query. Externally that’s provenance for a model. Internally it’s a content-gap audit across fifty-plus locales that I have never once been able to run. I suspect it’s the larger of the two returns, and it arrives first — before a single agent calls anything.

The strongest case against

Traffic volume is not value. If humans become one request in a thousand, that one request is still where the revenue is — most agents work on behalf of those humans, and the ones that don’t may be worth blocking rather than serving. Building for machine volume as such is a category error.

There’s also a sequencing risk I take seriously. MCP is young, enterprise patterns are still forming, and betting a content operation on conventions that haven’t settled is how you rebuild twice. That’s why the verification gate comes before the code, and why this starts as one read-only surface rather than a replatform. Every yes forecloses something else, and a replatform bet on unsettled conventions forecloses a lot.

But the counterargument doesn’t reach the locale problem, and that’s why I keep coming back to it. Silent fallback was wrong when only humans saw it. Making the data layer say what it actually knows is correct regardless of who’s asking.

---

Related Reading

• I Ran an AI-Powered SEO Audit on My Site. It Was Invisible to Google. — The small version of the same bug: URL structure quietly misrepresenting a site to machines.
• Don’t Automate the Rube Goldberg Machine — Eliminate before you automate. Better markup on a broken IA is the counterexample.
• The Cost of Every Yes — Why this starts as one read-only surface instead of a replatform.
• Two Letters, Two Eras — The longer arc: what changed between building pages for people and building records for machines.
• Verification Is the Bottleneck — The same fluent-confident-wrong failure, viewed as a constraint problem: what it costs to know when a machine is wrong.