Search for the best WordPress plugins and you get lists of thirty, most of them affiliate links, most of them recommending four plugins that each do the same job. Nobody publishes their own stack, because the honest version is less impressive than the list.
So here is ours. The site you are reading runs eight active plugins. No SEO plugin. No caching plugin. No security plugin. No backup plugin. No page builder. That is not a boast and it is not a template for every site, because some of those absences are only safe because something else is doing the job. What follows is the stack, the reasoning, the honest caveats, and the test we apply before adding anything.
Why the count matters at all
Every plugin is four things at once, and the plugin lists only ever discuss the first.
A feature. The reason you installed it.
A performance cost. Scripts and styles on every page, database queries, sometimes a cron job. The measurement approach is in website speed testing tools, and the thing it usually reveals is that the page is slow because of what was added rather than what was built.
A security surface. Plugin code runs with your site’s privileges. A plugin with an authentication bypass is your site with an authentication bypass, and the practical consequences are in website security that protects your SEO.
An update obligation. Somebody has to apply updates, and somebody has to notice when one breaks a template. Thirty plugins is thirty update streams and a combinatorial number of interactions.
The cost of a plugin is therefore not whether it is free. It is whether anyone will own it in eighteen months.
What this site actually runs
Eight plugins, all active, read from the site’s own installation on 2 November 2026.
Classic Editor. A deliberate choice rather than nostalgia. Our content is written as structured prose in a custom theme, our posts carry custom fields the theme renders, and the block editor’s output would add markup we would then have to strip. If you are building with blocks, this is exactly the wrong choice for you; the block approach has its own merits and we cover building for it in the custom blocks work on this site.
Contact Form 7. Forms. Chosen because it is small, it does one thing, and it does not try to become a page builder. Its cost is real: it loads a stylesheet and two scripts, and by default on every page. Confining them to the pages with forms is a four-line change and it is worth making.
Flamingo. Stores form submissions in the database so that a lost email is not a lost enquiry. From the same author as the form plugin, which is why it is here rather than a second forms product.
FluentSMTP. Transactional email delivery through a proper provider instead of the server’s mail function. This is the plugin most sites are missing, and its absence is why form notifications silently stop arriving. If you install nothing else from this list, install something that does this job and verify that enquiry emails are actually being delivered.
IndexNow, published by Microsoft Bing. Fires a submission on publish and update, which is the correct way to use it rather than by hand. What it does and does not reach is set out in every place you can actually submit a URL, and the concept in our IndexNow glossary entry.
Redirection. Manages redirects and logs 404s, which is how you find out that something you published a link to no longer exists. At scale the rules belong at the server or edge rather than in PHP, and the thresholds for moving them are in redirect management at scale.
Site Kit by Google. Connects Search Console and Analytics and surfaces both in the dashboard. We use it for the connection and the verification rather than the reporting, because the reporting we actually rely on is pulled through the APIs into our own pipeline, per how to export all your Search Console data with Python.
An MCP connector, which lets our own AI tooling read and write the site programmatically. This one is specific to how we work and is not a recommendation for anyone else; if you are not running agentic tooling against your own site, you do not want an authenticated write endpoint on it. We have described it by function rather than by name deliberately, for the same reason we do not publish our server configuration.
What we deliberately do not run, and the honest caveat on each
This is the part that matters, and every one of these comes with a condition.
No SEO plugin
Titles, descriptions, canonicals, Open Graph tags and structured data are emitted by our own theme, and sitemaps come from WordPress core. That removes a large dependency, a lot of front-end weight, and the duplicate-markup problem described in the schema validators piece on this site, where a theme and a plugin both emit an Organization node and disagree.
The caveat, which is significant. This only works because we build and maintain the theme. If you are on a third party theme and nobody on your side writes PHP, an SEO plugin is doing real work that would otherwise not get done, and removing it to save weight would be a bad trade. The right version of this advice is not “remove your SEO plugin”, it is “run one, not three, and know which one is emitting your markup”. The validation discipline is in automating structured data from your CMS with a validation script.
No caching plugin
Caching happens above WordPress in our setup, at the host and the edge, which is faster and has no PHP cost. A caching plugin is PHP solving a problem that a correctly configured server has already solved.
The caveat. If your host does no page caching and you have no CDN in front of the site, you need one, and the right answer is one caching plugin configured properly rather than three fighting each other. Shared hosting in particular usually needs it. The approach without the pileup is in Core Web Vitals for WordPress without plugin overload, and the device reality that makes it matter in mobile performance on low-end Android phones.
No security plugin
Our security posture is server and platform level: restricted admin access, managed updates, file permissions, a web application firewall at the edge, and no untrusted code. A security plugin scanning PHP from inside PHP is a weaker position than not having the vulnerable surface.
The caveat, and this is the one to take seriously. Not running a security plugin is only defensible if something else is doing the work. If your answer to “who applies updates” or “what blocks brute force on wp-login” is nobody, then a security plugin is better than the honest alternative, which is an unmonitored site. Removing it without replacing the function is how sites get compromised.
No backup plugin
Backups are taken at the host, off the server, and the only number that matters is whether a restore has been tested.
The caveat. An untested backup is not a backup, whoever takes it. If you cannot name the last time a restore was tested, you do not have backups, and in that situation a backup plugin with a verified restore beats a host’s promise you have never exercised.
No page builder
Templates are PHP in the theme. Page builders produce front-end weight, lock content into a proprietary format, and make migration expensive later.
The caveat. If marketing needs to build landing pages without a developer in the loop, that is a genuine business requirement and a builder may be the right answer. Make the decision knowing what it costs rather than discovering it during a replatform.
No analytics plugin beyond the connection
The tag is in the theme, and the analysis happens outside WordPress. A dashboard inside the admin is a convenience, not a reason to load a plugin’s assets on every page view.
The categories, and who should actually have what
Rather than a list of recommendations, here is the honest mapping of job to answer.
| Job | Needs a plugin? | Our answer |
|---|---|---|
| Transactional email delivery | Yes, almost always | FluentSMTP |
| Forms | Yes | Contact Form 7, scripts confined to form pages |
| Storing submissions | Yes | Flamingo |
| Redirects and 404 logging | Yes, until the volume justifies the edge | Redirection |
| Indexing submission | Yes, one, firing automatically | IndexNow |
| Search Console and Analytics connection | Convenient, not required | Site Kit |
| Titles, meta, schema, sitemaps | Only if you do not control the theme | Theme, plus core sitemaps |
| Caching | Only if host and CDN do not | Host and edge |
| Security | Only if nobody owns updates and access | Server and edge |
| Backups | Needed; plugin optional | Host, with tested restores |
| Page building | Only if non-developers must publish layouts | Theme templates |
| Image optimisation | Often, unless the pipeline handles it | Build and CDN |
The test before adding one
Six questions. A plugin that fails any of them does not go on.
- What job does it do that nothing installed already does? Overlap is the commonest cause of bloat. Two plugins emitting schema, two doing redirects, two optimising images.
- Who owns it? A named person who will apply its updates and notice when it breaks something. No owner, no install.
- What does it load on pages that do not use it? Check the rendered source after installing, not before. A plugin used on one page that loads assets on three hundred is a configuration problem worth fixing on day one.
- Is it maintained? Recent updates, a responsive author, a disclosed security history. An abandoned plugin is a scheduled incident.
- What happens when we remove it? Does the content survive, or is it locked in a proprietary format? This question is why page builders and some block libraries are expensive decisions.
- Could ten lines in the theme do it instead? Frequently yes, and when the answer is yes the ten lines are cheaper to own than the dependency. How to add them without touching core files is in the theme hooks work on this site.
Auditing a site that already has thirty
Most sites we are handed are in this position, and the cleanup is mechanical.
List every plugin with its version, its last update date, and what it is for. Anything nobody can name a purpose for is a candidate for removal.
Group by job. Where two plugins do the same job, one goes. The commonest duplicates are two SEO plugins, an SEO plugin plus a separate schema plugin, two caching plugins, and an image optimiser competing with the host’s own.
Check what each loads on the front end. Install order does not matter; what matters is which assets appear in the source of a page that does not use the feature.
Then remove in a staging environment, one at a time, with the before and after measurement recorded, because removing five at once and finding the site broken tells you nothing about which one mattered. The migration discipline for doing this safely is in the safe migrations work on this site.
Expect to find that a third of the list has no owner and no current purpose. That has been true of every inherited site we have audited.
What is a waste of effort
Installing a plugin to fix the performance problem caused by the previous four plugins.
Two SEO plugins, or an SEO plugin plus a schema plugin, both emitting markup.
A caching plugin on a host that already caches, which usually produces stale pages rather than fast ones.
Removing a security or backup plugin because a post like this one said we do not run them, without replacing the function.
Keeping a plugin because removing it feels risky, while never applying its updates for the same reason.
Judging a stack by its size rather than by whether each item has an owner.
A sensible order of work
- Confirm transactional email actually arrives, because this is the one that silently loses enquiries.
- Inventory every plugin with purpose, owner and last update.
- Remove the unowned and the purposeless, one at a time, on staging.
- Resolve every duplicate job down to one plugin.
- Confine each remaining plugin’s assets to the pages that use it.
- Decide, explicitly, whether caching, security and backups are the host’s job or a plugin’s, and make sure somebody owns whichever answer you chose.
- Apply the six-question test to anything new, forever.
If your site runs twenty-eight plugins and nobody can say what six of them do, get in touch.
Last verified: 2 November 2026. The stack above was read from this site’s own installation on that date, and we update this page when it changes.