Pagefind for Drupal

Pagefind Search brings high-performance, client-side search to Drupal. Unlike Solr or Elasticsearch, there is no search server to provision, tune, secure or pay for: the module builds a highly compressed static index, and searching happens entirely in the visitor's browser via WebAssembly, fetching only the few kilobytes of index a query actually needs.

It is a Drupal bridge to the Rust-based Pagefind engine, adding faceted listing pages, synonyms, promoted results and multisite search collections on top.

Why you might want this

• No search server. No Solr instance, no hosted search subscription, no query load on your web servers. The index is static files — serve them from your existing site or a CDN.
• Search costs nothing at runtime. Every keystroke is answered in the browser. A thousand concurrent searchers generate zero database queries.
• Small payloads. A query fetches a handful of index chunks plus a fragment per displayed result — tens of kilobytes, not a round trip per keystroke.
• Build it anywhere. The index is an artifact. Build it in CI, on a staging box, or on the site itself; production only has to serve files.

Features

• Faceted listing pages. Build filterable, sortable, paginated listings — archives, libraries, directories — through the bundled Search Displays UI. No code required.
• Expert field formatter. One formatter to mark fields as filters, weight them for relevance, expose them as metadata, or make them sortable.
• Guided Setup Wizard. Install to a working search page without reading the manual first.
• Synonyms, self-healing. Index-time synonym expansion with an admin UI. Editing synonyms queues a coalesced re-stage of affected content via cron — no manual rebuild.
• Featured results. Promote specific content to the top of results for targeted keywords ("best bets"), on both the classic search page and React displays.
• Multisite collections. Merge the indexes of other Pagefind-powered sites into a single search experience.
• Relevance controls. Term frequency, term similarity, page length and term saturation, applied consistently across every search surface.
• Developer tooling. Drush commands with real diagnostics, a Playground for live query debugging, and a Preview tab that shows exactly what HTML was staged for any node.

Requirements

• Drupal 10.3+, 11 or 12. PHP 8.1 or higher.
• A private file system ($settings['file_private_path']) — used for content staging and for the Pagefind binary, which is never web-accessible.
• Outbound HTTPS to GitHub releases for the automatic, checksum-verified binary download. You can also supply your own binary if your host blocks outbound traffic.

Depends only on Drupal core (Node, System, Path alias, Views). Media and Taxonomy support activate automatically when those modules are enabled.

Installation

composer require drupal/pagefind
drush en pagefind

Then follow the Quickstart in the module's docs/ directory, or use the built-in Setup Wizard from the Pagefind dashboard.

Scale, and what it costs to build

Engineered for sites of up to roughly 50,000 indexed documents across all indexed bundles. Above that a status-report warning appears, and a server-side backend is likely the better tool.

The practical limit is usually build-time memory, not document count. The Pagefind binary indexes the whole staging directory in a single pass — it has no incremental mode — so peak memory scales with the amount of text being indexed.

Measured on a corpus of full-length articles averaging about 3,000 characters each, peak resident memory during the index build was close to linear:

  2,500 pages     531 MB
  5,000 pages   1,051 MB
  8,000 pages   1,667 MB
 10,000 pages   2,055 MB

That is roughly 200 MB of RAM per 1,000 pages of substantial text content. Shorter pages — product listings, directory entries, brief news items — use considerably less. Budget accordingly: a 50,000-page site of long-form content should expect to need several gigabytes available at build time.

If the build is killed without explanation, this is usually why — check available memory rather than the index configuration. Note that PHP's max_execution_time and memory_limit do not apply to the binary; it is a separate process with its own timeout, configurable via the index_timeout setting (default 3600 seconds, 0 for unlimited).

Serving the index costs nothing. Once built it is static files. A machine that cannot build a large index will serve one without difficulty.

Security and access — read this before indexing

The built search index is world-readable static content, and there is no per-user result filtering. This is a deliberate and correctly-handled property of client-side search, not an oversight — but it is important to understand before you index anything.

Practically: index only content the anonymous user is allowed to view. The module stages every entity as the anonymous user precisely so that access-restricted content never reaches the index, and promoted results skip nodes the anonymous user cannot see. Revoking access to a node after an index build does not remove it from an already-published index; rebuild.

Evaluating this for a government or enterprise deployment? Start with the Security & access documentation.

Accessibility

The search surfaces meet WCAG non-text contrast, focus visibility and reduced-motion requirements. Interactive controls carry accessible names, AJAX changes are announced to assistive technology, and a documented accessibility statement ships with the module in ACCESSIBILITY.md.

Kernel suite: 121 tests, 1337 assertions. PHPStan level 8 and Drupal coding standards clean.

Documentation

Full documentation ships in the module under docs/, organised by audience — Quickstart, Concepts, Choosing a search surface, Indexing content, Search displays, Enterprise features and Troubleshooting for site builders; Architecture, Configuration reference, Extending & theming, Security & access, Scale & performance and Accessibility for developers.