Blog · Diagnosis

Information architecture for answers, not sessions

Published 25 June 2026 · Updated 12 October 2026 · 9 min read

Information architecture for answers, not sessions
Photograph: Filipp Romanovski / unsplash

The short answer: Information architecture for answers means every page carries one resolvable claim, at one stable URL, in blocks that survive being read alone. Classic site structure assumes a session: a visitor arrives, orients, clicks deeper, and accumulates context as they go. A retrieval system has no session. It lifts one passage, with no memory of your navigation, and writes a sentence from that passage alone.

That difference sounds small until you look at what it breaks.

A session carries context forward. A retrieval does not

Think about how a normal site teaches somebody what you do. The homepage sets the frame. The product page assumes the frame. A feature page assumes both, so it can open with "the workflow above" and nobody is lost. Context accumulates across clicks, and each page is allowed to be incomplete because the ones before it filled the gap.

Retrieval breaks that chain at the first link. A passage is selected for its own merits, pulled out, and placed beside passages from three other domains. Nothing upstream travels with it. If the paragraph the engine kept says "the workflow above runs in under an hour", the answer either drops it or repeats it without the workflow, and a reader learns nothing about you. This is a large part of why AI never mentions your brand even when the information is sitting on your site in plain sight.

So the first architectural rule is uncomfortable for anyone who has spent a decade removing duplication: a page must restate the minimum identity it needs. Who this is, what it is, what it costs, who it is for. Not the whole homepage again. One sentence that makes the passage self sufficient when it travels.

Build the unit of retrieval, not the unit of navigation

Navigation units are sections, tabs and accordions. Retrieval units are blocks: a heading plus the text underneath it, a table row, a list item, a short paragraph. Those are the things that get cut out and scored.

A useful test is to read a page as a stranger would read a single screenshot of one paragraph. Does that paragraph name the subject? Does it contain the number, the condition and the qualifier, or did you split them across three blocks because that read nicely on screen? Splitting is the usual failure. The claim sits in a heading, the qualifier sits in a footnote, the number sits in a table two scrolls down, and no retrieved chunk contains a complete, quotable statement.

Google's documentation on AI features is unusually blunt about the lack of special machinery, at least on its own surfaces. It says you do not need new machine readable files, AI text files or markup to appear in AI Overviews or AI Mode, and that there is no special schema.org structured data to add. What Google asks for is that the page is indexed and eligible to be shown with a snippet, and it lists keeping important content in textual form among its best practices. That page was last updated 10 December 2025. It is Google writing about Google. We have not found an equivalent published statement from the other engines in our prompt set, so read it as one engine's documented position, not as a rule of the category. What you can change is structural, not declarative.

Here is the mechanism most teams have never looked at. When a browser or an engine sends a reader to the exact sentence it quoted, rather than to the top of the page, it can do that with a text fragment directive in the URL, written as #:~:text=, with an optional prefix and suffix to disambiguate the match. The specification is a W3C Community Group draft, last published 13 December 2023. Which engines link this way, and when, is not something they document, so take this as a thing that can happen to your pages rather than a thing that reliably does.

The constraint that matters is in the specification itself: each part of the directive has to match text within a single block, so a match cannot span a block boundary. The draft defines block level display as any of block, table, flow-root, grid, flex or list-item. If the sentence an engine wants to point at is broken up by your markup, with half in a <p> and half in a <div> or a list item, or if a styled span is rendered as its own block, the directive fails to resolve and the reader lands at the top of the page instead of at the claim.

You can test this in about forty seconds, with no tooling:

  1. Pick the sentence on your page that you most want an engine to quote.
  2. Percent encode it and append #:~:text= plus that text to the page URL.
  3. Open the URL in a browser that supports text fragments.
  4. If the sentence highlights and scrolls into view, the passage is one clean block. If

    5. nothing highlights, your markup has chopped the claim into pieces.

Run that on ten of your own pages and you have ten results you checked yourself. In the sites we have audited, the failures cluster on marketing pages built out of nested layout components, and are rarer on documentation pages. We have not counted that across a defined sample, so it is an impression from our casework, not a rate. It is the same diagnosis that drives a self-audit checklist for AI visibility, applied to one specific layer of the stack.

One claim, one URL, and no session junk in it

Architecture for answers is also an argument about URLs. An answer is assembled from addresses, so an address that varies is an address that cannot accumulate trust.

