What Is the Relevance Score (_score) in Elasticsearch?
The single number that decides which result lands at the top of the page — and the reason two searches for the same word can rank completely differently.
Type a search into Google, Amazon, or any decent search box, and the results you actually want almost always land near the top — not through luck, but because every single result was silently assigned a number measuring how well it matches what you asked for. In Elasticsearch, that number is called _score. It’s arguably the most important concept in the entire search experience, yet it’s invisible to most end users and misunderstood by many engineers. This article opens it up completely: what it is, how it’s calculated, and how to actually influence it.
1Core Concepts
_score is a floating-point number that Elasticsearch calculates for every document returned by a search query, representing how relevant that document is to the specific query that was run. A higher _score means a better match; by default, Elasticsearch sorts search results from highest _score to lowest, which is exactly why the “best” matches naturally appear first.
Imagine judges at a talent show holding up scorecards after every performance. The judge isn’t declaring a performance “good” or “bad” in isolation — they’re comparing it against everyone else on stage that night, and producing a number that lets the show rank every act from best to worst. Elasticsearch’s _score works exactly the same way: it’s a relative, per-search ranking number, not some fixed, universal “quality rating” for a document.
What it is: a numeric relevance rating, unique to each document within the context of one specific search request.
Why it exists: without a way to rank “how well” something matches, a search engine could only tell you yes-or-no whether a document matched at all — utterly useless once thousands of documents technically match a broad query.
Where it’s used: default result ordering in every full-text search, powering “best match first” experiences across e-commerce, content platforms, and internal search tools everywhere.
_score is not a stored, permanent attribute of a document — it’s calculated fresh, on the fly, for every single search, based entirely on that specific query. The very same document can receive a completely different _score in a different search.
_score vs. Filters
Not every part of a search contributes to _score. Clauses run in “filter” context (a plain yes/no check, like “status equals shipped”) don’t affect relevance at all — they simply narrow which documents are considered. Only clauses run in “query” context (like a full-text “match” on a search phrase) contribute to the actual score. This is a big part of why understanding query vs. filter context matters so much for both relevance and performance.
2Architecture & Components
Elasticsearch’s default scoring algorithm, called BM25, blends several signals about how well a search term matches a document, relative to the whole dataset. Understanding these ingredients demystifies why some documents outrank others even when both technically “contain” the search word.
Term Frequency (TF)
How many times the search term appears in this particular document’s field — generally, more occurrences suggest stronger relevance, though BM25 applies diminishing returns so it doesn’t reward keyword-stuffing.
Inverse Document Frequency (IDF)
How rare or common the search term is across the entire index — a match on a rare word (“archaeopteryx”) counts for more than a match on a common word (“the”), since rare-word matches are more distinguishing.
Field Length Normalization
Adjusts for the total length of the field — a term match inside a short, focused field carries more weight than the same match buried inside an enormous block of text.
Boosting
An explicit multiplier you can apply to specific fields or specific query clauses, deliberately telling Elasticsearch “weigh this signal more heavily than the default formula would.”
graph TD
A[Search Query Submitted] --> B[For each matching document]
B --> C[Calculate Term Frequency
how often term appears here]
B --> D[Calculate Inverse Document
Frequency - how rare is the term]
B --> E[Apply Field Length
Normalization]
C --> F[Combine via BM25 formula]
D --> F
E --> F
F --> G[Apply any explicit
boosts]
G --> H["Final _score for this document"]
H --> I[Sort all documents by
_score, highest first]
3Internal Working
Query Parsing
The search request is parsed, and each clause is classified as either contributing to scoring (query context) or purely filtering (filter context).
Per-Shard Scoring
Each shard independently scores its own matching documents using statistics (like term frequency) gathered from its own local data, then returns its top-scoring candidates to the coordinating node.
Global Result Merging
The coordinating node merges the ranked lists from every shard into one final, globally sorted list, ordered from highest _score to lowest.
Response Returned
The final response includes each matching document along with its computed _score, letting clients see exactly how strongly each result matched, not just that it matched.
Picture several regional judging panels for a national competition, each scoring their own local entries independently, then sending only their top scorers to a national committee, which combines everything into one final overall ranking. Each Elasticsearch shard behaves like a regional panel; the coordinating node behaves like the national committee.
Because IDF (how rare a term is) is calculated using statistics from each shard individually by default, the exact same document can occasionally receive a very slightly different _score depending on how data happens to be distributed across shards — a subtle but well-known behavior worth knowing about when scores need to be perfectly reproducible.
4Data Flow & Lifecycle
When _score Is Calculated
- Any search using a scored query clause, like “match,” “multi_match,” or “query_string.”
- Boolean queries where at least one clause sits in “must” or “should” context.
- Any query where the results are being sorted by relevance (the default sort order).
When _score Is Skipped or Meaningless
- Plain Get-by-_id requests, which bypass scoring entirely.
- Queries that consist purely of filter-context clauses — Elasticsearch returns a constant score (commonly 1.0) since there’s nothing to differentiate relevance on.
- Searches explicitly sorted by another field (like price or date) instead of relevance — _score may still be computed but isn’t used for ordering.
A document’s _score only exists for the lifetime of that one search response — it is never stored back onto the document itself. Run the exact same query again a second later (perhaps after new documents were indexed, shifting the IDF statistics slightly), and the score for the same document could, in principle, shift too.
5Advantages, Disadvantages & Trade-offs
Advantages
- Automatically surfaces the most relevant results first, without requiring manual ranking rules for every query.
- BM25 is well-tested, fast to compute, and works well across a huge range of search scenarios out of the box.
- Fully customizable through boosting, function scores, and rescoring for domain-specific ranking needs.
Disadvantages
- _score alone doesn’t capture business priorities like profit margin, freshness, or personalization — those require explicit tuning.
- Raw _score values aren’t meaningfully comparable across different queries or different indices.
- Slight, shard-distribution-based score variance can occur, which surprises teams expecting perfectly deterministic ranking.
The core trade-off is convenience versus control: out-of-the-box BM25 scoring works remarkably well for general search with zero configuration, but any business that needs relevance tuned to specific priorities (boosting newer products, promoting sponsored listings) has to deliberately layer additional scoring logic on top.
6Security
Filtering Happens Before Scoring Matters
Document-level security filters restrict the candidate document set before scoring is even meaningful for those results — a user never sees a _score for a document they weren’t authorized to view in the first place.
Score-Based Inference
In rare, carefully constructed scenarios, comparing relative scores across multiple crafted queries could theoretically leak subtle statistical information about restricted data; sensitive systems typically avoid exposing raw scores to untrusted clients as an extra precaution.
Boost Injection
If user-supplied input is allowed to directly control boost values or scoring scripts without validation, a malicious client could manipulate ranking or trigger excessive computation — boost and script inputs should always be validated server-side.
Think of a restricted art auction: bidders never even see the items they’re not cleared to bid on, so there’s no ranking or comparison happening for those hidden pieces at all. Security filtering works the same way — it removes unauthorized documents from consideration entirely, before relevance scoring ever becomes relevant.
7Monitoring, Logging & Metrics
Relevance is famously hard to measure automatically, but several signals help teams catch scoring problems early:
- Click-through position tracking: if users consistently click results ranked 5th or lower instead of the top result, that’s a strong signal your relevance tuning doesn’t match user expectations.
- Score gap analysis: a huge score gap between the top result and everything else usually indicates a very confident, strong match; a flat, nearly identical score across many results often means the query wasn’t specific enough to differentiate well.
- A/B testing relevance changes: because relevance is subjective and business-specific, teams typically validate boosting or scoring changes through controlled experiments rather than trusting the formula blindly.
- Explain API usage in debugging: Elasticsearch’s “explain” feature breaks down exactly how a document’s _score was calculated, term by term — invaluable when investigating an unexpected ranking.
8Design Patterns & Anti-patterns
Pattern: Function Score for Business Priorities
Layering a function score on top of BM25 lets teams blend text relevance with business signals — like boosting newer listings, higher-rated products, or promoted content — without abandoning the underlying relevance algorithm entirely.
Pattern: Field Boosting
Assigning a higher boost to a “title” field than a “description” field reflects the intuitive idea that a match in the title is usually a stronger signal of relevance than the same match buried deep in a long description.
Pattern: Two-Stage Rescoring
Running a fast, simple query for the full candidate pool, then applying a more expensive, precise rescoring pass only to the top few hundred candidates, balances performance with high-quality final ranking.
Treating _score as an Absolute, Comparable Number
Comparing raw _score values across two entirely different queries (or different indices) is meaningless — the number only makes sense relative to other results within the exact same search.
Sorting Everything by a Non-Relevance Field by Default
Defaulting every search to sort strictly by date or price, ignoring text relevance entirely, throws away one of Elasticsearch’s core strengths and often produces a noticeably worse search experience for free-text queries.
9Best Practices & Common Mistakes
Best Practices
- Use the “explain” API when a ranking result looks wrong, rather than guessing at the cause.
- Boost important fields (like title) over less important ones (like long-form descriptions) deliberately.
- Validate relevance changes with real user click data or A/B testing, not just gut feeling.
- Keep filter-only conditions in filter context so they don’t unnecessarily affect scoring or performance.
Common Mistakes
- Comparing raw _score numbers between unrelated searches as if they meant the same thing.
- Overriding relevance sort with a rigid field sort by default, losing the benefit of text-match ranking.
- Ignoring shard-count-related score variance when perfectly reproducible scores are required.
- Exposing internal boost or scoring script parameters directly to untrusted client input.
10Real-World & Industry Examples
Best-Match Product Search
Online retailers blend text relevance with function-score boosts for stock availability, popularity, and margin, so the “best” result balances what the customer typed with what the business wants surfaced.
Recency-Weighted Relevance
News platforms commonly combine text relevance with a decay function that gently boosts more recent articles, so breaking stories don’t get buried behind older, heavily-matched archives.
Skill-Match Ranking
Job search platforms weight matches on job title and required skills more heavily than matches buried in a lengthy job description, using field boosting to reflect what actually signals a strong candidate match.
Help Article Ranking
Customer support search tools rely on _score to surface the single most relevant help article first, directly reducing support ticket volume when it works well.
11Frequently Asked Questions
12Summary and Key Takeaways
Key Takeaways
- _score is a per-search, per-document relevance number that determines default result ordering, from highest to lowest.
- By default, Elasticsearch uses the BM25 algorithm, combining term frequency, inverse document frequency, and field length normalization.
- Only clauses in query context affect scoring; filter context clauses narrow results without influencing _score.
- _score is never stored — it’s recalculated fresh for every search and can vary between different queries or over time.
- Boosting and function scores let you blend business priorities (freshness, popularity, margin) with raw text relevance.
- Security filtering removes unauthorized documents from consideration entirely, before scoring becomes meaningful.
- Use the explain API whenever a ranking result looks wrong, instead of guessing at the underlying cause.