Category: Uncategorized

The two most-installed full-site accessibility plugins in the WordPress directory are Web Accessibility by Elementor, formerly Ally, at 500,000 active installs, and Accessibility by UserWay, at 80,000.

The most-installed comparable plugin added in 2026 is Widewalk, at 100 active installs. That is not enough history to call it a replacement for either leader. It is enough to ask whether a plugin designed in 2026 does anything the established choices do not.

The short answer is yes, but mostly in how it is built. Widewalk brings a local-only, roughly 7 KB visitor toolbar to WordPress and to front ends WordPress does not render. It does not bring Ally’s scanner, guided remediation, or decade of install history. UserWay takes a third route: a hosted accessibility service placed on the site by a WordPress plugin.

The three plugins, before choosing one

Plugin	Active installs	Added	Last updated	Directory rating
Web Accessibility by Elementor	500,000	2015	24 August 2026	2.9/5 from 162 ratings
Accessibility by UserWay	80,000	2017	8 December 2025	4.0/5 from 57 ratings
Widewalk	100	1 September 2026	11 September 2026	No ratings yet

Those columns measure adoption, recency, and public feedback. They do not measure accessibility. Ally has more than six times UserWay’s installs, but its public reviews are much more mixed. Widewalk is newer than both and has no review sample at all. None of those facts can tell you how well a particular site works with a keyboard or screen reader.

What “top” means here: the plugins were ordered by the directory’s active-install field. The Accessibility category was cross-checked against the full live table by names and accessibility tags. Narrow tools—a carousel, an alt-text generator, or a dark-mode switch—were left out because they do not replace a site-wide accessibility plugin.

Ally is the only one of the three built around finding and fixing issues

Elementor’s Web Accessibility plugin combines three products: an Accessibility Assistant, a visitor-facing usability widget, and an accessibility-statement generator.

The Assistant is the important difference. Its directory listing says it scans individual URLs for more than 180 WCAG 2.1 AA violations, groups findings by type and severity, and guides the site owner through fixes. The examples include missing alternative text, form labels, ARIA landmarks, keyboard compatibility, table structure, and page navigation. Some changes can be made manually; AI suggestions use paid-plan credits.

The visitor widget covers the familiar controls: larger text, contrast modes, readable fonts, paused animation, hidden images, line height, text alignment, highlighted links, a reading guide, and skip links. The statement generator creates a page and can link it from the widget.

The compromise is that the more ambitious part is a service, not only a local plugin. The listing says an Elementor account is required for identification and purchased services, and AI fixes are paid. Its free and paid boundaries matter if the scanner is the reason you install it. The plugin also states plainly that no automated tool can guarantee accessibility and that human testing is still required.

Take Ally if you want one dashboard that can find problems, guide repairs, add a visitor toolbar, and publish a statement. Accept that the account connection and paid AI layer are part of that workflow, and check the mixed reviews against your own theme before rolling it out widely.

UserWay is the established hosted-widget choice

UserWay’s WordPress plugin is the connector for its accessibility widget. Its listing says the service makes smart modifications to elements that may block keyboard navigation or conflict with WCAG, ADA, Section 508, ATAG, and EN 301 549 requirements. After installation, the site owner receives widget login instructions by email.

That makes it the simplest of the three to describe: install a mature hosted widget rather than operate a WordPress-native scanning and remediation dashboard. It also has the broadest declared WordPress compatibility. The directory listing requires WordPress 4.7, while Ally requires 6.7 and Widewalk requires 6.2.

The trade-off is visibility. The current directory copy says much less about exactly which controls or fixes are local, which depend on the service, and how a site owner reviews changes. It names no PHP minimum, was last updated in December 2025, and says it was tested through WordPress 6.9.9. Those fields are author-supplied, so they are prompts to test—not proof that the plugin fails on a newer release.

Take UserWay if you want an established hosted-widget service, especially on a site too old for Ally or Widewalk’s declared minimum. Accept that the plugin is an entry point to an external account and service, and that its directory listing exposes less of the remediation process than Ally’s.

What did the 2026 newcomer actually add?

Widewalk does not beat the leaders by adding a thirteenth contrast switch. Its twelve controls overlap heavily with the widgets already here: text size, spacing, contrast, saturation, link highlighting, a dyslexia-friendly typeface, cursor size, animation pausing, image hiding, alignment, and tooltips.

Its new contribution in this comparison is a different set of constraints:

• No service connection. The listing says the front end makes no outbound requests, creates no account, loads no external font, sets no cookie, and keeps preferences in the visitor’s local storage.
• A documented route past WordPress. A React, static, or plain-PHP front end can load the same configured panel with one script tag even when WordPress is used only for administration.
• A hook for scripted motion. Version 1.0.6 added a page marker and a widewalk:motion event. A theme can use them to stop a JavaScript carousel when a visitor asks for less motion; CSS animation, video, audio, and moving SVG are handled by the panel itself.
• Theme isolation. The panel runs inside a shadow root so a theme’s button rules do not restyle it and its own CSS does not leak onto the site.
• A statement tied to the site’s choices. The generator records the target standard, scope, assessment method, last review, exclusions, and known shortcomings. The latest release keeps the known-shortcomings list live on the published page.

