WordPress Maintenance

Maintenance plans have a bad reputation because most of them are a cron job with an invoice attached: updates pushed straight to production, a backup nobody has ever restored, and a monthly PDF that says everything is fine right up until it is not.

Updates, on staging first

WordPress, plugin and theme updates are applied to a staging copy, then smoke-tested — home page, a template of each type, the checkout if there is one, the contact form — and only then applied to production. It is the one habit that separates a site that has never had an outage from a site whose owner learned what a white screen is.

Where an update is a major version with breaking changes, it gets scheduled and flagged rather than slipped in on a Tuesday.

Backups that restore

A backup is a claim until you restore one. Backups run off-site on a schedule, and the restore path is exercised — on staging, deliberately — so the day it is needed is not the first time it is used. You get told where the backups live and how to reach them yourself, because a backup only you can access is not really yours.

Monitoring that reaches a person

Uptime monitoring, with the alert going somewhere a human reads. A dashboard that shows an outage after the fact is not monitoring.

Security, in proportion

Most WordPress compromises come through the same few doors: an abandoned plugin with a known vulnerability, a weak admin account, or an upload directory executing PHP. So the watch is on file integrity, user accounts and failed logins, plus a check of the installed plugins against known vulnerability data. No security plugin that slows every request to display a threat score.

Performance and search, checked monthly

Sites do not get slow all at once; they get slow one uncompressed hero image at a time. Every month, Core Web Vitals and Search Console coverage are checked against the previous month, and anything that regressed is flagged with what caused it. Small fixes are included; anything larger is quoted before it is done.

A person, not a queue

You get a named contact and a defined response time. When something breaks, you message a developer who already knows how your site is built — not a form that generates a ticket number.

Sites I did not build

These are welcome, after an audit. Some inherited sites need stabilising work before a plan makes sense: an abandoned plugin to replace, a PHP version to move off, a backup regime that does not exist. If that is the case you will be told honestly, with the work quoted separately, rather than signed onto a monthly fee that quietly papers over it.