Nesta página: [ocultar]
Contamos o diretório do plugin WordPress.org em 31 agosto 2026. Do 71,067 plugins que ele lista, 41,367 passaram mais de um ano sem uma atualização. Isso é 58% da prateleira intocada. Now here’s the part that flips the usual advice: among the 500 most-installed plugins, só 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.
Resposta rápida: 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 bytes, the point where WordPress Site Health raises a critical issue. And drop any plugin whose “Testado até” field trails the current release, WordPress 7.1, by more than two versions.
Última revisão: agosto 2026. Plugin data pulled live from the WordPress.org API on 31 agosto 2026.
How We Checked This
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, queried on 31 agosto 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, não estimativas. 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, avaliação do usuário, declared “Testado até” version and last update date, all from the same API. Security figures come from Patchstack’s State of WordPress Security in 2026 whitepaper, Publicados 25 fevereiro 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. E “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 milhão de instalações, 96% Avaliação) 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, então, 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 bytes saved without an explicit autoload instruction is no longer autoloaded by default, controlled by the wp_max_autoloaded_option_size filtro. And Site Health raises a critical issue once your total autoloaded data passes 800,000 bytes, the default of the site_status_autoloaded_options_size_limit filtro. 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 relatório, published on 25 fevereiro 2026, gravado 11,334 new WordPress vulnerabilities during 2025. That is a 42% rise on 2024. Plugins accounted for 91% deles. WordPress core accounted for six, no total, all year. Do 11,334, alguns 1,966 were high severity, e 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. Em 12 Junho 2026, tampered scripts from Awesome Motive’s CDN began creating hidden admin accounts on 1.2 milhões de sites executando OptinMonster, TrustPulse ou PushEngage. A entrada foi uma cópia sem patch do UpdraftPlus no próprio servidor de marketing da Awesome Motive. 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 Minutos
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 bytes. That’s your bottleneck. Fix it before touching anything else.
- Instalar o Monitor de Consulta. É grátis, carrega 200,000 active installs at a 98% Avaliação, 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, ou mais do que 20 queries on a page where it does nothing visible, has failed to earn its slot.
- Audit every “Testado até” campo. Open each plugin’s directory page from your Plugins list and compare its declared compatibility against WordPress 7.1. Entre os 500 most-installed plugins, 86% declare 7.0.4 ou 7.1. A plugin still declaring 6.6 é incomum, not normal.
One warning on that fourth step. Nearly every troubleshooting guide online tells you to isolate conflicts with the Health Check & Troubleshooting plugin. Não. 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 agosto 2026.
Caching and performance
Non-negotiable, and free unless your host forces otherwise. Running LiteSpeed? Use LiteSpeed Cache (7 milhão de instalações, 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% classificação em 1 milhão de instalações. 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%, com 10 milhões e 4 milhão de instalações. 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, veja nosso guia para the best SEO tools for WordPress.
Backups
UpdraftPlus carries 3 million installs at 96%. Isso é também, 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. O que quer que você escolha, back up somewhere other than the server you’re backing up.
Segurança
Wordfence (5 milhão de instalações, 94%) é o padrão. Set expectations honestly, Apesar: 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.
Formulários
Formulário de Contato 7 matches Yoast at 10 milhão de instalações. Its rating is 80%, the lowest of any plugin named on this page. WPForms Lite sits at 96% através 5 million installs and 14,369 avaliações. 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 Analytics
Google Site Kit is free and official. Está 84% classificação em 5 million installs is the weakest of the free tools here, mostly on setup complexity. Ainda, 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”, lançado 2 dezembro 2025, added a native Accordion block. Collapsible FAQ sections no longer need a plugin.
Tabs plugins. WordPress 7.1, lançado 19 agosto 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, e é real. 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 “excluir”. The browser pipeline needs SharedArrayBuffer, so it currently runs on Chromium only: Chrome e Edge 137 ou mais recente. 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 milhão de instalações, 96%) is now doing work WordPress already did on the way in.
Now the one to remove for a different reason entirely. Health Check & Troubleshooting last shipped an update on 25 Julho 2024, and its own README now marks the plugin deprecated. It declares compatibility only up to WordPress 6.6.7, ainda 300,000 sites still run it. Troubleshooting Mode moved out to a separate canonical plugin, called simply Troubleshooting, que tem 400 instalações ativas. 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, então os cenários.
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: Formulário de Contato 7 tem 10 million installs and 2,178 avaliações, 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.
Despesas: USD 0. Blog pessoal, debaixo 5,000 visitantes mensais. Six plugins total. LiteSpeed Cache or WP Fastest Cache, Yoast SEO grátis, UpdraftPlus grátis, 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.
Carga de trabalho: Loja WooCommerce, 200+ pedidos por mês. 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, nem uma vez. At this order volume the host’s database performance outweighs any plugin choice you make, which our guide to Hospedagem de comércio eletrônico WordPress covers in detail.
Público: 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.
perguntas frequentes
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, de graça.
How do I find which plugin is slowing down my site?
Instalar o Monitor de Consulta, 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?
Não, 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”, não “removido”. 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, lançado 19 agosto 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, e 91% sat in plugins. The dangerous plugin is the abandoned one, e 41,367 plugins in the directory have gone over a year without an update. O junho 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. Se isso não acontecer, you still got a security one.
Veredicto Final
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. Instalar o Monitor de Consulta, run it on your slowest page, and remove anything adding queries where it does nothing. Then audit the “Testado até” 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.
Honestamente, 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, nosso must-have WordPress plugins guide prices each one at renewal.