AI assistants are appealing plugin advisers. They understand natural-language requests, explain trade-offs and can turn a complicated requirement into an orderly shortlist.
That ability raises an uncomfortable question:
does a well-explained recommendation mean the assistant looked at the right plugins?Not necessarily. A chatbot can reason carefully about an incomplete set of candidates. The missing result does not announce itself.
The failure can happen before the explanation
Consider a user who asks for a specialist WordPress capability. A model may remember established products, encounter widely cited plugins in web results or retrieve only a subset of a directory.If a low-profile plugin is absent from those sources, it may never be evaluated.
The assistant can still give an accurate description of the familiar candidates it did find. This is the
candidate-coverage problem: a valid comparison within a shortlist is not proof thatthe shortlist covers the relevant market.
Live web search and more specific prompts can improve discovery. They do not automatically ensure that every relevant plugin in a current repository was considered.
Why the same names may keep winning
Popular plugins often have more public reviews, tutorials, comparisons and discussion. Those materials can make them easier to retrieve and easier to justify as established choices.
That creates a possible feedback loop:
Existing visibility → more accessible supporting material → easier recommendations → potential further visibility.Less-known plugins can struggle to enter the loop if their relevant functionality is not surfaced. The mechanism could reinforce a visibility imbalance even when the assistant is acting cautiously and trying to avoid risky advice.
This is a
reasoned mechanism, not a measured ranking effect across all chatbots. WP-Repo's installation statistics show the scale of the low-adoption group, not how often any particular chatbot omits it.
WordPress data exposes the size of the question
In a WP Repo analysis of
26,851 plugin records with a declared
Tested up to value in the
7.x` series,
13,251 (49.35%) were in WordPress's
fewer than 10 active installations class.
These plugins are not shown to be undiscoverable. They are not shown to be unsuitable either. They simply have almost no visible adoption history to serve as positive recommendation context.
If an assistant relies on substantial adoption or multiple reviews to feel confident about an answer, what happens to a functionally relevant plugin without those signals? The answer cannot be obtained from installation figures alone. But the question cannot responsibly be ignored either.
Documentation, reviews and code are different evidence
A README can describe intended features and constraints. Reviews may describe user experiences. Install counts indicate reported adoption. None of these, alone, is a complete independentverification of the plugin's code or fit to a particular installation.
A chatbot is not *forced* by this limitation to recommend only popular plugins. It can identify a less-known functional candidate and explain why more testing or caution is warranted.What it should not do is treat popularity as if it proves a required feature exists.
The correct distinction is between
finding a plausible functional match and
endorsing it for production use.
What would count as proof of an AI discovery failure?
A meaningful comparison would first define a plugin inventory and a set of specific, documented requirements. Researchers would identify plausible functional matches in that inventory,then compare which of those candidates an assistant retrieved and recommended under repeatable conditions. The test would have to distinguish
not found from
found but rejected for a stated reason.
Only then could we estimate how often recommendation systems omit relevant plugins, and whether installation history or review volume helps explain the omissions.The installation distribution above is a starting point for that test,
not its result.
The question an AI recommendation should answer
Before recommending a plugin, the system should be able to say something meaningful about its candidate coverage:
- Did it search an identifiable plugin inventory or mainly recall familiar names?
- Could a lesser-known plugin with the same functionality enter the comparison?
- Are install counts and reviews being used as adoption context or as substitutes for functional evidence?
- Which claims come from plugin documentation, and which remain unverified?
The point is not that every AI recommendation is wrong. The point is that
a convincing recommendation can be incomplete without giving the user any sign of what is missing.WP Repo is being developed to approach plugin discovery from a defined, function-oriented candidate base. Its interactive service is not yet live,and these pages do not claim superiority established by a comparative chatbot benchmark.