The headless embed and scripted-motion event are features the other two listings do not document. That does not prove nobody else in the plugin directory has built them. It means the 2026 newcomer brings them to this three-plugin comparison.

There are important omissions. Widewalk deliberately does not scan pages, rewrite markup, recommend fixes, or claim compliance. Its statement generator is not wholly new—Ally has one too—and its basic visitor controls are not new at all. Most importantly, 100 installs and no ratings cannot supply the compatibility evidence that 500,000 installs can.

Take Widewalk if your priority is a lightweight visitor panel with no account or outbound service, or if WordPress does not render your public front end. Accept that you are choosing a new plugin with almost no public track record and no audit or guided-fix workflow.

Feature comparison

Need	Ally	UserWay	Widewalk
Visitor controls	Yes	Yes, through its widget service	Yes, 12 configurable controls
Page scanning	Yes, 180+ claimed checks	Service claims smart modifications; listing gives little audit detail	No
Guided source fixes	Yes, manual guidance and paid AI suggestions	Not described in the directory listing	No
Accessibility statement	Yes	Not described in the directory listing	Yes, including known shortcomings
Account or external service	Elementor account for Assistant and services	UserWay login and hosted service	None claimed
Non-WordPress front end	Not documented	Not documented by this plugin listing	One-script embed
Public adoption evidence	500,000 installs	80,000 installs	100 installs, no ratings

Choose by the compromise you can accept

• You need help finding and repairing WCAG issues: start with Ally. You give up a wholly local setup and may need a paid plan for the AI-assisted path, but neither of the other two documents a comparable scanner and guided-fix loop.
• You need an established hosted widget on an older WordPress install: UserWay has the lowest declared WordPress minimum and 80,000 installs. You give up some transparency in the directory listing and depend on an external account and service.
• You need privacy, a small payload, or a headless/static front end: Widewalk is the clearest fit. You give up scanning, remediation guidance, and nearly all adoption evidence.
• You need evidence that the site itself conforms: none of the three is enough. Use automated checks as one input, then test headings, forms, focus order, keyboard operation, screen-reader output, zoom, errors, and content with people. A toolbar can help a visitor without repairing the page beneath it.

Do not run two visitor toolbars together. Their controls can compete over the same colors, type sizes, focus, and motion. If Ally’s scanner is useful but another toolbar is the better visitor interface, test whether the widget can be disabled before combining anything.

The useful answer is not one winner

Ally is the broadest WordPress-native workflow in this group: scan, fix, offer visitor controls, and publish a statement. UserWay is the established service-led option and declares support for much older WordPress versions. Widewalk is the small 2026 alternative for a site that values local operation, front-end independence, and a deliberately limited promise.

The newcomer did add something, but not a new definition of accessibility. It made the toolbar smaller, more private, easier to carry outside a WordPress-rendered theme, and easier for a developer to connect to scripted motion. Whether those are the right advances depends on what you are willing to lose: Ally’s audit workflow, UserWay’s adoption history, or Widewalk’s simplicity.

Data note: Plugin metadata comes from WP Analyzer’s copy of the public WordPress.org directory, read on 9 October 2026. Feature descriptions are claims in each plugin’s current directory listing and changelog; the plugins were not benchmarked on the same test site. Install figures are rounded by WordPress.org. Ratings, “tested up to,” minimum versions, update dates, and feature claims can change after publication. The AI category covers part of the directory, so the result was cross-checked against the full live table and limited to comparable full-site accessibility products.

The WordPress directory has closed about 50,700 plugins. The live directory, the one you can still install from, is about 74,000. Closed is a different set: the slug is still known, and the directory refuses to serve the plugin.

A closed listing is easy to hear as a security event. The reason field says something broader. About one in three closures is a guideline violation. About one in five is labelled unused. About one in six is the author asking for the plugin to be taken down. Security issues are about one in eight.

What the directory wrote down

Every closed row in this record carries the reason the API returned the last time the slug was asked. Six labels cover almost all of them.

Reason	Plugins	Share of closures
Guideline violation	About 16,000	About 1 in 3
Unused	About 10,500	About 1 in 5
Author request	About 8,800	About 1 in 6
Unknown	About 6,600	About 1 in 8
Security issue	About 6,400	About 1 in 8
Licensing or trademark	About 2,300	About 1 in 20

What this means: most plugins that leave do so because the listing broke a rule, because nobody was shipping it, or because the author took it down. A security closure is a large group. It is not the typical one.

2018 was a cleanup, not a breach

The year on the closed date is uneven. 2018 accounts for about 14,300 closures, more than any other year in the record. About 9,800 of those are labelled unused. Security closures that year were about 100.

No later year repeats that shape. Closures since 2019 run between roughly 2,000 and 5,000 a year, and the mix shifts toward guidelines, author requests, and security. 2026, still unfinished, already has about 2,200 closures.

What this means: a spike in the closed count is not, by itself, a spike in vulnerabilities. In this record the largest spike is a pile of plugins marked unused.

Security closures are newer than the rest

The security rows have their own history. Before 2021 the directory closed fewer than 200 plugins a year for a security issue. After that the count steps up, and 2024 is the heaviest year in the record.

