WordPress Core Already Gives Us a Path to Better Plugin Discovery

The Add Plugins screen is one of WordPress Core’s quiet strengths. It gives millions of sites a stable, familiar way to search a directory that keeps changing. Core does not need to bundle a frozen catalog or know the ranking rules. It asks WordPress.org for current results and handles the important local work: permissions, compatibility notices, installation, updates, and activation.

That architecture gives us a useful opportunity. We can make plugin discovery more relevant and give qualified new plugins a fairer chance without replacing the screen people already understand.

Plugin search currently treats success as evidence that a plugin deserves more chances to succeed. That makes some sense: a large install base can be a useful confidence signal. But it also creates a trap for new plugins. A plugin needs users to earn visibility, and visibility to earn users. Good work can disappear before anyone has a chance to find out whether it is good.

My proposal keeps the parts that work—Core, the Plugins API, and Elasticsearch—and improves what the search system optimizes for. It would understand the job behind a query, check whether a plugin can credibly do it, and give qualified but underexposed plugins a controlled chance to prove themselves.

The first useful version can ship as a WordPress.org service improvement. A future Core release could build on it with even better explanations, filters, and privacy-conscious measurement.

Core already gives us the right delivery path

The Add Plugins screen lives in WordPress Core. Core checks permissions, builds the screen, sends the query, displays plugin cards, and handles installation. In the current source, plugin-install.php creates a WP_Plugin_Install_List_Table; that table calls plugins_api( 'query_plugins', … ); and plugins_api() requests results from the WordPress.org Plugins API.

This split is the whole opportunity, and it is a strength of Core’s architecture.

WordPress.org can improve which plugins the API returns—and in what order—while keeping the request and response contract compatible. The existing Add Plugins screen can display those better results. No Core update, separate plugin, or action from the site owner is required for that first phase.

That is not a way around Core. It is Core doing exactly what a durable client should do: provide a trusted interface while a live service improves behind a stable boundary.

This would benefit any WordPress site that uses the built-in WordPress.org plugin search, can reach WordPress.org, and has a user with permission to install plugins. That is the precise claim. A disconnected site, a managed host that replaces the directory, or a user without installation permission is outside that path.

Core is already creating more room for discovery work. In WordPress 7.1, the plugin list table can render groups supplied by the API. The API can return a groups map and a group value for each plugin, and Core prints those group headings. WordPress.org can test clearer result sets on current sites while older clients continue to receive the ordered plugin list they understand.

Keep Elasticsearch and give it a better job

WordPress.org already uses Elasticsearch for plugin search. More precisely, the public Plugin Directory code hooks into Jetpack Search and modifies the Elasticsearch query. It searches fields including plugin title, excerpt, description, tags, author, contributors, and slug. It then applies score functions for recency, tested-up-to version, active installs, resolved support threads, and rating. You can read the current query in the WordPress.org repository.

Those are sensible signals. The improvement is to stop asking one blended score to answer three different questions:

• Relevance asks: Does this plugin solve the problem in the query?
• Confidence asks: Is there enough evidence to trust this result?
• Discovery asks: Has a qualified plugin received enough exposure for us to learn anything about it?

Active installs can contribute to confidence. They should not stand in for relevance, and they should not decide whether an unknown plugin ever receives an impression. The concern is not hypothetical: open WordPress.org tickets have documented the self-reinforcing effect of active-install weighting and proposed capping its contribution.

I would keep Elasticsearch. It is proven infrastructure for the directory’s exact-text search, filters, and current ranking. Modern Elasticsearch can also perform vector retrieval and reciprocal rank fusion, but the public repository does not tell us the version, license, capacity, or topology of the production cluster. Those details need confirmation from the WordPress.org infrastructure team.

That private-infrastructure check is not a blocker. If the live cluster supports the needed features, hybrid retrieval can stay inside Elasticsearch. If it does not, Elasticsearch can keep returning its text candidates while a small semantic sidecar returns vector candidates; the WordPress.org service can combine the two ranked lists with the published RRF formula. Either route preserves the current engine and the current API.

