Pagefind: Full-Text Search Without a Server

Most small business websites do not have a search bar. The visitor lands on the homepage, navigates through the menu to find what they are looking for, and either succeeds or gives up. On a site of fifteen pages, the menu is enough. On a site of fifty pages with a deep blog, a service-area directory, and an FAQ, the menu stops being enough and the visitor needs a way to type "frozen pipes" and find the relevant page in one step.

The search bar is the answer. Building one used to mean either a third-party hosted service (Algolia, Swiftype, costing $30 to $300 per month) or a server-side search runtime (Elasticsearch, Meilisearch, requiring an actual server). Both are overkill for a small business.

Pagefind is the third option, and it is the one I install on every site I build. This post explains what it is, how it works, and why it has changed what a "small website with search" looks like.

What Pagefind is

Pagefind is a static-site search tool. At build time, after the site has been compiled to static HTML, Pagefind crawls the output, extracts the searchable content from each page, and builds a small index. The index is split into chunks (each chunk a few KB) and uploaded alongside the rest of the site to the CDN.

When a visitor types in the search box, a small JavaScript loader fetches only the index chunks needed for that specific query. The actual search happens in the visitor's browser, against the chunks that just downloaded. There is no server query, no API call, no third-party service involved. The whole loop from keystroke to results displayed is typically 50 to 150 milliseconds.

The crucial design choice: Pagefind does not download the entire index up front. A site with 200 pages might have a 5 MB total index, but a single search only loads the few chunks relevant to the query terms, usually 50 to 200 KB. The cost to the visitor is the cost of a single image, not the cost of a database client.

Why this works

The math behind Pagefind is unintuitive but correct. A traditional search engine assumes the index is too large to ship to every visitor, so it lives on a server and visitors query it remotely. Pagefind flips the assumption: most search queries only touch a small slice of the index, so it ships the slice and skips the server.

For a small-to-medium site (under 5,000 pages), the slice approach is meaningfully faster than the server approach. There is no network round-trip to a remote search service, no rate limit, no cold-start latency, no API key to leak. The first search may pull 100 KB of index data; subsequent searches reuse cached chunks and feel instant.

For very large sites (millions of pages), Pagefind's approach breaks down because the index becomes too unwieldy to chunk effectively. But "very large" is way beyond what any small business website will ever reach.

How I wire it into client sites

The integration runs at three places in the build:

1. Pagefind runs as a post-build step. After Eleventy compiles the static HTML, Pagefind crawls the output directory and writes the index to a folder alongside the rest of the site. This adds a few seconds to each deploy and produces no other change.
2. The search UI is a small JavaScript component. Pagefind ships a default UI (about 30 KB compressed) that I drop into the site. It produces the search box, the results list, and the keyboard navigation. I customize the styling to match each client's brand.
3. The search modal is wired into the navigation. Every site I build has a search icon in the header that opens a modal with the Pagefind input. The keyboard shortcut / opens it from any page. The escape key closes it. This is a standard pattern visitors recognize from Notion, Linear, GitHub, and most modern documentation sites.

The whole integration takes about an hour at site setup, then runs forever. Each new page added to the site is automatically included in the next deploy's index.

What it costs

Pagefind is open source and free. The hosting cost is the same as the rest of the site (zero on Cloudflare Pages). There is no per-search fee, no monthly subscription, no traffic-based pricing. Adding search to a small-business site cost real money five years ago; today it is a build step.

What the visitor experiences

The search-modal flow on a site with Pagefind:

1. Visitor clicks the search icon in the header (or presses / from anywhere on the site).
2. A modal opens with a focused input field.
3. Visitor types a query.
4. Results appear within 100 ms, ranked by relevance, with the matching terms highlighted in context.
5. Visitor clicks a result and the modal closes as the new page loads.

The whole flow feels native to the site rather than tacked on, which is the design goal. Search bars that feel like a cheap third-party plugin are common on small-business sites; the right answer should feel like the rest of the navigation.

What clients can do with it

The search bar is mostly invisible until a visitor needs it. For most service-business sites, that means one to three percent of visitors actually use it on a typical visit. Of those, the search experience determines whether they stay or bounce.

For clients, three things are worth knowing:

Every page on the site is searchable from launch. No separate "add this page to the search index" step. The next deploy after a new page lands includes that page in the index automatically.

Search analytics are limited. Pagefind runs entirely in the browser, so I can't easily see what visitors are searching for. For clients who want that data, the trade-off is wiring an analytics event for each search, which adds a small amount of complexity. Most clients do not need this.

Specific pages can be excluded from search if needed. Thank-you pages, hidden landing pages, and other operational URLs can be marked to skip the index. This happens automatically for any page already marked noindex for search engines.

Why this matters for the lifetime of the site

A search bar built into the site at launch becomes more valuable over time. A site with fifteen pages does not need search; a site with seventy-five pages absolutely does. Adding search retroactively after the site has grown is a real piece of work; building it in from the start adds zero to the timeline.

The trade-off pattern is similar to other build-time decisions: the cost of including the feature now is roughly zero; the cost of adding it later is real; the value of having it is small at first and grows continuously.

If your current site does not have working search

Three patterns I see on small-business sites:

No search at all. Common on small WordPress and Squarespace sites. Adding it usually requires a plugin (WordPress) or sometimes a paid integration (Squarespace).

Search exists but does not work well. The default WordPress search relies on a SQL LIKE query against post titles and content. The relevance ranking is poor, the results page is ugly, and the typical small-business site has no useful results because the search query keywords do not match the page text. Yoast and similar plugins can improve this with effort.

Search exists via a third-party service. Algolia and Swiftype produce excellent search but cost $30 to $300 per month and require ongoing index management. For most small businesses, the cost outweighs the benefit.

For sites I build, Pagefind sidesteps all three patterns. The search is built in, fast, free to host, and stays current automatically. For sites I do not build, Pagefind can be retrofitted into most static-site setups in a few hours, but adding it to WordPress is harder than just including it in a fresh build.