Year	Closed for a security issue
2020	About 100
2021	About 600
2022	About 800
2023	About 500
2024	About 2,000
2025	About 1,700
2026, to 4 October	About 600

2026 is a partial year, so it cannot be lined up against 2024 yet. The level since 2021 is still far above the years before it.

What this means: security closure is a practice the directory now does in volume. It is also recent. Reading the whole history of closed plugins as a history of exploits will over-count the early years and under-count the last five.

Closed is not the same as quiet

A separate count looks at plugins that are still live and have not shipped a release in two years. Those you can still install. A closed plugin you cannot. The status split on the statistics page is the place those two facts sit next to each other: live, closed, and the thinner “not found” set, where the API has nothing at all for a slug that was once in the index.

What to do with a closed plugin

• Read the reason before you read the year. Unused, author request, and a guideline violation ask for different next steps.
• Treat a security closure as a reason to find out what replaced it. That is the group where the code itself was the problem.
• Do not treat a quiet live plugin as closed. Installable and maintained are different, and this record keeps them in different counts.
• A trademark or licensing closure is about the listing. It is a small share of the total, and it is not a statement about whether the last release had a vulnerability.

The main conclusion

About 50,700 plugins have left the directory. About a third were closed over guidelines, about a fifth for going unused, and about a sixth because the author asked. Security is a real and growing share. Across the whole record it is about one closure in eight.

Data note: Figures come from this site’s copy of the public WordPress plugin directory, read on 4 October 2026. Reasons are the labels the plugin API returns, rounded here so a later refresh of a few dozen rows does not change the sentence. The statistics page is the same record on a slower refresh, so its closed total can sit a little behind this piece.

About 43,000 live plugins have never been rated. That is more than half the directory. About 8,800 have been rated exactly once, and that one rating is five stars. Almost all of those sit on plugins with under 1,000 installs.

The stars start to mean something only after more people have written. About 6,300 plugins have ten ratings or more. Among them, the average is about 4.5 out of five, and it barely moves as plugins get larger. A plugin on a million sites and a plugin on a thousand sites score the same.

One review is a coin flip that landed on five

A single five-star review is the most common “rated” plugin in the directory. About 8,600 of those 8,800 plugins have fewer than 1,000 active installs. At that size, one visitor who liked the plugin is the entire public record.

The ratings section already refuses to chart this. It draws the star bands only for plugins with ten ratings or more, because below that a single review moves a plugin by whole stars. The highest-rated board goes further and requires 500 ratings. Without a floor the board is a list of plugins with one friendly click.

What this means: a five-star badge with a count of one is a sample size, displayed as a verdict.

Ten ratings still do not separate anyone

Raise the floor to ten ratings and the distribution collapses into the top of the scale. Of those 6,300 plugins, about 4,100 average 4.5 or higher and about 1,300 sit between 4 and 4.5. About 170 average under 3 stars. Only 13 plugins with 100 ratings or more average under 3.

Split the same plugins by how widely they are installed and the average does not budge.

Active installs	Plugins with 10 or more ratings	Average stars
1 million or more	67	4.53
100,000 to 1 million	383	4.48
10,000 to 100,000	About 1,500	4.50
1,000 to 10,000	About 2,700	4.49
Under 1,000	About 1,800	4.39

The plugins people actually use are not rated higher than the small ones that managed to collect ten reviews. They are rated the same, because almost everything that collects reviews lands between 4 and 5.

What this means: the star average is a filter for “has a crowd of people been angry enough to write it down?” Once the count is real, the answer is almost always no. The number stops ranking plugins and starts confirming that they were not hated in public.

An unrated plugin is not a bad one

Taken across every live plugin, the average rating falls under two stars. That figure is in the statistics page for a reason: an unrated plugin is stored as zero. About 43,000 zeros will swamp any average. It is a statistic about missing reviews, and it is the easiest wrong reading of this data.

The same trap runs the other way. A small plugin with one five-star review is not a better plugin than a large one with a 4.6 from several hundred people. The large one has been complained at, and survived it. The small one has been visited by one generous person.

What to read instead of the stars

• Ignore the average until there are at least ten ratings. Under that, you are reading one or two people.
• Treat 4.5 and 4.8 as the same number. That is where almost every reviewed plugin lives, at every size.
• Use a floor when you rank. The highest-rated board on this site requires 500 ratings for this reason.
• Pair the stars with a maintenance date. A plugin can sit at 4.7 and still have gone quiet. The maintenance section is the other half of the decision.

The main conclusion

Most plugins have no rating. The most common rating that does exist is a single five stars, left on a plugin almost nobody runs. Among plugins with enough reviews to count, the average is about 4.5 everywhere you look, from a thousand installs to a million. The stars tell you that people are reluctant to mark a plugin down. They do not tell you which plugin to install.

Data note: Figures come from this site’s copy of the public plugin directory, read on 4 October 2026, and are rounded. The ratings section is the same record. Its headline totals refresh on a slower clock, so the unrated count there can differ by a few hundred.

62,851 live plugins name exactly one person in the contributor list. That is about 85% of the directory. One plugin names nobody. Together they account for about 130 million of the roughly 325 million active installs the directory reports — about 40%.

