How WordPress.org plugin search ranking works
Oct 28, 2026
WordPress.org’s plugin search runs on Elasticsearch, and the code that builds its query is open source, in the plugin directory’s class-plugin-search.php. So the order of the results isn’t a mystery or a secret algorithm. It’s a three-step process: decide which plugins match at all, score how well each one matches the words, then multiply that score by six numbers taken from the plugin’s listing. This guide walks through the machine from start to finish. For what to change on your own listing, see How to rank higher in WordPress.org plugin search.
Step 1: which plugins get in
The query has one required part, a “must” clause: the base search across the listing’s text. A plugin that fails it isn’t in the results at all, whatever its installs or rating. In practice that means every word of the search has to appear somewhere in the listing, apart from short words the index drops, and allowing for word forms (“forms” finds “form”). The details are in How to choose a plugin name, short description and tags that search can find.
Two filters run alongside it. Plugins marked as disabled are left out, and searches made from the block inserter only look at block plugins.
The required clause carries a boost of just 0.1. Passing it gets you in; it barely adds to your score. Almost all of the text score comes from the optional parts that follow.
Step 2: the text score
Next come five optional “should” clauses. Each one that matches adds to the score, by an amount Elasticsearch works out from how well the words fit that field, multiplied by the clause’s boost:
| Clause | Fields it reads | Boost |
|---|---|---|
| The words in the name and slug, added together | title, slug | 5 |
| The author or a contributor | author, contributors | 3 |
| The whole phrase, in order, in the name | title | 2 |
| The words, best single field | short description, description, tags | 2 |
| The words, anywhere | name, short description, description, tags | 2 |
A few things follow from the table. The name is the only field that appears in three of the five clauses, which is why it matters most. The name and slug are summed, so a plugin with the search in both outscores one with it in the name alone. The short description, description and tags compete inside one clause where only the best of them counts, so saying the same thing in all three earns little extra.
How much each clause adds isn’t a fixed number. Elasticsearch uses BM25 scoring, which weighs things like how rare a word is across the whole directory and how long the field is. Those statistics live inside WordPress.org’s index and aren’t published, so nobody outside can compute the text score exactly. TrackWP estimates it from which fields match, and the Rank Simulator reports how closely that estimate fits the real order for each search.
Searches in other languages
If someone searches from a translated WordPress, or from a localised WordPress.org site, the query reads the translated name and description first. The English versions still count, but with a much smaller boost. A plugin with a translated name can therefore rank differently in, say, German search than in English. TrackWP’s keyword tracking can check positions per language.
Step 3: the six multipliers
Once a plugin has a text score, Elasticsearch’s function_score multiplies it by six functions. The query leaves the score mode at its default, so the six results are multiplied together, and that product multiplies the text score:
Final score = text score × freshness × “Tested up to” × installs × size × support × rating
| Function | Reads | Shape |
|---|---|---|
| Freshness | Last release date | 1 for 180 days, then halves every 360 days |
| “Tested up to” | Readme header against the current WordPress branch | 1 within 0.1, then falls by 0.6 every 0.4 |
| Installs | Active installs | log10(2 + 0.375 × installs) |
| Size | Active installs, only at 1 million or fewer | 0.75 per 900,000 below 1 million |
| Support | Support threads resolved in the last two months | log10(2 + 0.25 × resolved) |
| Rating | Average stars (2.5 if no ratings) | √(0.25 × stars) |
These are exact. The numbers are in the published code, and TrackWP computes them the same way. The methodology page draws each curve.
Because they multiply, a weak factor is never cancelled out. A ×0.50 halves the score, and only strength in the other factors can outweigh it. And because installs sit inside a logarithm, a big plugin’s lead is much smaller than its install count suggests.
A worked example
Take two plugins whose listings match a search equally well.
- Plugin A has 1 million installs, a 4.5-star rating and 10 resolved threads in the last two months, but last released 400 days ago.
- Plugin B has 20,000 installs, 5 stars and 25 resolved threads, and released 30 days ago.
Both are tested with the current WordPress.
| Factor | Plugin A | Plugin B |
|---|---|---|
| Freshness | ×0.65 | ×1.00 |
| “Tested up to” | ×1.00 | ×1.00 |
| Installs | ×5.57 | ×3.88 |
| Size | ×1.00 | ×0.73 |
| Support | ×0.65 | ×0.92 |
| Rating | ×1.06 | ×1.12 |
| All six multiplied | ×2.53 | ×2.90 |
Plugin B ranks above a plugin with fifty times its installs, because A let its freshness and support slide. If A’s text match were 20% better, though, A would win again: 2.53 × 1.2 is 3.04. That is the whole system in miniature. Text match and the six factors trade off against each other, and neither decides on its own.
Step 4: the order you see
Results are returned in order of the final score; the query sets no other sort. WordPress.org shows them a page at a time and caps a search at 50 pages, so on a crowded search the plugins past that point can’t be reached by paging at all.
The order isn’t fixed from day to day. Freshness changes every day once a plugin is past 180 days. Install bands, ratings and the resolved count change as the directory updates. Every major WordPress release moves the “Tested up to” origin for everyone at once. A plugin can drop a few places overnight without touching its listing, because a rival released an update or its own two-month support window lost a few resolved threads. Why did my plugin drop in WordPress.org search? covers how to tell which.
What the formula ignores
Some things plugin authors often worry about aren’t in the query at all:
- Downloads. Only active installs count. A release-day spike in downloads does nothing for search.
- The number of reviews. Only the average rating is used. Ten 5-star reviews and a thousand score the same.
- Plugin age. An old plugin gets no bonus for having been around; only the date of its last release counts.
- Unresolved threads. The support factor counts resolved threads, so an open thread doesn’t lower your score directly. It’s a resolved thread you haven’t earned yet.
Seeing it for a real search
The Rank Simulator runs a live WordPress.org search and lays out all of this for the plugin you choose: its estimated text score, its six factors, and the same figures for the plugins just above and below it. From there you can try a change, such as a release, a new “Tested up to” or more resolved threads, and see where the plugin would move.