Developers search docs with half-remembered method names, error strings and questions. A docs search has to survive all three: match «getColections» to getCollections, keep v2 answers out of v3 results, and answer «how do I rotate a key?» with the paragraph that says so — and a link to prove it.
Create an ingest job from a sitemap, a list of URLs, or Markdown and HTML files. Re-run it from CI on every docs deploy.
Store them as facetable fields, so the search box can default to the reader's version and offer the rest as filters.
Bind an assistant to the same collection. Questions get a short answer with numbered sources; keyword lookups stay instant.
Identifier lookups — a function, a flag, an error code — need exact and prefix matching with typo tolerance, and must not be «understood» into something else. Topic searches — «webhooks retry» — need sensible ranking of guides over changelog noise. Questions need retrieval plus a grounded answer. One index serves all three: keyword and hybrid retrieval for the first two, the assistant for the third.
Guides, the API reference and the changelog rank differently and update on different schedules, so they work best as separate collections searched together. A single multi_search request returns them as sections of one dropdown — «Guides», «API», «Changelog» — in one round trip.
Zero-result analytics then tell you what your docs are missing: every query that found nothing is a page someone expected to exist.
Prefix search, typo tolerance and configurable token separators keep camelCase names, dotted paths and flags findable.
A filter on version and product keeps results inside the reader's context; facets offer the way out.
The assistant answers from your docs only and returns the passages it used, so every claim links back to a page.
The MCP server gives Claude, Cursor and other agents the same search over your docs that humans get.
{
"searches": [
{ "collection": "docs_guides", "q": "rotate api key", "query_by": "title,headings,body",
"filter_by": "version:=v3", "per_page": 5 },
{ "collection": "docs_api", "q": "rotate api key", "query_by": "operation,summary",
"filter_by": "version:=v3", "per_page": 3 }
]
}
// -> one response, two sections: Guides, API referenceExplore more
The best way to evaluate a search platform isn't reading one more comparison table.
Only then make the decision.