This is a different cut from how many plugins a publisher already has. That piece looked at new plugins in a single year, and at the size of the account behind them. This one looks at the names on the plugin page itself, across every plugin the directory still serves.

Two names change the odds

Plugins that list two or more people are about 15% of the directory and hold about 60% of the installs. The chance of reaching 10,000 installs rises with the length of the list.

People credited	Plugins	Share of installs	Reach 10,000 installs
One	About 63,000	About 40%	About 1 in 50
Two or three	About 9,500	About 31%	About 1 in 15
Four to ten	About 1,600	About 22%	About 1 in 5
Eleven or more	75	About 7%	About 1 in 2

A plugin with four to ten credited people is about ten times as likely to pass 10,000 installs as a plugin with one name on it. The 75 plugins with eleven or more people average about 290,000 installs each. The biggest-teams board is the top of that last row. Jetpack sits at the far end of it, with 130 credited contributors.

What this means: the directory is a solo activity. The install base is not. Most of the sites running a plugin from this directory are running one that names more than one person.

A name on the page is not a headcount

The contributor list is whoever has a WordPress.org profile on that plugin. It is not a count of employees, and it is not a count of who wrote the code.

A company can ship a plugin under a single account. A long list can be a firm that already had customers, with the engineers, the support staff, and the release managers all credited. The same caveat as the publisher piece applies here: the thing that shows up in the data is an organisation with somewhere to send the plugin, and the contributor count is one of the ways that organisation becomes visible.

Adding three names to a readme does not move a plugin from “1 in 50” to “1 in 5”. The plugins in the longer rows were already the ones with a team behind the release. The list records that. It does not cause it.

What this means: use the length of the credit list as a hint that more than one person is keeping the plugin alive. Do not use it as a quality score, and do not treat a single name as proof of a one-person company. The field cannot see the people who were never added to it.

What to do with this if you are the only name

• Read the odds as a base rate, not a forecast. About 1,200 one-person plugins have still reached 10,000 installs. The rate is about 1 in 50, which is uncommon and not impossible.
• A second credited person is already a different row. Plugins with two or three names reach 10,000 installs about 1 time in 15.
• Look at the other signal of an organisation. The publisher piece, on how many other plugins the account already has, is the matching count for new launches.
• Judge the plugin on its own page. A long credit list can sit on a plugin you still should not install, and a single name can sit on one you should.

The main conclusion

About 85% of live plugins credit one person. Those plugins hold about 40% of reported installs. The other 15% — the plugins with two or more names — hold about 60%. The longer the list, the more often the plugin has passed 10,000 installs, from about 1 in 50 with one name to about 1 in 2 once eleven people are credited.

The list is a trace of who showed up to be named. It is the closest thing the directory publishes to “was there a team,” and the installs follow it.

Data note: Figures come from this site’s copy of the public plugin directory, read on 4 October 2026. One plugin with a contributor count of zero is folded into the “one person” prose and left out of the “exactly one” count of 62,851. Install totals add the directory’s rounded active-install figures, so they are approximate. The rankings page lists the plugins at the top of the contributor count.

Tested up to is a string the plugin author typed. WordPress does not run a compatibility test and fill it in. On 4 October 2026 the current line in this record is WordPress 7.1: Yoast SEO, Elementor, Contact Form 7, WooCommerce and LiteSpeed Cache all say 7.1.2.

About 24,000 live plugins, roughly one in three, name some WordPress 7 release. About 20,000 still say WordPress 6. About 29,000 say WordPress 5 or older. About 1,200 leave the field blank.

The long tail is where the old versions sit

Restrict the count to plugins with 10,000 active installs or more — about 2,200 plugins — and the picture tightens. About three in four of them say WordPress 7. About 90 say WordPress 5 or older.

Tested up to	All live plugins	10,000 installs or more
WordPress 7	About 24,000	About 1,600
WordPress 6	About 20,000	About 470
WordPress 5	About 8,700	About 50
WordPress 4 or older	About 20,000	About 40
Blank	About 1,200	3

A plugin under 1,000 installs is where a Tested up to of WordPress 4 still lives in volume. A plugin that has already reached 10,000 installs has usually had the line moved, because someone is still shipping it.

What this means: an old Tested up to value is mostly a property of the long tail. On a plugin people actually run, the field is usually current. When it is not, that is the exception worth reading twice. Pair it with the last release date: a plugin that says WordPress 6 and shipped last month is in a different position from one that says WordPress 4 and shipped in 2019.

The PHP line is blank on two plugins in five

Requires PHP is a minimum, not a target. A plugin that says 7.4 is claiming it runs on 7.4 and, by implication, that the author has not promised anything about older releases. It is not a statement that the plugin fails on PHP 8.

About 31,000 live plugins leave the field empty. That is about two in five. About 20,000 name PHP 7.4, about 9,500 name something from 7.0 to 7.3, about 8,000 still name PHP 5, and about 5,400 name PHP 8. Fewer than one live plugin in ten has a PHP 8 minimum written down.

Requires PHP	Live plugins
Blank	About 31,000
7.4	About 20,000
7.0 to 7.3	About 9,500
5.x	About 8,000
8.x	About 5,400

