What a WordPress maintenance plan should actually include

Maintenance is the least glamorous line on any web invoice and the one most likely to be quietly worthless. The test is simple: if the plan cannot tell you what it did last month in specifics, it did not do much.

Here is what a plan should actually contain.

Updates applied on staging first

The single habit that separates a site that has never had an outage from one whose owner has learned what a white screen looks like. Updates go to a staging copy, get a smoke test — home page, one of each template type, checkout if there is one, the contact form — and only then reach production.

Auto-updates are fine right up until a plugin release breaks your checkout at 2am and nobody notices for a week.

Backups that have been restored

A backup is a claim until somebody restores one. The plan should say where backups go, how often, how long they are kept, and — the part almost nobody does — when the restore was last tested. Ask for the date of the last test restore. The answer tells you everything.

You should also be able to reach the backups yourself. A backup only your agency can access is not really yours.

Monitoring that reaches a person

Uptime checks are cheap; the value is entirely in where the alert goes. A dashboard that shows yesterday’s outage is not monitoring, it is a diary.

Security in proportion

Most WordPress compromises arrive through three doors: an abandoned plugin with a public vulnerability, a weak or stale admin account, and an uploads directory that executes PHP. So the work is: check installed plugins against known vulnerability data, review user accounts and failed logins, watch file integrity, and keep PHP and WordPress current.

What it is not: a security plugin that adds a request to every page load to render a threat score.

Performance and search, checked against last month

Sites do not get slow all at once — they get slow one uncompressed hero image at a time. A monthly comparison of Core Web Vitals and Search Console coverage catches the regression while it is still one page.

The report should name what changed and what caused it. “Everything looks good” is not a report.

A named human and a response time

When something breaks you want to message a developer who already knows how your site is built. A ticket number is not a relationship.

Questions worth asking before you sign

• Do updates go to staging first, and can I see the staging URL?
• When did you last test a restore of my backup?
• Where are the backups stored, and can I download one myself today?
• What is the response time, and who answers?
• What did you actually do last month — specifically?
• If I cancel, what stops working?

That last one matters. A maintenance plan should run on your hosting, your accounts and your backups. Cancel it and nothing should break; you simply stop having someone watch it.

What it is not

It is not a content retainer, and it is not an excuse to defer real problems. If an inherited site needs stabilising — an abandoned plugin to replace, a PHP version to move off, a backup regime that does not exist — that work should be quoted honestly and done, not papered over with a monthly fee.