Begin with your use case

A private search engine cannot be ranked meaningfully without a user and a task. Someone who wants fewer advertising profiles has different needs from a journalist protecting sources, a family seeking safe results, a developer searching code, or a multilingual researcher comparing regional sources. Define the important outcomes before comparing brands: anonymous access, low retention, strong local results, independent indexing, image search, accessibility, parental controls, or resistance to centralized control.

Next identify the unacceptable outcomes. These might include account-required search, indefinite query history, behavioral advertising, third-party trackers, precise location, unencrypted access, opaque upstream providers, or poor coverage for a language. A short must-have and must-not-have list prevents a glossy feature page from shifting the criteria during evaluation.

Category 1: collection and identifiers

List the information generated by a search: query text, network address, browser details, cookies or other storage, account identity, location, click records, diagnostics, and support messages. Ask which items are necessary for immediate delivery, which are optional, and which create a durable identifier. A service can collect less by allowing signed-out use, using manually selected regions, keeping preferences locally, and avoiding third-party page resources.

Do not reward absolute “no data” language unless the provider defines it. Every network service processes some information long enough to respond. Precise descriptions of short-lived operational data are often more credible than claims that nothing is ever seen. Give higher marks when the policy names fields, purposes, access controls, and exceptions.

Category 2: retention and deletion

Retention determines whether a momentary search becomes a long-term record. Look for specific periods for raw query logs, security records, click data, account history, support tickets, and backups. “As long as necessary” should be accompanied by criteria or examples. Check whether identifiers are removed before longer-term analytics and whether derived profiles or inferences are deleted with the source history.

Test account controls when accounts exist. Can history be disabled before collection, deleted by date, exported, and removed when the account closes? Does deletion affect all devices and connected products? Anonymous services may have no person-linked history to delete, which can be a stronger design than a complex deletion dashboard. Avoid penalizing a provider for not retrieving records it never tied to a user.

Category 3: profiling, ranking, and ads

Determine whether past searches and clicks influence future results, suggestions, or ads. Contextual advertising based on the current query creates a different privacy profile from behavioral advertising based on a history across services. A subscription model can reduce advertising incentives but does not guarantee minimization. Donations, licensing, affiliate links, and commercial APIs also create trade-offs that should be disclosed.

Ask what “unbiased” means. Every index and ranking system selects, weights, filters, and orders information. A useful promise is narrower: no person-specific ranking based on a behavioral profile, transparent regional and safety controls, documented handling of sponsored results, and a process for removals and corrections. Score clarity rather than impossible neutrality claims.

Category 4: index source and result quality

Some providers build their own indexes, some license results, and some combine multiple sources. Independent indexing offers control and diversity but may have gaps in freshness, language, maps, shopping, or niche topics. Proxying an established index can improve coverage while introducing an upstream relationship. The provider should explain which source receives the query and whether the upstream party can identify the user.

Test a balanced set of queries rather than only your favorite topic. Include current news, an obscure factual question, local services, a non-English query, an exact phrase, technical documentation, images, and a known spam-prone term. Record relevance, source diversity, freshness, duplicate handling, and whether sponsored content is clearly labeled. Search quality is personal, so keep the raw notes instead of converting everything into one universal score.

Category 5: security and page architecture

Require HTTPS, valid certificates, modern browser compatibility, and no mixed active content. Inspect whether the results page loads remote scripts, fonts, images, pixels, or ads from other companies. Fewer third parties reduce data exposure and make the service easier to audit. A content security policy, secure cookies when cookies are used, and clear security contact are positive signals.

Security is broader than transport. Account features should support strong authentication, session management, and deletion. Provider infrastructure should use least privilege, incident response, access logging, and vulnerability management. Public detail may be limited for security reasons, but a mature service can still describe its program, publish incident notices, and accept vulnerability reports.

Category 6: governance, jurisdiction, and processors

Identify the legal entity, country of establishment, locations of processing, relevant privacy contact, and categories of processors. Jurisdiction affects legal obligations and user rights, but country alone should not become a shortcut for trust. Technical minimization can reduce the data available under any legal request. Transparent procedures and published aggregate reports can add context.

