A search index is a named list of page types. It decides what a reader’s search box is allowed to find, and it is the one thing you configure for search — everything else is built for you. Both of Leed’s search implementations read this same record: the prebuilt index that ships inside your site, and the live endpoint described on Live Documentation Search. Create the index once and the right implementation picks it up.
What a search index is
An index holds a Title and a list of Page Types. That is the whole record. It is not a search engine setting, it has no relevance knobs, and it holds no content of its own — the content is collected from your published pages every time the site builds.
Because it is a list of page types rather than a list of pages, you never maintain it as your documentation grows. A page added to a covered page type is searchable at its next publish.
The screen is named three different ways in the product, and all three lead to the same place: the settings menu calls it Search & Autolinks, the settings home card calls it Search & autolinks, and the panel header on the page itself reads Search Indexes.
Creating an index
- Open Settings → Search & Autolinks. The panel is headed Search Indexes, with the description “Manage search indexes for your documentation and API pages.”
- Choose Create Search Index.
- Give it a Title. This is required — the dialog refuses with Title is required if you leave it blank.
- Select the Page Types it should cover. You can select several, and you can leave the list empty and fill it in later.
- Choose Create.
An existing index expands into the same two fields, and both save as you edit: the Title saves a second after you stop typing, and a change to the Page Types list saves immediately.
Creating and editing indexes needs page-type write access, so a reader-only account sees the list without the Create Search Index control.
Binding an index to a documentation set
An index does nothing until a set points at it. On the documentation or API page type, under Configuration Overrides, set the Search Index field.
The select lists your indexes by name. Not Set is the unbound state, and until you leave it, that set’s search box has nothing to search — the modal still opens, and finds nothing. When the field carries a company-level default it is annotated “(company default)” and the Not Set option is not offered; pick an index explicitly to override it.
An index can only cover page types that already exist, so build the set first — Creating a Documentation Set walks that flow, and the Search Index field is on the same panel as the rest of the set’s configuration.
What the build produces
On the prebuilt path, every build walks the rendered pages of every page type named by an index and writes one compact index per search index into your site’s static files. The reader’s browser downloads it on first search and queries it locally — no search server, and nothing leaves their machine.
Pages belonging to no index are skipped entirely, so an unlisted page type is not merely unranked, it is absent.
Documents are heading sections, not pages
Each page is split at its headings, and every section becomes its own searchable document. A result therefore points at a heading anchor rather than the top of the page, and its title reads Page title - Heading. That is why a hit on a 4,000-word reference page drops the reader at the row they were looking for. A section contributes up to 5,000 characters; anything past that is truncated.
How a result is ranked
| Extracted from | Weighted as | Notes |
|---|---|---|
| Page title | Highest | Carried on every section of the page, so the title works even for a deep section hit |
| Labels | High | The label names, not their ids |
| Page type name | Moderate | Lets a reader narrow toward “API” or “Guides” by typing it |
| Section body | Baseline | Up to 5,000 characters per heading section |
The built files are stamped with a hash of their own content and requested with that hash in the URL, so a reader never gets yesterday’s index out of a browser cache after you publish.
Scoping an index
Because an index is a list of page types, scoping is a matter of deciding which boxes should find which content.
| Goal | Index setup | Result for the reader |
|---|---|---|
| Keep the product docs and the API reference separate | One index per set, each naming a single page type | Searching from the docs never surfaces endpoint pages, and the reverse |
| One search across guides and reference | One index naming both page types, bound to both sets | The same results wherever they search, with the page type shown on each hit |
| Surface release notes from the docs | Add the posts page type to the documentation index | Release notes appear in documentation search without joining the docs navigation |
Several indexes can coexist, and several sets can share one. What you cannot do is give a single set two indexes — the field holds one.
The index is also a permission boundary
With live search, the searchable universe is resolved on the server from the page the reader is on: their current page type, then the index bound to it, then that index’s page types. The browser never names an index and never sends a page-type list of its own. A filter that points outside the resolved set is rejected rather than quietly widened.
The practical consequence is worth stating plainly: the index is the only control over what a reader can reach through search, and a reader cannot widen it by editing a request. If a page type should not be findable from a given set, keep it out of that set’s index.
The same record scopes what your readers’ AI clients can search over MCP, so an index change moves both surfaces at once — Docs MCP Tool Reference covers the tool side of it.
Publishing an index change
Index changes are their own item in the publish flow, labeled Search Indexes, and they take effect on the next build. Until then readers keep searching the index that shipped with the last deployment.
An index with unsaved-to-the-site changes shows an unpublished-changes indicator on its row, the same marker every other publishable record uses. Index changes go out alongside everything else described in Publishing a Documentation Set.
One exception is worth knowing: a live-search site picks up an index edit as soon as it is saved in the CMS, because the endpoint reads the record rather than a built file. A prebuilt-search site needs the build.
What a reader actually sees when they open search — the modal, the keyboard shortcut, the result list — is the same on both implementations and is documented at Site Search for Readers. Which page types exist to put in an index in the first place is at Page Types.