Just One More Plugin: The WordPress Habit That Ate Your Site

There is a specific moment, familiar to anyone who has ever run a WordPress site for longer than a fortnight, when the phrase 'I'll just install a quick plugin for that' passes the lips. It sounds harmless. It is, in the same way that 'just the one' has ever been harmless. Two years later, the wp_options table weighs more than the human body, the homepage loads forty-seven JavaScript files, and something called 'WP Smart Analytics Turbo Lite' is quietly opening a WebSocket to a datacentre in Guangdong to report that a user in Basildon scrolled past your About page.

The WordPress plugin repository is the largest unsupervised public buffet in software. Sixty thousand-odd items, most of them free, most of them written by someone who has since taken up gardening. And every WordPress admin, sooner or later, becomes the person at the buffet who stacks the pastries on top of the curry because you can, and it is included, and nobody at the door is going to stop you.

The install that never comes alone

Nobody installs one plugin. This is the first and most important lie. You installed a contact form. The contact form has a 'recommended companion' notice in your dashboard the moment it activates. The companion has an add-ons page. The add-ons page has upsells. The upsells have their own dashboards. Your admin sidebar now has seven new menu items and you have not made a form yet.

Underneath, the same plugin has quietly enqueued its own copy of jQuery, its own copy of a date picker library the browser has shipped natively since 2018, an icon font of one thousand glyphs to render three, a Google Fonts stylesheet loaded from an origin the plugin author did not check for GDPR compliance, and an admin-ajax heartbeat that fires every fifteen seconds whether or not anyone is on the page. Multiply that by twenty active plugins. Now stand back and marvel at why the Time To First Byte on your brochure site is measured in geological epochs.

• →The 'lite' plugin that loads its full pro codebase anyway, so it can show you a nag banner for the paid tier.
• →The SEO plugin that adds a settings screen to every post type it has ever heard of, whether you use them or not.
• →The page builder that registers eighty-three shortcodes globally so its widgets 'just work', and then never deregisters them when you deactivate it.
• →The security plugin whose main threat model turns out to be your ability to log in.
• →The 'cookie consent' plugin that itself sets three tracking cookies before the banner has finished rendering.

Where exactly is that request going?

Open the Network tab on a mature WordPress site and prepare for a small existential crisis. Half the requests you cannot immediately identify. A third of them are going to hostnames you have never authorised, from plugins you barely remember installing, doing things you never agreed to.

The plugin ecosystem has a long and colourful history of what security researchers, being generous, call 'undocumented telemetry'. Free plugins acquired by opaque holding companies. Silent updates that added tracking libraries. The famously excruciating Wordfence write-up on the Pipdig affair, where an official theme vendor's shared codebase was quietly DDoSing competitors from thousands of unrelated customer sites. The steady drip of stories about big-name plugins being sold, refactored, and repurposed as data-collection pipelines with a page-builder skin bolted to the front.

None of this requires malice, incidentally. Most of it is just economics. A developer with 200,000 installs, no monetisation, and a mortgage receives an email offering five figures for the plugin. The plugin changes hands. The new owner ships an update. The update phones home. The update, six months later, phones somewhere else. Your users' IPs, referrers, and browsing behaviour are now inventory in a marketing data auction you did not attend.

“Every plugin you install is a permanent handshake with a stranger you will never meet, on behalf of visitors who did not agree to be introduced.”

The database as burial ground

The truly special betrayal is the one that outlives the relationship. Uninstall a WordPress plugin and, in a healthy universe, its tables, options, cron jobs, user meta, and transients would be politely swept up on the way out. In the actual universe we inhabit, roughly none of that happens.

The WordPress uninstall hook is optional. Most plugin authors, correctly reading the room, decline to implement it, on the grounds that a user who deactivates a plugin at 2am on a Tuesday during an outage tends to react poorly when their settings vanish. So the safer default became: leave everything behind, forever, just in case.

Poke around the wp_options table of any WordPress site older than three years. You will find:

• →Serialised settings blobs from plugins uninstalled during the Obama administration.
• →Autoloaded options weighing several megabytes each, being pulled into memory on every single page load, for a feature nobody uses.
• →Orphaned custom post types with thousands of rows, from a portfolio plugin the client tried for a week in 2019.
• →Half-populated tables prefixed with wp_wfhits, wp_yoast_indexable, wp_actionscheduler_actions, growing at a rate that would embarrass a mid-sized government department.
• →Cron jobs pointing at endpoints on domains that no longer resolve, retried politely by WordPress every twelve hours since 2021.

This is not database administration. This is stratigraphy. Give it long enough and there is a genuine, non-satirical academic paper in it: 'Sedimentary Layers of the wp_options Table: A Case Study in Digital Deposition, 2010–2035'. Somewhere, a PhD candidate is already drafting the abstract.

The compounding tax

Every plugin looks, in isolation, like it costs nothing. That is the trick. The costs are all downstream and diffuse. A quarter of a second here. Forty extra database queries there. A tiny risk of a supply-chain compromise. A tiny amount of PII leaking to an ad network. A tiny bit of admin UI clutter. A tiny bit of cognitive load for whoever inherits the site.

None of it registers as a bill. All of it registers as 'the site feels a bit slow lately', 'the client says the dashboard is confusing', 'the hosting company keeps ringing about database size', and eventually 'we should really rebuild this from scratch'. The rebuild-from-scratch conversation is where a decade of quiet plugin accumulation finally shows up as a five-figure line item, dressed as something else.

How to have the habit without the hangover

• →Before installing anything, ask if a native WordPress feature, a theme option, or ten lines of PHP in a snippet plugin will do the job. Almost always, they will.
• →Audit the Network tab on a logged-out page load every quarter. Any third-party hostname you cannot identify is guilty until proven innocent.
• →Check plugin ownership history, not just star ratings. A plugin sold to a new owner in the last twelve months is a plugin worth re-evaluating from scratch.
• →Prefer plugins that document what they store in the database and how they clean up. The ones that do not document it are the ones leaving the mess.
• →Once a year, on a staging copy, deactivate every plugin, delete it, and run a cleanup query on wp_options for orphaned autoloaded rows. The performance improvement will embarrass you.
• →Better yet: rebuild the eighty percent of the site that is genuinely just content and forms as static HTML, or as a small AI-generated app, and reserve WordPress for the fifteen percent that actually needs a CMS. The plugin sprawl was always downstream of the platform.

The moral, briefly

The plugin buffet is not free. It never was. The price is paid in performance, in privacy leaks your visitors never consented to, in database rows that will outlive the business, and in the slow accumulation of technical debt that eventually forces the rebuild you were trying to avoid by installing a plugin for it in the first place.

Somewhere in the middle of the next century, when the last VPS hosting the last unpatched WordPress 6.x installation finally succumbs, a digital archaeologist will lever open the database, blink at the wp_options table, and file a paper titled 'Evidence of Ritual Deposition in Late-Period Content Management Systems.' The peer reviewers will note that the specimen appears to have been buried alive under its own accessories. Try not to be that specimen.