The WordPress Maintenance Gaps We Keep Finding When We Take Over a Site

When we take over hosting and maintenance for a new client, usually migrating away from an agency that has gone quiet or a “maintenance plan” that turned out to be just plugin updates, we run the same audit every time. The industries are different. The site sizes are different. The gaps we find are almost always the same.

Backups that exist somewhere, but were never tested

A backup plugin running is not the same as a working recovery plan. We have inherited sites where backups had been silently failing for months, and sites where the only backup lived on the same server as the site itself, which protects against nothing. A restore you have not tested is a theory, not a safety net.

Updates handled by extremes, never the middle

Most sites fall into one of two failure modes: updates left untouched for months because nobody wants to risk breaking something, or auto-update switched on for everything with no one checking what actually changed. Both create the same outcome eventually, either a known vulnerability sitting unpatched, or an update that silently breaks a page nobody notices until a client calls. The fix is staged updates on a schedule, tested before they go live.

Plugin sprawl that is quietly taxing every page load

Sites accumulate plugins the way garages accumulate tools: a contact form from years ago, an old page builder nobody uses anymore, a caching plugin fighting with another caching plugin. Each one adds database queries, script requests, and one more thing that can conflict at the next core update. We regularly remove a third of a site’s active plugins without the client losing a single feature they actually use.

A database that has never been cleaned

Post revisions, spam comments, orphaned transients, and abandoned plugin tables build up for years if nothing prunes them. None of it is visible from the dashboard, and all of it slows down every query the site runs. This is one of the quieter reasons a WordPress site gets slower every year even when nothing else has changed.

Every team member with administrator access

We regularly find agency staff, past contractors, and long-departed employees still holding full admin accounts. Every one of those accounts is a live credential that can be phished, reused, or simply forgotten about. Role-based access, reviewed on a schedule, closes this without slowing anyone down.

Nobody watching for downtime

A surprising number of clients only find out their site is down when a customer emails to ask why the contact form is not working. Uptime monitoring is a five-minute setup, and it is the difference between catching an outage in sixty seconds and finding out about it a day later.

No documentation, no changelog

When there is no record of what has been changed, updated, or configured, every new person touching the site starts from zero, and small decisions made under time pressure never get revisited. A simple changelog turns “why is it set up like this?” into a two-minute answer instead of an afternoon of investigation.

Why this is worth fixing properly

None of this is about fear, it is about what we actually find, every time, when we take over a site. It is exactly why MSPs and agencies outsource this layer to us rather than handling it in-house: a proper WordPress maintenance plan means someone is actually checking these seven things on a schedule, not assuming they are fine.