How to Structure a Knowledge Base for AI Search

Your knowledge base is indexed. AI search cannot use it.

That is the gap this article addresses. Indexing means a crawler reached your pages and recorded them. Citability means an AI system retrieved a specific section, understood it without surrounding context, and trusted it enough to surface as an answer. Those are two different standards, and most documentation sets are built for the first while failing the second.

This article is written for the person who owns the documentation set at a B2B manufacturer, distributor, or ecommerce business. You can edit templates. You can publish schema. You are not an SEO. What you need is a structural framework that tells you exactly how to build pages that AI systems can retrieve, extract, and cite.

The thesis is simple: a knowledge base does not become AI-search ready because it has clean navigation or valid schema. It becomes AI-search ready when each page and each section works as an independent retrieval unit, answers a specific sub-question completely, and exposes verifiable facts that a machine can lift without losing context.

This article covers:

• Why the difference between indexability and citability changes how you write every page
• How AI systems decompose broad queries into sub-questions and what that means for your page structure
• The information architecture rules that govern hierarchy, splitting, and page scope
• A reusable template for every knowledge-base article
• How to handle sequential and chronological content
• Glossary and definitional page architecture
• Structured data that is still valid and where it actually helps
• How to find and fix duplication and contradiction across your documentation set
• How to maintain what you build so it does not decay

One honest scope note: this article covers on-site structure. Whether AI systems cite your knowledge base at all also depends on third-party corroboration, which is a separate problem covered in where AI citations actually come from.

Indexability Is Not Citability

A page that is indexed has passed one test. It is reachable, it is recorded, and it appears in a search engine’s database. That is the minimum requirement for visibility. It is not the standard for AI citation.

Answer engine optimization starts with understanding how AI systems actually retrieve content. They do not read a page the way a human does, from top to bottom. They extract fragments. A section gets pulled, evaluated in isolation, and either used or discarded. If that section requires context from three paragraphs above it to make sense, it fails the extraction test. The page stays indexed. The section never gets cited.

That gap has a measurable shape. One page on this site, covering why structure determines whether AI can use your content, sits at average position 61.8 in Google web search with zero clicks from 496 impressions over 90 days. The same page is simultaneously the most-cited Wenstein asset in Bing’s AI answers, with 455 citations in the same period. Same page. Near-invisible in web search. Most-quoted in AI answers. That is the difference between indexability and citability expressed as data rather than argument.

How AI Systems Decompose a Query

When someone submits a broad question to an AI system, the system does not search for one page that answers everything. It breaks the question into smaller sub-questions, retrieves evidence for each, and synthesizes a response. This is the retrieval-augmented generation pattern that now underlies most AI search products.

Microsoft Research’s Chain-of-Retrieval Augmented Generation (CoRAG, NeurIPS 2025) formalizes this behavior: rather than performing a single retrieval step, a system generates a chain of sub-query and sub-answer pairs, each step dynamically reformulating the next query based on what the previous step returned. The practical consequence for your knowledge base is that a broad question does not produce one retrieval event. It produces several, each targeting a narrower sub-question.

A question like “how do I set up approval workflows in your system” might decompose into:

• What is an approval workflow in this product?
• Who can create or modify approval workflows?
• What are the step-by-step setup instructions?
• What conditions or limits apply?
• What happens if the workflow fails?

Each sub-question is a retrieval event. If your knowledge base has one long article that buries the answers to all five inside a narrative, the system may retrieve none of them cleanly. If you have five sections, each opening with a direct answer to its sub-question, the system can retrieve all five and cite the relevant ones.

Google Research’s Sufficient Context study (ICLR 2025) adds a second constraint: retrieval systems evaluate whether a retrieved snippet contains enough information to answer the sub-question on its own. A snippet that depends on surrounding context to be interpretable fails that test, even if the full page is accurate. The implication is not just that you should write clearly. It is that each section must be self-sufficient, with its own answer, its own conditions, and its own definitions.

This is the structural implication: write for sub-questions, not for topics. A topic is a container. A sub-question is a retrieval unit.

