You May Not Need Algolia™

Static sites probably do not need hosted search

Image by Dan Levy

Most site search decisions start too late.

By the time someone says “we should use Algolia,” the team has usually skipped the useful question: what kind of content are we searching?

If the answer is “HTML pages we already build,” Pagefind should be the first thing you try. Not because Algolia is bad. Algolia is very good at a bunch of hard problems. But if your search index changes when your site deploys, a hosted search service may be infrastructure cosplay.

Use Pagefind when your searchable content is generated at build time. Reach for Algolia when search needs to accept live writes, business rules, user-specific ranking, or operational guarantees that your static build cannot provide.

That rule covers more sites than people expect: blogs, documentation, marketing sites, internal handbooks, product guides, course catalogs, and a surprising number of “apps” that mostly publish pages.

The Shape Of The Problem

Algolia gives you an external search system. You create records, push them into an index, configure ranking, wire up a UI, and keep the thing synchronized with your source of truth.

Pagefind looks at the HTML you already shipped and builds a static search index beside it.

That distinction sounds boring until you maintain the integration.

With Algolia, your site has a second copy of your content. Now you need to answer questions like:

• Did the deploy finish but the index update fail?
• Which fields are canonical: the CMS fields, the rendered page, or the search record?
• Who owns ranking tweaks when they stop matching the page?
• What happens when the free tier turns out not to be the real shape of your traffic?

Sometimes those questions are worth it. For a marketplace, support portal, or large e-commerce catalog, they probably are. For a static documentation site, they are often self-inflicted complexity.

Pagefind Works Because It Refuses The Extra System

Pagefind’s trick is not magic. It is taste.

It waits until your pages exist, indexes the finished HTML, and writes a collection of static assets you can put on the same CDN as the rest of your site. The browser downloads only the chunks it needs. There is no search server to keep warm, no crawler quota to watch, and no webhook pipeline trying to remember what changed.

That makes the failure mode much easier to understand:

• If the page deployed, the indexed content came from that page.
• If the page did not deploy, users cannot see it anyway.
• If search is wrong, the problem is usually in your rendered markup or Pagefind config, not in a distant synchronization job.

This is why I like it for content sites. The index follows the artifact.

What Setup Actually Looks Like

For a plain static site, the workflow is pleasantly dull:

• CLI: Scan your site’s HTML files, generate an index, and deploy it to a global CDN—all in minutes.
• Static Site Generators: Use PageFind’s plugins for Astro or Hugo to automate the indexing process.
• Custom Solutions: Utilize PageFind’s API to build tailored search experiences that fit your unique requirements.

The Getting Started guide is enough to get moving. The better test is operational: can you rebuild the index in CI, deploy the output, and explain every search miss by inspecting rendered HTML?

Where Algolia Still Wins

Pagefind is not a tiny Algolia hiding in a trench coat. It is a different answer.

Use Algolia, OpenSearch, Postgres search, or another live system when your search index needs to change independently from a site deploy.

That includes:

• inventory counts that change every few minutes
• per-user permissions or private results
• custom ranking driven by revenue, freshness, popularity, or experiments
• federated search across systems that do not render into one static site
• analytics and operations support that a business expects from a managed vendor

Those are real needs. Pretending Pagefind handles them because it is fast would be the other kind of vendor blog voice.

The Decision I Use

Ask one question first:

Can the search index be rebuilt from the same static output users are browsing?

If yes, start with Pagefind. You get private-by-default search, CDN-friendly assets, and one fewer service account with opinions.

If no, name the thing that makes the index live: inventory, permissions, personalization, analytics, ranking, or write frequency. Then choose the database or search service that owns that job explicitly.

Algolia is not the villain here. The villain is adopting a second system before proving the first artifact was insufficient.