The large plugins are only partly cleaner. Among plugins with 100,000 installs or more — about 470 of them — about 210 say PHP 7.4, about 95 still say PHP 5, about 70 leave it blank, and 19 say PHP 8.

Classic Editor reports 8 million installs and a PHP minimum of 5.2.4. All-in-One WP Migration reports 5 million and a minimum of 5.3. Both lines are floors the readme still states. They are evidence the header has not been moved, not evidence that those sites are running PHP 5.

What this means: you cannot look up a PHP requirement for about 31,000 plugins, because the author never wrote one. Where a huge plugin still says PHP 5, read it as a stale minimum. The useful question is the Tested up to line and the date of the last release, which tell you whether anyone is still standing behind the current WordPress.

What to check before you install

• Read Tested up to against the WordPress version you run. A 7.x value matches the current major line in this record. A 6.x value can be a plugin that has not yet bumped the header after a release.
• Weigh an old value harder on a small plugin. Under 1,000 installs, WordPress 4 and 5 are common. At 10,000 installs they are rare, so an old value there is more informative.
• A blank PHP line tells you nothing. About two in five plugins have one. Do not treat the blank as “works everywhere.”
• An old PHP minimum on a popular plugin is usually a readme that stood still. Confirm with the changelog, not with the header alone.

The main conclusion

About one live plugin in three says it was tested on WordPress 7. Among plugins with 10,000 installs, about three in four do. The plugins that still name WordPress 4 or 5 are concentrated in the long tail.

The PHP requirement is a weaker field. It is blank on about two plugins in five, and a large share of the plugins people actually run still advertise a PHP 5 minimum that belongs to an older readme. Tested up to, read next to the last release date, is the compatibility signal the directory actually keeps current.

Data note: Figures come from this site’s copy of the public plugin directory, read on 4 October 2026, and are rounded. Tested up to and Requires PHP are author-supplied strings. Install counts are the directory’s own rounded bands. A plugin page on this site shows the raw string for that plugin.

More than 16,000 plugins were added to the WordPress directory in the last twelve months. About three out of four came from a publisher with three or fewer plugins to their name.

Fewer than 100 of those plugins reached 1,000 active installs. Around 40 of the ones that did came from those same small publishers.

At first glance that looks fair. Small publishers made most of the launches and took a good share of the wins. But the share of launches and the share of wins are not the same thing, and once you compare them the picture changes.

An established publisher was about four times more likely to succeed

Small publishers made roughly three quarters of the launches but won under half the breakouts. Publishers with four or more plugins did the opposite.

Publisher	New plugins	Reached 1,000 installs	Chance of reaching 1,000
Three or fewer plugins	About 12,000	Around 40	About 1 in 300
Four or more plugins	About 4,000	Around 55	About 1 in 70

So a first or second plugin had roughly a quarter of the chance of a plugin from a publisher who already had a shelf of them.

What this means: the directory treats every plugin the same way, but users do not. A publisher who already has plugins has somewhere to announce the next one.

It is not because one group launched later

A new plugin needs time to gather installs, so a gap like this could simply mean one group launched more recently. That is not what happened here. Both groups averaged about four months old. And when the plugins are split by age, the gap stays — and grows for the older ones.

Plugin age	Three or fewer plugins	Four or more plugins
Six to twelve months old	About 0.8% reached 1,000	About 3% reached 1,000
Under six months old	About 0.1% reached 1,000	About 0.8% reached 1,000

What this means: more time does help a plugin grow, but it does not close the gap. Waiting is not the missing ingredient.

The installs are far more concentrated than the wins

Counting breakouts makes the two groups look close. Counting actual users does not. Plugins from established publishers hold roughly nine tenths of all the installs won in the last year.

They also climbed higher. More than a third of their breakouts went on to pass 10,000 installs. Among small publishers, only about one in eight did.

There is a second difference worth noticing. The small publishers won around 40 breakouts between roughly 40 different accounts — almost exactly one each. The established publishers won around 55 breakouts between about 30 accounts, so several of them won more than once. The most active single publisher passed 1,000 installs with eight separate plugins in twelve months.

What this means: for a small publisher, reaching 1,000 installs was usually a one-off event. For an established one it was closer to a repeatable process.

“Small publisher” does not mean “small company”

This is the part that matters most, and it is easy to miss. A publisher with one plugin is not always a solo developer working alone.

Look through the small publishers that reached 1,000 installs this year and you find a hosting company, a payment gateway, a card network, a legal-text service, a shipping platform, a national delivery firm and a famous web archive. Each one published its first WordPress plugin. Each one already had customers who wanted it.

Only about a third of these winners even had their own product website listed. The rest were mostly genuine independents — and they are the smaller part of an already small group.

What this means: the thing that carries a plugin past 1,000 installs is an existing audience. A big plugin portfolio is one way to have one. An existing customer base is another. Starting with neither is the hardest version of the problem, and it is also the most common.

What to do with this if you are planning a plugin

None of this says a first plugin cannot work. Around 40 of them did this year. But they did it with something behind them, so it is worth being honest about what you have before you start.