Conversational search optimization is not a new channel. It is a stress test that reveals whether your documentation is built for retrieval or only for reading. Most knowledge bases fail it, not because the content is wrong, but because the structure assumes sequential reading in an environment that demands independent extraction.

Key distinction: Indexability is a crawl outcome. Citability is a structural outcome. You control the second one.

Information Architecture Rules for a Retrieval-Ready Knowledge Base

Structure is not cosmetic. The hierarchy you choose, the depth you allow, and the rules you use to split or consolidate pages all determine whether AI systems can navigate and extract from your documentation.

Microsoft Research’s PIKE-RAG framework identifies inappropriate segmentation as a primary cause of retrieval failure in domain-specific knowledge bases, stating directly that it “disrupts semantic coherence and leads to inefficient data retrieval.” The solution PIKE-RAG demonstrates is context-aware segmentation that preserves the document’s original hierarchical structure. For a knowledge base publisher, that means the structural decisions you make before writing determine whether downstream retrieval systems can extract coherent answers at all.

Hierarchy Depth and Category Width

A knowledge base built for AI retrieval needs a hierarchy that is shallow enough to be navigable and specific enough to be meaningful. In practice, that means:

• Top-level categories should map to distinct user goals, not internal product divisions. A user asking a question does not know how your product is organized internally.
• Deeper hierarchies add retrieval friction. A page buried several levels down is harder to reach, harder to contextualize, and less likely to accumulate the authority signals that make it citable. Keep the structure as flat as the content genuinely allows.
• Category width matters less than category clarity. Fewer, cleaner categories with well-scoped articles outperform broad categories with overlapping content.

When to Split a Page and When to Keep It Together

This is the decision most documentation owners get wrong. The rule is not “one topic per page.” The rule is: one primary retrieval unit per page.

Split a page when:

• It answers more than one distinct sub-question that users would search for independently
• The page has grown long enough that a user scanning for one answer has to read through unrelated content
• Two sections contradict each other because they were written at different times for different product versions

Keep content together when:

• The sub-questions are genuinely sequential and cannot be understood out of order
• Splitting would require each child page to repeat the same context, creating duplication
• The combined page is still short enough to extract from cleanly

Glossary and Definitional Pages

Every technical term your product uses is a retrieval opportunity. DefinedTerm schema gives you a machine-readable way to declare that a page defines a specific term. A well-built glossary creates a layer of definitional authority that AI systems can reach when a user asks “what is X” in your domain.

The Wenstein glossary is a worked example of this architecture applied at scale: 193 terms across 35 pages, each entry carrying DefinedTerm and DefinedTermSet markup, with 28 of the 35 pages indexed by Google within one day of publication without a manual indexing request. The speed of indexation reflects how clearly the schema signals content type to crawlers. For a closer look at how those pages are built for both search and retrieval, see how we build glossary pages.

Define terms locally on every article page as well. Do not assume the reader has visited your glossary. If a section uses a term that needs definition, define it in that section. Retrieval systems pull sections, not sites. A term that is undefined in the extracted section is a gap in the answer.

The information gain test: before publishing any page, ask whether it adds something a reader could not get from the pages that already exist. If it does not, it competes with your own content for the same retrieval slot.

Structured Data: What Still Works and What Does Not

Structured data is not an AI citation lever. It is a machine-readability layer. Understanding the difference will save you from implementing markup that no longer does what you expect.

What Changed in 2026

Google deprecated FAQ rich results on May 7, 2026. The FAQPage documentation was subsequently removed from Google Search Central. FAQPage schema remains a valid Schema.org type, and you can still implement it accurately. What it will not do is trigger a Google rich-result display. If your team was adding FAQPage markup to earn a visual SERP feature, that rationale is gone.

HowTo schema had already been narrowed before this. It is still valid for genuinely procedural pages, but it is not a current mainstream Google rich-result opportunity for most publishers.

Google Search Central’s AI features guide is unambiguous: “There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary” and “There’s also no special schema.org structured data that you need to add.” The directive is to focus on useful, accessible content and standard technical hygiene. Invented “AI schema” tactics are not supported by any current platform documentation.

