> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synscribe.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Why Documentation Matters for SEO, GEO, and Agent Discovery
> See how documentation helps users complete tasks and gives search engines and AI agents evidence for discovering, evaluating, and recommending a product.
Documentation matters for SEO, GEO, and agent discovery because it connects a practical question to
a concrete product capability. Existing users can use the answer to complete a task. Search engines
can rank it for the task, and AI agents can retrieve it as evidence while evaluating or recommending
the product.
That means documentation creates value both before and after someone chooses the product. Before
selection, it makes the capability findable and defensible. After selection, it helps a person or
agent use the capability correctly without guessing.
This lesson uses three observed examples to show how that happens:
* Promptwatch found that how-to content and documentation together made up **8.2%** of the ChatGPT
citations it classified in its study period.
* ChatGPT recommended Attio first for an agent-controlled CRM use case after searching Attio's
official documentation and citing its MCP capability.
* A narrow Bun guide appeared fourth in a captured Google search for `create simple HTTP server`.
These examples do not prove that publishing documentation automatically produces rankings or
recommendations. They show why documentation belongs in both the product-support strategy and the
product-discovery strategy.
## Documentation supports use, discovery, and product selection
By the end of this lesson, you should be able to:
* explain the two moments in which documentation creates value;
* describe why a focused documentation page is useful to a search engine or agent;
* separate an observation from the conclusion it can reasonably support;
* connect better documentation to a support or growth outcome;
* recognize the pattern shared by the Promptwatch, Attio, and Bun examples.
## How documentation creates value before and after product selection
Most teams recognize the value on the right side of this sequence:
```text theme={null}
A user chooses the product → reads the documentation → completes the task
```
Discoverable documentation can enter one step earlier:
```text theme={null}
A person or agent asks a question → finds a focused documentation page
→ understands that the product can do the job → chooses or tries the product
```
This gives documentation two audience jobs and two organizational outcomes:
| Documentation job | Value for the audience | Potential value for the organization |
| ------------------------------------------- | ------------------------------------------- | --------------------------------------------------------------------------- |
| Help people and agents **use** the product | Complete a task correctly without guessing | Fewer repeated support questions, faster activation, fewer avoidable errors |
| Help people and agents **find** the product | Discover and evaluate a relevant capability | More qualified discovery, consideration, trials, and users |
The second outcome is possible because search engines and answer engines need sources. A product
capability that exists only in a sales call, a dashboard label, or an internal explanation is
difficult for an external system to retrieve and verify. A public page gives the capability a stable
URL, a name, an explanation, and evidence.
## Promptwatch: how-to and documentation made up 8.2% of classified ChatGPT citations
[Promptwatch analyzed 1,027,802 classified ChatGPT citations](https://promptwatch.com/data/chatgpt-citation-types-over-time)
from 1 January to 4 February 2026. In that sample:
* **How-To** pages accounted for **5.9%** of classified citations.
* **Documentation** pages accounted for **2.3%**.
* Together, those two categories accounted for **8.2%**, or roughly one in twelve classified
citations.
### What the Promptwatch citation data supports
How-to content and documentation form a meaningful part of the material ChatGPT cites. They are not
only destinations for people who already know the product name.
This makes sense from first principles. Many questions sent to an answer engine are practical:
* How do I complete this task?
* Which product supports this workflow?
* What is the correct request or configuration?
* Why did this operation fail?
A good how-to or documentation page is built to answer exactly that kind of question. It names the
task, explains the mechanism, and provides steps or technical facts that an answer can use.
### What the Promptwatch citation data does not prove
The chart does not show that documentation is the largest citation category, that every
documentation page will be cited, or that changing a title will cause an 8.2% gain. Promptwatch also
notes that its chart includes only citations it classified and that the mix of source types changes
over time.
Treat the result as evidence that these page types participate in AI discovery, not as a guaranteed
ranking formula.
## Attio: dedicated MCP documentation supported an agent recommendation
The Attio example begins with a broad product-selection question, not a branded search:
> what crm can i use that an ai agent can control and help me do my crm tasks
In the captured result, ChatGPT considered Attio, HubSpot, Pipedrive, and Salesforce. It recommended
Attio first for an AI-agent-centric setup and supported that recommendation with Attio's official MCP
integration, REST API, and webhooks. The result cited Attio's documentation.
The relevant source is not a vague AI landing page. It is Attio's dedicated
[MCP documentation page](https://docs.attio.com/mcp/overview). The page makes the capability easy to
understand and retrieve by answering a predictable sequence of questions:
1. What is Attio MCP?
2. Why would someone use it?
3. What can an agent do with it?
4. How is it connected?
5. Which tools are supported?
6. What could a user ask an agent to do?
7. What are the rate limits and security conditions?
Its supported-tools table pairs machine-oriented tool names with plain-language descriptions and
example prompts. An evaluator can move from “I need an agent-controlled CRM” to concrete operations
such as searching, creating, updating, and deleting records.
### Why Attio's MCP page is useful to an AI agent
An agent cannot reliably recommend a capability it cannot identify. The Attio page turns an abstract
claim—“our CRM works with AI agents”—into a source that answers four retrieval questions:
| Retrieval question | Evidence on the page |
| ----------------------- | --------------------------------------------------------- |
| What is the capability? | A hosted MCP server for connecting AI tools to Attio |
| What can it do? | A named inventory of supported operations |
| How is it used? | Setup instructions, endpoint details, and example prompts |
| What constrains it? | Rate-limit and security information |
That specificity gives an answer engine something it can use to explain *why* the product fits the
request. The documentation does more than make Attio mentionable; it makes the recommendation
defensible.
### What the Attio recommendation does not prove
This is one captured result. It does not prove that Attio will always be recommended ahead of
HubSpot, or that the MCP page was the only cause of the recommendation. Product fit, brand knowledge,
other sources, the model, and the wording of the prompt can all change the answer.
The defensible lesson is narrower: when the model looked for evidence of an agent-controllable CRM,
Attio had a dedicated first-party page that clearly described and demonstrated that capability.
## Bun: a task-specific documentation page ranked for a generic search
The Bun example shows the same principle in traditional search. In the supplied Google result for
`create simple HTTP server`, Bun's guide ranked fourth with the title
[Write a simple HTTP server](https://bun.com/docs/guides/http/simple).
The result works without requiring the searcher to know Bun. Its title leads with the job the person
wants to do. The product becomes the way to complete that job.
Bun repeats this task-shaped pattern across focused guides:
| Developer's task | Bun page |
| ---------------------------------- | ---------------------------------------------------------------------- |
| Build a Remix application | [Build an app with Remix](https://bun.com/docs/guides/ecosystem/remix) |
| Create a basic HTTP server | [Write a simple HTTP server](https://bun.com/docs/guides/http/simple) |
| Reload a server during development | [Hot reload an HTTP server](https://bun.com/docs/guides/http/hot) |
Compare the focused title `Write a simple HTTP server` with a broad title such as `HTTP` or
`Bun.serve reference`. The focused version tells a searcher, search engine, or agent:
* which task the page owns;
* what outcome to expect;
* why this page differs from neighboring HTTP pages;
* which page to retrieve for this exact question.
The snippet reinforces the promise by describing the observable result: a server listening on a
port and returning a response. The page is therefore useful in both stages. It can be selected for a
generic task, and it can help the reader perform that task with Bun.
### What the Bun search result does not prove
A search-result position is a snapshot. It can vary by date, location, device, and search-result
changes. The screenshot does not isolate which ranking factor produced position four.
What we can observe is that a product documentation page matched a non-branded task query with a
narrow title and a page dedicated to the requested outcome.
## How documentation enters search and agent discovery
The three examples operate at different levels, but they fit one discovery chain:
```text theme={null}
1. A person asks a practical or product-selection question.
2. A search engine or agent looks for a source that answers it.
3. A focused documentation page makes a capability or task easy to identify.
4. The source is retrieved, ranked, or cited.
5. The product enters consideration and the page helps the task continue.
```
The page must succeed at both halves of the chain. A discoverable page that cannot deliver its
promised task disappoints the reader. A complete page with a vague identity may never be selected.
This is why the course evaluates documentation with two verbs:
* **Find:** Can a person, search engine, or agent identify the right page for the question?
* **Use:** After selecting it, can a person or agent complete or verify the answer?
## Audit one product capability for documentation discovery
Choose one important product capability and answer these questions:
```text theme={null}
Question a potential user would ask without knowing our product name:
Public page that should answer it:
Can the page title identify the task or capability on its own? yes / no
Does the opening directly explain how our product satisfies the need? yes / no
Does the page show concrete steps, operations, or evidence? yes / no
Could an agent cite the page to justify a recommendation? yes / no / unknown
Could an existing user complete the task from the page? yes / no / unknown
```
If no single page owns the answer, the capability is harder to discover and harder to use. The next
lesson gives you the model for evaluating what that page must do.
Continue to
[What Makes a Good Documentation Page](/theory/documentation-site/what-makes-a-good-documentation-page).