Website care
Updates, backups, monitoring and hardening.
A website is not a finished object. Platforms update, plugins break, certificates expire, forms stop delivering and attackers scan continuously. Maintenance is the difference between a site that lasts five years and one that quietly stops working.
What should a website maintenance plan cover?
Six things: applying platform, theme and plugin updates on a schedule with a way to roll back; automated off-site backups that have been tested by actually restoring one; uptime and certificate monitoring that alerts a human; security hardening and malware scanning; performance and error checks after changes; and a small allowance of content edits so the site does not go stale.
The item most often missing is the tested restore. A backup nobody has ever restored is an assumption, not a safety net, and the moment you find out is the worst possible moment.
The second most often missing is checking that your forms still deliver. Contact forms break silently after updates more than any other single component.
What actually goes wrong over time
Sites rarely break dramatically. They decay. A plugin update changes a layout nobody notices for three weeks. A form stops delivering after a mail configuration change. A certificate expires on a Saturday. An abandoned plugin becomes a known vulnerability and an automated scanner finds it.
Almost none of this requires anyone to attack you deliberately. The overwhelming majority of compromised business websites are found by automated scanners looking for known vulnerabilities in outdated software, and the site is then used to send spam, host phishing pages or inject links.
That last consequence is the one that catches marketing people out. A compromised site frequently gets used to host content that damages your search visibility long before you notice anything is wrong.
The whole argument for a maintenance plan is that these problems are cheap to prevent and expensive to discover late.
What a real plan contains
Ask any provider to confirm each of these in writing. The gaps tend to be in the same places.
Updates, on a schedule, with a rollback
Core platform, themes and plugins, applied at least monthly and immediately for security releases. Applied on staging first where a staging environment exists, and with a restore point taken before anything is touched.
Backups off-site, and actually tested
Daily for a site that changes, stored somewhere other than the server the site runs on, retained long enough to recover from a problem discovered weeks later. And restored to a test environment periodically, because an untested backup is an assumption.
- Stored off-site, not on the same server
- Retention long enough to survive a late discovery
- Restored at least once so you know it works
Monitoring that reaches a person
Uptime checks, certificate expiry warnings, and alerts that go somewhere a human reads. A monitoring dashboard nobody opens is not monitoring.
See the remaining steps: What a real plan containsHide the remaining steps: What a real plan contains
Security hardening and scanning
Administrator accounts limited and named, login endpoint protected, file permissions correct, unused themes and plugins removed rather than deactivated, and regular malware scanning.
Post-change verification
After every update round: does the site still render, do the forms still deliver, did anything shift in Core Web Vitals, are there new errors in the log. This is the step that turns updates from a risk into a routine.
A small content allowance
Hours, staff changes, a new service, a seasonal notice. Sites go stale because small edits have no obvious route, and a modest included allowance keeps the site current without a separate quotation for every change.
None of this is expensive individually. All of it is expensive to arrange in a hurry after something has gone wrong.
What to watch after every update
Plugin and theme updates commonly add weight. Google publishes the thresholds and reports your real field performance in Search Console, which makes drift detectable rather than mysterious.
SourceCore Web Vitals thresholds, Google (web.dev)
A site that passed at launch and fails a year later has usually accumulated rather than broken. Checking after update rounds catches it while the cause is still obvious.
Questions to ask any maintenance provider
The answers to these separate a real plan from a line item on an invoice.
- When was my backup last restored to verify it works, and where is it stored?
- What is the update cadence, and is there a staging environment or do updates go straight to live?
- Who gets alerted if the site goes down at two in the morning, and what is the response?
- How would I know if my contact form stopped delivering?
- Who has administrator access, and is that list current?
See the full checklist: Questions to ask any maintenance providerHide the full checklist: Questions to ask any maintenance provider
- What happens if the site is compromised? Is cleanup included or billed separately?
- Am I on shared hosting, and if so what happens when another site on the same server is attacked?
- If I leave, do I get the files, the database and the domain without a discussion?
The form question is the one that produces the most revealing answer. Most providers have no process for it, and it is the most common silent failure there is.
Hosting, and what the cheap tier actually costs
Hosting is the floor under every performance number on your site. Server response time sets the starting point for Largest Contentful Paint, and no amount of front end work gets underneath a slow server.
The cheapest shared plans put a large number of sites on one machine. Your performance depends on what those other sites are doing, and in some configurations a security problem on a neighbouring site can affect yours.
The relevant questions are not about advertised disk space. They are whether a staging environment is available, how quickly the host actually responds, whether backups are included and where they are stored, and whether the environment is current enough to run the software versions your site needs.
We do not think hosting should be a secret or a margin. Whatever arrangement you end up with, the account should be in your name and you should be able to leave with your files.
Doing it yourself, or not
This is genuinely feasible to do in-house for a small site, and worth being clear about what it requires.
| Item | In-house | Managed |
|---|---|---|
| Updates | Possible, needs discipline | On a schedule with rollback |
| Backups | Possible, rarely tested | Off-site and periodically restored |
| Out of hours outage | Whoever notices | Alerting to someone on call |
| Compromise cleanup | Specialist work, usually urgent | Included or clearly priced |
| Cost | Time, and risk concentrated on one person | A monthly fee |
The real difference is not capability, it is consistency. Most in-house maintenance works well for six months and then stops the first time somebody gets busy.
What happens if a site is compromised
Speed matters and panic does not help. The sequence that works is: take the site offline or into maintenance mode to stop further damage, preserve a copy of the compromised state for diagnosis, then restore from a known clean backup rather than attempting to clean the live site in place.
After restoring, the entry point has to be found and closed, because restoring without that simply resets the clock. All passwords and keys get rotated, administrator accounts get reviewed, and the software that was out of date gets updated.
Read the full breakdown: What happens if a site is compromisedHide the full breakdown: What happens if a site is compromised
Then the search side. A compromised site is frequently used to inject spam pages or links, and Search Console will often have flagged a security issue. Requesting a review after cleaning is part of the recovery rather than an afterthought.
The whole process is considerably faster and cheaper when a tested, recent, off-site backup exists. That single item is the difference between an afternoon and a fortnight.
Which is why a backup you have never restored is not a backup, it is an assumption. Backups fail quietly in ordinary ways: the database is captured but the uploads folder is not, the job has been silently erroring since a plugin update, the retention window is shorter than the time it took anyone to notice the problem, or the archive is stored on the same server that just failed. None of those are visible from a dashboard showing a green tick.
The test is simple and takes under an hour. Restore the most recent backup into a staging environment, open the site, and check that the pages, the images and the form submissions are all there. Doing that once a quarter is the difference between knowing you can recover and hoping you can.
We do not publish a price for this piece of work on its own, because the right scope depends on what already exists. What is published is the bundle pricing: 2,400, 3,600 or 4,800 dollars a month depending on which channels are running. You can read the full breakdown on the pricing page, and you will get an exact number in writing before anything starts.
How this connects to the rest
Maintenance is the ongoing half of web design and development. A build without it is a decision to let the site degrade, and we would rather say that at the point of sale than a year later.
It protects the investment in search work directly. A compromised or slow site undoes technical SEO, and a site that goes down loses rankings as well as enquiries.
It protects paid advertising too, since a site that stops loading is still receiving paid clicks until somebody notices.
For WordPress specifically, the hardening and update work is the same discipline described in the WordPress build page, applied continuously rather than once.
Ask when your backup was last restored.
Ask whoever currently maintains your site. If the answer is that it has never been tested, that is the gap worth closing first, whoever closes it.
Straight answers.
Do I really need a maintenance plan?
If the site runs on WordPress or any platform with plugins, yes, or the equivalent has to happen in-house consistently. Outdated software is how most business sites get compromised.
If the site is on a fully hosted builder that handles updates itself, the requirement is smaller, though backups and form monitoring still matter.
How often should updates be applied?
Security releases immediately. Everything else at least monthly, applied on staging first where one exists, with a restore point taken beforehand.
Automatic updates for everything with no verification step is a different risk: things break and nobody notices.
Where should backups be stored?
Somewhere other than the server running the site. A backup on the same machine protects you from a mistake and not from a server failure or a compromise.
And it should have been restored at least once. An untested backup is an assumption.
What if my site gets hacked?
Take it offline, preserve a copy for diagnosis, restore from a known clean backup, find and close the entry point, rotate credentials, then request a security review in Search Console if one was flagged.
Restoring without closing the entry point simply resets the clock, which is why the diagnosis step is not optional.
Can I move my site elsewhere?
Yes, and you should confirm that in writing before signing with anyone. You should be able to take the files, the database and the domain without a negotiation.
Any arrangement that makes leaving difficult is a reason to look elsewhere.
How would I know if my contact form stopped working?
Unless somebody is testing it, you would not, which is exactly why this is the most common silent failure on business websites.
A monthly submission test from a real device takes two minutes and should be part of any plan. If yours does not include it, do it yourself today.
Where this comes from.
Primary documentation and published research behind the guidance on this page.
Talk to the team
A short call, a look at how the business currently shows up, and a straight answer on what we would do first.