Static sites are fast precisely because there’s no dynamic layer at request time. That same property makes adding search a deliberate architectural choice rather than a configuration toggle. The options are better than they were five years ago, but picking the wrong one still means latency, cost, or operational complexity you’ll regret.
Why static search is a distinct problem
On a server-rendered site, a search box fires a database query. On a static site, you have pre-built HTML and nothing to query at request time. The three viable approaches each handle that constraint differently:
- Client-side search: ship the index as a compressed file, load it in the browser, and query it there.
- Hosted search-as-a-service: send queries to a third-party API (Algolia, Typesense Cloud) that runs the index on its own infrastructure.
- Self-hosted search server: run a lightweight server (Meilisearch, Typesense) alongside your static files to handle queries.
Most Jamstack projects should start with option one.
Client-side search: the right default for most sites
For documentation sites, blogs, and marketing sites with fewer than a few thousand pages, client-side search is the cleanest approach. No API keys, no dependency on a third-party service, no extra server to maintain.
Two tools dominate this space today. Pagefind is a post-build binary that crawls your output directory and generates a compressed, chunked index, then ships a small JavaScript bundle to query it. It integrates with virtually any static site generator (Astro, Eleventy, Hugo, Next.js static export) because it operates against rendered HTML, not your source files. Users download only the index chunks relevant to their query. For a typical blog, the search UI is functional with about fifteen lines of configuration.
Fuse.js is a JavaScript fuzzy-search library. It’s flexible and easy to drop into existing code, but it requires you to build and ship the index yourself, usually as a JSON file generated at build time. For smaller sites that already have a CMS feeding data into a build step (which you may already be thinking about if you’ve read our post on choosing a headless CMS), Fuse.js is a natural fit.
The trade-off worth understanding is index size. Client-side search loads the full index before any query can run. Pagefind handles this well through chunking. Fuse.js does not unless you implement it yourself. If your content library is large, that upfront load will show up in performance measurements, and you should know that before you commit.
Client-side search is often dismissed as a hack. It isn’t. For most content sites, it’s the most reliable architecture: no API round-trip, no external service dependency, and no cold-start latency on the first query.
When to move to a hosted service
Hosted search services earn their cost when client-side falls short. The clearest signals:
Your index is too large to ship. If your site has tens of thousands of documents, or each document is long (think documentation with embedded code samples), the index file becomes a problem. Even with chunking, you’re shipping significant data before any query runs.
You need features the browser can’t provide. Typo tolerance that maps “recieve” to “receive”, synonym expansion, geo-aware results, and real-time updates as content publishes all require server-side processing.
You’re building something closer to an app than a site. Product catalogs, job boards, and real-time filtered listings have requirements that stretch what client-side libraries can do. If you’re thinking through how search fits into a more commerce-heavy architecture, it connects directly to questions about headless commerce and how your data model is structured.
Algolia is the market leader. It’s fast, the documentation is thorough, and the free tier covers most small to medium projects. The cost curve steepens quickly at scale. Typesense Cloud is the open-source alternative with more predictable pricing, and it can also be self-hosted if you want full control. Both offer JavaScript SDKs and component libraries for React and Vue that reduce integration work.
Building a useful index
Regardless of which approach you choose, structuring the index well matters more than which tool you pick. Fast search over poorly structured content is still a frustrating user experience.
A few things to get right before you ship:
Index the right fields. Title, headings, and a short excerpt usually outperform full body text. Full-body indexing balloons the index and tends to surface results where a query matches a parenthetical aside rather than the core subject of a page.
Set field weights. A match in a page title should score higher than a match buried in body copy. Every tool supports this; most teams leave it at the defaults and wonder why results feel off.
Exclude noise. Navigation copy, footer text, cookie banner prose, and boilerplate legal text all produce irrelevant results and inflate the index. Pagefind has a data-pagefind-ignore attribute for exactly this. Most hosted services let you configure excluded fields.
Rebuild the index on every deploy. Search results that point to old URLs or deleted pages erode trust quickly. Treat the index as part of your build artifact, not a one-time setup step. Your build pipeline should regenerate and push the index as part of the same job that deploys the site.
If your content lives in a CMS, the index rebuild often connects naturally to the same webhooks that trigger your build. Worth planning before you implement search, because it shapes how you structure your data model.
Multilingual sites add another layer: a single mixed-language index produces low-quality results because term weighting and stemming are language-specific. A separate index per locale is the right approach, which connects to the broader decisions involved in building a multilingual site.
How Strynal approaches search
Search is a content feature as much as a technical one. The right implementation depends on the size of the content library, how often it changes, what the audience expects when they type a query, and what the site is trying to accomplish. We scope that before we pick a tool.
For most sites we build under our websites and apps practice, Pagefind handles search well and adds zero operational overhead. For projects with complex content models or large corpora, we bring in Typesense, either cloud-hosted or self-hosted depending on budget and control requirements. The index rebuild runs in the same deployment pipeline as the site so results never go stale.
If your site already has a search box that isn’t finding what people are looking for, the fix is usually upstream of the tool. It’s in the index structure and the content model. That’s where we start.