• Name your audience first. Not “WordPress users” — the actual group you can already reach. A client list, a mailing list, a forum you post in, an existing product’s customers.
• If you have no audience, build the audience first. That might mean one useful free tool, or writing about the problem for a few months before the plugin exists.
• Treat your first plugin as the start of a portfolio. The repeat winners are repeat winners partly because each plugin gives the next one a place to be announced.
• Solve a problem someone already pays to solve. The companies in this data launched into demand they could already see in their support queue.

The main conclusion

Most new plugins come from publishers with almost no track record. Almost none of the installs do.

The gap is not about code quality, and it is not about waiting longer. It is about who can tell people the plugin exists on the day it ships. That is the part worth planning before the first line of code.

Data note: Figures come from this site’s copy of the public WordPress plugin directory, read on 1 October 2026, covering plugins added in the twelve months to that date. A publisher is identified by their WordPress.org account, so a company using several accounts is counted as several publishers, and plugins that have since been closed are not counted. WordPress publishes install counts in broad bands, so these are approximate by nature. Rounded figures are used throughout to keep the focus on the pattern. See the methodology page for details.

More than 14,000 WordPress plugins were added to the directory between January and late September 2026. That is more than the totals for 2024 and 2025 combined.

Only about 60 of those plugins reached 1,000 active installs. In other words, fewer than one in 200 reached that level.

The main lesson is simple: building a plugin has become easier, but finding a real need and reaching users has not. This article looks at what helped the stronger launches, which trends became crowded, and where the data may point to better opportunities.

Plugin creation grew much faster than plugin adoption

For many years, the directory added roughly 3,000 to 4,000 plugins annually. The pace rose sharply in 2025, then increased again during the first nine months of 2026.

Period	New plugins	Share with AI terms in the name
Typical year from 2021 to 2024	About 2,000–4,000	Usually below 5%
2025	About 6,000	About 8%
Jan–Sep 2026	14,000+	About 11%

About four in five plugins from the 2026 group still reported fewer than ten active installs. The same pattern appeared whether or not a plugin used AI in its name.

What this means: easier development creates more supply, not more demand. A finished plugin is only the start. It still needs a clear audience, a useful difference and a way to reach users.

AI improved the odds, but most AI plugins stayed small

Plugins with AI-related terms in their names performed better as a group. They were nearly four times as likely to reach 1,000 installs. But the chance was still low.

2026 group	Number of plugins	Reached 100 installs	Reached 1,000 installs	Below 10 installs
AI term in the name	About 1,500	About 5%	About 1.3%	About 79%
All other plugins	Nearly 13,000	About 2.6%	About 0.3%	About 80%

AI clearly helped some plugins get attention. It did not remove the basic launch problem: almost four out of five plugins in both groups remained below ten installs.

What this means: a popular keyword may improve discovery, but it is not a product strategy. The plugin still needs to solve a specific problem better than the available alternatives.

Most breakout installs came from AI, but distribution mattered

Roughly one quarter of the plugins that passed 1,000 installs were in AI & Automation. Together, they accounted for about two thirds of the installs among the breakout group.

Several genuinely new plugin types appeared:

• MCP servers: six breakout plugins let AI assistants connect to and work with WordPress.
• AI provider libraries: three plugins connected WordPress to major model providers such as OpenAI, Anthropic and Google.
• AI site builders: three products helped users create or manage sites with AI. AI Agent by SiteGround reached the one-million install band.
• Visibility in AI search: two plugins focused on helping sites appear in answers from AI assistants rather than only in traditional search results.

MCP was one of the clearest new areas. By the time of this analysis, the directory contained around 175 MCP plugins, and roughly three quarters had arrived during 2026.

However, the largest launches did not come from unknown teams. SiteGround and Cloudways already served large customer bases. The WordPress AI team released the provider plugins. Brainstorm Force already had established WordPress products and users.

What this means: being in a growing market helps, but access to users can matter just as much as the product. Before building, decide how people will discover the plugin. “Publish it in the directory” is rarely enough.

Two trends show how quickly a gap can fill

The llms.txt rush

llms.txt is a file that describes a site for language models. It is useful, easy to understand and relatively simple to add to WordPress. That made it an obvious plugin idea.

More than 80 plugins used llms.txt in their name, and about 60 of them arrived in 2026. Only three passed 1,000 installs. The leading plugin, Website LLMs.txt, launched about a year before most of the new entries and reached the 40,000 install band.

The lesson: a real need can still become crowded very quickly. Timing, trust and early distribution may matter more than small differences in implementation.

The EU withdrawal-button rush

New European rules created demand for order-withdrawal buttons in online stores. Around 65 plugins addressed this need, and about 60 appeared during 2026. Only five passed 1,000 installs.

The strongest newcomer reached about 5,000 installs. Meanwhile, Germanized for WooCommerce, an established compliance plugin with around 70,000 installs, added the requirement as another feature.

The lesson: a new rule can create demand, but it does not always create a separate product category. Existing products may serve the same need faster by adding one feature.

Before following a visible trend, ask three questions: How many competitors are already building it? Does the idea need a separate plugin? Do established products already have the users and the ability to add the same feature?

Where the data suggests more room

