SOURCE

You May Not Need Algolia

Properties1
tagsweb-dev, site-search, pagefind, algolia, static-sites, jamstack
AUTHOR
Dan Levy
PUBLISHED
2025-03-01
ORIGINAL
view original

5 min read

You May Not Need Algolia

Author: Dan Levy (NEW: dan-levy) | Published: 2025-03-01 | Source: article

Summary

Dan Levy’s essay is the decision rule that completes the Site Search spectrum: hosted crawl (Adding Search To Your Site In 15 Minutes / Site Search 360), build-time static index (Getting Started with Pagefind), and live API-backed search (Algolia and peers). The useful question is not “which search vendor?” but what kind of content are we searching? If the answer is HTML pages the site already builds, Pagefind should be the first thing you try. Algolia is good at hard problems; if the search index changes when the site deploys, a hosted search service may be “infrastructure cosplay.”

Use Pagefind when searchable content is generated at build time. Reach for Algolia when search needs live writes, business rules, user-specific ranking, or operational guarantees a static build cannot provide. That covers more sites than people expect: blogs, docs, marketing sites, internal handbooks, product guides, course catalogs, and “apps” that mostly publish pages.

Algolia is an external system: records, ranking config, UI, and a second copy of the content that must stay in sync. That creates failure modes — deploy succeeded but index update failed; which fields are canonical (CMS, rendered page, or search record); who owns ranking when it drifts from the page; free-tier traffic surprises. Those questions are worth it for a marketplace, support portal, or large ecommerce catalog. For a static docs site they are often self-inflicted.

Pagefind waits until pages exist, indexes finished HTML, and writes static assets onto the same CDN. The browser downloads only the chunks it needs. No search server, crawler quota, or webhook. Failure mode: if the page deployed, the index came from that page; if it did not, users cannot see it; if search is wrong, look at rendered markup or Pagefind config, not a remote sync job. “The index follows the artifact.” Setup is CLI against HTML, SSG plugins (Astro, Hugo), or the API. The real test is operational: rebuild in CI, deploy the output, explain misses from rendered HTML.

Algolia (or OpenSearch, Postgres, etc.) still wins when the index must change independently of deploy: inventory counts, per-user permissions, revenue/freshness/popularity ranking, federated search across systems that do not render into one static site, vendor analytics/ops. Pretending Pagefind handles those because it is fast is the other vendor-blog voice. First question: Can the search index be rebuilt from the same static output users are browsing? If yes, start with Pagefind (private-by-default, CDN assets, one fewer service account). If no, name the live requirement and choose the system that owns it. The villain is adopting a second system before proving the first artifact was insufficient.

Key Claims

  • Decision rule: if the index rebuilds with the static site, start with Pagefind; use Algolia (or another live engine) only when the index must move independently of deploy. (practitioner rule)
  • Hosted search on a static HTML corpus is often extra infrastructure, not a capability upgrade. (opinion, well-argued)
  • Algolia means a second copy of content and sync/ownership failure modes. (architectural)
  • Pagefind indexes finished HTML onto the same CDN; “the index follows the artifact.” (architectural)
  • Pagefind does not replace Algolia for inventory, permissions, personalization, federated live sources, or vendor-grade ops. (explicit)
  • Covers blogs, docs, marketing, handbooks, guides, catalogs, and page-publishing “apps.” (claimed scope)

Notable quotes

“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.”

Why citable: The decision rule in one paragraph. The line Site Search was missing.

“Can the search index be rebuilt from the same static output users are browsing? If yes, start with Pagefind.”

Why citable: Operational test a practitioner can actually run in an audit.

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

Why citable: Anti-vendor-default principle; applies beyond search.

Connections

Entities mentioned: Dan Levy (NEW: dan-levy) · Pagefind (NEW: pagefind), Algolia (NEW: algolia) Concepts referenced: Site Search, Rendering Strategies (CSR / SSR / SSG / ISR / RSC), Web Architecture & Scalability

Contradictions / Tensions

  • Fills the API-backed vs. build-time gap that Adding Search To Your Site In 15 Minutes left (hosted-crawl only, promotional for Site Search 360, no Pagefind/Algolia comparison). This is the independent decision piece; Getting Started with Pagefind is the how-to.
  • Not anti-Algolia. Tension is with defaulting to hosted search on SSG sites, not with Algolia as a product. Keep that distinction on Site Search.
  • Recency: 2025-03-01 per ingest brief; extract only shows “over 1 year ago” relative to 2026-09-04 fetch. Re-check if Pagefind’s component API has moved (the official docs at fetch use pagefind-modal / pagefind-component-ui).

Notes

Highest-leverage web-dev source in this batch for Site Search. Extract filename is danlevy-pagefind.txt. Flag NEW entity pages: pagefind, algolia, dan-levy (author; optional if the wiki prefers not to entity every blogger).