What the new search would do

Search should begin by understanding the job, not by guessing which familiar plugin name the user meant.

A query such as “a lightweight event calendar with recurring events, no external account, and good block support” contains several requirements:

• an event calendar;
• recurring events;
• no required external service;
• block-editor support;
• a preference for a focused implementation.

Plain keyword search may catch some of that. It may miss a plugin whose readme uses “repeat schedules” instead of “recurring events,” or rank a large calendar suite that requires a hosted account even though the query explicitly rules one out.

My proposed retrieval pipeline has five parts:

1. Exact retrieval stays. Slug, plugin name, author, and precise feature terms should remain strong. If someone searches for a known plugin, the system should not get clever.
2. Semantic retrieval joins it. A multilingual embedding model finds plugins whose documented capabilities match the meaning of the request, even when the wording differs.
3. The two result lists are fused. Reciprocal rank fusion combines exact-text and semantic candidates without pretending their raw scores are directly comparable.
4. Hard constraints and evidence are applied. The current request supplies locale and WordPress version, so the server can use those immediately. Required services, multisite support, maintenance status, and other verifiable facts can filter or rerank the candidate set. Core already checks each returned plugin’s declared PHP requirement against the local site before allowing installation.
5. A small top set is reranked. A multilingual reranker can compare the whole query with the strongest candidates. This happens after retrieval, not on every plugin in the directory.

The first version does not need a chat box, a generated answer, or a model improvising on every keystroke. Search can still look like search. The intelligence belongs behind the result list.

Build a better plugin document

Search quality is limited by what the index knows. Today, much of a plugin’s meaning is trapped in prose written for a readme page.

I would create a structured search document for every plugin, with fields such as:

• capabilities and integrations;
• explicit exclusions and limitations;
• required external services and accounts;
• data handling and telemetry disclosures;
• WordPress and PHP requirements;
• multisite, block, and accessibility support;
• free functionality and paid boundaries;
• evidence for each extracted claim.

Models can help extract this structure offline, when a plugin is submitted or updated. They should not be treated as an authority. A capability needs evidence from the readme, plugin headers, source, or a test. Claims that cannot be supported should not become ranking facts.

This is also where multilingual models matter. WordPress is global, but plugin discovery still asks authors and users to meet in the same vocabulary. A multilingual index can connect a query and a plugin description across wording—and, after careful evaluation, across language—without turning every search into a translation exercise.

Give unknown plugins a fair test, not a free pass

The cold-start problem cannot be solved by semantic search alone. A ranking system trained on existing behavior will tend to reproduce existing exposure.

I would test a small discovery allowance—roughly one or two positions on a typical first page, or 10–15 percent of eligible impressions—for plugins that are:

• among the most relevant results for the query;
• compatible with the WordPress version supplied to the API and declare their PHP requirement for Core’s local compatibility check;
• recently maintained;
• not flagged by the approved known-vulnerability source used for the experiment;
• have passed automated quality checks and isolated runtime smoke tests;
• still too underexposed for install count to tell us much.

That is not a lottery. An unrelated plugin never earns a discovery position just because it is new. A plugin with unresolved safety or compatibility concerns never earns one because its author needs users. The plugin first clears a relevance and quality gate; the discovery system only decides whether a qualified candidate receives a fair test. Automated checks help with that gate, but they are not a security certification or a replacement for the Plugin Review and Security teams.

The idea is close in spirit to the Featured Plugins experiment, which is testing visibility for newer plugins that meet a defined bar. Search could turn that principle into a repeatable, query-specific system: not “this plugin is featured for everyone,” but “this lesser-known plugin is unusually relevant to this particular need and has cleared the checks required for limited exposure.”

Rotation matters. Exposure should be capped by plugin and by author so one developer cannot occupy the discovery lane with a family of similar plugins. A plugin should graduate into ordinary ranking when it accumulates enough trustworthy evidence, or pause when its outcomes are poor.

Measure what the current architecture can actually observe

Raw installations are a weak finish line. Bulk deployment on a hosting network is not the same evidence as many independent people finding a plugin useful for the query they entered.