Google's own URL structure guidance, last updated 10 December 2025, says to avoid session IDs in URLs and to use cookies instead, and warns that overly complex URLs can generate large numbers of addresses pointing at identical or near identical content. Its crawl budget guidance, last updated 22 July 2026, puts rough thresholds on when crawling itself starts to hurt: sites of a million or more unique pages whose content changes about weekly, or ten thousand or more unique pages changing daily. Those are Google's published thresholds for Googlebot. We have not seen comparable figures from any other engine, so do not carry them across. Below that, crawl rate is rarely your problem. Duplication still is, because it splits corroboration. Four URL variants of the same comparison page means four weak candidates rather than one strong one.

The practical version: one canonical address per claim, parameters stripped from anything you want cited, redirects collapsed to a single hop, and the same wording of the claim on whichever variant survives. At least one engine publishes the split: OpenAI's crawler documentation describes OAI-SearchBot crawling for search and ChatGPT-User fetching a page because a user asked. That documentation says the user initiated fetch is not used to crawl the web automatically, and that a site's robots.txt rules may not govern it, since a person started it. Whether the other engines in our prompt set divide their agents the same way is something we have not verified. Where it holds, a page that renders correctly for only one of those agents is a page that answers inconsistently.

Hubs still matter, for a different reason

Internal linking was always sold as a way to move visitors through a funnel and to pass ranking signals along. The second reason survives, with a twist. A cluster of pages that reference each other with honest, descriptive anchor text gives a retrieval system repeated, consistent evidence that the same entity owns the same topic. We have not found an engine that documents what internal corroboration is worth, so that sentence is inference from what comes back quoted, not a published mechanism. One page claiming expertise is an assertion. Nine pages agreeing, in compatible language, is at least harder to contradict.

Keep two things straight. Anchor text should describe the destination in the words a buyer would use, because that text is often the only context an engine has for the link. And the pages in a cluster must not contradict each other, since a retrieval system has no way to tell which of your two prices is current. Contradiction inside your own site is one of the more common findings in our audits, and it rarely survives a single reading pass by a human.

Timing expectations should be set honestly here. Structural work shows up on a crawl and re-embedding cycle, not overnight, which is covered in how long AEO takes to show up in answers. Engines differ too. The way Gemini answers brand questions leans on a different source mix than a chat assistant doing a live fetch, so the same structural fix pays off at different speeds in different places.

If you want to see what this looks like written up against a real site, the sample audit report shows the structural findings section in full.

Honest limits

Chunking is not public as far as we can see. We looked for documentation of how a document is split, how large the windows are, and whether headings travel into each chunk as context, across the five engines our audit prompt set covers, and found none as of October 2026. That is absence from the documentation we could find, which is not proof that nothing is published and certainly not proof that the behaviour is the same everywhere.

Everything above about block structure is inferred from what comes back quoted and what comes back mangled, across the few dozen sites we have audited, which is casework rather than a sample drawn to represent anything. The inference could be wrong in detail even where the fix still helps. The one hard claim in this post, that a text fragment cannot match across a block boundary, comes from the specification rather than from us. We also cannot say what a clean block boundary is worth on its own, because it travels with other changes and we have not found a way to isolate it without holding a site still for months.

FAQ

Does this mean I should delete my navigation? No. Humans still arrive and still need to move around. The point is that navigation cannot be load bearing for meaning. A page should make sense with the chrome stripped off.

How long should a block be? Long enough to contain a complete claim with its qualifier, short enough that it is not diluted. We have no word count we can defend with a measurement, so do not take one from us. Write the complete claim in one block, then check what actually gets quoted.

Is a FAQ section a shortcut to this? Partly. Question headings with self contained answers are naturally good retrieval blocks. They stop helping when the answer is thin, or when the same question gets a different answer on another page of the site.

Should every page have structured data then? Markup helps machines resolve identity and relationships, and it is worth having. It does not rescue a page whose text is incomplete. Google's documentation is explicit that no special schema.org structured data is needed for its own AI features, and we have not found a comparable statement from the other engines either way.

Sources

All five sources were opened and checked on 12 October 2026.

Related reading

Why AI never mentions your brandA self-audit checklist for AI visibilityHow long AEO takes to show up in answersHow Gemini answers brand questionsInternational and multilingual AI visibilityOutdated pages are poisoning your answers