Search on your own website: when you need it and how we do it without a server
When a business website benefits from its own search, and how a static site provides fast search without a server.
The short answer
A website with a handful of pages needs clear navigation, and a search box on it is clutter that mostly returns nothing. A website with a knowledge base of dozens or hundreds of articles, a catalogue, a document library or a long archive needs search, because visitors arrive with specific questions that navigation cannot anticipate. The traditional way to provide it is a server running queries against a database, or a third-party search service with a script and a subscription. A static site does not need either. At build time the pipeline reads every page and produces a compact search index split into small chunks; the visitor’s browser loads a tiny core and fetches only the chunks a query needs, so searching hundreds of pages transfers a few kilobytes and returns in milliseconds. There is no server, no database, no third-party service and no visitor data leaving the site. Good site search then shows results as you type, highlights matches, handles typos and synonyms sensibly, and records what people searched for and did not find, which is one of the best sources of content ideas a business has.
When search is needed and how it is provided
| Site | Search needed? | How |
|---|---|---|
| Brochure site, up to a few dozen pages | No; navigation and a clear site map | None |
| Knowledge base or blog with dozens to thousands of articles | Yes | Static index built at build time; instant in the browser |
| Product catalogue of modest size | Yes, with basic filtering | Static index with filters on structured fields |
| Document library | Yes | Static index including document text where extractable |
| Large store with faceted filtering | Yes, complex | The store platform’s search or a hosted search service |
| Application searching live user data | Yes, dynamic | Search built into the application’s data layer |
What good site search does
- Appears where expected: in the header on sites that need it, with a keyboard shortcut for the people who use those.
- Responds as you type, with results in well under a second.
- Shows context: the page title, the matching excerpt with the match highlighted, and the section it belongs to.
- Forgives: partial words, typos within reason, and synonyms the business knows its customers use.
- Filters by type or section where the content has structure.
- Handles no results with suggestions and a route to contact, never a dead end.
- Records queries, especially those with no results, anonymously, for the content team.
- Works without JavaScript at a basic level, or falls back to a clear alternative.
What the search log tells you
The queries with no results are content the audience wants and the site does not have, in the audience’s own words. The queries with results that nobody clicks are content that exists but is titled or written in the wrong language for its readers. The most frequent queries are what the navigation should surface directly. A monthly look at the log is one of the cheapest content strategies available, and it comes free with a search that records queries.
What this means for you
Add search when the site has enough content that navigation cannot expose it all, and build it as a static index that searches instantly in the browser without a server, a database or a third party. Make it forgiving, contextual and honest about no results, and read the query log monthly for what your audience is asking. On a small site, leave the box out and make the navigation do its job.
Frequently asked questions
Does our website need a search box?
If a visitor can find anything within two clicks from the navigation, no; a search box on a ten-page site is clutter, and its empty results frustrate. If the site has dozens of articles, products or documents, yes, because navigation cannot expose them all and visitors arrive with specific questions. The threshold is roughly where the site map stops fitting on one screen.
How can a static site search without a server?
At build time, the pipeline reads every page and produces a compact search index, broken into small chunks by word fragments. The browser loads a tiny core and then fetches only the chunks relevant to what the visitor types, so a search across hundreds of pages transfers a few kilobytes and returns in milliseconds. Nothing runs on a server; the index is files on the edge network like the rest of the site.
What about very large sites or complex filtering?
Static indexing handles thousands of pages comfortably. A store with faceted filtering across tens of thousands of products, or an application searching live user data, uses a hosted search service or the platform's own search. For business websites, knowledge bases and catalogues of modest size, the static approach covers the need without another service to pay for and secure.
Sources
- Pagefind documentation (accessed 2026-09-12)