There is no safe number. A site with forty small, well-maintained plugins can be easier to run than one with eight, if three of those eight are page builders, form suites or all-in-one toolkits that touch every page. What matters is what each plugin does, who maintains it, and how much of the site depends on it.
Start with an inventory
List every plugin, active or not, with its version, when it was last updated and whether it came from WordPress.org, a commercial vendor or your own team. Inactive plugins are worth removing straight away: they still sit on the server and can still be attacked.
- What it does, in one sentence, and which pages or features depend on it
- When it was last updated, and whether the vendor is still active
- Whether it adds settings, tables or shortcodes that would outlive it
- Whether it loads scripts or styles on every page, or only where needed
- Whether it overlaps with another plugin or with WordPress core
Sort them into three groups
- Keep: maintained, focused plugins that do one job well, such as an SEO or redirect tool
- Replace: plugins that duplicate core features, or large toolkits where you use one small part
- Rebuild: anything business-critical that is unmaintained or deeply customised, which belongs in your own code
The third group is where the risk sits. A membership, booking or donation plugin that has been bent to fit your process over years is often the reason updates are frightening. Moving that logic into a small custom plugin your team owns usually costs less than another year of working around it.
The goal is not fewer plugins. It is a site where you know what every plugin is for, and can update any of them on a Tuesday afternoon.
Watch the page builder
Page builders deserve their own line in the audit. They make early pages fast to build, then lock content into markup that only the builder can read. On a large site that makes redesigns, migrations and accessibility fixes far harder. The block editor, with a set of custom blocks designed for your content, gives editors the same flexibility without the lock-in.
Make updates routine
An audit only helps if the site stays tidy afterwards. That means plugins managed in version control rather than installed from the dashboard, a staging site that matches production, automated checks on key pages after each update, and someone who decides whether a new plugin is allowed in. With that in place, a security release like WordPress 7.1.4 becomes a same-day task rather than a project.
We run plugin audits as part of a Blueprint for organisations whose WordPress site has become hard to change. Sometimes the answer is a rebuild. Often it is a few weeks of careful pruning on the platform you already have.
