A Good WordPress Maintenance Plan

Most WordPress sites are maintained the way most people floss: enthusiastically after a scare, then not at all. The site works, so nothing gets touched; then a plugin three versions behind gets exploited, or an update finally applied in bulk breaks the checkout, and suddenly maintenance becomes an emergency with a consultant’s invoice attached.

A maintenance plan exists to convert those spikes into a flat, boring line. But “maintenance plan” has come to mean anything from a genuine operations schedule to a 30-euro monthly fee for clicking the update button. This article describes the real thing: what the work actually is, how often each piece needs doing, and how to tell a serious plan — whether you run it yourself or pay someone — from theater.

The Principle: Maintenance Is Risk Management on a Schedule

Every task in a good plan exists to shrink one of three risks:

1. Compromise — the site gets hacked through something outdated or misconfigured.
2. Loss — data disappears and cannot be recovered.
3. Decay — the site slowly gets slower, breaks in small ways nobody notices, and quietly stops earning.

If a task does not map to one of those, it is busywork. If one of those risks has no task mapped to it, the plan has a hole. That mapping is the whole design method — everything below is just the schedule it produces.

The Weekly Layer: Updates and a Pulse Check

Updates, with a process rather than a button

Updates are the heart of maintenance because outdated plugins are the leading cause of WordPress compromises — and because updates themselves are the leading cause of self-inflicted breakage. The process matters more than the frequency:

• Security releases: apply fast. Within 24–48 hours of release, faster if the vulnerability is being actively exploited. This is the one category where waiting is the risky choice. Auto-updates for minor core releases should simply be on.
• Feature updates: apply deliberately. Weekly batch, read the changelogs (thirty seconds each — you are scanning for “major rewrite,” “breaking change,” or a database migration), take a backup immediately before, then update and actually look at the site afterwards.
• Test where breakage is expensive. A brochure site can update in production with a fresh backup standing by; a store or membership site should push updates through staging first, with a five-minute click-through of the money paths: homepage, key landing pages, add to cart, checkout, login, forms.
• Major core versions and page-builder majors: wait a week or two unless a security issue forces the pace. Let the ecosystem find the incompatibilities for you.

The pulse check

Five minutes: confirm uptime monitoring saw no incidents, glance at the backup log to confirm backups actually ran (silent backup failure is a classic — the job that has been erroring for four months), and skim security scan results. The point is not depth; it is that no failure gets to be four months old.

The Monthly Layer: Verify, Review, Prune

Restore a backup. Actually restore one.

This is the single most-skipped task in all of website operations, and the most valuable. A backup that has never been restored is a rumor. Once a month, restore the latest backup to a staging or local environment and confirm the site comes up and the newest content is present. When this works, it takes fifteen minutes. When it does not work, you have just discovered a catastrophic problem on a calm Tuesday instead of during a disaster — which is the entire return on investment of a maintenance plan, realized in one task.

While you are there, check the backup coverage: files and database, stored off the server, with retention that goes back far enough to predate a slowly-discovered problem. A rule of thumb: daily backups kept for 30 days, plus a monthly kept for a year, covers most realistic recovery scenarios including “the infection started six weeks ago.”

Security review

• Review the user list: departed staff, unfamiliar admins, dormant accounts with high privileges. Every account is a door; monthly is how often you count the doors.
• Check that 2FA is still enforced for privileged roles (people quietly disable it).
• Skim the security plugin’s log for patterns worth acting on — not the thousand blocked bots, but the targeted repeated attempts.

Prune the estate

Deactivated plugins still execute vulnerable code paths in some scenarios and always add update surface. Monthly: delete deactivated plugins and themes (keep one default theme for debugging), empty giant spam queues, and clear expired transients. A leaner site is easier to update, easier to scan, and easier to reason about during an incident.

The Quarterly Layer: The Slow Decay Items

Some things break too slowly for weekly rituals to catch:

• Performance spot-check. Test three key pages with a consistent tool and compare against last quarter’s numbers, not against perfection. A site that got much slower over a year did it in small steps, invisible without a baseline.
• Form and email deliverability test. Submit every important form; confirm the notifications arrive and transactional email lands in an inbox, not spam. Deliverability rots silently as sender requirements tighten.
• PHP version review. Check what your host offers versus what you run. Upgrading PHP on a maintained site is a staging-test-then-switch afternoon; on a neglected one it becomes a migration project.
• License audit. Expired premium licenses mean plugins that silently stop receiving security updates while appearing perfectly healthy. This failure mode is invisible from the dashboard — you have to check.
• Content and integration sweep. Broken outbound links, the abandoned Twitter widget, the analytics property nobody looks at, the popup advertising an event from last year. Decay risk, in its purest form.

The Standing Layer: Things That Run Continuously

A plan is not only scheduled human attention; it is also the machinery that watches between visits:

• Uptime monitoring with alerting to a channel someone actually reads. Checking every minute from outside your own network; anything less and your customers become your monitoring system.
• File integrity monitoring / malware scanning, so a compromise is discovered in hours rather than when Google flags you.
• Automated daily backups, off-server, with the retention described above.
• A change log. A shared note where every update, config change, and plugin install gets one line with a date. When something breaks, “what changed recently?” is always the first question; a plan that cannot answer it in thirty seconds is running blind.

What a Good Plan Refuses to Promise

Whether you are buying a care plan or writing one for clients, the boundary line matters as much as the inclusions. A serious plan is explicit that maintenance is not:

• Development. “Small tweaks” is the phrase that destroys maintenance contracts. Good plans define a monthly time-box for minor content edits (say, 30 minutes) and quote everything beyond it separately.
• Unlimited incident recovery. A plan should promise that backups exist, restores are tested, and incidents get a defined response time — not that any disaster is fixed for free regardless of cause.
• SEO and marketing. Adjacent, valuable, different discipline, different line item.

Ambiguity here is why both cheap plans (which secretly include nothing) and generous plans (which secretly include everything) collapse.

The Whole Plan on One Table

Total: roughly four to six hours a month for a typical business site — which is also a fair way to sanity-check what a care plan should cost, once you multiply by a reasonable hourly rate and add the tooling.

Closing: The Plan Is the Calendar, Not the Intention

Everyone intends to maintain their site. The difference between intention and a plan is that a plan has dates, an owner, and a checklist that produces a small written record each time it runs. Put the weekly slot in an actual calendar, write the one-line log entries, and restore that backup once a month even though it feels redundant — especially because it feels redundant. Boring, on schedule, forever: that is what a healthy WordPress site looks like from the inside.

Photo: Luis Quintero on Pexels