The New Digital Experience Is Machine-Readable

A few years ago we worked on a product where the same fact — a machine is running, at this rate, with this fault pending — had to appear on a web dashboard, a phone in someone’s pocket, a wall-mounted screen on a factory floor and a control panel bolted to the equipment itself. Four consumers. One fact. None of them could be allowed to disagree.

That taught us something before the current wave of AI made it fashionable. Once a fact has more than one consumer, the page stops being the unit of information. You are no longer editing screens. You are maintaining a record, and every screen is one view of it.

The new part is who the second consumer is. It used to be another one of your own surfaces. Increasingly it is somebody else’s system, reading your information on behalf of a person who never sees your site.

Markup is the last layer, not the first

The commodity article on this topic is a tutorial on structured data — the machine-readable labels you add to a page so a search engine knows this number is a price and that one is a rating. Add the code, pick your types, validate, wait for results. It is not wrong. It is aimed at the wrong end of the problem.

Structured data is a transcription. It is the point where information you already hold gets written out in a form a machine can parse. If there is nothing to transcribe — if your opening hours live in three page templates, your price lives in the CMS and also in the checkout and also in a PDF, and your service description is a paragraph rather than a record — then the markup is a hand-typed duplicate of information nobody controls. It will drift, and drift is the failure mode.

Google’s own guidelines treat this as a question of accuracy rather than tagging. The markup must describe what a reader can actually see on the page. It must not misrepresent it. Getting that wrong can cost you eligibility for enhanced results altogether, and Google says plainly that getting it right still guarantees nothing. Read that as an instruction about your sources of truth, not about your tags.

The stack underneath the markup

We find it useful to treat this as seven layers, each only as good as the one below it. The ordering is our judgment, not a standard.

Content model. Are your products, services, locations, people and policies held as records with named fields, or as prose inside page templates? Everything above depends on the answer.

Identity. Does each thing have one canonical name, one canonical address on your site, and a stable link to the records describing it elsewhere — your business listing, your catalogue feed, your industry registries? Machines match up things, not pages.

Structured data. The transcription. Generated from the record, never hand-written page by page.

Distribution. Feeds and direct connections. Google populates its shopping data both from what retailers publish on the web and from product information sent to it directly. Two channels carrying the same catalogue — safe only if both are generated from one source.

Permissions. Below.

Actions. Also below.

Information architecture. How things relate: what belongs to what, what supersedes what, what is current. This is the layer AI-era advice ignores almost entirely, and it decides whether a machine assembling an answer about you assembles a coherent one.

The three layers most businesses skip

Identity, permissions and actions are where the real gaps are, because none of them are visible in a browser.

Permissions became concrete this year. An IETF working group is developing a common vocabulary for stating how your content may be used by automated systems — separating, for instance, permission to train a model on it from permission to search it, each of which you can allow or refuse. It is still a draft, and the mechanism for attaching those preferences to content is being settled in a separate document. But the direction is clear enough to plan around. The humble robots.txt file is becoming a policy surface with legal weight rather than a crawling courtesy, and deciding what you permit is now a business decision somebody has to own.

Actions are stranger. The vocabulary for declaring them — book, reserve, quote, renew, return — has existed since 2014, with a standard way to say what can be done to a thing and how to do it. It has been waiting a decade for the demand. Most businesses still cannot use it, for a mundane reason: they have never written down what their actions are. If booking exists only as a sequence of screens, there is nothing to declare. Exposing actions safely is a separate discipline — our colleagues have written about the API and permissioning side — but the modelling has to happen first, and it happens here.

Most websites still serve humans first

This is the strongest argument against everything above, and it is largely correct. Most sites have one consumer, one channel and information that changes twice a year. For them a rigorous content model is expensive abstraction. We have watched teams spend a quarter building one for a fourteen-page site and ship nothing else.

It is also worth being plain about what we cannot claim. Google’s own guidance says there are no additional requirements to appear in its AI answers, and that you do not need to create new machine-readable files or markup for them. Nobody outside the platforms has data showing that structured data causes citation. We are not going to pretend otherwise. The case for this work is not visibility. It is that information which disagrees with itself gets represented inconsistently everywhere it is used — and you no longer control all the places it is used.

So the test is whether it matters yet, not whether you are mature. This work earns its cost when at least two of these are true:

• The same fact appears on more than one surface — site, app, connected TV or embedded screen, partner, marketplace.
• The information changes faster than a person can reasonably keep up with: price, availability, stock, hours, capacity.
• Being wrong has a consequence — regulated, safety-relevant, contractual or transactional.
• Somebody else already publishes a version of your data, and theirs is winning.
• Your catalogue is too large to audit by reading it.

One of those, ship the page. Two, model it properly.

The five-answer audit

If you want to know where you stand, do not run a validator. Take one fact from each of five categories — a product, a service, a location, a catalogue item and a transaction — and trace each through five questions.

1. Where is the authoritative copy? Name the single system. If the answer is a list, you have found your problem.
2. Can a machine get it without your interface? Without running your JavaScript, without inferring meaning from your layout, without a login it cannot hold.
3. Is it the same value everywhere it appears? Page, feed, app, listing, PDF. Check the PDF.
4. Is it stated or inferred? “Open 9 to 5” inside a paragraph is inference. A labelled field is a statement.
5. Who may use it, and have you said so anywhere a machine can read?

Five facts, five questions, twenty-five answers. In our experience what emerges is never a missing markup type. It is one or two things — usually a location, usually a price — that no system owns. Fix ownership first. The markup is then generated, correct by construction, and cheap.

That is the shift worth naming. Machine-readability is not a layer you add to a finished website. It is the content model you either built or did not, showing up years later in a form you cannot patch. If you are weighing an AI or automation initiative on a platform that cannot answer question one, the honest sequence is to fix the model first.