The AIO Content Model

Why a content model, and why now

Most published guidance about writing for AI systems describes outcomes rather than structure. It says content should be authoritative, clear, and quotable, which is difficult to argue with and difficult to act on. A content model is a narrower thing: a description of how a document is put together, at the level of headings, paragraphs, claims, and evidence, so that the pieces of it can be retrieved and reused correctly by a system that will never read the whole page.

The reason this matters now is that the retrieval step has become visible in platform documentation. Google states that to be eligible to appear as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to be shown in Google Search with a snippet. OpenAI documents a distinct crawler, OAI-SearchBot, and states that sites opted out of it will not be shown in ChatGPT search answers. These are not descriptions of how a model reasons. They are descriptions of whether your text is available to be pulled at all, and they are checkable.

The AIO Content Model set out below is an AIOFacts proposal. It is assembled from documented mechanisms, but the assembly is ours, and no AI platform has confirmed it as the right shape.

The retrieval unit is often a passage, not a page

The single most useful structural fact available in public documentation is that citation systems frequently operate below the level of the page. Anthropic's Citations documentation describes how documents are processed for its API: contents are chunked to define the minimum granularity of possible citations, plain text and PDF documents are automatically chunked into sentences, and the model can cite a single sentence or chain together multiple consecutive sentences to cite a longer passage. The documented citation formats are character indices for plain text and page numbers for PDFs.

That is one vendor's implementation of one feature, and it should not be generalized into a claim about how AI assistants handle web content. Platform behavior varies and most of it is undocumented. But it is a concrete, published example of a system in which the unit attached to a claim is a sentence or a short run of sentences, not a document.

Google's snippet controls point in a compatible direction. The robots meta tag specification states that the nosnippet rule will also prevent the content from being used as a direct input for AI Overviews and AI Mode, and that max-snippet will also limit how much of the content may be used as a direct input for those features. The data-nosnippet attribute works at the element level, on individual span, div, or section elements. A publisher's control surface here is measured in characters and elements, which suggests the consuming systems work at that resolution too.

The practical consequence is the foundation of everything below. If a passage may be lifted out of its page and shown next to a claim, then a passage that only makes sense in the context of the four paragraphs above it is a passage that can be extracted incorrectly.

What the documentation actually asks for

It is worth being precise about how little the platform guidance demands, because a large amount of published advice invents requirements that the documentation explicitly denies.

Google's AI features page states that there are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary, and that you do not need to create new machine readable files, AI text files, or markup to appear in these features, and that there is no special schema.org structured data that you need to add. The stated eligibility condition is indexing and snippet eligibility.

OpenAI's crawler documentation draws a boundary that is often blurred in practice. GPTBot is described as being used to make its foundation models more useful and safe and is not used to determine search results. OAI-SearchBot is the crawler that surfaces websites in ChatGPT's search features. ChatGPT-User handles user-initiated fetches and is documented as not being used to determine whether content may appear in search. These are independent controls, so a site can be visible in one system and absent from another, and a robots.txt file written for one purpose can produce a result nobody intended in the other.

So the honest reading is that access is a prerequisite and structure is not a documented requirement. The model below proposes what makes extraction go well once access exists, which is a weaker claim than saying it is what AI systems reward.

What one peer-reviewed study measured

The most frequently cited academic work in this area is GEO: Generative Engine Optimization, by Aggarwal and colleagues, published at KDD 2024. The paper introduces a benchmark of user queries with associated web sources, and reports that its methods can boost visibility by up to 40 percent in generative engine responses, measured with position-adjusted visibility metrics of its own construction.

Two findings from that work are relevant to a content model. The methods that performed best in the study were content changes that added verifiable material: adding citations to credible sources, adding direct quotations, and adding quantitative statistics. The method drawn from traditional search practice, keyword stuffing, showed little to no improvement and performed worse than the unmodified baseline on some measures. The paper also reports that effectiveness varies by domain, so the gains are not uniform.

The limits deserve equal weight. This is one study, on one benchmark, against the generative systems available at the time it was run, using visibility metrics the authors defined. It is evidence that structural changes to content can move measured citation behavior. It is not proof that any particular production system today behaves that way, and it should never be quoted as a description of what AI systems weigh.

The AIO Content Model: seven structural properties

