Adding Fast Site Search to a Static B2B Site

Your B2B site ships on a static stack. It’s fast, cheap to host, and impossible to take down with a traffic spike. Then a prospect lands on it, wants to find your pricing model or a specific case study, and there’s no search box. They poke at the nav, give up, and bounce. For a marketing or RevOps leader, that’s a qualified visitor lost to a missing 40-pixel input field. The good news: static site search is a solved problem, and you can add instant, client-side search without standing up a server or paying for a hosted index.

This is a guide to doing it well. Not the toy demo that breaks at 200 pages, but a real implementation that holds up across a growing content library and stays fast on a mid-range phone.

Why static site search trips people up

The instinct, coming from a WordPress or database-backed world, is that search needs a backend. Type a query, hit an endpoint, run a LIKE against a database, return rows. On a static stack there’s no database and no application server to query, so the reflex is to reach for a hosted search SaaS and bolt it on.

That reflex is usually wrong for a B2B marketing site. Hosted search is built for catalogs with tens of thousands of items and high query volume. A typical B2B site has somewhere between 30 and 600 indexable pages: services, case studies, journal posts, a few resource pages. That fits comfortably in a search index small enough to ship to the browser. When the index lives client-side, every keystroke returns results with no network round trip, which is the difference between search that feels instant and search that feels like a form submission.

The architecture decision here is the same one that should drive the rest of the build. If you’ve read our take on the B2B website architecture that converts, this is a natural extension: keep the runtime simple, push work to build time, and let the browser do the rest.

Takeaway: For a content site under roughly 1,000 pages, client-side search is faster, cheaper, and simpler to operate than a hosted search service. Reach for SaaS only when index size or query volume genuinely demands it.

The two viable patterns

There are two clean ways to do static site search, and the right one depends on how big your content gets.

Pattern 1: Ship a prebuilt index with a JS search library

At build time, you walk your content, extract searchable fields, and serialize an index into a JSON file. In the browser, a small library loads that index and runs queries against it in memory. Libraries in this space include FlexSearch, MiniSearch, Lunr, and Fuse.js. They differ in size and features, but the model is identical: index in, query out, no network.

This pattern is ideal when:

• Your total content is small enough that the index stays under a few hundred kilobytes gzipped.
• You want fuzzy matching, field weighting, or typo tolerance you control directly.
• You’re comfortable wiring the index generation into your build.

Pattern 2: Use a fragment-based search built for static generators

Tools like Pagefind take a different approach. Instead of one monolithic index, they build a fragmented index at deploy time by crawling your generated HTML, then load only the index shards relevant to the current query. The result scales to thousands of pages while keeping the initial download tiny, because the browser fetches index chunks on demand rather than all at once.

This pattern is ideal when:

• Your content library is large or growing fast.
• You don’t want to maintain a custom indexing step; you point the tool at your build output.
• You want search to stay fast even as the page count climbs.

For most B2B sites we work on, Pattern 2 is the default because it requires almost no maintenance and degrades gracefully as content grows. Pattern 1 wins when you need precise control over ranking and matching behavior.

Implementing it on a static stack

Here’s the sequence we follow on an engagement, framework-agnostic but written with a static generator like Astro in mind. (For why that stack tends to be our starting point, see why we build B2B sites on Astro.)

1. Decide what’s searchable. Not every page belongs in the index. Include journal posts, case studies, service pages, and resources. Exclude thank-you pages, legal boilerplate, and thin landing variants. Add a frontmatter flag so authors can opt a page out.
2. Generate the index at build time. Whether you’re emitting JSON for a JS library or running a post-build crawl, this step must run in CI as part of the deploy. The index is a build artifact, never a hand-maintained file.
3. Load the search UI lazily. Don’t ship the search library or index on first paint. Load it on interaction: when the user focuses the search input or presses a keyboard shortcut. This keeps it off the critical path entirely.
4. Render results client-side. As the user types, debounce input by a small interval, run the query, and render a results list with title, a short excerpt, and the URL. Highlight the matched terms.
5. Make it keyboard-first. A real search experience supports a focus shortcut, arrow-key navigation through results, and Enter to open the highlighted result.

What to put in each indexed record

Keep records lean. Every field you add inflates the index. A practical record for a B2B page includes:

• Title — weighted highest in ranking.
• A short summary or excerpt — weighted second.
• Body text — weighted lower, and often truncated to the first few hundred words rather than the entire page.
• URL and content type — so you can label results (“Case study,” “Journal”) and let users filter.

Resist the urge to index every word of long pages. The first several hundred words of a well-written B2B page almost always contain the terms people search for, and truncating keeps the index small.

Keeping it fast and accessible

Search that’s slow or unusable with a keyboard defeats the point. A few things we check on every build.

Performance

The two costs are the index download and the query execution. Manage both:

• Ship the index gzipped or brotli-compressed; these files compress extremely well because they’re repetitive text.
• Lazy-load everything search-related so it never touches your initial load. Search has no business affecting your Largest Contentful Paint or interactivity scores. If you’re tightening those metrics broadly, our Core Web Vitals optimization playbook covers the surrounding work.
• Debounce queries so you’re not running a search on every single keystroke, and cap rendered results at a sane number, typically 8 to 12, with a “see all results” affordance if you have a dedicated results page.

Accessibility

Search is a high-traffic interaction, so it has to work for everyone:

• Use a real label on the input, even if it’s visually hidden.
• Announce result counts to screen readers with a polite live region.
• Make the results list fully keyboard-navigable, with a visible focus state on the active result.
• Ensure the search panel can be dismissed with the Escape key and returns focus to where the user was.

These are small additions, but they’re the difference between a feature that ships and a feature that quietly excludes part of your audience.

A decision checklist before you build

Run through this before writing any code. It saves you from over-engineering or picking the wrong tool.

• How many pages will be indexed in 12 months? Under a few hundred, either pattern works. Into the thousands, lean fragment-based.
• Do you need typo tolerance and custom ranking? If ranking precision matters for conversion, a JS library you control gives you the knobs.
• Who maintains the index step? If no one owns a custom build script long-term, pick the lower-maintenance crawl-based tool.
• Where do results lead? A quick-search dropdown for nav, a full results page for deeper exploration, or both. Decide before you design the UI.
• What’s your performance budget? Set a hard ceiling on the index size and the search bundle, and fail the build if either is exceeded.

In our engagements, teams that answer these five questions up front almost never have to rebuild search later. Teams that skip them tend to ship something that works at launch and buckles a year in when the content library has tripled.

Closing: search that earns its place

Site search is one of those features that looks optional until you watch a prospect hunt for something and leave empty-handed. On a static B2B site, you can add fast, instant, client-side search without compromising the speed and simplicity that made you choose a static stack in the first place. The build-time index, the lazy-loaded UI, the keyboard support, the performance budget: none of it is exotic, and all of it compounds into an experience that quietly helps visitors find what converts them.

If you’d rather have this built and tuned alongside the rest of your marketing infrastructure, that’s the kind of work we do every day. Explore our services, browse more practitioner notes in the journal, or get in touch and we’ll scope it with you.