The verdict

The important part of Pagefind is not placing a search box on a page. It is making “what enters the index” a build contract. Pagefind’s documentation says it runs after a static site generator and writes a static search bundle into the generated site. Its multilingual mode reads the lang attribute on html to build and load language-specific indexes. A bilingual site can have a polished UI and still return the wrong results if language, draft handling, and build order are undefined.

An index after the build

Pagefind does not require a hand-built database. The site emits HTML first, then Pagefind scans the output directory and creates static search files. There is no Pagefind server component; the browser loads the generated index. That is why a dev server is not enough to validate final search behavior. Test the actual production or preview build after indexing.

Draft isolation must happen before indexing. If a production build writes a draft: true page into its output, Pagefind may treat it as an ordinary page. The gate is therefore: exclude drafts from the production build, run Pagefind against that output, and inspect the resulting index for draft routes.

The bilingual boundary

Pagefind’s multilingual documentation says it reads html lang, indexes languages independently, and loads the matching index in the browser. English supports stemming; Chinese and other specialized languages use segmentation without the same stemming behavior. A Chinese query should not be forced through English root-word rules, and English filtering should not be changed by accidental Chinese metadata.

The smallest useful contract is:

zh page
  lang = zh-CN
  Chinese index only
en page
  lang = en
  English index only
production build
  drafts excluded
Pagefind
  scans production output only

Relevance is not result count

Pagefind can be a candidate retriever while the application still decides whether a result has a safe lexical relationship to the query. English stemming can surface low-confidence candidates. If the product requires unrelated ordinary words to return zero results, use Pagefind’s data, content, and locations to apply a general acceptance rule. Do not create a blacklist for three surprising words or rely on an absolute score threshold.

Load each result’s data once and share it between filtering and rendering. An asynchronous search needs a request generation so an older promise cannot overwrite a newer query. The Chinese path should retain its language-specific segmentation and index behavior.

Common failure modes

Treating Pagefind as a runtime database; judging production search on a dev server; omitting lang; leaving drafts in the output; inferring the original match by parsing highlighted HTML; weakening the draft gate to satisfy a test; and looking only at result counts instead of links and excerpts are all easy mistakes.

A reproducible check

npm run build:production
npm run test:search
Inspect index language
Inspect public routes
Query English positives
Query Chinese positives
Query random absent terms
Type quickly
The last query owns the UI

Evidence boundary

Pagefind’s documentation and repository support post-build indexing, lang-based multilingual search, and the specialized-language behavior described here. Draft isolation, application precision filtering, and Omnihex’s route checks are site-level engineering methods, not a Pagefind guarantee of search quality.