AIOFacts proposes the following model. Each property is a structural test that can be applied to a draft before it is published, and each exists because of a failure mode that extraction makes possible.

The unifying idea is that every passage should survive being removed from its page. If a sentence taken alone would be ambiguous, undated, unattributed, or overstated, extraction will publish that defect rather than fix it.

• Self-contained passages. Each section, and ideally each paragraph, restates its subject rather than depending on a pronoun that refers to something several paragraphs earlier. A passage that begins with the phrase this approach has already failed the test.
• Explicit entity naming. Name the organization, product, standard, or person in full rather than writing we, the company, or the platform. Extracted text carries no context about whose site it came from.
• Question-shaped headings. Write the heading as the question the section answers, so the boundary of the section matches the boundary of a retrievable answer rather than cutting across it.
• Evidence adjacency. Put the source next to the claim it supports, inside the same passage, rather than collecting references at the end of the document. A footnote at the bottom of a page does not travel with a sentence lifted from the middle of it.
• Scope and date stamping. State when a claim was verified and what it applies to. Documented platform behavior changes, and an undated statement about a crawler or a feature becomes wrong silently.
• Terminological consistency. Use one term for one concept across the entire corpus, and define it once in a canonical place. Alternating between synonyms fragments the evidence a system can assemble about what you mean.
• Declared uncertainty. Mark what is unknown, disputed, or a position, inside the passage rather than in a disclaimer elsewhere. A caveat placed in a separate section is a caveat that extraction can strip away.

Where structured data actually fits

Schema.org describes itself as a collection of shared vocabularies webmasters can use to mark up their pages in ways that can be understood by the major search engines, and names Google, Microsoft, Yandex, and Yahoo as the founding sponsors. It is a real published vocabulary with a governance process, which distinguishes it from most of what is currently proposed for AI consumption.

Its role in this model is narrow and specific: it is the machine-readable statement of the same facts the visible text already states. Google's general structured data guidelines are direct about this. They instruct publishers not to mark up content that is not visible to readers of the page, require that markup accurately represent the page content, and state that structured data must not be used to deceive or mislead users or misrepresent ownership, affiliation, or primary purpose. The same guidelines note that correct markup does not guarantee a rich result.

Read alongside the AI features guidance, which says no special schema is needed for AI Overviews or AI Mode, the reasonable position is that structured data is an agreement mechanism rather than an entry ticket. It gives a second, unambiguous rendering of claims the prose already makes. Where the two disagree, the guidelines treat that disagreement as a problem with the markup.

Machine-readable files and the llms.txt question

The llms.txt proposal, published by Jeremy Howard in September 2024 and revised since, proposes adding a markdown file at a site root to provide what it calls LLM-friendly content, alongside clean markdown versions of individual pages. The proposal reports substantial adoption, including thousands of sites publishing such a file and major AI labs publishing their own.

Adoption by publishers is not the same as consumption by retrieval systems, and these two facts sit in tension. Google's AI features documentation states plainly that you do not need to create new machine readable files or AI text files to appear in its AI features. AIOFacts is aware of no platform documentation from a major assistant provider stating that an llms.txt file is read as a retrieval or ranking input.

The defensible position is therefore modest. Publishing clean, well-structured markdown of your own content is low cost and consistent with the model above, because it removes navigation and template noise from the text a system might process. Treating llms.txt as a mechanism that causes citation is not currently supported by anything checkable.

How to test this rather than believe it

The model is falsifiable in parts, and the parts should be tested separately. Access is the easiest: server logs will show whether OAI-SearchBot and the other named crawlers actually reach your pages, and robots.txt and snippet directives can be read back to confirm they say what you intended. Google's guidance on helpful, reliable, people-first content asks whether it is self-evident who authored the content and whether background is provided about how automation or AI generation was used, which are structural properties a page either has or does not.

Citation outcomes are much harder to test honestly. Assistant answers vary between sessions, between users, and over time, and a page appearing in an answer does not establish which of its properties caused that. Anyone reporting a causal result from a small number of prompts is reporting noise. The available evidence indicates that structural changes can move measured visibility, per the GEO study, but the reliable measurement of that effect on a live site remains an open problem rather than a solved one.

AIOFacts publishes this model as a working proposal and expects to revise it. If platform documentation appears that contradicts any part of it, the documentation wins and this page will be corrected.