The classification data covers every plugin above 10,000 installs—more than 2,000 established products. This makes it possible to compare large fields and look for a useful combination: proven demand, unhappy users and few recent winners.

Sub-category	Established plugins	Average installs	Average rating	New winners since 2024
Advertising & Ad Management	10+	About 180,000	About 3.5	None
Payment Gateways & Processing *	20+	About 60,000	About 3.9	None
Email Marketing & Newsletters	About 30	About 140,000	About 4.1	None
Polls & Surveys	Fewer than 10	About 85,000	About 4.2	None
Link Monitoring & Optimization	About 10	About 375,000	About 4.3	None
Comment & Discussion Management	Fewer than 10	About 165,000	About 4.4	None

Advertising and ad management stands out. It has several established plugins, strong average adoption, the lowest rating in this comparison and no recent plugin above 10,000 installs.

That is a useful signal, not proof of an easy opportunity. Low ratings may show that users are unhappy, but the lack of new winners may also point to technical complexity, support costs or strong incumbents. Reviews and support forums should be the next place to investigate.

Payment gateways show why the extra check matters. The market is large, but payment companies often publish the winning plugins themselves. An independent developer may have limited access to the partnerships, testing and trust needed to compete.

What this means: look for demand and dissatisfaction, but also check whether the market is open to an independent product. A weak rating is a lead for research, not a complete business case.

Attention and market depth are not the same

Some established categories support far more installs per successful plugin than the areas receiving the most attention.

Category	Average installs per established plugin
SEO	About 270,000
Multilingual & Translation	About 230,000
Performance	About 210,000
Security	About 200,000
Design & Customization	About 90,000
AI & Automation	About 70,000

AI & Automation had the lowest average in this comparison, despite receiving the most attention from new developers. Multilingual and translation had much stronger adoption per established plugin but attracted very few new breakout products.

What this means: do not use the number of new launches as a measure of market quality. A busy category may simply be easy to enter. A quieter category may have deeper demand—but it may also require more expertise, so research the barriers before choosing it.

A practical way to choose a plugin idea

Use the directory as the start of the research, then move from numbers to real user problems.

1. Find a repeated complaint. Read low reviews, support forums and community discussions. Look for a problem users describe in their own words.
2. Confirm that people already spend time or money on it. Several established plugins with meaningful installs are stronger evidence than search interest alone.
3. Check whether users are dissatisfied. Low ratings and unresolved support threads can show where existing products fall short.
4. Check whether the market is open. Avoid fields where a platform owner, payment company or hosting provider controls distribution or access.
5. Plan distribution before development. Know which community, integration partner, customer list or search query can bring the first users.
6. Start with one narrow result. Solve the clearest part of the problem, test whether users care, and expand only after adoption.

The main conclusion

Fewer than 0.5% of the plugins added in the first nine months of 2026 reached 1,000 installs. That does not mean developers should stop building plugins. It means they should spend more time choosing the problem and planning the launch.

The strongest opportunity is not always the newest trend. It is often a specific, repeated problem in a market that already has users, where current products are weak and an independent developer can still reach the audience.

Start with the complaint, not the headline. Build the smallest useful solution. Decide how it will reach users before writing the full product.

Data note: Figures come from this site’s copy of the public WordPress plugin directory, read on 1 October 2026. “Added in 2026” covers 1 January through 23 September, the newest record available for this analysis. Approximate figures are used to keep the focus on durable patterns. WordPress itself publishes install counts in broad buckets, so they are not exact measurements. See the methodology page for details.

The WordPress plugin directory has no categories. It has tags — a handful of free-text labels per plugin, typed by whoever wrote it — and there are 64,231 distinct ones in use across the live directory.

Why that is not a classification

Nothing connects “ecommerce” to “woocommerce”, or stops “post”, “posts” and “gutenberg” from all describing the same plugin. There is no hierarchy, no definitions, and no review. It works well enough as search keywords and fails completely as a way of counting anything.

Try to answer “what share of the directory is about security” from a tag cloud and you will find you cannot. The labels overlap, compete and repeat, and the ones that matter most are the ones nobody bothered to type.

So we asked a model to build one

There was no starting list. The first plugin through the classifier had an empty taxonomy and proposed the first category; every plugin since has either matched something that already existed or added to it. That has produced 14 categories and 51 sub-categories so far.

The interesting part was not getting an answer. A language model will always give you an answer. The interesting part was whether it gives you the same answer twice.

The first design was not consistent

It was not close. Re-running a plugin through the same model, with the same prompt, changed its top-level category two times in three. And it invented a brand-new category for roughly 40% of plugins, which means the taxonomy never stopped growing — and a taxonomy that never stops growing is just a tag cloud with extra steps.

The fix was structural rather than clever. The original design had the model look up candidate categories with a tool call and then place the plugin in a second call, so it was always choosing from a shortlist it had fetched a moment earlier. The prompt now carries the entire taxonomy, both levels, in the single call that does the placing. The model sees everything that exists before it decides whether anything fits.

After: 40 out of 40

• Top-level agreement on re-run went from about 1 in 3 to 40 out of 40, with a single sub-category flip.
• The new-category rate fell from a flat 40% to 15%.
• Cost per plugin halved, from two calls to one — a side effect, not the goal.

