WordPress maintenance: updates, backups and fixes across every site.

“WordPress maintenance” sounds like a single service, which is why it gets underestimated. In practice it is a set of unrelated tasks bundled under one name, each with its own cadence and its own failure mode. Updates protect against compromise. Backups protect against everything else. Performance work protects revenue. They are not substitutes for one another.

The reason WordPress specifically needs this is its plugin model. A typical site runs a dozen or more third-party plugins, each maintained by someone else, on their own release schedule, with their own security record. That extensibility is why WordPress runs so much of the web, and it is also why an unmaintained WordPress site degrades faster than a static one.

The part most checklists get wrong

Almost every WordPress maintenance checklist lists “take backups” and stops there. Taking a backup is the easy half. The half that matters is restoring one — to a staging site, on a normal Tuesday, before you ever need it. A meaningful share of backup systems fail on first restore: incomplete database exports, missing uploads, a plugin that stored data outside the tables. Discovering that during an actual incident is how a bad morning becomes a bad quarter.

Backups are the only part of WordPress maintenance that turns a catastrophe into an inconvenience, and they are the part most often misconfigured. Three failures account for nearly all of it.

Backing up to the same server as the site

A backup stored in a folder on the same hosting account is not a backup. It shares a fate with the thing it protects: if the server fails, the account is suspended, or an attacker gets write access, both copies go together. Off-site means a different provider — object storage, a separate cloud account, somewhere with its own credentials.

Backing up files but not the database, or the reverse

A WordPress site is both. The database holds posts, pages, users, settings, orders and most plugin data; the filesystem holds uploads, themes and plugin code. Restoring one without the other gives you a site that loads and is missing everything that matters. Check that your backup includes the uploads directory in particular — it is usually the largest thing on the site and the most commonly excluded to save space.

Never testing the restore

This is the one that catches experienced people. Backups run nightly and report success for a year; the first actual restore reveals that the database export was truncated, or that a plugin stored its data in a custom table nobody included. Restoring to a staging site once a month is unglamorous and it is the only thing that converts a backup from an assumption into a fact.

How long to keep them

Long enough to survive a problem you did not notice immediately. Compromises and corrupted content are often discovered weeks later, and a rolling seven days of backups is no help if the damage happened on day nine. Thirty days of daily backups, with monthly snapshots kept longer, covers the realistic cases. For a store, keep more — the cost of storage is trivial next to the cost of reconstructing orders.

Step-by-step: how to back up a WordPress site, covering the manual database and file export as well as the automated route. For core releases specifically, the latest WordPress version tracks what shipped and what to check before applying it.

Almost none of it is sophisticated. WordPress sites are rarely targeted individually — they are found by automated scanners looking for known vulnerable versions of popular plugins, then exploited at scale. The implication is reassuring and slightly boring: keeping software current handles the overwhelming majority of the threat.

The maintenance tasks that carry real security weight:

• Update promptly, especially plugins. The dangerous window is between a vulnerability being disclosed and your site being patched. Disclosure is public, so that window is exactly when scanning traffic spikes. See how to update WordPress and plugins safely for the order to apply them in.
• Remove what you are not using. A deactivated plugin still has its code on the server and can still be exploitable. Delete rather than deactivate.
• Audit users and roles. Old contractor accounts and unnecessary administrator access are a standing risk that costs nothing to remove.
• Watch for abandoned plugins. A plugin with no update in two years is not stable, it is unmaintained — and it will never receive the patch when something is found.

If a site has already been compromised, maintenance is not the right tool and cleanup is a different job with its own sequence — isolate, identify entry point, clean, rotate every credential, then patch what let them in.

Where the manual hours actually go

Ask anyone maintaining WordPress sites where the time goes and the answer is rarely the work itself. Applying an update takes seconds. What takes the time is the surrounding ritual: logging into each dashboard, checking what changed, spot-checking the front end afterwards, noting it down for the client, and repeating that per site. The task does not scale badly — the ceremony around it does.

That is the specific thing automation should target. Not replacing the judgement about whether a major version bump is safe, but removing the twelve identical logins that surround a decision you already made.

The condition that makes automation safe

Unattended maintenance is only sensible when the recovery path is fast. An automated update that breaks a checkout page at 3am is worse than no automation, if fixing it means restoring last night's database and losing a day of orders. Snapshotting before every change makes the reversal one click rather than a recovery project — which is what makes running it unattended a reasonable thing to do at all.

See how one-click undo works.

