Index

Humans Take Journeys, Agents Take One Fetch

· Tom Cranstoun · 7 min read

On 24 September 2026 Google released its September spam update. The Search Status Dashboard entry is short: "Released the September 2026 spam update, which applies globally and to all languages. The rollout may take up to two weeks to complete." Google didn't say what the update targets.

The SEO community filled the gap. A summary on Reddit's r/DoSEO put it in one line: "It doesn't chase links; it evaluates real usefulness". Other advice follows from that: judge each page on first-hand experience and unique value, don't rush to change URLs or add redirects while rankings settle, and assess the impact only once results have settled.

That reading is an interpretation, not a statement from Google. Right or wrong about Google, it describes how an AI agent reads your site.

An Agent Judges the Page It Fetched

An agent sent to answer a question about your business doesn't take the journey you designed. Most agents read one file and decide. They don't open the menu, click through to the next step or come back later for the terms. A few follow a link or two, but you can't design for the few. An agent doesn't experience the site the way a visitor does: the landing page that sets the scene, the menu that narrows the choice, the next step that answers the question the last one raised.

This is the case MX is built for: a machine reading a file in isolation. It might be a web page, a PDF or a policy exported from the system that produced it. Whatever arrives has to explain itself, because nothing around it will.

Technical writers reached a version of this idea long before agents did. Mark Baker's book Every Page Is Page One argues that readers arrive from a search, not from the table of contents, so each page has to stand on its own. For a machine, it's stricter still: page one is usually the only one it reads.

So whatever the page needs to be understood has to be in the fetch. If the price is behind a tab, the terms on another page, and the date it was last checked nowhere at all, the agent works from the part it got. It won't reach the rest, and rather than say so, it fills the gap with a guess.

A content strategy built on journeys was sensible when every reader was a person. A page could lean on the one before it. It could leave context to the menus and links, because the navigation was always there. An agent reading a single fetch gets the page without the journey around it.

Why People Need Journeys

None of this makes journeys a mistake. People like them for a good reason.

We can only hold so much in mind at once. Present twenty options side by side and a person struggles to compare them. Present five, then the next five, and they can reason about each set. A good journey is a way of limiting how much someone has to carry at each step. Progressive disclosure, tabs, accordions and a clear next step all exist because too much at once is overwhelming. That's cognitive overload, and good design is built to prevent it.

A machine has no such limit. It can hold the whole page, every specification, every review and every term, as easily as it holds one line. What it lacks is the context a person picks up along the way. Being led is no help to it. It wants everything, in the fetch it made.

Humans want a drip feed. Machines want it all at once. That's the conflict: the same page is asked to hold back for one reader and to say everything for the other.

Where Jevons Comes In

I expect the number of single fetches to rise. I've written about Jev, TypeSafe's decision model, named after William Stanley Jevons. His paradox says that making a resource cheaper tends to increase total use rather than reduce it. I've measured a small decider making a decision in about a tenth of a second at no marginal cost, and argued that cheap decisions multiply.

Follow that to a single page. A router fetches it to decide which model should handle it. A decider fetches it to check whether it's current. Another asks who owns it, and another whether it may be quoted. Each of those is one fetch, made by a machine with no interest in the journey. The more of them there are, the more of your content's life is spent being read one page at a time. Every one of those reads that has to guess also costs energy that a declared answer would save.

What MX Adds

MX leaves the journey in place and adds the layers a single fetch needs, inside the page, where a person doesn't have to look at them and a machine can't miss them.

  • What the page is. A title, a description and a type the machine reads directly, rather than inferring them from the layout.
  • Its place in the journey. Declared relationships to the pages before and after it, and to the collection that holds it. The journey a person walks becomes a set of references a machine can read in the one file, without having to follow any of them.
  • Who stands behind it. An author, a maintainer and a point of contact, so the claims on the page can be attributed.
  • Whether it's current. A modified date and a version, so a decider asking "is this still true?" has an answer rather than a guess.

A person sees the page as it always was: the scene set, the choice narrowed, the next step clear. A machine sees the same page with its context declared. The visible design limits what the human has to hold at once. The metadata gives the machine everything in one go. Both describe the same content.

This is the thinking behind the line the MX Manifesto opens with: "MX is to machines what UX is to users". UX designed the journey. MX makes sure each step of it can stand on its own.

Design for Both

The practical test is simple. Take any page on your site and fetch it on its own, without the pages around it. Ask what a reader would know if that fetch were all they had. Is it clear what the page is, who's responsible for it, when it was last checked and where it fits? If the answer depends on the journey, a machine doesn't have it.

The community reading of the spam update points the same way, whatever Google's intent turns out to be: judge the page on what it offers. Agents already work like that. MX doesn't ask you to choose between the two readers. Keep the drip feed for the people who need it, and declare in every page what a machine reading it alone needs to know. That's design for both.

Where Your Own Content Stands

A single fetch shows what an agent can know about your page. Whether your pages declare enough to be read that way is what an MX audit measures.