What does website maintenance actually include?
Maintenance plans vary enormously, and the names don't tell you much. Here's what the work actually is, how often each part needs doing, which parts get left out, and what you can sensibly handle yourself.
Website maintenance is the work that keeps a working website working, safe and recoverable after it launches. For most business websites it comes down to four jobs: keeping the software up to date, keeping backups you can actually restore, watching for problems, and fixing small things before they pile up.
The trouble is that the same name covers very different amounts of that work. For one company, maintenance means clicking update once a month. For another, it's monitoring, tested backups, security work and a developer on call. Both get called a maintenance plan, and the price difference between them is real for a reason.
The four jobs that make up most of it
Keeping the software current. A WordPress site runs on WordPress itself, a theme, a set of plugins, and the PHP version on the server. All of them get updates, and some of those updates close security holes that attackers start scanning for soon after they're announced. PHP versions also expire: PHP 8.2 stops getting security fixes on December 31, 2026, and WordPress recommends PHP 8.3 or newer.
Keeping copies you can restore. Backups of both the files and the database, stored somewhere other than the server they came from, kept long enough to go back before a problem started, and tested by actually restoring them.
Watching for problems. Checking from outside that the site is up, that the security certificate and domain aren't about to expire, that scheduled jobs are running, and that the forms on the site still deliver.
Fixing the small things. A broken link, a plugin that needs replacing, a page that needs a new phone number. Small jobs that pile up when nobody owns them.
How often each part needs doing
| Task | How often | Why it matters |
|---|---|---|
| Security updates | As soon as practical after release | Known holes get scanned for quickly |
| Other plugin, theme and core updates | Weekly to monthly, tested first | Falling behind makes every later update riskier |
| Backups | Daily for most sites, more often for stores | Limits how much you can lose |
| Test restore | At least a few times a year, and after any change to how backups work | A backup you've never restored is a guess |
| Uptime monitoring | Continuous, checked from outside your network | You find out before your customers tell you |
| Form and email test | Monthly, and after updates or hosting changes | Forms fail quietly |
| User and plugin review | Monthly to quarterly | Old accounts and unused plugins are risk with no benefit |
| PHP version upgrade | Before your version's support ends | Unsupported versions stop getting security fixes |
| Domain and certificate expiry | Monitored automatically (certificates daily), renewed automatically | Either one can take the whole site offline |
Updates are the part that needs judgment
The software part sounds simple: click update. It isn't, because every update changes code your site depends on, and a lot of the risk in maintenance lives right there.
WordPress already does some of this on its own. By default it installs minor security releases automatically, and on sites first installed since late 2020 it's set to install major releases too, unless a host or developer changed that. Automatic updates for plugins and themes are off by default until you turn them on, apart from rare forced security updates from WordPress.org. For a simple site with a few well-maintained plugins, that's a reasonable baseline. For a store, a booking site or anything heavily customized, a broken update costs real money, so updates should be tried on a copy of the site first, then applied to the live site and checked: the forms, the checkout, the logins and anything else that brings in work.
One difference worth checking first is what happens when an update does break something. Applying updates and fixing what an update breaks are different jobs, and it's worth knowing which one you're paying for.
A backup only counts if it restores
Having a backup isn't the same as having one someone has restored recently. Backups fail in quiet ways: the job stopped running months ago, the files were saved but the database wasn't, or the only copy lives on the same server that just failed.
A sound setup keeps copies away from the server, keeps enough history to go back past a problem that started weeks ago, and gets tested by restoring a copy and checking that the site works. It's close to what the federal Cybersecurity and Infrastructure Security Agency advises: keep offline, encrypted backups, and regularly test that they restore. On a store, a restore also needs a plan for the orders that arrived after the backup was taken, so they aren't overwritten.
Checking that things happen when nobody's looking
A lot of maintenance is confirming that things that are supposed to happen on their own actually do. Backups, scheduled emails, and many plugin tasks run on a schedule, and when the schedule stops, nothing on the website looks different.
We ran into exactly that on our own site in September. During a move to a new server, the hosting panel's default scheduled-task job turned out to fail on every run, because it used a different PHP version than the site did. With WordPress's built-in scheduler switched off in favor of that job, no scheduled task ran at all, and nothing visible said so. We found it because we were checking the move, not because anything alerted us. That's the case for monitoring the jobs, not just the homepage.
Forms deserve the same treatment. A contact form can look perfect and send nothing, and the only reliable check is to submit it and see whether the message arrives. If yours doesn't, our guide to missing order and form emails explains where they usually go.
What plans often leave out
When you compare plans, these are the lines worth looking for, because they're the expensive parts:
- Fixing what an update breaks, rather than just applying updates
- Testing updates on a copy before they reach the live site
- Restoring from backup, and how often restores are tested
- PHP upgrades, which can break older code
- Small content changes, and how many are included
- Cleaning up a hacked site, and whether that's included or billed separately
- A written record of what was done each month
None of these is unusual to ask about. A provider who does the work will answer quickly.
What you can sensibly handle yourself
A simple brochure site with a handful of popular plugins can be maintained by an owner with a checklist and an hour a month. Keep WordPress's automatic minor updates on, use a reputable backup service that stores copies off the server, update plugins on a quiet day and check the site straight afterward, submit your own contact form once a month, and set a reminder to check that backups are still running.
It's time to pay someone when the site takes orders or bookings, when it brings in a meaningful share of your work, when it's heavily customized, or when the hour a month keeps not happening. At that point the real question isn't whether maintenance is worth it, but who's responsible when something breaks at a bad moment.
Questions to ask before you pay for a plan
- Are updates tested on a copy of the site before they go on the live one?
- If an update breaks something, is fixing it included?
- Where are backups stored, how long are they kept, and when was a restore last tested?
- Who gets alerted when the site goes down, and what happens next, at what hours?
- Is cleaning up after a hack included?
- How many small changes are included each month?
- Will I get a record of what was done?
- What happens if I cancel, and how do I get my site and accounts back?
For comparison, our Website Care plan is $199 a month, flat: managed hosting, updates tested on a copy first, off-site backups with tested restores, security hardening, malware scanning and a firewall, and two Quick Fixes a month. Whoever you use, those questions are the ones that separate a plan from a promise.