Search without a search service¶
Adding search to a documentation site usually means adding a dependency: an Elasticsearch cluster to keep alive, or a hosted index that sees every query your readers type. For a site of a few dozen pages, both are the wrong size of answer.
The index is a build artefact¶
Material for MkDocs builds a lunr.js index at publish time and ships it as a single JSON file alongside the pages. The browser downloads it once and searches locally. There is no query that leaves the reader's machine, no service to run, and nothing that can be down while the site is up.
The trade is index size. It grows with the corpus, and somewhere past a few hundred pages the download stops being free. At that point the honest options are a real search backend or splitting the site — not pretending the client-side index still fits.
What that costs here¶
Nothing operationally. The whole search feature is one line:
It is worth knowing what you give up: no typo tolerance beyond what lunr does natively, no analytics on what people searched for, and no ranking you can tune. For a site whose job is to be readable rather than to be optimised, that is a good trade.