How to Add Search to a Static Site Without a Server

A static site gets full-featured search not through a server with a database, but through a ready-made search index that is built at site build time and loaded into the browser along with the pages. All the query logic - matching, ranking results, suggestions - runs on the client side, without a single call to a backend. Below we break down how this works technically and when this approach is enough, and when you need a full search service instead.

On Astro, Eleventy, and other static-generator projects, Exceltic.dev regularly sees the same moment: the site grows, the number of sections and articles passes a hundred, and regular menu navigation is no longer enough - readers need search. The team opens the hosting panel and runs into the same question: there is simply no server in the architecture that could handle a query.

The static-site community solved this problem without a backend - through an index that is built once at deploy time and then lives on as an ordinary static file. Below is how this works in practice, what the options are, and where this kind of search hits its limits.

The problem becomes acute for content-heavy sites - documentation, blogs, catalogs - where the article count runs into the hundreds. A site like this has no server that can run a text query on the fly: the page is served as a ready-made HTML file from hosting or a CDN. Without a separate mechanism, there is simply no search on the site, and the reader either uses Ctrl+F in the browser or leaves to search on Google instead.

Static search index: a pre-built file or set of files containing the data needed for site search, created once at build time and then served to the browser as an ordinary static resource.

Why a static site does not have “normal” search

On a site with a server - WordPress, for example - search is simple: a PHP script receives the user’s query, hits a MySQL database, and assembles a list of matching pages on the fly. That query runs fresh on every request, so the result always reflects the latest data.

A static site works differently. Astro, Eleventy, Hugo, and other generators turn content into ready-made HTML files at build time, not on each user request. Hosting or a CDN simply serves these files to the browser without doing any computation on their end - that is exactly where their speed and simplicity come from.

A site like this has neither a database nor a process that could run a SQL query against article text. A search box that sends a request to a server that does not exist will return a 404 or simply do nothing.

Client-side search: search where matching the user’s query against the site’s content happens in the browser, not on a server. This is exactly what fills the gap - the computation moves to where the site already physically lives: the user’s browser.

The options - an overview of approaches

There are three working approaches to search on a static site, and they cover different scenarios rather than competing head-on.

• A pre-built index in the browser. At site build time, a search index is generated, loaded into the browser, and handles queries right there on the client. An example of such a tool is Pagefind, an open-source library for full-text search on static sites that requires no infrastructure of your own to host.
• A third-party search service or API. The index is built and stored not in the browser but on an external provider’s servers (Algolia or Meilisearch Cloud, for example). The site sends a request over the network and gets back a ready-made list of results - which is effectively a return to the server model, just with someone else’s server.
• A CMS or platform’s built-in search. If the content lives in a headless CMS with its own search API, you can use that function directly without adding a separate tool - relevant for sites built on an architecture like Astro and Sanity, where the content already lives in a managed store.

All three options solve the same problem - finding the right page for a text query - but they distribute the load differently between the browser, the site build, and a third-party server.

Which option fits when

The choice depends not on developer preference but on content volume and search-quality requirements.

• A small site or documentation (up to a few thousand pages). A pre-built index in the browser is enough: it requires no payment for a third-party service and no separate infrastructure, and results appear instantly after the query is typed.
• A large catalog or e-commerce site. Here client-side search usually stops being enough - you need faceted filters, personalized results, and analytics on failed queries, all of which third-party search services offer but which map poorly onto a static index.
• You need fuzzy search and synonyms. Basic client-side search libraries can forgive typos and partial matches, but advanced handling of synonyms, language-recognition errors, and field weighting is usually better implemented by specialized services.
• You need personalized results. Showing different results to different users requires a server that knows the query context - a client-side index simply cannot do this by design.

In most cases, a first-option static index is enough for an agency site, blog, or documentation - the other two options come into play once content volume or result-quality requirements go beyond what static search can handle.

How client-side search works in practice

Let’s break down the mechanism using the pre-built-index approach - the most common scenario for static sites.

1. Generating the index at build time

After the static generator has built the site’s HTML pages, a separate build step scans the finished files, extracts text and metadata, and packages them into a search index. This step runs once per deploy, not on every user request.

# first, the normal static site build
astro build

# then a separate indexing step over the finished HTML files
npx pagefind --site dist

2. Loading the index in chunks as the query is typed

The site’s entire index is not loaded into the browser all at once - that would make the page heavy on large sites. Instead, the index is split into chunks, and the browser loads only the fragments needed for the user’s current query.

3. Ranking results

Once the browser has found matches, it sorts them by relevance: factoring in how often a word appears on the page, its position in headings, and overall text length. All of this logic runs in the JavaScript code loaded alongside the index.

4. Working offline and on slow connections