Microsoft’s Bing follows the same direction. Bing’s Webmaster Guidelines point to content quality, crawl accessibility, and accurate structured data as the relevant signals. Neither Microsoft nor Google has published a schema type that specifically unlocks AI answer inclusion.

What Structured Data Still Does

Markup still serves two real functions:

• Machine readability: structured data tells crawlers, AI systems, and other automated readers what a page is about, who it belongs to, and what type of content it contains. This is useful even without a visible SERP feature.
• Interoperability: valid schema makes your content more portable across systems that consume structured data, including third-party AI products, knowledge graph systems, and voice interfaces.

Use DefinedTerm schema for glossary entries. Use FAQPage where it accurately describes the visible page content. Use HowTo only when the page is genuinely procedural and the markup mirrors the visible steps exactly. Use Article schema for editorial content.

Google Search Central states the rule plainly: keep markup only when it accurately describes visible page content and serves a practical purpose. Do not add it expecting a rich result or AI-feature boost.

An answer engine reads your visible content first. Schema reinforces what is already clear. It cannot substitute for structure that is not there.

The Knowledge-Base Article Template

Every article in your knowledge base should follow the same structural pattern. Consistency is not a style preference here. It is a retrieval signal. AI systems that encounter the same structure repeatedly across a documentation set learn to expect the answer in a predictable location.

The template has six components. Apply them in order.

1. Question as the Title

The title of every knowledge-base article should be the question a user would actually ask. Not “Approval Workflows.” Not “Managing Approvals.” The title should be “How Do I Set Up an Approval Workflow?”

Question-framed titles map directly to the sub-questions AI systems generate when decomposing a broader query. A title that matches a sub-question is a retrieval advantage.

2. Direct Answer First

The opening paragraph answers the question completely. Not partially. Not after context-setting. It gives a user everything they need to understand the answer, even if they read nothing else on the page.

This is the extraction test. If an AI system pulls only the opening paragraph of your article and presents it as the answer, it should be accurate and complete.

3. Conditions

State the conditions under which the answer applies. Which user roles can perform this action? Which product tiers include this feature? Which configurations change the behavior? Conditions prevent a correct answer from being applied incorrectly.

4. Procedure

For action-based content, use numbered steps. One action per step. One outcome per step. Each step should be independently understandable, because retrieval systems extract steps individually.

5. Limits

State explicitly what the feature does not do, what its boundaries are, and what error states or exceptions exist. Limits are the section most documentation skips and most users need.

6. Related Answers

End every article with links to related articles in your knowledge base. These links serve two purposes: they help users navigate to adjacent sub-questions, and they signal to retrieval systems that your documentation set has depth and coherence on this topic.

Use vector search principles when deciding which related articles to surface: link to the articles that are semantically closest to the current page’s primary question, not just the ones that are topically adjacent in your navigation hierarchy.

Sequential and Chronological Content

Sequential content, where the order of steps matters, and chronological content, where events or versions are organized by time, require different structural decisions than standard question-answer articles.

Sequential Content

When steps must be performed in order, the procedure section of the template is not enough on its own. You need to make the sequence explicit at the top of the page, before the steps begin.

State the sequence plainly: “This procedure has five steps and must be completed in order. Completing step three before step two will result in an error.” A user who arrives at step four via a direct search link needs to know immediately that they are mid-sequence.

Each step still follows the same rule: one action, one outcome, independently understandable. The difference is that each step should also state its prerequisite explicitly. “Before completing this step, confirm that step two is complete” is not redundant. It is the context that makes the step extractable without being misleading.

Chronological Content

Version histories, release notes, and policy change logs are chronological by nature. Structure them so the most recent entry is first. AI systems retrieving content about “current” behavior should reach the current version, not the oldest one.

For each version or time period, use a consistent heading format: “Version 4.2 (Released March 2026)” rather than just “Version 4.2.” The date makes the entry independently interpretable when extracted out of sequence.

Separate active documentation from archived documentation. A page that mixes current behavior with deprecated behavior creates retrieval ambiguity. If a user asks how something works today, the answer should not require the reader to determine which version applies.