The economics change completely somewhere around the tenth site. Below that, maintenance is a chore you absorb. Above it, it is a scheduling problem: the work is not harder, there is just more of it arriving at once, and the cost of context switching between client environments starts to dominate the cost of the work.

This is also where the risk profile changes. One disclosed vulnerability in a plugin you have standardised on is now present on every site you manage. The response you need is one instruction applied across the portfolio, not an afternoon of logins while the window stays open.

Managing multiple WordPress sites covers the fleet workflow, and WordPress site management covers the day-to-day operation side.

No single change makes a WordPress site slow. What happens is that a launch-day site is fast, and then over two years it gains a slider, a chat widget, three tracking scripts, a few hundred uncompressed images and forty thousand rows of post revisions. Each addition is individually defensible. The cumulative effect is a site that takes four seconds to load and nobody can point to why.

That accretion is why performance belongs in maintenance rather than in a one-off optimisation project. An audit fixes the current state; a recurring check stops it drifting back within a year.

The four things worth checking monthly

• Image weight. Consistently the largest win and the most neglected. Uploaded-at-full-resolution photography, served unresized, is the single most common cause of a slow WordPress page.
• Script bloat. Every plugin that loads its assets on every page, including the pages that do not use it. Contact form scripts on the blog, slider libraries on the checkout.
• Database size. Post revisions, expired transients, spam comments and orphaned metadata from plugins removed long ago. This also inflates every backup you take.
• Core Web Vitals from field data. Lab scores measure a fast connection in a data centre. Real-user data measures your actual visitors, which is what search ranking uses and what your customers experience.

Treat the score itself as a diagnostic rather than a goal. A perfect synthetic score on a page that still feels slow to a real visitor on mobile data has optimised the wrong thing.

Everything above applies to a store, with the intervals tightened and two additions. A brochure site that breaks is embarrassing; a store that breaks is losing money for every hour it stays broken, and the loss is measurable, which changes how much maintenance is worth.

• Back up daily, at minimum. Orders arrive continuously and cannot be reconstructed from the front end. A weekly backup on a store means accepting the loss of up to a week of transactions.
• Test checkout after every update. Not just that the site loads — that a real product can be added, a shipping method selected, and payment reached. Checkout involves more third-party moving parts than any other flow on the site.
• Watch payment gateway and shipping plugin updates specifically. These integrate with external APIs that change on someone else's schedule, and a silently failed integration can look completely normal from the admin.
• Never update during a sale. Freeze changes around campaigns, launches and seasonal peaks. The upside of a routine update is small; the downside during peak traffic is not.

A maintenance routine is a scheduled opportunity to notice something before a client does. Most WordPress failures give warning if anyone is looking: memory warnings before a white screen, slow queries before a timeout, a plugin conflict on staging before it reaches production.

The failures worth recognising on sight are a database connection error, the generic critical-error message WordPress shows when PHP fails fatally, and the white screen that appears when a fatal error occurs with display disabled. Each has a small set of likely causes and a standard diagnostic order — and each is far cheaper to resolve when the last change made is known and reversible, which is exactly what a maintenance log gives you.

The practical difference maintenance makes here is narrowing the search. Debugging a site nobody has touched in eight months means considering everything. Debugging one with a change log means starting with the last thing that changed, which is usually the answer.

The troubleshooting section covers each of these errors in full, along with hacked-site recovery and speed optimization.

All three are legitimate. The wrong answer is the fourth option most sites are actually on: intending to do it yourself and not doing it.

Do it yourself if

You have one or two sites, you are comfortable in the admin, and — the part people skip — you will genuinely put a recurring block in the calendar and honour it. The work is not difficult. The failure mode is not incompetence, it is that nothing forces the task to happen, so it slides until something breaks. If the last six months suggest that is you, pick another option honestly rather than resolving to try harder.

Hire an agency if

The site earns meaningful money and you want a person accountable when it stops. What you are buying is judgement and someone to call, not the mechanical work. Ask any prospective provider two questions: when did you last test a restore from backup, and what happens if an update you applied breaks the site. The answers separate a real service from a monitoring dashboard with an invoice attached.

Automate it if

The work is repetitive, you have more than a handful of sites, or you are an agency delivering this for clients. The recurring tasks in the table above are almost entirely mechanical — the judgement is in deciding the policy once, not in executing it forty times. Automation earns its place when it removes the ceremony and keeps the reversibility.

These are not exclusive. The common arrangement for an agency is automating the scheduled work, keeping a human on the exceptions, and pricing both into a plan.