Machine View

This page reads itself · July 2026, last updated September 2026 ·

I tried to see my own website the way a machine sees it. The result is below: on the left, a page as a human knows it. On the right, what a machine gets from it. None of it is mocked up, the apparatus opens the real page and reads its source.

Hover a line on the right and the matching spot on the left lights up. And the other way round. Some lines never light up, because the other side simply never receives them. Those spots are what this is about.

The apparatus

Which page
Which machine
View
Human rendered page
Machine

Loading …

 
 
 

both sides one side only

What this page shows

Five views, five ways of reading. Whether a page is machine-readable depends on which machine is reading.

  • AI search: the source code as ChatGPT or Claude receive it on a direct fetch. No JavaScript. Whatever a script writes onto the page later is missing here.
  • Structured data: what the page says about itself, in machine-readable form. Whether that buys anything is covered below.
  • Agent · tree: roles and names instead of layout. This is how browser agents read, programs that remote-control a browser and carry out tasks. Screen readers depend on the same tree.
  • Agent · HTML: trimmed HTML, only the operable elements. More complete than the tree, and better or worse depending on the model.
  • Agent briefing: llms.txt, a file meant to tell AI systems what this site is about. Whether it gets read at all: more on that below.

The most important point: the big US assistants do not run JavaScript on a direct fetch. In one test a decoy phone number sat in the source code and the real one only appeared via script. ChatGPT and Claude reported the decoy. Three tests since late 2025 show the same picture; all three are single measurements. The route via a search index does render. Only the direct fetch does not.

How the apparatus works

Everything happens in the browser, no server.

On the left sits the real page, loaded in a frame. The apparatus reads its source, its structured data, and the llms.txt, and sets them against the five views. The tree and HTML views are reproductions of the formats used by Playwright and Stagehand, the most common tools browser agents are built with. The mapping between left and right comes from text matching and is fuzzy at the edges. To verify: open the source, find the same data.

Why the tree matters

An element without a name does not exist for an agent.

Google says it plainly: agents rely on the accessibility tree, the same tree screen readers use. Since spring 2026, Lighthouse, Google's website testing tool, checks it in a category of its own. A button that consists only of an icon has no name in this tree. The agent can neither see it nor use it.

This is not an edge case. A survey of one million home pages found empty buttons on 30.6 percent, and on half of them form fields lack labels. The average website reads to an agent like a half-labelled form.

Observations, not proof

Four claims circulate on this topic. None is as solid as it sounds.

Structure beats pixels? The studies disagree: sometimes the text-based variant wins clearly, sometimes the one with screenshots. What is certain is that the serious agent tools work through structure, not through screenshots.

Accessibility helps agents? The number cited everywhere for this, success falling from 78 to 42 percent, comes from a study that did not change a single website. It took the mouse away from the agent. The comparison I announced here is still outstanding. What I built on 29 August 2026 is something smaller: an illustration. Two versions of the same page, generated from one content definition and identical to within eight of 1,265 pixels in height — one properly marked up, the other built as div soup. In the first, each of the eight controls carries a role and a name; in the second, none of seven does, and where the first offers eight elements to the keyboard, the second offers one. The second version works perfectly well: trigger its buttons programmatically and they do exactly the same thing.

Why this is not evidence. I left the markup out myself and then measured that it is missing. The result was fixed by the blueprint; anyone who knows how an accessibility tree is built could have predicted it. A self-built case says nothing about the world, which is why it deliberately does not appear on the evidence page. What it shows is the mechanism alone: that two pages can be identical for people and not for a machine. So on the same day I measured real pages instead of building more of my own.

The survey: 160 home pages from the DAX, MDAX and SDAX. Not a selection of mine — the companies come from three indices, the addresses from Wikidata. What was measured is Chrome's own accessibility tree, twice; 135 of 136 evaluable pages returned the same result both times, down to the element.

The result contradicts what I expected. Of 13,527 controls, 456 carry no name: 3.4 percent. And the rate does not deteriorate among mid-caps: DAX 3.1, MDAX 3.8, SDAX 3.3 percent. The suspicion that smaller companies without accessibility teams fare markedly worse does not survive measurement. Fifty-seven of the 135 pages have no gap at all. The common story of a machine-unreadable web does not hold for German listed companies.

