Pagefind vs Algolia vs Typesense for content sites — which one I actually pick in 2026

Search is the feature most static-site builders postpone until the site grows enough that it actually matters — at which point retrofitting it is annoying. I run 46 content sites; here’s the decision matrix I use, and the three real options behind it.

The framework

Everything else in this post is the detail behind those three axes.

Pagefind — the default I reach for first

Pagefind is a static-site search library. You run it as a post-build step against your dist/ folder; it generates a search index file in /pagefind/ that ships as a static asset. At runtime the browser fetches a small chunk of the index, runs the query in WASM, and returns results.

Cost: $0/mo. No server. No quota. No vendor account.

Setup time: ~10 minutes for an Astro site. Add the dependency, add a postbuild script, drop in their <PagefindUI> component.

Index size: I’ve personally pushed it to 4,000 pages without issues. The Pagefind team has shipped it on a 1M-page index but you pay in download size — the per-page chunk fan-out grows.

What it doesn’t do:

• No real-time updates (rebuilds the index per deploy).
• No relevance tuning UI (you can’t drag a result up; it ranks on lexical scoring).
• No A/B testing or analytics.
• No typo tolerance as good as Algolia’s.

Algolia — the paid king when search IS the product

Algolia is hosted search-as-a-service. You stream your records via their API; their cluster indexes them in milliseconds. Your frontend queries against their REST/JS clients. Their relevance engine handles typo tolerance, synonyms, filters, faceting, multi-tenancy.

Cost: Free up to 10k records + 10k searches/month. Beyond that, ~$0.50 per 1k searches with the standard plan. A medium-traffic SaaS will land at $50-200/mo. They’ve changed pricing models a few times.

Setup time: ~1-2 hours. The complexity is in shaping your records correctly. The relevance tuning has a learning curve.

Where Algolia genuinely wins:

• Real-time index updates — you addObject() and the search picks it up within seconds.
• Typo tolerance. Best in class. Their fuzzy matching feels native.
• Faceted filtering — multi-attribute filtering with counts. Pagefind has this; Algolia’s UI is more polished.
• Multi-tenant search at scale. If your SaaS serves customer-segmented data, Algolia’s tenant-isolation primitives are mature.

If search is the product (e-commerce, real estate listings, job boards), Algolia is the answer. For content sites where search is a feature, it’s overkill.

Typesense — the self-hosted middle

Typesense is open-source search with most of Algolia’s surface (typo tolerance, faceting, multi-tenancy, instant search) but self-hosted. You run a Typesense node or cluster on your own infra; queries hit your endpoint, not theirs.

Cost: $0 software cost; $5-50/mo for hosting (1 GB RAM minimum, more for serious indices).

Setup time: 2-4 hours including provisioning a server and securing it.

Where Typesense wins:

• Compliance / data residency. If your search data is regulated (healthcare, EU GDPR-strict), self-hosting beats handing it to Algolia.
• Predictable cost at scale. Algolia’s per-search billing punishes high-traffic sites. Typesense’s cost is “size of the box.”
• Open-source. No vendor lock-in. Switch hosts whenever.

Where it loses:

• You operate it. Server failures are your pager.
• Setup complexity. Algolia is npm install. Typesense is apt install + nginx + TLS + monitoring + backups.

I use Typesense on exactly one empire surface: a customer-facing tool catalog where I wanted faceted search but the cost projection on Algolia at scale was unreasonable. For 44 of the 46 sites, Pagefind wins on simplicity.

The decision in one paragraph

For a content site under 10k pages with build-time updates, use Pagefind. For a product where search IS the experience and budget isn’t tight, use Algolia. For everything in between — index size in the tens or hundreds of thousands, per-record updates, predictable cost matters more than zero-ops — evaluate Typesense.

That covers 95% of cases. The remaining 5% is custom: ElasticSearch at huge scale, Meilisearch if you’ve already standardized on Rust tooling, hand-rolled Postgres FTS if your data is small and your team is Postgres-fluent.

The empire’s actual mix

Three vendors across 46 sites. The default is the right answer for the empire’s median site. Outliers get the outlier solution.

The mistake most teams make

Picking Algolia first because it’s the “real” search and Pagefind feels like a toy. Pagefind handles every search query a normal content site will ever see, for free, with zero ops. Switching from Pagefind to Algolia later is a one-day project; switching from Algolia to Pagefind once you’ve designed around Algolia’s relevance model is a one-week project.

Start with the simpler option. Move when the simpler option fails for a specific, measurable reason — not because you imagine it will.

What I’d tell past-me

If you’re picking search for a new content site:

1. Use Pagefind unless you have a concrete reason not to.
2. The reason has to be measurable — “I have >10k pages,” “I need per-record updates,” “I have a compliance requirement.” Vibes don’t count.
3. Budget Algolia at $50/mo minimum. The free tier is for prototyping, not production.
4. Self-host Typesense only if you’re going to operate it well. A neglected Typesense node is worse than a working Pagefind index.

The empire’s search story is boring. Boring is the goal.