What should people be able to find?
Start with one task. A reader may want a help page, a developer may want the exact heading that explains an error, and a signed-in customer may want a record only their team can see. The right search setup depends on where that information lives and who is allowed to find it.
What kind of search are you adding?
Write down one query a person might enter and the result they should be able to open. Then decide which source should supply it.
| What someone needs | What to search | What to check first |
|---|---|---|
| Find a help article | Public pages your site builds | The result opens the published page. |
| Find an answer in documentation | Public pages and their headings | The result jumps to the right section or version. |
| Find a private team record | A limited copy of the app’s records | The actual search response contains only records that team may see. |
On a small screen, scroll the table sideways to read every column.
Can someone learn about a private record from a result?
Yes, even when the destination page is locked. A search result can reveal a title, a snippet or a count. Keep private material out of a public index. For private app search, apply access rules before the results leave the server or search service, and check permissions again when opening the record.
A filter such as “Guides only” helps readers narrow results. It does not prove the reader has permission. Test as a member of a second account, not just as the person who configured search.
Compare tools
Scroll the table sideways to read every column.
| Tool | What goes into search?Where the searchable copy comes from. | Who can see results?Whether access needs a server-side check. | How do updates appear?The work that keeps results current. | What affects cost or limits?Requests, records, crawling or hosting. | What can you keep?How you rebuild or move search. |
|---|---|---|---|---|---|
| Pagefind | Public HTML files produced by your site build. | The browser downloads the search files. Include only public content. | Rebuild the index and publish it with the matching pages. | MIT-licensed static workflow. Budget for build time, hosting and downloads. | Keep the source pages, labels and build settings. Generate a fresh bundle. |
| Algolia | Structured records you send from a catalog, site or app. | For private results, issue a short-lived key scoped to the account. Keep admin, write and unrestricted search keys server-side. | Send updates and deletions from the source. Check that indexing tasks completed. | Standard Free lists 10,000 monthly requests and 50,000 records. Grow meters them separately. | Export records, settings, rules and synonyms. Keep original records in your app. |
| Algolia DocSearch | Headings and text extracted from eligible public technical documentation. | Public documentation only under the free program. Approval and branding are required. | Schedule crawls and inspect the extracted records after content moves. | Separate free program with limits on records, monthly requests and crawling. | Keep docs and crawler configuration. Inspect extracted records in the dashboard. |
| Meilisearch | Send documents with stable IDs and choose searchable and filterable fields. | Issue short-lived tenant tokens with enforced account filters. Keep unrestricted keys server-side. | Wait for update and deletion tasks to succeed, then check the results. | Cloud prices instances by size and region, with charges for disk and outbound data. Self-hosting leaves the server and backups to you. | Keep source data and index settings. Use a dump for migration or a same-version snapshot for recovery. |
| Typesense | Import records into a collection with typed fields. Size memory for the search index. | Use scoped keys. If you pin results, enforce the filter on curated hits too. Keep parent keys server-side. | Check each result in a bulk import. Delete by record ID and confirm the old result disappears. | Cloud meters cluster time and bandwidth. The select-configuration free allowance is one-time. | Export JSONL and retain the schema separately. For self-hosted recovery, test a snapshot. |
| Fuse.js | A list your app already has, with selected fields such as names or short descriptions. | Browser search sees the list it loads. Keep private collections behind a server-side access check. | Update the list and its index together when records change. | No query fee for the library. List size, field lengths and device speed affect responsiveness. | Keep the source list and search settings. Rebuild any saved index from that list. |
| MiniSearch | Records with stable IDs and selected fields, such as help titles and article text. | The index can expose searchable terms. Keep private indexes on the server and check what each account may see. | Replace or remove records by ID. Regenerate a saved index when it changes. | No query fee for the library. The index needs to fit in browser or server memory. | Keep the source records and configuration. Reload a saved index using the same options. |
| AddSearch | Public pages found by a crawler, or records you send through the indexing API. | Keep private pages behind app access checks and out of a public index. Verify protected search separately. | Recrawl changed pages or update the records you sent by API. | Plan limits cover documents, queries, domains and indexes. Suggestions count as queries. | Export indexed URLs and IDs. Keep source pages and rules separately. |
| Orama JavaScript library | Records with fields you define. Add vectors if your search uses them. | Keep private records in a server-side index and enforce access before returning results. | Update the records in the index or rebuild from the latest source. | No per-query library fee. Budget for runtime, storage and any service used to create embeddings. | Keep source records, stable IDs and field definitions. An optional plugin can save the index. |
| Elasticsearch | Documents your app sends to a separate search service, with field types you choose. | Check app access on the server. Elastic also offers plan-dependent document and field read restrictions. | Send updates and deletions, then check results after the index refresh. | Self-managed servers or hosted resources. Serverless meters indexing, queries, storage and transfer. | Keep source records and settings. Use compatible snapshots where your deployment supports them. |
How do you keep results current after a change?
Find the step that refreshes the searchable copy. A static index updates when you rebuild and publish it, a crawler updates when it revisits the pages, and an app index updates when the app or its connector sends changes. Include deletions and moves in that workflow.
After a change, search the new title, search the old title and open the result. If the old result remains, check the last build, crawl or indexing task before tuning the ranking.
What should you test before switching search on?
Use fictional content in an isolated build or search index. Before running anything, verify the input folder or account and index are disposable. If you cannot confirm that, write the queries and expected results on paper and keep collection and indexing untested.
- Try the phrase a reader would typeChoose a common query and a distinctive phrase. Open the result and check the page or section. If both searches fail, inspect whether the content reached the index.
- Check for an intentionally missing resultSearch for a phrase from an excluded sample. For account-specific search, repeat from a second fake account and inspect the returned titles and snippets. They should reveal nothing about the first account’s records.
- Make the empty state helpfulCheck a query that should have no results. Give the reader a way to try a shorter term or clear a filter. For private search, use the same empty result when no record is visible to that account.
What do you keep if you change search tools?
Keep the original pages or records, stable links and IDs, and the rules that decide which fields and terms are searchable. Keep account permissions in your app. The search index is a copy you should be able to rebuild from those pieces.