Fundamentals · 26 August 2026

By Eddie Eastwood, Founder

How Does Content Structure Impact AI Visibility?

Why structure is a separate problem from being crawlable

A page can be fully readable to every AI crawler, fast, well-marked-up, and still lose the citation to a competitor, because being readable and being extractable are not the same test. Readability asks whether a crawler can fetch and parse the page at all. Extractability asks whether, once parsed, the page contains a block of text a model can lift on its own and hand to a user as a complete answer. Our companion piece on making a website readable by answer engines covers the crawling and markup side; this one is entirely about what happens once the crawler is already in the door.

The distinction matters because the two problems have different symptoms and different fixes. A rendering or robots.txt problem is invisible content: nothing there for any engine to extract, structured or not. A structure problem is different: the words are all present and a person reading the page understands it fine, but the passage a model would need to quote is spread across three paragraphs, mixed in with a second question, or missing an answer-first opening entirely. Fixing it is an editing job on the words already on the page, not a technical setting.

The academic case for treating this as a content problem rather than a technical one is set out in our explanation of query fan-out, which covers the generative-engine research on what makes a source more likely to be quoted. This page starts one step later, from the page you already have.

Answer-first blocks: the passage a model can actually lift

Open every section with two to four sentences that answer the heading's question completely and stand on their own, before any supporting detail, caveat or story follows. Apply a simple test to your own draft: read only that opening block, out of context, as if it were the entire answer. Does it still make sense? Is it still accurate? If yes, a passage-extraction system can lift it cleanly. If the real answer only becomes clear two paragraphs later, an extraction system either grabs the wrong sentence or skips the section for a competitor's page that led with the answer.

Reorder rather than cut: state the answer first, then explain, qualify or expand underneath it. A reader in a hurry gets what they came for immediately. A reader who wants the full picture keeps scrolling. And the model gets a clean, quotable block regardless of which kind of reader it is serving.

Google's own documentation on featured snippets describes exactly this dynamic from the other direction. Google's systems select and elevate the passage a page provides; a site cannot mark a passage as "the snippet" directly, and there is no fixed minimum length requirement (Google Search Central, Featured snippets and your website). ^[1] The instruction runs the same way for generative answer engines: they select what is already extractable. A page that never states a self-contained answer anywhere gives the extraction step nothing to select, no matter how good the underlying knowledge is.

One question per section: do not make a heading do two jobs

A section that tries to answer "how much does it cost" and "how long does it take" in the same block of prose hands an extraction system a mixed passage that answers neither question cleanly. The fix is mechanical: split it. Each <h2> or <h3> should own exactly one question, with its own answer-first opening beneath it.

A reliable tell that a section is doing two jobs: if you find yourself reaching for "also" or "additionally" to introduce what is really a separate question inside an existing section, that is the signal to split it into its own heading rather than keep writing.

This discipline scales up to the whole page, not just individual sections. A single, sprawling page trying to cover everything about a topic is harder for a model to extract from cleanly than several focused pages that each own one part of the question well. This is the same logic behind decomposing a broad topic into its constituent sub-questions before writing a word of body copy, covered in more depth in our explanation of query fan-out: a generative engine typically breaks one query into several smaller searches and stitches together the strongest answer to each piece, so a page answering several specific sub-questions gives each one a passage to extract. ^[2]

Heading logic: write headings as the questions people actually ask

Each heading should be phrased as a question a real customer would type into ChatGPT or ask a voice assistant, not as an internal label. "Our Process" tells a model nothing about what question the section answers. "How long does a kitchen refit usually take?" maps directly onto a real query and gives the model an obvious reason to extract the paragraph beneath it.

Build the heading structure from the actual questions your customers ask, on the phone, in emails, in reviews, before drafting a word of body copy. A heading list built this way satisfies the one-question-per-section rule above, because each heading already names a single, specific question rather than a general topic area.

Google explicitly recommends the same underlying discipline for human readers, independent of any AI angle: "People generally appreciate it when web pages are organized by paragraphs and sections, along with headings that provide a clear structure to navigate content" (Google Search Central, Google's Guide to Optimizing for Generative AI Features). ^[2] Question-shaped headings serve the same navigational purpose for a human skimming the page as they do for a model deciding what a section is about; the two audiences are not in tension here.

Tables and lists: give a model relationships it does not have to reconstruct

Prose forces a model to reconstruct relationships between facts from sentence structure alone, which introduces room for error at exactly the point where accuracy matters most. A table states the same facts directly: this row, this column, this value, with no inference required. Pricing tiers, feature comparisons, service areas, timelines and any other structured, multi-attribute data belong in an actual <table> element, not a paragraph trying to hold several data points together with commas.

The reverse also holds. Do not force a table where the content is not genuinely tabular. A single linear sequence of steps ("first do X, then Y, then Z") usually reads better as a numbered list than as a table with one column pretending to be structured data. Match the structure to the actual shape of the information rather than defaulting to the most "technical-looking" format available.

What structure cannot do on its own

Structure earns a page the chance to be extracted. It does not earn the page the citation. Google is direct about this ordering in its own generative-AI guidance, which puts unique, useful content ahead of every technical suggestion it makes (Google Search Central, Google's Guide to Optimizing for Generative AI Features). ^[2] Our read of that guide in full covers what Google confirms matters and what it says to ignore.

A page with a real, specific, well-evidenced answer wins over a page with slicker formatting and less to say, every time a model has to choose between them.

FAQ

What is an "answer-first block" and how long should it be?

It is the first two to four sentences under a heading, written to answer that heading's question completely and make sense read entirely on its own, with supporting detail, caveats and examples following after it rather than before it. There is no fixed word count; the test is whether the opening alone would work as a standalone answer if a model quoted only that.

Can one section answer more than one question if the questions are related?

No. A section that tries to cover two questions gives an extraction system a mixed passage that answers neither cleanly. Split each question into its own heading with its own answer-first opening. Watch for "also" or "additionally" introducing what is really a second question inside an existing section.

Do I need to rewrite everything specifically for AI, separately from writing for people?

No. Google's own documentation states there is no requirement to write differently for AI systems or to break content into artificially small chunks. Structuring for extraction (answer-first openings, one question per heading, tables for comparative data) happens to serve human skimmers and AI extraction at the same time, because both are looking for the same thing: a clear, findable answer.

Is a table always better than prose for AI visibility?

Only for genuinely tabular, multi-attribute data such as pricing tiers, feature comparisons or timelines. A single linear sequence of steps usually reads better as a numbered list, and narrative reasoning or context reads better as prose. Forcing data into a table it does not fit adds noise rather than clarity, for a model and a human reader alike.