Review hosting, content-delivery, security, analytics, advertising, payment, and upstream index partners. A provider can have a strong front-end policy while sending query pages through a complex supply chain. Note whether subprocessors are listed, changes are announced, and contracts limit reuse. Give credit for architectural separation that prevents one party from seeing identity, query, and click together.

Category 7: controls and usability

Privacy controls should be understandable and available without dark patterns. Evaluate anonymous use, manual region selection, safe-search controls, language, appearance, non-personalized mode, history, result-opening behavior, and search-suggestion settings. Check keyboard navigation, screen-reader labels, contrast, text resizing, and mobile layout. A privacy service that excludes users with disabilities fails an important usability standard.

Preferences should not require a permanent identifier when a local or URL-based setting can work. A cookie may be reasonable for chosen settings if it is transparent and not used for profiling. The interface should explain which choices are local, account-synced, or server-side. Exportable settings and clear reset controls help users verify the state.

Category 8: evidence and accountability

The NIST Privacy Framework presents a risk-management approach for identifying and managing privacy risk. A consumer comparison can borrow that mindset: identify the data and purposes, govern responsibilities, control processing, communicate clearly, and protect information. The framework is not a search-engine rating, but it encourages evidence and continuous management instead of one-time promises.

Look for independent assessments, reproducible applications, open-source components, technical papers, transparency reports, audit scopes, and policy change logs. Each has limits. Open source does not prove the hosted service runs the same code. An audit covers a period and control set. A warrant canary is not a substitute for minimization. Score evidence according to what it actually demonstrates.

Build a weighted scorecard

Use a simple scale such as 0 to 3 for each category: 0 means unacceptable or undisclosed, 1 means limited, 2 means adequate, and 3 means strong and well supported. Weight the categories based on the use case. A high-risk researcher may give collection, routing, and jurisdiction more weight. A family may prioritize safe-search controls and ease of use. A developer may prioritize technical coverage and direct documentation links.

  • Collection and identifiers — suggested baseline weight: high.
  • Retention and deletion — high.
  • Profiling and advertising — high for users avoiding behavioral targeting.
  • Index source and result quality — medium to high, depending on daily reliance.
  • Security and page architecture — high.
  • Governance, jurisdiction, and processors — medium to high.
  • Controls, accessibility, and usability — medium.
  • Evidence and accountability — high when claims are difficult to observe directly.

Keep disqualifiers outside the weighted total. For example, lack of HTTPS or mandatory account linking may be an automatic rejection even if other scores are strong. Record the review date because products change. Do not publish a permanent ranking based on a one-day test without a process for updates and corrections.

Run a two-week real-world trial

  1. Use the candidate as the default for routine searches and keep a log of failed or especially good queries.
  2. Test normal and private windows, mobile and desktop, signed-out use, and any optional account features.
  3. Review browser storage and third-party requests before and after changing preferences.
  4. Check direct result links, sponsored labels, region controls, and whether suggestions send partial queries.
  5. Repeat a small benchmark set at different times to separate one-off ranking changes from persistent gaps.
  6. Read the privacy policy after hands-on testing; concrete observations make vague language easier to question.
  7. Decide whether a secondary engine solves occasional gaps without replacing the privacy-oriented default.

A trial captures friction that documents cannot. A provider may have excellent policies but poor accessibility, or good results but confusing settings. Conversely, a sparse interface may become comfortable after a few days. The purpose is not loyalty; it is to find a sustainable default and understand when to use another tool.

Conclusion

Comparing private search engines requires more than counting privacy words on a homepage. Examine data collection, retention, profiling, index relationships, security, governance, controls, and evidence. Test result quality with your own queries and weight the categories according to actual risk and daily needs.

The best outcome may be a small toolkit rather than one winner: a privacy-focused default, a specialized secondary index, a private browser profile, and stronger anonymity tools for exceptional cases. A documented, repeatable comparison protects against marketing hype and makes future changes easier to evaluate.