The chronological structure test: if an AI system retrieved only one version entry from your release notes, would a user know whether it describes current or past behavior? If not, the entry needs a date and a status marker.

Comparison Pages and Decision-Format Content

A knowledge base is not only a help center. For B2B manufacturers and distributors, it is often the place where buyers make pre-purchase decisions: comparing configurations, understanding which product tier fits their requirement, or evaluating whether your system integrates with their existing stack.

Comparison content follows different structural rules than procedural content. The retrieval unit is not a step. It is a decision criterion.

How to Structure a Comparison Page

Each comparison page should answer one decision question: “Which option is right for me given condition X?” That question should appear in the title. The answer should appear in the opening paragraph, stated as a direct recommendation, not a neutral summary.

The body of the comparison page should then support that recommendation with:

• The criteria that drive the decision. Name them explicitly. Do not assume the reader knows what matters.
• How each option performs against each criterion. A table is the most retrievable format for this. Retrieval systems can extract structured tabular data more reliably than comparative prose.
• The conditions that change the recommendation. If the answer is different for a buyer with a specific configuration or scale, state that explicitly as a separate condition, not a footnote.

What Comparison Pages Are Not

A comparison page is not a feature list. A feature list answers “what does this product do?” A comparison page answers “which option should I choose and why?” If your comparison page does not contain a recommendation, it is a feature list with a misleading title.

A comparison page is also not a competitor takedown. The retrieval value of comparison content comes from its specificity and its usefulness to a buyer making a real decision. Content that exists to disparage a competitor rather than to help a buyer decide is less likely to be cited and less likely to be trusted.

The comparison page test: if you removed the product names and replaced them with “Option A” and “Option B,” would a reader still be able to make a decision from the page? If not, the decision criteria are not explicit enough.

Crawler Access and Bot Policy

Structure is irrelevant if the crawlers that feed AI systems cannot reach your pages. This section covers the access decisions that matter most.

GPTBot and OAI-SearchBot Are Not the Same

OpenAI operates two distinct crawlers with different purposes. The OpenAI crawler documentation states that each crawler setting is independent of the others. A publisher can allow OAI-SearchBot while disallowing GPTBot, or the reverse. The two decisions do not travel together.

The practical distinction: OAI-SearchBot is used to surface websites in ChatGPT’s search features. Sites opted out of OAI-SearchBot will not appear in ChatGPT search answers. GPTBot is used for model training. Blocking GPTBot affects training data inclusion. These are separate robots.txt decisions.

Most documentation on “allowing AI bots” treats these as interchangeable. They are not. Review your robots.txt entries for both separately and make an explicit decision for each.

What Blocks Retrieval Without Blocking Crawling

A crawler can reach a page and still fail to extract usable content. Common causes:

• Content in JavaScript-rendered elements that are not in the initial HTML response
• Content behind login walls or session-dependent states
• Tabs and accordions that hide content from the default page load
• Token limits: pages that are so long that retrieval systems only process the first portion

Keep critical answers in the visible HTML body. A page that requires JavaScript execution to reveal its most important content is a page that many retrieval systems will treat as empty.

The access rule: if the answer is not in the HTML that a crawler receives on first request, assume the answer is not retrievable.

Duplication and Contradiction Control

A knowledge base that has grown over time almost always contains two problems: pages that answer the same question in slightly different ways, and pages that contradict each other because they were written at different times.

Both are retrieval liabilities. When AI systems encounter two pages that answer the same sub-question, they may retrieve either, or neither, depending on which signals are stronger. When they encounter two pages that contradict each other, the contradiction reduces trust in both.

Finding Duplication

Run a content audit against your own knowledge base using these tests:

• Title similarity: if two article titles ask the same question, the pages are probably duplicates
• Opening paragraph similarity: if two articles open with nearly identical direct answers, they are competing for the same retrieval slot
• Search query overlap: if the same internal search query returns multiple results with similar content, users and AI systems are encountering the same ambiguity

