What website maintenance should actually include (and who patches your server)

Quick answer: Real website maintenance is more than “we’ll update your plugins.” It should cover software updates (including the PHP version your site runs on), backups that are actually tested by restoring them, uptime and security monitoring, and — the part most plans are vague about — a clear answer to who patches the server. On shared or managed hosting the host often handles the server layer; on a VPS or a custom app, someone on your side has to. A maintenance plan that doesn’t say who owns patching isn’t really maintaining the thing most likely to hurt you.

“Website maintenance” is one of those line items everyone pays for and few can describe. When a security issue like the October 2026 PHP vulnerabilities lands, the difference between a plan that quietly kept you patched and one that only updated a few plugins becomes very real, very fast. Here’s what a plan worth paying for actually includes.

1. Updates — all the way down to PHP

Most plans update WordPress core, plugins and themes. Good — that’s the visible layer. But underneath the application sits the PHP version, the database, and the server software, and those age out of support too. A plan that updates plugins while leaving the site on an end-of-life PHP version is painting a house with rotting foundations.

Ask specifically: does this cover the PHP version, and who decides when and how we move to a newer one?

2. Backups you’ve actually restored

“We take daily backups” is table stakes. The question that matters is: have you ever restored one? An untested backup is a guess. A real plan restores backups periodically to confirm they work, keeps them somewhere separate from the live site, and can tell you how quickly you’d be back up after a disaster. “How long to recover?” should have a known answer, not a shrug.

3. Uptime and security monitoring

Someone should be watching so you’re not the one who discovers the site is down — from a customer’s angry email. That means uptime monitoring that alerts, and security monitoring that flags the obvious bad signs (file changes, malware, suspicious logins). Monitoring without an agreed response is just a louder alarm, so it pairs with the next point.

4. A clear answer to “who patches the server?”

This is the one that catches people out, so it’s worth being blunt about. Responsibility for the server layer — PHP, the operating system, security patches — depends on your hosting:

• Managed hosting: the host usually patches the server and PHP. Your plan’s job is to track that they do, choose a supported PHP version, and keep the application layer current.
• Shared / cPanel hosting: the host maintains the server, but you often choose the PHP version — so someone has to own that choice.
• VPS or dedicated server, or a custom app: nobody patches it unless your side does. This is where “we assumed the host handled it” becomes a breach.

A maintenance plan should state, in writing, which of these you’re on and who owns each layer. In our experience, the gaps that cause real damage are almost always at this boundary — the bit each party assumed the other was doing.

5. Agreed response times

“We’ll get to it” isn’t a commitment. A plan should say how fast something gets looked at — and ideally distinguish “the site is down” from “please change this text”, because they’re not the same urgency.

6. No lock-in

You should be able to leave. That means you hold (or can get, on request) your hosting, your domain, your code and your backups — without a fight. A provider confident in their work doesn’t need to trap you; the ones worth keeping, you keep because you want to. (Our notes on red flags when hiring a development agency and choosing an Adelaide development partner go deeper on spotting the difference.)

The questions to ask any provider

If you’re weighing up a maintenance or care plan, ask:

1. Does this cover the PHP version, and who decides when we upgrade it?
2. Are backups tested by restoring them, and how fast can you recover the site?
3. What exactly do you monitor, and what happens when something trips?
4. On my hosting, who is responsible for server and security patches — you, me, or the host?
5. What are your response times, and do they differ for “down” versus “a small change”?
6. If I ever leave, do I keep everything — hosting, domain, code, backups?

The answers tell you quickly whether you’re buying genuine cover or a line item.

Good maintenance is unglamorous and almost invisible — which is exactly why it’s easy to under-buy until the day it matters. If you’d like a straight conversation about what your site actually needs looked after, and who should own each part, get in touch. We work with businesses across Adelaide and around Australia, and we’re happy to tell you if your current arrangement is fine as it is.

Common questions

What should a website maintenance plan include? At minimum: software updates (including the PHP version, not just plugins), backups that are tested by restoring them, uptime and security monitoring with an agreed response, a clear statement of who patches the server, defined response times, and no lock-in on your hosting, domain, code or data.

Who is responsible for keeping my website’s server patched? It depends on your hosting. Managed hosts usually patch the server and PHP; on shared hosting you often choose the PHP version yourself; on a VPS or custom app, your side owns it entirely. A good maintenance plan states this explicitly rather than leaving it assumed.

Is updating plugins the same as maintaining my site? No. Plugin updates are the visible layer. Real maintenance also covers the PHP version, the server, tested backups, monitoring and recovery — the parts that cause the most damage when neglected and are the easiest to overlook.

How do I know if my maintenance provider is actually keeping me secure? Ask them the six questions above — especially who owns server and PHP patching, and whether they’ve ever restored one of your backups. Clear, specific answers are a good sign; vague ones are the warning.