Where gaps remain, they are almost always logos and icons serving as links or buttons: Talanx links its six group brands as unnamed logos, GFT its partners, Atoss its social profiles. Add carousel arrows and play buttons. Fix that, and most of the gaps close with a single measure. One case shows how narrowly you can miss: MBB links its subsidiaries with a carefully maintained title attribute — but because the link text is a non-breaking space, the link stays nameless in the tree.

Structure is the weaker point: 52 of the 135 pages have no main-content landmark, so the marker for where content begins and navigation ends is missing. And of 3,979 images, 1,662 carry no name — though five sixths of those are SVG icons merely lacking the marker that would declare them decorative.

On admission, where I had to correct myself: twelve of the 160 pages reject automated retrieval, 7.5 percent. That is bot defence from Akamai and Cloudflare, detecting from the TLS fingerprint that no ordinary browser is asking. A regular, remote-controlled Chrome got through several of these sites — the defence separates tool from browser, not human from machine. An earlier version of this page said a third, lumping together bot defence, stale addresses, country selectors and technical errors.

What this survey does not answer either: whether an agent completes its task. It measures what it finds, not what it achieves. The original question — does better markup improve success? — remains open. All figures, with their limits, are on the evidence page.

Structured data creates visibility? The cleanest test so far compared almost 2,000 pages after they added JSON-LD with matched control pages. Result: no measurable effect in ChatGPT and Google's AI mode, a slightly negative one in AI Overviews. I keep the markup anyway, because it keeps the foundation clean. I do not promise myself an effect from it.

There are rules everyone follows? Google, OpenAI, Perplexity, and Meta explicitly exempt their user-triggered fetches from robots.txt; Anthropic is the exception. Blocking AI crawlers blocks training and search. The agents keep running. And the standard meant to settle this has been stuck in a working group for over a year.

And the promised answer on llms.txt: it is here because it exists. 97 percent of these files get not a single request, server logs across 137,000 domains show. The format was invented for tool documentation, not for visibility. Where it demonstrably works, it saves agents time. Nothing more.

The easiest case

This website is the easiest case there is.

About thirty pages, static, no CMS, a single external script. On a grown brand site with a tag manager, a consent layer, and three agencies involved, the right-hand column would look different. What is handcraft here becomes a question of ownership and process there.

And clean structure is only the entry ticket. My own measurements show both sides: ask about me, and this website is the primary source. Ask whom to hire for this topic, and my name does not come up. Between those two results lies no technical problem. What lies there is what third parties write.

Sources

These figures, and the others I have checked for my writing, are laid out one by one on the Evidence page: each with its primary source, sample size, date, and what it explicitly does not prove. Made for citing.

A short glossary

  • Accessibility tree: the structure the browser computes from every page: all elements with role and name, no layout. The basis for screen readers and agents.
  • Browser agent: software that operates a browser the way a human does: reads, clicks, types, and carries out tasks.
  • Crawler: a program that fetches websites automatically, for a search index or for AI training.
  • JSON-LD: an invisible block in the source code where a page states facts about itself: who, what, when. The "structured data" in this text.
  • Lighthouse: Google's website testing tool, built into the Chrome browser.
  • llms.txt: a text file at a fixed address meant to tell AI systems, in short form, what a website is about.
  • Playwright: the most common tool programs use to remote-control a browser. Many browser agents are built on it.
  • robots.txt: a text file in which a website declares which crawlers may access it. A convention, not a law.
  • Screen reader: software that reads a page aloud, for blind and visually impaired people.
  • Source code: the HTML text the server delivers before the browser does anything with it.
  • Stagehand: a newer tool of the same kind as Playwright, built specifically for AI agents.

My own terms at a glance: To the overview → · Context: Machine Readable Brands

The essay behind this apparatus: The Gap That Doesn't Respond. → (first published at The Business of Brand Management)

Contact

LinkedIn · E-Mail · Home