The machine-readable layer
Every page is read twice.
A person reads prose. A machine reads fields. The second reading is what decides how you get described in an answer you will never see, and it is the one almost nobody engineers. Everything printed on this page is this site's own markup — not an illustration of what markup could look like. You can check it against the page you are reading.
The same page, read two ways
Open any page here and you are reading sentences. A heading, a paragraph, a link, arranged so that the meaning arrives in a particular order and each part is coloured by the part before it. A model retrieving the same page is not reading it that way. It is looking for facts it can lift out cleanly without having to interpret the prose wrapped around them: what this organisation is called, what it sells, who it serves, what it published and when.
Both readings come out of the same file. The visible one is written. The machine-readable one is engineered, and it is a separate deliberate act — a page can read beautifully to a person and still hand a retrieval almost nothing it can use. That is the ordinary case, not the exception, and it is the gap the work sits in.
The panel below is not a diagram of somebody else's site. The fields on the right are the ones this page is serving you as you read it.
What we build into a page
Structured data restates facts a page already makes in prose as labelled fields, in a form built for parsing rather than for reading. It sits alongside the visible page instead of replacing it. Four such records and one plain-language map are published across this site, and each one settles a different question that a machine would otherwise have to guess at.
- An entity record, which settles what this organisation is, what it is called, and what else it goes by — the question anything has to answer before it can say a single other thing about you.
- A service record, which states what is actually sold and across which surfaces, as fields rather than as a sentence something has to parse correctly first.
- A question record, which pairs each question a buyer asks with the answer given, so that an assistant reaching for one quotes the answer as written instead of assembling its own.
- An article record, which attributes each piece of writing to the organisation and dates it, so it can be treated as a citable source rather than as loose text found on a page.
- A plain-language map of the site addressed to models rather than to crawlers, naming every page and what each one settles.
What we deliberately leave out
The service record carries no prices and no figures of any kind. That is not an oversight, and it is worth explaining because it shows where this work goes wrong quietly.
This site publishes no prices, and two separate tests enforce that by scanning the copy. Neither of them reads structured data. A price placed in the service record would therefore be invisible to every guard on the site while being perfectly visible to every machine reading it — published, in effect, to the only audience that was never meant to see it first.
That asymmetry is general. The machine-readable layer is where a claim can be made without anyone noticing it was made, which is exactly why it needs governing as tightly as the copy does, and why the guard on this page checks the fields rather than the sentences.
The field we cannot fill yet
One field in our own entity record is empty, and it happens to be the one that would matter most.
There is a field whose entire purpose is to list the other places on the internet that are demonstrably the same organisation. It is how a machine tells two similarly named entities apart. Ours is empty.
We ran our own method on ourselves the day this site launched and published the result. The finding was that our name does not resolve to us: an older set of firms and one long-established product hold it, and a search for the name as written returns them instead. That is precisely the problem this field exists to solve, and we cannot use it, because the field takes corroboration and we have nothing yet to point it at.
A firm that sells structured data has an obvious incentive to imply that structured data fixes this. It does not. Markup states a claim; it does not corroborate one. An entity is only disambiguated when independent sources agree about it, and nothing we add to our own site counts as an independent source about our own site. The remedy is being cited somewhere that is not here, which is slower and harder to sell and is nevertheless what the finding says.
So the field stays empty, and it stays printed on this page rather than left out of the specimen. On the day it fills, this section stops being true — and a test in this repository is written to fail at that moment, deliberately, so that the copy gets rewritten instead of quietly ageing into a false claim.
The instrument that measures it
Engineering the layer is half the job. The other half is finding out whether it changed anything, and that means measuring the answers themselves rather than admiring the markup that was supposed to influence them.
Each engagement gets its own bank of questions, written for that client: the things a prospect would actually type, and the things they would actually ask out loud, before deciding anything. Those questions are put to search results and to assistant answers alike, live rather than read out of a pre-aggregated database, and every raw result is kept.
Every one of those measurements is made by a person. Nothing on that side is automated, and that is a constraint we chose rather than one we have not got round to lifting. Scoring an assistant answer means deciding what the answer actually said about you — whether being described as an alternative to somebody else counts as being named — and that decision is not a step on the way to the measurement. It is the measurement.
Why a record beats a snapshot
A single run tells you a position and nothing about direction. Both channels drift underneath you: rankings move on their own, and model answers change as providers update them, so a result read once is indistinguishable from a result that was about to change anyway.
The questions are therefore frozen at the start and asked again unchanged. Two runs of the same bank can be compared. Two runs of differently worded banks can only be reconciled, which is a much weaker thing and tends to produce a story rather than a measurement.
As each week's run lands it joins the record instead of replacing it. That accumulation is the actual asset, and it is why a later month is worth more than the first one — not because the reporting improves, but because by then there is something to compare against that came from you rather than from an industry average.
Both columns come from this page. The fields on the right are the entity record it is serving you as you read this, printed from the same source that emits it — including the one that is empty.
Illustration. An instrument is only reading a change if everything except the thing being measured stayed the same — which is why the questions are frozen before the first run rather than improved between them.
The procedure behind every measurement is written out on the methodology page, and the first run of it against this firm is published in the day-one baseline.