WordPress maintenance: the complete guide

What WordPress maintenance actually is

WordPress maintenance is the recurring work of keeping a WordPress site secure, available, recoverable and performing. That is the whole definition. Everything else is detail about how each of those four things is achieved.

It is worth being precise, because maintenance frequently gets conflated with two other things it is not. It is not development, which changes what the site does. It is not content management, which changes what the site says. Maintenance keeps the existing site working, and confusion between these three is the most common reason care plans lose money.

Why WordPress specifically needs it

A WordPress site is not one piece of software. It is core WordPress, a theme, and typically twenty to thirty plugins, each maintained by a different team, on a different release schedule, with different testing standards. Nobody tests that specific combination except the site running it.

Two consequences follow. First, updates arrive constantly and unpredictably. Second, any update can interact badly with any other component, which means updating carries genuine risk. Maintenance exists to manage that tension: apply updates quickly enough to stay secure, carefully enough not to break things.

The four jobs maintenance does

1. Keep software current so known, published vulnerabilities are not sitting exposed.
2. Keep a working copy so mistakes and attacks are recoverable.
3. Watch the site so problems are found before customers find them.
4. Record what was done so the work is accountable and diagnosable.

Any maintenance routine that covers all four is adequate. Any routine missing one has a specific, predictable failure mode: skip updates and you get compromised, skip backups and a bad day becomes a disaster, skip monitoring and outages last longer than they should, skip records and you cannot diagnose anything or prove anything.

Updates: the highest-value task

Patching is the single highest-value maintenance activity. The overwhelming majority of successful WordPress compromises exploit a known vulnerability in a plugin or theme, for which a patch already existed. Not a novel attack, not a zero day, just software that was out of date.

How quickly to apply what

• Security releases: hours to days. These should not wait for a monthly window.
• Patch releases: weekly is fine.
• Minor versions: weekly or monthly, with verification.
• Major versions: test on staging first, always, regardless of how well-behaved the plugin usually is.

The right way to apply an update

1. Take a restore point immediately before, not last night's backup.
2. Assess risk: version jump, changelog, what the plugin touches, how critical the site is.
3. Apply on staging first if the risk is anything above routine.
4. Check the result: HTTP status, PHP errors, key pages rendering correctly.
5. Test the things that earn money: forms, cart, checkout, login.
6. Roll back and pin the version if anything fails.

That sequence is not controversial. The problem is that it takes six to ten minutes per site when everything goes well, which is why it stops being followed somewhere around the fifth site. Automating it is what makes it happen every time.

Backups: the one that saves you

A backup is only real if it has been restored. Almost every WordPress site has a backup plugin. A much smaller number have a backup that would actually restore, and the failure modes are boring: a PHP timeout partway through a large database, a full destination, expired credentials, a schedule that silently stopped, or a backup stored on the same server as the site it protects.

What good backup practice looks like

• Off-site. A backup on the same server protects against mistakes, not against server loss.
• Encrypted. Backups contain your entire database, including user data.
• Frequent enough to match what you would lose. Daily for a brochure site. Continuous for a store, where a nightly backup discards every order since midnight.
• Restore-tested. On a schedule, automatically, with a pass or fail result.
• Granular. Restoring one file should not require rolling the whole site back.
• Retained sensibly. Long enough to recover from a compromise you did not notice immediately. Thirty days minimum, ninety is better.

Monitoring: knowing before your customers do

Monitoring answers a simple question: is the site working right now? The details matter more than the question.

Check intervals should be 60 seconds rather than five minutes, because a five minute interval means an outage can run nine minutes before anyone knows. Checks should come from multiple locations and be confirmed from a second before alerting, otherwise routing problems produce false alarms. And checking for HTTP 200 is not sufficient, because a WordPress site can return 200 while displaying a database error.

Response time deserves attention alongside availability. A site whose response time has tripled over six weeks is on its way to an outage, and that is the point at which it is cheap to fix.

Security: inventory beats vigilance

Security maintenance is often framed as vigilance, which is the wrong model because vigilance does not scale and does not survive a busy month. The better model is inventory.

If you know exactly which plugin and theme versions run on which sites, then every new advisory becomes a lookup rather than an investigation. Without that inventory, security news is just anxiety.

The security tasks that matter

• Match advisories against installed versions, continuously.
• Remove unused plugins rather than deactivating them. Deactivated code is still present.
• Replace abandoned plugins. No update in over a year means no fix is coming.
• Audit administrator accounts. Dormant admin accounts are a standing risk.
• Enforce two-factor authentication on every administrator.
• Monitor file integrity so unexpected changes are visible.
• Watch SSL expiry, security headers and exposed endpoints.

Performance: catching decay

Performance maintenance is about trend rather than absolute numbers. Sites are fast at launch and get slower gradually as plugins accumulate, images go up unoptimised and scripts are pasted into headers. Nobody notices because nobody compares this month to six months ago.

Measure Core Web Vitals per template rather than only the home page, on mobile and desktop, on a schedule. Alert on sustained regression rather than on a single noisy measurement, and correlate regressions with what changed around the same time.

How much time it takes

Honestly measured, including report assembly, support conversations and context switching, most people spend one to two hours per site per month on maintenance done properly. Estimates are usually lower than reality because the small interruptions do not get counted.

At five sites that is manageable. At twenty it is thirty hours a month, which is most of a working week, produces nothing billable, and is the point at which the routine quietly degrades.

What it costs

Two separate costs. Tooling typically runs $2 to $6 per site per month for a platform that covers management, backups, monitoring, security and reporting, more if you assemble it from separate products. Labour is the larger number: at 1.5 hours per site and an effective cost of $65 an hour, that is roughly $98 per site per month before tooling.

Which is why the tooling decision is really a labour decision. A platform that costs $3 and removes an hour of work is not a $3 expense.

WordPress maintenance mode, what to automate and what not to

Automate: update application with verification, backups and restore testing, availability and performance monitoring, vulnerability matching, report generation, database optimisation, alert routing.

Keep human: deciding whether to replace an abandoned plugin, judging whether a visual change is acceptable, major version upgrades on revenue-critical sites, talking a client through an incident, deciding what a care plan should contain.

The line is judgement. Anything where the correct action is determined by the facts should be automated. Anything where the correct action depends on context, relationships or trade-offs should not be.

One qualification that matters: automation without verification is not automation, it is delegation to chance. Applying updates automatically with no restore point, no post-update checks and no rollback is worse than doing it manually. The verification is what makes automation safe.

Maintenance for client sites

When you maintain sites for other people, two obligations get added to the four above: prove the work happened, and stay profitable doing it.

Proof matters because good maintenance is invisible. A month with no downtime and no compromise looks identical from outside to a month where nothing was done. Without a report, the line item is the easiest thing to cut at renewal.

Profitability matters because delivery cost scales with client count while price usually does not. The specific killer is undefined support: a plan sold as updates and backups becoming unlimited small edits. Define the allowance, track it, show it in the report.

Both are covered properly in the care plans guide, which is the natural next thing to read if you maintain sites for clients.