What a WordPress Maintenance Plan Should Cover

Updating is the visible part of maintenance and the least valuable on its own. Anyone can click 'update all'; the value is in doing it without breaking the site.

• WordPress minor and security releases applied promptly, ideally automatically.
• Plugin and theme updates on a regular schedule, with changelogs read for breaking changes.
• Security fixes applied immediately rather than at the next scheduled window.
• Major updates tested on staging first, especially on a store.
• A backup taken before each update round, so a bad update is a five-minute rollback.
• PHP version kept current, tested on staging before switching.

A plan that says 'daily backups' without saying where they're stored, how long they're kept and whether restores are tested is describing a cron job, not a recovery capability.

• Automated backups of files and database, at a frequency matching how much work you could afford to lose.
• Stored off the web server, with credentials held somewhere other than the site.
• Enough retention to reach back past a compromise discovered late — thirty days of dailies plus some monthlies.
• Failure alerting, because backup jobs stop silently.
• A restore tested to staging at least quarterly, with the process written down and the time it takes recorded.

• Two-factor authentication enforced on administrator accounts.
• Login rate limiting covering wp-login.php, XML-RPC and the REST API.
• File integrity monitoring, so changed core or theme files are noticed in hours.
• Alerts on new administrator accounts and role changes.
• A quarterly user audit, removing accounts for people who've left.
• Unused plugins and themes deleted rather than deactivated.
• Monitoring against known plugin vulnerabilities, so you hear about a problem before it's exploited.

The point of monitoring is that you find out before your customers do.

• Uptime monitoring with alerts, checking more than the homepage — a site can be up while the checkout is broken.
• SSL certificate expiry alerts. Expired certificates are an entirely avoidable outage.
• Domain renewal reminders, which are an even more avoidable one.
• Form submission monitoring. A contact form that silently stops delivering is one of the most expensive failures there is, because nothing looks wrong.
• Error log review, so recurring PHP warnings get fixed rather than accumulating.
• Core Web Vitals tracking, so a gradual slowdown is noticed.

Every site accumulates small jobs: a broken link, a plugin conflict after an update, an image that needs swapping, a form field to add. A good plan includes a monthly allowance for these.

Be clear about what counts. 'Small content changes' should be defined — a number of hours, or a description of what's in and out. Ambiguity here is where the relationship sours, because the client thinks a new page is a small change and the developer thinks it's a project.

You should receive something monthly that says what was done: which updates were applied, what was found and fixed, whether backups ran and were tested, any security events, and current performance.

This isn't bureaucracy. Without it you're paying a retainer with no visibility, and you have no record for the day you need to show that the site was maintained.

It also catches drift. A report that says 'no updates available' three months running means either a remarkably stable stack or nobody checking.

Sites get slower on their own. Plugins add assets, the media library grows, the database accumulates, and a site that scored well at launch quietly slips below the thresholds two years later.

• A quarterly performance check on the templates that matter, compared against the numbers from launch.
• A plugin audit each quarter: what is still used, what duplicates something else, what is no longer maintained.
• Image library review, so uploads at full resolution don't accumulate unnoticed.
• Database housekeeping when there is a symptom — bloated autoloaded options, expired transients, orphaned metadata from removed plugins.
• Broken link checks, internally and outbound, since linked sites move and disappear.
• A check that analytics and conversion tracking are still firing. Tracking breaks silently after theme and plugin changes, and nobody notices until a quarterly report looks wrong.

• A staging environment, and evidence that updates go there first.
• Restore testing, not just backup running.
• A stated response time for something being broken, and what counts as urgent.
• Named coverage hours, and what happens outside them.
• A clear list of what's included and what's billed separately.
• Access and ownership that stay yours, so you could move to another provider without losing anything.
• Someone who will tell you when the site needs work they haven't been asked to do.

Entirely reasonable for a simple site, provided you're honest about whether it will actually happen. The failure mode isn't inability, it's that maintenance is never urgent until it's an emergency.

If you do, set calendar reminders rather than relying on intent: a monthly update session on staging then production, a quarterly restore test and user audit, and alerting configured so problems come to you rather than waiting to be found.

The single most important one is the restore test. Everything else has a second chance; a backup that doesn't restore does not.

The way to think about cost isn't the monthly fee against zero. It's the monthly fee against what an incident costs: the cleanup, the lost orders, the delisting from Google, and the time spent on all of it.

For a site that generates revenue, maintenance is cheap insurance. For a store, it isn't optional — a store is handling payments and customer data on unpatched code otherwise.

If you'd like an existing site reviewed to see what state it's actually in before deciding, send me the URL and I'll tell you what I find.