After the needed index fragments have loaded once, search keeps working without repeated calls to a server - which makes it resilient to an unstable connection. On a slow connection, the only delay is loading small index fragments, not waiting for a server response.

On a documentation site with 300-500 pages, the assembled search index typically totals from one to a few megabytes, but thanks to chunking, the browser only loads tens to hundreds of kilobytes on the first query - most of the file stays untouched until the query becomes specific enough. According to Pagefind’s own documentation, the library is able to index sites of 10,000 pages while keeping the network load on the search interface within a few hundred kilobytes total - the exact numbers depend on how much text is on each page and on the indexing settings. As of mid-2026, Pagefind remains one of the most widely used tools of this kind in the static-generator ecosystem.

What you lose compared to server-side search

Client-side search covers the basic scenario, but it does not replace full server-side search for every task.

Personalized results. The index is built ahead of time and is the same for every visitor - showing different users different results based on their history or role is impossible without a server.

Advanced query analytics. Server-side search can log every query and build reports on what people searched for and did not find. A client-side index has no such analytics by default - you would have to collect it with a separate mechanism.

Index growth alongside content volume. The more pages and text a site has, the heavier the index gets. For a site with tens of thousands of articles, the amount of data that needs to stay up to date on every build becomes a noticeable line item in build time.

Common mistakes

Most problems with client-side search do not surface at implementation time - they show up months into running the site.

• The index is built on files that are not final. If the indexing step runs before the finished HTML is ready, the index ends up with incomplete or stale content.
• The index rebuild is forgotten in the auto-publish pipeline. If content is updated by a separate process (a CMS webhook, for example) and the indexing step is not wired into that same pipeline, search starts returning stale results.
• Search is never tested on a slow connection. An index that runs fine on office Wi-Fi can noticeably lag on mobile data - this is worth checking separately.
• Expecting faceted filters and personalization from a basic solution. A client-side index does not replace a full search service for a catalog with dozens of filter attributes.
• No fallback for when JavaScript is unavailable. Search depends entirely on a script running in the browser - without a fallback (regular navigation, for instance), a user with JS disabled is left with no search at all.

Who this matters for

This topic matters for teams building or already running a content site on a static stack - documentation, a blog, a knowledge base, or a catalog of a few hundred pages - without a dedicated backend developer on the project. That includes agencies and startups building a corporate site from scratch on Astro or a similar generator, as well as teams that already have a finished site but lack search over the content they’ve accumulated.

Frequently asked questions

Does client-side search work on a site with tens of thousands of pages?

Yes, with caveats. According to Pagefind’s documentation, the library is built to handle sites at that scale by splitting the index into chunks and loading only the fragments needed. That said, index build time grows along with content volume, and on very large catalogs it makes sense to weigh that time against the benefits of a third-party search service.

Does client-side search need a separate server or hosting for the index?

No, and that is the main advantage of this approach. The index is a set of static files deployed alongside the rest of the site to the same hosting or CDN, with no separate infrastructure and no monthly fee for a third-party service. The index is generated by the same build process as the rest of the site, so there is no need to set up a separate service to host it - it simply becomes part of the regular deploy, alongside the HTML files and other static assets.

Can client-side search forgive typos and match partial words?

Basic client-side search libraries, including Pagefind, support simple fuzzy search and partial word matches. That said, advanced handling of synonyms, word forms, and field weighting is usually better implemented by specialized third-party services - worth keeping in mind for sites where search precision matters for conversion. For documentation and blogs, basic accuracy is usually enough, and finer-grained tuning of results gets added later as user complaints about irrelevant results accumulate.

How does the index update when content on the site changes?

The index is rebuilt on every site deploy, as part of the same build. If content is published automatically - through a webhook from a headless CMS, for example - it’s important to make sure the indexing step is wired into that same deploy pipeline, or search will lag behind the site’s actual content. In practice this is one extra command in the build script right after the HTML files are generated - without it, new articles simply will not show up in search results, even though the page itself is already published.

How long does it take to add search to an already-built site?

For a site on a static generator with a few hundred pages, a typical client-side search integration is a job of a few hours to a day or two, depending on how much customization the results interface needs. This is a targeted addition to an already-built site, not a separate project from scratch - the existing architecture and content stay untouched, and only the indexing step and a search box interface get added.

In short: client-side search covers search for documentation, a blog, or a catalog without a server and without a monthly fee for a third-party service - the index is built at build time and runs right in the user’s browser. For a catalog with faceted filters, personalization, or complex query analytics, this solution usually is not enough anymore. A related question - how a static site accepts dynamic data at all without a backend - we covered in the article on forms without a backend on a static site: it’s the same architectural fork, just applied to submitting data instead of searching for it.

If your static site is growing content but still has no search - tell the Exceltic.dev team about your project. We’ll look at your content volume and propose a search architecture for your site.