When you find duplicates, consolidate into one canonical page and redirect the others. Do not leave both live with minor wording differences.

Finding Contradiction

Contradiction is harder to find because the conflicting information is often in different sections, different articles, or different product version pages.

The most reliable approach is to maintain a single source of truth for every factual claim. If a feature’s behavior is documented in three places, only one of those places should state the authoritative version. The others should link to it, not restate it.

The contradiction test: search your knowledge base for the same fact stated in multiple places. If the statements do not match exactly, one of them is wrong. Find which one is current, update it, and remove or link the others.

Maintenance and Decay

A knowledge base that is accurate today and ignored tomorrow becomes a retrieval liability. AI systems retrieve content and present it as current. If the content is not current, the answer is wrong, and the source that provided it loses trust.

What Decays and When

The sections most likely to decay are:

• Procedural steps tied to a UI that changes with product releases
• Limits and constraints that change as features are updated
• Conditions tied to pricing tiers or access levels that evolve
• Comparison content that references competitor behavior, which changes independently of your product

Google Search Central’s guidance on content for AI features emphasizes accuracy and currency. A page that was accurate when published but has not been reviewed since a product update is not a trustworthy source. It is a liability.

A Maintenance Schedule That Works

Attach a review date to every article at publication. Set the review interval based on content type:

Content type	Suggested review interval
Procedural how-to articles	Every product release cycle
Limits and constraints	Quarterly
Conceptual and definitional content	Annually or when the underlying concept changes
Comparison and alternative pages	Quarterly
Version histories and release notes	Ongoing; add entries at each release

When you review an article and confirm it is still accurate, update the “last reviewed” date visibly on the page. A visible review date is a trust signal. It tells both users and AI systems that a human has checked this content recently.

Do not delete outdated articles without redirecting them. A deleted page with no redirect breaks any link that pointed to it, including internal links from other knowledge-base articles. Redirect to the current version.

The Honest Ceiling

Everything in this article improves your knowledge base’s eligibility for AI retrieval. It does not guarantee citation.

AI systems cite sources they trust, and trust is partly a function of what happens off your site. Third-party coverage, community references, and external corroboration all influence whether an AI system treats your knowledge base as a reliable source or as a self-interested one. A perfectly structured knowledge base that no external source has ever referenced is still a knowledge base that AI systems approach with less confidence than one that has been cited, linked, and discussed elsewhere.

That problem has a different solution set. Where AI citations actually come from covers it directly.

Now It’s Your Turn.

Structure is a decision you make before you write. Most documentation teams make it after, when the problems are already embedded in hundreds of pages.

The framework in this article is not a rewrite project. It is a standard you apply going forward and audit backward. Start with your ten highest-traffic knowledge-base articles. Run each one against the template. Check whether the title is a question, whether the opening paragraph passes the extraction test, whether conditions and limits are stated explicitly, and whether related answers point to the right pages.

Then ask the harder questions:

• If an AI system extracted one section from your best-performing knowledge-base article today, would it make sense on its own, or does it depend on context from the sections around it?
• How many of your knowledge-base articles have titles that are topic labels rather than questions a user would actually ask?
• When was the last time you checked whether two articles in your knowledge base contradict each other?
• Does your robots.txt file make an explicit, deliberate decision about GPTBot and OAI-SearchBot separately, or does it treat all AI crawlers as one category?
• Is your glossary built as a retrieval layer, or is it a navigation convenience that no one uses?

If your documentation set needs a structural review before it can serve as a reliable AI retrieval source, that is the conversation worth having before you publish another article that compounds the existing problems.

Explore our answer engine optimization services to understand how we approach knowledge-base structure, retrieval readiness, and AI discoverability as an integrated advisory engagement.

---

Frequently Asked Questions:

---

You might find these articles worth reading as well:

• How to Structure a Knowledge Base for AI Search
• The Best AEO Agency May Not Be the One With the Best Pitch
• Answer Engine Optimization Starts With Structure.
• Conversational Search Optimization Is Not a New Channel. It Is a Stress Test.
• Most B2B AEO Strategies Are Built to Fail.