A similarity gate sits in front of every proposed category and folds a near-duplicate onto the existing row. It deliberately compares across category boundaries, so a sub-category proposed under the wrong parent gets matched to the right one instead of duplicating under the wrong one.

What we still cannot tell you

Consistency is not correctness. We measured whether the model agrees with itself; we did not measure whether it is right, and we cannot, because there is no ground-truth categorisation of the WordPress plugin directory to measure against. If there were, we would not have needed to build one.

Every placement is published so it can be judged. That is the only honest form of quality control available here.

The other caveat is coverage. Classification costs a model call per plugin, so it advances in batches — 114 plugins have been through it so far out of 73,049. The shape of the taxonomy is meaningful; the plugin counts inside it are counts of that sample, and the categories page states the coverage figure at the top rather than at the bottom.

Full method, including the prompt change and the three data-integrity bugs that cost real debugging time, is on the method page.

Of the 73,049 plugins the WordPress directory still serves, 35,652 have not published a release in over two years. That is 49% — and every one of them is still one click away in your admin.

The numbers

• 26,169 shipped a release in the last six months — 36%
• 31,493 shipped one in the last year — 43%
• 35,652 have been silent for two years or more — 49%

The gap between those first two lines is worth sitting with: only about one plugin in fourteen shipped code in the six months after its previous release but inside the year. Plugins do not gently slow down. They are either being worked on or they have stopped.

Installability is not maintenance

Nothing about being in the directory implies anyone is still there. A plugin is removed when it is reported and closed, not when its author loses interest — so abandonment is invisible until you go looking for it. The directory does publish the last-updated date on every plugin page. It is the most useful field it has and the one people scroll past.

This matters more than the usual “is it compatible” worry. An unmaintained plugin does not stop working on the day WordPress updates; it stops getting security fixes years before you notice anything at all.

What to check instead of the install count

Three fields, all of them on the plugin’s own page, all of them on ours:

• Last release date. Inside a year is fine. Past two years, assume nobody is home.
• Number of ratings, not the rating. 42,257 live plugins have never been rated at all. A 5.0 from one review is not a 5.0.
• Support threads resolved. The directory reports a recent window. Threads open and unanswered is the clearest signal there is.

The plugins that do well on all three tend to be the ones you have heard of — TablePress and Wordfence both carry thousands of ratings and ship constantly — but the test is cheap enough to run on anything, and it is the one that separates a plugin kept alive deliberately from one simply left up.

A note on what this is not

None of this says the long tail should be deleted. A plugin that does one small thing correctly and has needed no changes since 2019 is not abandoned in any sense that matters — the field records silence, and silence has more than one cause. What the 49% figure argues for is looking, not panicking.

The maintenance breakdown sits on the statistics page, and the limits section of the method page is honest about what a last-updated date can and cannot tell you. Figures read September 2026.

The WordPress plugin directory is usually described with one number, and it is normally wrong. We keep our own copy of it — every slug it has ever published, with the full public record for each one — so here is what the count actually breaks down into.

There are three different totals

The directory index has published 126,319 plugin slugs. Ask the API about each of them today and only 73,049 still answer: the other 53,270 have been closed by their author or by the plugin team, or have gone entirely.

Which number you quote depends on what you are claiming. “The directory has over 126,000 plugins” is true of its history. “You can install 73,049 plugins” is true of today. They are forty percent apart, and almost nobody says which one they mean.

Almost nothing in it is widely used

Across the live directory, active installs fall like this:

• 68 plugins on a million sites or more — 0.1%
• 398 between 100,000 and a million — 0.5%
• 1,722 between 10,000 and 100,000 — 2.4%
• 4,816 between 1,000 and 10,000 — 6.6%
• 9,750 between 100 and 1,000 — 13.3%
• 30,676 between 10 and 100 — 42.0%
• 25,619 on fewer than ten — 35.1%

Sixty-eight plugins. That is the entire top of the directory. Everything anyone argues about on Twitter — Yoast SEO, Elementor, WooCommerce, Contact Form 7 — lives inside a rounding error, and three quarters of the directory is on fewer than a hundred sites.

The bottom band is a floor, not a measurement

This is the part that trips people up. The directory never publishes an install count below ten. Everything with nine users, or one, or none at all, reports the same thing — so that bottom band of 25,619 is not “plugins with a handful of users”. It is “plugins the directory declines to count”.

The rounding is just as aggressive at the other end. Every plugin above ten million shares one published figure, which is why Yoast, Elementor and Contact Form 7 all show exactly 10,000,000 and no ordering between them is meaningful.

Read the shape of this distribution, not its edges. The middle of it is measured; both ends are policy.

What that means when you search for a plugin

It means the search box is showing you a long tail that is genuinely long. A plugin with 40 active installs is not a hidden gem that nobody has noticed — it is in the same band as forty thousand others, and the directory has told you almost nothing by showing you that figure.

It also means install count is a poor first filter. Two better ones — when the plugin last shipped code, and how many people have actually rated it — are covered in the next piece.

The full distribution, with the ratings and arrival-year charts beside it, is on the statistics page. Figures here were read in September 2026; that page says when its own copy was last refreshed.