Almost everything written about being read by AI stops at the fetch. Can the crawler get in, is the content in the HTML, is there structured data. All of that matters and all of it is the first half. The second half is what happens to the page once it is inside, and it is where a great deal of genuinely good writing quietly fails.
Here is the shape of it. A retrieval system does not store your page. It cuts your page into passages of a few hundred tokens, stores each one separately, and when somebody asks a question it finds the two or three passages that look most relevant — yours next to passages from forty other sites — and hands those to the model. The answer is written from the passage. Not from the page. The rest of your page was never in the room.
The question that decides whether you get cited is not "is this page good?" It is "is any 300-token slice of this page good on its own?"
The three ways a page fails the cut
1. The pronoun with nothing behind it
You introduce the product in the opening paragraph and then write about it naturally, the way anybody would. Four hundred words later a section begins:
It costs €29 a month, and includes everything in the free tier plus the crawl.
Read from the top, that is clear and well written. Retrieved on its own it is a sentence about an unnamed thing costing an unnamed buyer €29. A model handed that passage and asked "how much is X?" cannot safely say it is about X, so it does not — it uses a competitor whose passage said the name.
2. The reference to somewhere else on the page
"As the table above shows." "See the previous section." "The following steps." Each of these points at something that, after the cut, is in a different passage sitting in a different place in the index. To a reader going top to bottom they are invisible; they are only clear because the reader is holding the part the retrieval system threw away.
3. The page with nothing to cut on
This is the commonest and the most fixable. A chunker splits at headings and carries the heading path into each passage, so a page with real headings is most of the way to being chunkable for free. A long page with one heading at the top has nothing to split on, so it gets split on nothing in particular — and every passage after the first arrives with no label at all.
And the fourth thing, which is not a failure of writing
Your menus get chunked too — the ones that are not marked as menus. Anything inside a <nav>, <header>, <footer> or <aside> can be recognised as furniture and dropped, and on a well-built site it is. Everything else is fair game: the language switcher in a plain <div>, the block of related links inside the article, the mega-menu assembled out of list items. Each of those becomes a passage of pure link text that goes into the index, can be retrieved, and answers nothing. It is not badly written; it is simply not content — but it occupies the same budget as content.
What this looks like across the real web
We ran the cut across 292 well-known public sites on 2026-09-06 — one page each, the home page, split the way a heading-aware retrieval pipeline splits, then asked of every passage whether a reader who saw only that passage would know what it was about. 261 of them had enough content to cut at all.
| Measure | Median across 261 pages |
|---|---|
| Passages one home page cuts into | 11 |
| Share of the content that stands alone in one passage | 100% |
| Share of what would be retrieved that is navigation | 1% |
The median is the part worth saying plainly, including where it is inconvenient for us: the median well-known home page survives the cut, at 100% of its content standing alone. These are famous companies with editors, and their front pages are short, heavily headed and written to be skimmed — which is exactly the shape that chunks well. If your home page is like that, this is not your problem.
It is the tail that matters, and the tail is not small: 17 of 261 (7%) of these pages leave under three fifths of their content in a passage that could be quoted, 23 of 261 (9%) are more than half navigation once cut up, and 5 of 261 (2%) have no prose passages at all — every piece of them is a list of links pointing somewhere else.
And a home page is the easiest page a site has. The pages an assistant is actually asked about — the long explainer, the documentation section, the article you spent a week on — are the ones with paragraphs that refer back to earlier paragraphs, and they are not in this sample. Run the check on one of those rather than on your front page.
One honest caveat, because this subject is full of confident claims nobody has measured. Every retrieval pipeline chunks slightly differently: the window varies, some overlap the passages, some carry more metadata than others. What does not vary is the underlying fact that the model sees a fragment rather than the page. The structural advice below survives any of the variations, and where our simulation makes a specific choice — split at headings, carry the heading path, cap at about 300 tokens — it is written down so you can disagree with it.
What to actually do
- Give every section a heading that names its subject. Not "Overview" and "Details" — the words somebody would search for. This one change does most of the work, because it is what the chunker splits on and what it carries into the passage.
- Open each section with the subject rather than a pronoun. Write "AXRAY costs €29 a month" where you would have written "It costs €29 a month". It reads slightly more formally to somebody going top to bottom; it reads correctly to everybody else.
- Delete the cross-references, or replace them with the thing itself. "As shown above" becomes the number. "See the previous section" becomes a link, which survives the cut.
- Keep the navigation out of
<main>. Anything inside your<nav>,<header>,<footer>and<aside>landmarks can be recognised as furniture and left out. Anything in a plain<div>in the middle of your content cannot. - Restate the essential fact in the section that needs it. Repeating your own name, your price or your location once per section feels redundant when you read the page whole. It is the difference between being quotable and not.
How to see it for your own page
The report shows every passage, the heading it sits under, and the reason any of them cannot stand alone. From a terminal it is one command:
npx axray-cli your-site.com --json | jq '.retrieval | {chunks: (.chunks | length), standalone: .score, navigation: .navigationShare}'
No language model is involved in any of it. Every verdict comes from the structure of the page — the heading above a passage, how its first sentence opens, whether it points at something outside itself — which is what makes the result reproducible, and what makes it something you can argue with rather than something you have to believe.
See your own page cut into the passages an assistant is actually handed, and which of them can be quoted.