Retrieval systems do not read pages the way people do. They split each page into passages, called chunks, embed each one, and pull the best-matching chunks into the model's context; the model then writes from those fragments. The unit of competition in AI search is the passage, not the page. Architecture, at both site level and page level, means organizing your content so that every section can be lifted out alone and still carry your brand and your claim.
Site level: clusters, hubs, and the pages answers are assembled from
An AI answer is typically assembled from passages across several pages and often several sites. You are competing to be the best source for specific passages, which changes what a good site structure is for. Three principles do most of the work.
Cover the meaning-space of your topic, since retrieval matches on meaning rather than exact strings; a cluster of pages around one topic, tied to a hub page, gives the retriever a relevant passage for the many phrasings and fan-out queries a prompt generates. Give every page one clear job, because a page that is half feature tour and half pricing explainer produces chunks about neither. And treat internal links as a statement of what relates to what: they are how both crawlers and readers learn which page is your canonical answer on a subtopic. The fan-out queries these clusters need to cover come out of the inventory built in Prompt and Topic Research.
Page level: sections a chunker can lift
A chunker will cut your page into pieces at boundaries you do not control, though in practice headings and paragraph breaks guide the cut. Write each section to pass the lift test: pulled out alone, with no surrounding page, a reader can still tell what it is about, who it is about, and what it claims. Three habits get you there. Open each section with its point rather than building up to it. Name the subject in the section itself, because a chunk that says "it also includes" refers to something the model never sees, while a chunk that says "Acme's starter plan includes" survives extraction. Keep one idea per section, so the chunk's embedding points at one meaning instead of averaging across three.
Heading structure as a retrieval API for your page
Headings tell the machine what each block is about before it reads the block; treat them the way an engineer treats function names in a public interface. "Pricing for teams of 10 to 50" gives a retriever and a reader the same information; "Let's talk numbers" gives neither anything. Google's guidance for its AI features says the same thing from the platform side: content organized into paragraphs and sections, with headings that provide clear structure, is what its systems work best with.Google's guide to AI features on Google Search, in the section on organizing content in a way that helps your readers.
The same Google document pushes back on the fragmenting version of this advice: there is no requirement to break content into tiny pieces for AI, and no ideal page length.The mythbusting section of the same guide, under "chunking content", states Google's systems understand multiple topics on a page and show the relevant piece. Both statements are correct, and they resolve cleanly: the goal is self-contained sections, not short pages. A 3,000-word page whose sections each pass the lift test is well-architected. Thirty stub pages carrying one paragraph each are not; they are thin content wearing a chunking costume.
Fact-source pages: the unglamorous pages machines quote
Retrieval systems reward a category of page most marketing sites never build: the page that exists to state facts. A company-facts page with founding date, ownership, headcount, and locations. Product spec pages with real numbers. A pricing page that states prices in text rather than trapping them in a JavaScript calculator or a sales call. A methodology page explaining how your numbers are produced. These pages answer the fan-out queries that run underneath comparison and recommendation prompts, and they are where a fetcher lands when a user asks a specific question about you at answer time.
They also protect you. When your own site states these facts in plain, extractable text, the machine does not have to reconstruct them from third-party pages that may be stale or wrong; the same facts belong in your markup too, which is the redundancy argument in Structured Data and Machine-Readable Facts.
An audit you can run this week
Take your ten most important pages. Split each at its headings, read every section in isolation, and ask the lift-test questions: subject named, claim clear, meaning intact out of context. Sections that fail get rewritten under Writing for Retrieval and Citation. Then list the fact-source pages above and check which ones exist on your site at all. On most sites the audit takes an afternoon and the missing fact pages are the fastest architectural win available.