このページで: [隠れる]
WordPress.org プラグイン ディレクトリを数えました。 31 8月 2026. の 71,067 リストされているプラグイン, 41,367 1年以上更新しないままだった. あれは 58% 何も触れずに放置されている棚の. Now here’s the part that flips the usual advice: among the 500 most-installed plugins, それだけ 22 have gone that long. Neglect lives almost entirely in the long tail, so the question was never how many plugins you run. It’s which shelf you picked them off.
簡単な回答: There is no plugin limit, in core or anywhere else. Thirty actively maintained plugins are a safer bet than eight abandoned ones. Two numbers matter more than the count. Keep total autoloaded database data under 800,000 バイト, the point where WordPress Site Health raises a critical issue. And drop any plugin whose “Tested up to” field trails the current release, WordPress 7.1, by more than two versions.
最終レビュー済み: 8月 2026. Plugin data pulled live from the WordPress.org API on 31 8月 2026.
これをどのように確認したか
Most articles on this topic quote a plugin count someone guessed at in 2019. We went to the source instead. Every directory figure below comes from the official WordPress.org plugin API, 問い合わせた 31 8月 2026, not from a secondary blog post.
The method: we pulled the full directory sorted by last-update date. Then we binary-searched for the exact point where plugins cross the one-year and two-year staleness lines. That gives counts, 推定ではない. We ran the same test separately on the 500 most-installed plugins. That second pass is what exposed the gap between the directory as a whole and the plugins people actually run.
For each named plugin we recorded active installs, ユーザー評価, declared “Tested up to” version and last update date, all from the same API. Security figures come from Patchstack’s State of WordPress Security in 2026 whitepaper, 公開 25 2月 2026. Every byte threshold quoted here comes from the WordPress developer reference and core dev notes. None of it is our reading of what a plugin appears to do.
Two limits you should know about. We ran no synthetic load tests and profiled nothing on a controlled server, so no timing claim here is ours. と “tested up to” is a self-declared field. A developer can bump it without testing anything, which makes it a useful negative signal and a weak positive one.
The Real Limit Is Not a Number of Plugins
Ask ten hosting support teams and you’ll get ten different caps. Twenty on shared hosting. Fifty on a VPS. Five if you want to be safe. None of these numbers survive contact with an actual site, because plugins are not interchangeable units of weight.
A caching plugin like LiteSpeed Cache (7 百万インストール, 96% 評価) runs early, writes a static file and gets out of the way. It makes every later page load faster. A poorly built social-feed widget does the opposite. It fires an external HTTP request on every page view, blocking rendering while it waits for a third-party server you don’t control. Both count as “one plugin.” One pays for itself; the other taxes every visitor.
Think of it as a budget, それから, not a cap. Each plugin spends from four separate accounts, and you go over budget in one of them long before you hit any magic number. Here’s what those accounts are.
The Four Costs Every Plugin Charges You
1. Autoloaded database data
This is the cost almost nobody measures, and it’s the one WordPress itself now polices. Options marked “autoload” get pulled from the database on every single page load, whether the page needs them or not. A plugin that stores a large settings blob this way charges you on every request forever, including on pages where the plugin does nothing.
WordPress 6.6 put two guardrails in core. Any option larger than 150,000 バイト saved without an explicit autoload instruction is no longer autoloaded by default, controlled by the wp_max_autoloaded_option_size フィルター. And Site Health raises a critical issue once your total autoloaded data passes 800,000 バイト, the default of the site_status_autoloaded_options_size_limit フィルター. Those two numbers are the closest thing WordPress has to an official plugin limit, and neither of them counts plugins.
2. Database queries per page load
Every plugin that reads settings, checks a licence or filters a query adds SQL. A well-built plugin adds two or three queries and caches the result. A badly built one runs a query inside a loop, so a page listing 50 products fires 50 extra queries. That’s the pattern that turns a fast site slow without changing the plugin count at all.
3. Front-end HTTP requests
Plugins that load their own CSS and JavaScript on every page, rather than only where they’re used, are the classic bloat source. Worse are plugins loading assets from a remote domain, because you inherit that server’s latency and its uptime. This is also a security cost, as the June 2026 breach below shows.
4. Security surface
Patchstack’s State of WordPress Security in 2026 報告, published on 25 2月 2026, 記録された 11,334 new WordPress vulnerabilities during 2025. それは 42% rise on 2024. Plugins accounted for 91% 彼らのうちの. WordPress core accounted for six, 合計で, all year. の 11,334, いくつか 1,966 were high severity, と 46% had no fix from the developer at the moment of public disclosure.
That last figure is the one to sit with. Nearly half the time, the responsible move (update immediately) isn’t available to you. Every plugin you install is a bet that its developer will still be answering security reports in three years. Our directory count says 58% of them aren’t answering anything at all.
Remote assets and security surface collided in the clearest case of 2026. の上 12 六月 2026, tampered scripts from Awesome Motive’s CDN began creating hidden admin accounts on 1.2 million sites running OptinMonster, TrustPulse or PushEngage. The way in was an unpatched copy of UpdraftPlus on Awesome Motive’s own marketing server. Attackers took a CDN key from it and rewrote the JavaScript those plugins load into customer sites. Site owners who had done nothing wrong were compromised through a file they never hosted.
How to Measure Your Own Plugin Load in 20 分
So how do you find out what your own site is spending? Stop counting plugins and measure the four costs directly. One free plugin, about twenty minutes.
- Check autoloaded data first. Go to Tools, then Site Health, then the Info tab, and open the Database section. A critical issue about autoloaded options means you are over 800,000 バイト. That’s your bottleneck. Fix it before touching anything else.
- クエリモニターをインストールする. それは無料です, 運ぶ 200,000 active installs at a 98% 評価, and needs no configuration. It adds a panel to your admin toolbar listing every database query on the current page, attributed to the plugin that fired it. Open the Queries by Component view. It ranks your plugins by how much database work each one causes.
- Load a real page. Not the homepage. Homepages are usually cached hardest, so they hide the problem. Open a product page, a category archive or a long post instead. Note the total query count and the slowest component.
- Deactivate one suspect, then re-measure. Change one thing at a time. Anything adding more than 100ms, またはそれ以上 20 queries on a page where it does nothing visible, has failed to earn its slot.
- Audit every “Tested up to” 分野. Open each plugin’s directory page from your Plugins list and compare its declared compatibility against WordPress 7.1. その中で、 500 most-installed plugins, 86% declare 7.0.4 また 7.1. A plugin still declaring 6.6 珍しいです, not normal.
One warning on that fourth step. Nearly every troubleshooting guide online tells you to isolate conflicts with the Health Check & Troubleshooting plugin. しないでください. The next section explains why, and it’s the clearest case on this page of advice that stopped being true while everyone kept repeating it.
What You Should Actually Install
Six jobs need a plugin on a normal WordPress site in 2026. Everything beyond these is a want, not a need, and wants are where plugin lists go wrong. Install counts and ratings below are live from the WordPress.org API on 31 8月 2026.
Caching and performance
Non-negotiable, and free unless your host forces otherwise. Running LiteSpeed? Use LiteSpeed Cache (7 百万インストール, 96%). It talks to the server’s own cache instead of emulating one in PHP. On Apache or NGINX, WP Fastest Cache holds a 98% 全体の評価 1 百万インストール. Both do the job at USD 0.
SEO
One plugin, never two. Running Yoast and Rank Math together produces duplicate meta tags and conflicting sitemaps. Both sit at 96%, と 10 ミリオンと 4 百万インストール. The review base is what separates them: Yoast’s score rests on 27,819 reviews against Rank Math’s 7,497. Same rating, very different sample size. For paid tiers priced at renewal, のガイドを参照してください the best SEO tools for WordPress.
バックアップ
UpdraftPlus carries 3 100 万件のインストール 96%. それも, awkwardly, the plugin whose unpatched copy opened the June 2026 supply chain attack. Read that as an argument for automatic updates, not against the plugin. 何を選んでも, back up somewhere other than the server you’re backing up.
安全
ワードフェンス (5 百万インストール, 94%) デフォルトです. Set expectations honestly, けれど: Patchstack’s 2026 report found that traditional web application firewalls blocked only 12% of WordPress-specific exploit attempts. A firewall plugin is a speed bump, not a wall. Patching is the actual defence. If you want to check your current exposure first, we have a walkthrough on how to test your WordPress site security.
フォーム
お問い合わせフォーム 7 matches Yoast at 10 百万インストール. Its rating is 80%, the lowest of any plugin named on this page. WPForms Lite sits at 96% 横切って 5 million installs and 14,369 レビュー. A 16-point rating gap between two free plugins doing the same job is the clearest install-count-versus-quality mismatch in the directory right now. Popularity measures age and marketing, not quality.
分析
Google Site Kit is free and official. これは 84% 全体の評価 5 million installs is the weakest of the free tools here, mostly on setup complexity. まだ, don’t pay for an analytics plugin that reformats data Google gives you at no cost.
Four Plugin Jobs WordPress Core Now Does Itself
Core has absorbed a lot of small-plugin territory across three releases in nine months. Three of the four below are clean deletions. The fourth depends on which browser your editors use, which is a stranger sentence than it ought to be. We’ll get to it.
Accordion and FAQ plugins. WordPress 6.9 “Gene”, 解放された 2 12月 2025, added a native Accordion block. Collapsible FAQ sections no longer need a plugin.
Tabs plugins. WordPress 7.1, 解放された 19 8月 2026, stabilised the Tabs block and the Playlist block in core.
Reading-time and word-count plugins. Also core since 6.9, as the Time to Read and Word Count blocks.
Image optimisation plugins. One caveat on this one, そしてそれは本物です. WordPress 7.1 processes images in the browser before upload, and it does more than resize. Core now handles compression, cropping, EXIF rotation, thumbnail generation and conversion to WebP or AVIF, all client-side. That covers most of what people bought Smush or EWWW for.
Here’s the caveat, and it’s the reason this one is a “check first” rather than a “消去”. The browser pipeline needs SharedArrayBuffer, so it currently runs on Chromium only: ChromeとEdge 137 またはそれより新しい. Firefox and Safari fall back to server-side processing automatically, and so does any upload over a non-SSL connection. Same site, same plugin, different result depending on which browser your editor happens to use.
So keep the plugin if any of three things is true. Your editors use Firefox or Safari. You need to bulk-optimise images already in the library, because client-side processing only touches new uploads. Or you use it for CDN delivery, which core does not do at all. Otherwise Smush (1 百万インストール, 96%) is now doing work WordPress already did on the way in.
Now the one to remove for a different reason entirely. 健康診断 & Troubleshooting last shipped an update on 25 7月 2024, and its own README now marks the plugin deprecated. It declares compatibility only up to WordPress 6.6.7, まだ 300,000 sites still run it. Troubleshooting Mode moved out to a separate canonical plugin, called simply Troubleshooting, これには 400 アクティブインストール. That replacement has reached roughly one in 750 of the users it was meant to inherit. That’s what a handover looks like when nobody announces it loudly. Delete the old one. A two-year-stale plugin with admin-level reach is not a diagnostic tool, it’s a liability.
While you’re auditing, check whether your caching plugin duplicates something your host already does. Managed WordPress plans usually run server-level caching, and stacking a PHP cache plugin on top can slow things down instead.
How to Decide Whether a Plugin Earns Its Slot
Four checks before you click install, then the scenarios.
Check the last update date, not the star rating. A 5-star plugin last touched in 2023 is a liability. Check active installs against review count: お問い合わせフォーム 7 もっている 10 million installs and 2,178 レビュー, which describes a plugin people inherited rather than chose. Check whether it loads assets from a remote domain, because that makes its vendor’s security your security. And check whether WordPress 7.1 already does the job.
バジェット: 米ドル 0. 個人ブログ, 下 5,000 月間訪問者数. Six plugins total. LiteSpeed Cache or WP Fastest Cache, Yoast SEO free, UpdraftPlus free, WPForms Lite, Site Kit, Wordfence free. Skip Elementor entirely at this size. Its Essential tier costs USD 49 a year and no longer includes popups, custom CSS or eCommerce features. The tier that does what people expect is Advanced Solo at USD 99. A block theme gives you that layout control at USD 0.
ワークロード: WooCommerce ストア, 200+ 毎月の注文. Autoloaded data sets your ceiling here, not plugin count. WooCommerce plus 15 extensions is normal and fine. WooCommerce plus one badly built shipping plugin writing a 400 KB settings blob is not. Run the Site Health check monthly, 一度ではない. At this order volume the host’s database performance outweighs any plugin choice you make, which our guide to WordPress eコマースホスティング covers in detail.
観客: multi-author site. Three or more people hold admin access. Cap installs by policy, not by number. Write the rule down: no plugin under 10,000 active installs goes live without a second person reviewing it. The long-tail neglect rate is the reason. At that install level you’re deep in the 58%.
Inherited site. You just took over a build somebody else made. Don’t audit plugin by plugin. Open Site Health, check autoloaded options, then run Query Monitor on the slowest page and sort by component. Two hours of that beats two days of deactivating things one at a time. Sites like this typically carry three to six plugins nobody has opened the settings page for since launch.
Threshold: 25-plus plugins and you can’t say what each one does. That’s the actual danger sign, and it has nothing to do with 25 being special. If you can’t name a plugin’s job from memory, you also aren’t tracking whether its developer is still shipping security fixes. Not knowing is the risk. The count is just what makes not knowing likely.
よくある質問
How many plugins is too many for WordPress?
There is no threshold, and any article handing you one is guessing. WordPress defines no plugin limit anywhere in core. The limits it does define are about data. One is 150,000 bytes for a single autoloaded option. The other is 800,000 bytes of total autoloaded data, the point where Site Health calls it critical. Measure those two instead of counting icons on your plugins page. Sites running 40 plugins on a good host routinely beat sites running 10 on cheap shared hosting.
Do plugins slow down your WordPress site?
Some do, some make it faster, and most do neither in a way you’d notice. A caching plugin makes every page load faster. A plugin that only runs in wp-admin costs your visitors nothing. The ones that hurt add database queries or load remote scripts on every front-end page view. Query Monitor tells you which of yours is doing that in about five minutes, 無料で.
How do I find which plugin is slowing down my site?
クエリモニターをインストールする, open a slow page while logged in as an administrator, and look at the Queries by Component panel. It attributes every database query to the plugin responsible and ranks them. Then deactivate your top suspect, reload the same page and compare. Change one plugin at a time, or you won’t know which change did what.
Is it safe to leave a deactivated plugin installed?
いいえ, and it’s one of the most commonly misunderstood points in WordPress security. A deactivated plugin still has its PHP files sitting in your web directory, and some vulnerabilities are exploitable in files WordPress never loads. It also stops getting your attention while it keeps collecting CVEs. Deactivated means “not running today”, いいえ “削除されました”. Delete it.
Do I still need an image optimisation plugin in 2026?
Less often than last year, but check your browser before you delete anything. WordPress 7.1, 解放された 19 8月 2026, added client-side image processing that resizes, compresses and converts to WebP or AVIF before the file leaves your machine. That pipeline is Chromium-only for now, so Chrome and Edge get it while Firefox and Safari quietly fall back to server-side. Keep the plugin for bulk-optimising your existing library or for CDN delivery. Core does neither.
Can too many plugins get my site hacked?
The count isn’t the risk; the maintenance status is. Patchstack recorded 11,334 new WordPress vulnerabilities in 2025, と 91% sat in plugins. The dangerous plugin is the abandoned one, と 41,367 plugins in the directory have gone over a year without an update. The June 2026 Awesome Motive breach proved a harder point too. A fully updated plugin can still hurt you if it loads scripts from a vendor’s compromised CDN.
Does deleting unused plugins actually improve speed?
Usually only a little, and often not at all, because a deactivated plugin isn’t executing. The real gain is in two other places. Deleting removes attack surface, and it removes leftover autoloaded rows some plugins leave in the options table after deactivation. Check Site Health before and after: if your autoloaded total drops, you got a speed win. もしそうならなければ, you still got a security one.
最終評決
Delete the plugin-count rule. It’s the wrong unit. Your autoloaded data total predicts whether the site is slow. How recently each plugin shipped an update predicts whether it gets hacked. Neither is a count.
Three things to do this week. Open Site Health and check autoloaded options against the 800,000-byte line. クエリモニターをインストールする, run it on your slowest page, and remove anything adding queries where it does nothing. Then audit the “Tested up to” field on every plugin you run. Delete whatever trails WordPress 7.1 by more than two releases, starting with Health Check & Troubleshooting if it’s there.
正直に, most sites finish that audit two or three plugins lighter and measurably faster. The count was never what changed. What changed is that you now know what each remaining plugin costs you.
Working through the rest of your setup? If plugin overhead wasn’t your bottleneck, the server usually is. For front-end speed, fixing render-blocking resources moves Core Web Vitals more than any plugin swap will. And if your real question is which plugins to buy, not how many to run, 私たちの must-have WordPress plugins guide prices each one at renewal.