The no-Core phase can measure search quality without inventing telemetry the current client does not send:

• relevance on a published, hand-judged set of real plugin searches;
• exact-name and exact-slug success rates;
• no-result and low-confidence query rates;
• latency, error rate, and fallback rate;
• how often qualified underexposed plugins receive impressions;
• aggregate movement in downloads, active installs, ratings, and support activity, treated as directional evidence rather than query-level attribution.

The current Plugins API request does not provide a privacy-safe chain from a search impression to activation, persistence, removal, or rollback. The first release should not pretend otherwise, and it should not try to reconstruct that chain from site identity, IP address, or other incidental data.

A later Core enhancement could add an explicit, privacy-reviewed experiment token and a small set of consented or appropriately governed aggregate outcome events. That would let WordPress measure activation, persistence, early removal, or failure without smuggling tracking into a server-side change. Core’s review process is an asset here: accessibility, privacy, security, and user control should shape that feature before it ships.

The evaluation set should contain real plugin-search needs across languages and site types, judged by WordPress practitioners. Offline judgments catch obvious failures before traffic is involved. A limited live comparison can then test latency, reliability, exposure, and aggregate behavior without claiming outcome data the client does not send.

The software and infrastructure I would use

The practical stack has a confirmed path and a fallback path:

• WordPress Core’s existing admin and Plugins API remain the delivery path. The request already carries the query, locale, and WordPress version. Core renders the response and performs local WordPress and PHP compatibility checks.
• The current WordPress.org PHP service continues to own the API contract, deterministic ranking policy, caching, rollout flags, and fallback behavior.
• The existing Elasticsearch service continues to provide BM25 text retrieval and today’s structured filters. Native vector search and native RRF are an optimization only after the production version, license, and capacity are confirmed.
• Hugging Face Text Embeddings Inference can serve multilingual-e5-large-instruct on CPU or supported GPUs. Its official documentation also supports reranker endpoints. I would benchmark models on a WordPress-specific relevance set instead of choosing from a generic leaderboard.
• Faiss is the fallback vector index if production Elasticsearch cannot host vectors. It is an MIT-licensed similarity-search library, not another public database to operate. The semantic sidecar can rebuild its index from the authoritative plugin documents.
• Application-level RRF in the PHP service or semantic sidecar merges the Elasticsearch and vector rankings when native Elasticsearch RRF is unavailable. The formula is small, deterministic, testable, and independent of an Elasticsearch subscription feature.
• Python indexing workers build structured plugin documents and embeddings when plugin code or readme data changes. The existing directory data remains authoritative; generated fields carry evidence and can always be rebuilt.
• Plugin Check, WP-CLI, WordPress Playground, and Playwright provide static checks, isolated activation tests, compatibility runs, and repeatable browser tests. Plugin Check provides static and runtime checks for directory requirements and best practices; it is one quality signal, not a complete security audit. Playground documents both its command-line tooling and Playwright integration.
• The existing WordPress.org deployment and monitoring platform should run and observe these services. The public code does not reveal its orchestration, secrets, network policy, logging, or alerting stack, so the proposal should integrate with those standards rather than prescribe replacements from the outside.

No model needs permission to rewrite the final ranking on its own. No learning-to-rank system is needed until there is clean, representative outcome data worth learning from. No new component becomes a single point of failure: if embedding, vector retrieval, reranking, or policy evaluation times out, the API returns the current Elasticsearch ranking.

One dependency cannot be settled from public code: the approved source and governance process for known-vulnerability status. That must be chosen with the Plugin Review, Security, Privacy, Legal, and infrastructure contributors. Until it is, the experiment can use the same documented/manual safety qualification as the Featured Plugins experiment rather than claim an automated security gate it does not yet possess.

What is confirmed, and what still needs an infrastructure check

Here is the boundary after checking WordPress 7.1 Core, the public WordPress.org search code, and the current documentation for the proposed services:

The proposal is possible without knowing every private production detail because it does not depend on one undocumented Elasticsearch feature. The private details still matter for sizing, latency, deployment, security review, and operations. They are implementation questions for the teams who run WordPress.org, not facts an external proposal should invent.

Start with a narrow, reversible experiment

I would ship this in stages:

1. Build a judged set of real plugin searches and publish the evaluation method.
2. Audit the production Elasticsearch version, license, query path, capacity, latency budget, and operational constraints with the infrastructure team.
3. Add structured capability documents and multilingual embeddings to a test index or sidecar.
4. Run the proposed ranking in shadow mode, compare it with the current results, and verify the fallback under failure.
5. Add deterministic compatibility and quality gates, with human review for any unresolved safety signal.
6. Test one or two discovery positions on a small share of eligible search traffic.
7. Publish aggregate results, failure cases, infrastructure costs, and ranking changes.

Every stage can be measured. Every stage can be rolled back. The existing search remains available as a control.

The hard part is not adding a model. The hard part is deciding what a healthy plugin ecosystem should reward, then making those choices visible enough to challenge.

My answer is straightforward: reward relevance first, confidence second, and give qualified unknown work enough exposure to produce evidence of its own. Keep popularity as a clue, cap its power, and stop asking plugins to be popular before they are allowed to be found.

WordPress already has the screen, the API boundary, the search engine, the compatibility protections, the testing tools, and a live experiment proving that better discovery matters. Core built the foundation. This proposal uses it to make the directory more helpful now, then gives future Core work better evidence and better services to build on.

Can this scale to WordPress?

Yes, if we keep it retrieval-first. WordPress.org currently lists more than 70,000 free plugins. That is a large catalog for a person to navigate, but a modest corpus for a modern search index. One 1,024-dimension float vector per plugin would occupy roughly 275 MiB before index overhead. Even several evidence-backed chunks per plugin remain within an ordinary production search footprint, and Elasticsearch supports approximate nearest-neighbor search plus vector quantization when memory matters.

The real scaling risk is query-time model inference, not the number of plugins. Running a large multilingual model and reranker for every keystroke would add unnecessary latency and cost. The production path should therefore have firm limits:

• skip semantic work for exact plugin names, slugs, and authors;
• cache normalized query embeddings and common result sets;
• generate plugin embeddings asynchronously when a plugin changes, not during a search;
• run text and vector retrieval in parallel, then merge only their short result lists;
• rerank perhaps 10–30 finalists, never the whole directory;
• replicate the stateless embedding service horizontally and use the dynamic batching, tracing, and metrics built into TEI;
• give the semantic branch a strict latency deadline and return the current Elasticsearch ranking whenever it misses.

Millions of WordPress sites do not mean millions of simultaneous semantic searches; the additional load is tied to people using Add Plugins. But the true request rate, traffic peaks, cluster topology, and available hardware are private operational facts. The WordPress.org infrastructure team would still need to size and load-test the system.

That is why the rollout matters as much as the software: run the new path in shadow mode, enable it for a small percentage of traffic, watch tail latency and failure rates, and expand only when it stays inside the existing service budget. A generated answer for every query would be difficult and unnecessary to scale. Cached hybrid retrieval with bounded reranking and an Elasticsearch fallback is a much more practical fit for WordPress.

---

Technical note and sources

This proposal was checked against the WordPress 7.1 release from August 19, 2026. The no-Core-release conclusion applies to server-side retrieval, ranking, and compatible result-group changes made behind the existing Plugins API contract. Richer interface controls, PHP-version-aware server ranking, or privacy-reviewed outcome telemetry are good candidates for later Core work.

• WordPress 7.1 plugin-install.php
• WordPress 7.1 plugin install list table
• WordPress 7.1 plugins_api() implementation
• Current WordPress.org Plugin Directory search query
• WordPress.org Plugin Directory
• Elastic vector storage and quantization guidance
• Hugging Face Text Embeddings Inference
• Elastic hybrid search documentation
• Elastic reciprocal rank fusion reference
• Hugging Face Text Embeddings Inference supported models and hardware
• Faiss similarity-search library
• Featured Plugins experiment