Search is two systems stacked together: an index that finds every document matching a query fast, and a ranking function that decides which matches to show first. Most "bad search" complaints are actually ranking complaints — the right result exists in the index, but relevance scoring buried it on page three.
Quick Answer: Search = retrieval (find candidates fast via an index) + ranking (score and order those candidates by relevance). Exact-match retrieval fails on typos and synonyms; relevance ranking is a tunable product decision, not a fixed algorithm.
Retrieval: How the Index Finds Candidates in Milliseconds
An index is a precomputed lookup structure that maps words to the documents containing them, so search doesn't scan your entire database on every keystroke. Without one, a query against a million-row table means a million-row scan; with one, it's a near-instant dictionary lookup. This is why "just add a search bar" is never a five-minute engineering task.
The core structure nearly every search engine uses is an inverted index — the reverse of a normal document-to-words mapping. Instead of "document 5 contains these 200 words," it stores "the word 'onboarding' appears in documents 5, 19, and 204." Databases like PostgreSQL (tsvector), Elasticsearch, and Algolia all build variants of this structure under the hood.
Why "Just Use SQL LIKE" Breaks Down at Scale
A LIKE '%query%' clause works for a demo and fails in production because it can't use an index efficiently — the database still scans row by row for substring matches. It also has no concept of relevance; every match is equally "correct," so a title match and a buried footnote match rank identically.
Three specific failures show up almost immediately once real users start typing:
- No typo tolerance. A user searching "recieve" gets zero results for "receive," even though the content exists.
- No stemming. Searching "running" won't match documents containing only "run" or "runs" unless the index explicitly links word forms.
- No ranking signal. Every row that matches is treated as equally relevant, so a one-word passing mention outranks nothing — there's no "outranks," just an unordered list.
This is the underlying reason dedicated search infrastructure (Elasticsearch, Algolia, Meilisearch, Postgres full-text search, or a vector database for semantic matching) tends to replace naive LIKE queries once a product has more than a few hundred searchable records.
Why Exact-Match Search Fails Real Users
Exact-match search fails because human language is messy — people misspell words, use synonyms, and phrase the same intent a dozen different ways, none of which a literal string comparison can bridge. The fix is a layer of text normalization and expansion that sits between what the user typed and what the index actually matches against.
Three normalization techniques handle most of the gap between "what was typed" and "what was meant":
| Technique | What It Solves | Example |
|---|---|---|
| Fuzzy matching / edit distance | Typos, misspellings | "recieve" → matches "receive" |
| Stemming / lemmatization | Word form variation | "running," "runs" → both match "run" |
| Synonym expansion | Vocabulary mismatch | "cheap" → also matches "affordable," "low-cost" |
A practical takeaway: none of these are free. Stemming can over-match (stemming "universe" and "university" to a shared root in poorly tuned systems) and synonym lists require ongoing curation as your domain's vocabulary evolves. Treat them as tunable settings, not a one-time setup.
Semantic and Vector Search: The Newer Layer
Vector-based (embedding) search adds a fourth layer: instead of matching words, it matches meaning, so a query for "how to cancel my plan" can retrieve a document titled "ending your subscription" with zero shared keywords. This is genuinely useful for natural-language queries and support content, but it isn't a replacement for keyword indexing — most production systems now run hybrid search, blending keyword and vector scores, because pure semantic search can drift toward "related but wrong" results on precise queries like part numbers or exact names.
Ranking: The Formula That Decides What Users See First
Ranking is the scoring step that takes every candidate document the index returned and orders them by estimated relevance to this specific query and, often, this specific user. This is where "search quality" as a felt experience actually lives — two products can index identical data and feel completely different to use based on ranking alone.
The classic starting-point formula, still underlying much of Elasticsearch's default scoring, is TF-IDF (term frequency-inverse document frequency): a term that appears often in one document but rarely across all documents is a strong relevance signal, while a common word like "the" contributes almost nothing. Its modern refinement, BM25, adds diminishing returns for repeated terms and normalizes for document length, and is the default ranking algorithm in Elasticsearch and Lucene-based systems today.
Beyond raw text relevance, most production ranking functions blend in several categories of signal:
- Textual relevance — how well query terms match the document (BM25/TF-IDF score)
- Popularity/engagement — click-through rate, purchase count, or view count on that result historically
- Recency — freshness matters heavily for news and inventory, less for reference documentation
- Personalization — a user's own history, role, or stated preferences
- Business rules — sponsored placement, in-stock status, margin, or editorial curation
The Product Decision Hiding Inside the Ranking Formula
Choosing how to weight those signals is a genuine product decision, not a purely technical one — it encodes what your team believes users actually want, and it's worth stating explicitly rather than letting it default to whatever the search vendor ships. An e-commerce search that over-weights popularity will keep surfacing the same bestseller and starve new inventory of visibility; one that over-weights recency on a documentation site will bury the canonical guide beneath a typo-fix commit from last week.
This is conceptually the same territory as prioritization frameworks like RICE or Kano — you're trading off competing signals against a limited set of top-of-page slots, and the "right" weighting is a hypothesis to test, not a constant to solve for once. If your team already runs structured prioritization exercises, the instinct transfers directly to tuning a ranking formula.
How to Evaluate Search Quality with Real Queries
The only reliable way to know if your search is good is to test it against real queries your actual users type, not the clean, well-formed queries your team assumes they type. Search quality evaluation is fundamentally an information-retrieval measurement problem, and PMs can borrow standard metrics from that field without needing a data-science background.
Two metrics cover most of what you need:
| Metric | What It Measures | Why It Matters |
|---|---|---|
| Precision@k | Of the top k results shown, how many are actually relevant | Catches "noisy" results cluttering the top |
| Recall | Of all truly relevant documents, how many did search surface at all | Catches "the answer exists but was never returned" |
| Zero-result rate | % of searches returning nothing | Direct signal of vocabulary gaps or index blind spots |
| Click-through position | Average rank position of the clicked result | A rising average rank position over time signals ranking decay |
Build a Query Test Set from Real Search Logs
Pull your top 50-100 most frequent search queries from logs, plus a sample of queries that returned zero results, and manually judge whether the current top results are actually correct — this single exercise usually surfaces more ranking problems than any amount of algorithm reading. Jakob Nielsen's Nielsen Norman Group has long documented that a meaningful share of site-search sessions end in abandonment specifically because the visible results don't match user intent, which is a symptom this exercise catches directly.
Track zero-result queries as a standing backlog item, not a one-time audit. Each one is either a missing synonym, a missing piece of content, or a genuine content gap — and distinguishing between those three is exactly the kind of judgment call that separates a shallow "fix the algorithm" reflex from an actual root-cause fix. This same "the interface can be perfect and the request still fails silently" pattern is a close cousin of the reliability issues covered in how the web works: a PM's mental model — a request can succeed technically and still fail the user.
Search Architecture Decisions PMs Should Weigh In On
PMs don't need to pick the search library, but they do need to weigh in on the tradeoffs that determine whether search feels fast, relevant, and maintainable as the catalog grows. Three decisions come up in nearly every search-feature scoping conversation.
- Build vs. buy. Managed search services (Algolia, Typesense, Elasticsearch's hosted offerings) trade cost and some flexibility for dramatically faster time-to-launch and built-in typo tolerance — often the right call unless search is a genuine core differentiator.
- Reindexing strategy. Every content update needs to propagate into the index, and the lag between "content changed" and "index updated" is a real UX decision, not just an engineering detail — a support team that just corrected an article shouldn't have to wait an hour for search to reflect it.
- Faceted filtering. Filters (category, price range, date) work against the same index and interact with ranking — a filter that's too aggressive can return zero results even when relaxing it slightly would surface a good match, which is its own version of the zero-result problem above.
These decisions depend on how cleanly your underlying data is structured — a category field that's sometimes a string and sometimes an array will produce inconsistent facets no matter how good your ranking formula is. This is exactly the kind of groundwork Prodinja's Data Modelling tool is designed to help with: it walks you through defining entities and fields explicitly — including type consistency — before that structure becomes the thing your search index and ranking logic both depend on. Search quality is downstream of data modeling decisions made months earlier, which is easy to forget when you're staring at a ranking tweak.
Key Takeaways
- Search is retrieval plus ranking — an index finds candidate matches fast, and a separate scoring function orders them by relevance; most complaints about "bad search" are ranking complaints, not missing-content complaints.
- Exact-match string comparison fails on typos, word-form variation, and synonym mismatches — fuzzy matching, stemming, and synonym expansion each solve a distinct piece of that gap.
- Relevance ranking is a product decision, not a fixed formula — how you weight textual match, popularity, recency, and business rules encodes what your team believes users want.
BM25is the modern default text-relevance algorithm in most search infrastructure, refining the olderTF-IDFapproach with length normalization and diminishing returns on repeated terms.- Hybrid search (keyword plus vector/semantic) handles natural-language queries that pure keyword matching misses, but shouldn't fully replace keyword indexing for precise lookups.
- Evaluate search with real query logs, tracking precision, zero-result rate, and click position — not intuition about how users search.
- Search quality depends on clean, consistent data modeling upstream of the index and ranking layer, not just algorithm tuning downstream.
Frequently Asked Questions
How does search actually work behind the scenes?
Search works by first building an inverted index that maps words to the documents containing them, then, at query time, retrieving candidate documents from that index and scoring each one with a ranking formula before displaying results in order.
Why do my search results feel wrong even though the data exists?
Results usually feel wrong because of ranking, not missing data — the correct document is likely in your index but scored lower than less-relevant matches due to how your ranking formula weights text relevance, popularity, recency, and business rules.
What is the difference between search relevance and search ranking?
Relevance is the underlying property of how well a document actually answers a query; ranking is the engineering implementation that estimates relevance using signals like BM25 text scoring, click history, and recency, then orders results accordingly.
Should I build custom search or use a managed service like Elasticsearch or Algolia?
For most products, a managed service is the faster and lower-risk path since it ships typo tolerance, stemming, and ranking infrastructure out of the box; building custom search only makes sense when search is a core differentiator with unusual requirements.
How do I know if my product's search quality is actually good?
Pull your most frequent real search queries plus your zero-result queries from logs, manually judge whether the top results are actually relevant, and track precision, zero-result rate, and average click position over time rather than relying on anecdotal impressions.
Search architecture decisions connect closely to two other technical foundations worth understanding: what an API actually is for product managers, since most search features are exposed through one, and the accumulating cost of technical debt, since a poorly modeled search index is exactly the kind of debt that compounds quietly. For the broader map of foundational technical concepts every PM should know, see the technical foundations complete guide; and if you're validating that search actually solves a real user job, pair this with the jobs-to-be-done complete guide and the customer journey complete guide to make sure the query patterns you're optimizing for map to a real moment in the user's journey.