Your docs site probably shouldn't have a search bar.
I know that sounds wrong. Every docs template ships with one. Every competitor has one. The instinct, the second you publish a handful of pages, is to wire up Algolia, drop a Cmd+K hint in the header, and call it professional. Skip it. If your docs site is under fifty pages and your navigation is even slightly organized, a search bar does nothing useful and often does real damage.
The reason is boring: humans scroll faster than they search. Scrolling is one movement. Searching is a decision, a typed query, a scan of results, a click, and then you're reading anyway. On a small docs site, the total time-to-answer is shorter when the user ignores the search bar entirely and uses the sidebar. If that's true, the search bar isn't just redundant. It's a detour your reader has to mentally reject every time they land on a page.
The search bar tells users your docs are messy
A search bar is a signal. It tells the reader "we have so much content that you probably won't find what you need by browsing." For a two-person SaaS with eighteen docs pages, that signal is a lie, and readers can feel it. They open your docs, see the search bar, assume there must be a lot buried behind it, and then feel frustrated when the obvious page they need isn't surfacing in the top three results.
I've clicked around a lot of small SaaS docs sites in the last year. Here's the pattern I keep seeing. A four-section sidebar with maybe twenty total pages. A prominent Cmd+K search in the header. I type a reasonable query. The top result is a stale blog post that got indexed accidentally. The second result is a heading from a page I was already on. The third is the page I actually wanted, one click away from the homepage via the sidebar anyway. The search bar turned a ten-second task into a thirty-second task and made the product look less polished in the process.
Bad search is worse than no search. Confluence is the classic example. It has a search bar on every page, and the search bar is how you discover that Confluence can't find anything written more than six months ago unless you remember the exact title. Older GitBook spaces had the same problem. A poorly-configured Algolia index, where nobody tagged or weighted properly, will confidently return the "Changelog 2023" entry when the user searches for "auth." Every time search fails, the reader updates their priors about whether your docs can be trusted. That's a much bigger cost than people realize.
Good navigation is what a small docs site actually needs. A sidebar that groups related pages under three or four clear category labels. Page titles that describe their content in four words or fewer. A homepage that functions as a table of contents, not a marketing splash. Breadcrumbs for anything nested more than two levels. If you've done that work, scrolling and clicking beats search. If you haven't done that work, adding search doesn't fix the underlying mess, it just hides it. This is the same logic behind good knowledge base design: structure first, then worry about retrieval.
When search is actually worth it
Fine. Let me give the other side its fair due. At scale, search becomes necessary. The threshold, from what I've seen watching real docs sites operate, lands somewhere around fifty pages of substantive content. Not fifty stub pages. Fifty pages where a user might plausibly spend more than a minute reading each one.
The other trigger is cross-reference density. Some docs sites have twenty pages but each page references eight other concepts, and readers regularly jump sideways across the taxonomy instead of drilling down through a sidebar. Stripe's API docs are a fair example. So are large open-source framework docs where the same primitive (say, middleware, or hooks) is discussed across auth, caching, routing, and error handling pages. There, navigation fundamentally cannot replicate how users actually move through the content, and search earns its place.
The third trigger is versioned docs. If you maintain separate docs for v1, v2, and v3 of an API, a reader coming in from Google often lands on the wrong version and needs search to confirm the concept exists on their version too. This is rare but real, and if you've hit it, you already know.
Outside those three cases, you're better off investing the same hours into tighter documentation organization than into configuring Algolia. Reorganize the sidebar. Collapse redundant pages. Rewrite titles so they describe content, not marketing themes. The ROI on navigation work compounds across every page view. The ROI on a search bar only kicks in the fraction of the time a reader actually uses it, which on small sites, per my own skimming habits and those of basically everyone I've asked, is rare.
Add search when
Add a search bar when at least one of these three things is true:
Your site crosses fifty pages of real, substantive content and your sidebar is starting to require scrolling itself. Your content is heavily cross-referential and readers can't predict which category a concept lives under. You maintain multiple versions of the docs and users frequently land on the wrong one.
If none of those three is true, skip it. Your readers will not miss it. They will, quietly, appreciate that your docs load faster, look cleaner, and signal "this is a small product with focused docs" instead of "this is a product so sprawling we gave up on organizing it." The search bar is table-stakes software thinking, and table-stakes thinking is what produces docs nobody actually reads.
A small docs site with no search bar and a great sidebar beats a small docs site with a search bar and a mediocre sidebar, every time. The ordering of the work matters. Navigation first. Page count growth second. Search bar, only if and when the first two force the issue. Most teams trying to figure out what to document for their MVP are nowhere near that threshold yet, and pretending otherwise just adds surface area you'll have to maintain.
If you're going to be the team that ships search anyway because the header looks empty without it, at least promise yourself you'll measure its use. If fewer than five percent of your sessions touch it in the first month, it was a tell, not a tool. Take it down.