Web Development
Website maintenance that prevents emergencies
Website maintenance is the difference between a small patch today and a hacked site or dead server at the worst possible moment. We handle updates, security, backups and monitoring on a monthly plan, so problems get caught small.
Who it is for: Businesses whose site nobody technically owns: no one runs updates, no one checks backups, and problems surface only when a customer reports them.
Everything in this service
- Core, plugin and dependency updates, tested before applying
- Security hardening and malware scanning
- Daily off-site backups with tested restores
- Uptime and performance monitoring with alerts
- Monthly report plus a small-fixes allowance
What to expect
- A site that stays online, patched and fast
- Restores that work because backups are tested
- One number to call when anything breaks
How website maintenance actually works
What website maintenance actually covers
Maintenance is a vague word, and vagueness is why so many businesses pay for it without knowing what they get. In practice it is a defined set of recurring tasks, most of which are invisible when they are being done well and extremely visible when they are not.
The core of it is security and currency. Platform core, plugins, themes and server-side dependencies all release updates, and a meaningful share of those updates close known vulnerabilities. Applying them promptly, after checking them on a staging copy rather than gambling on the live site, is the single highest-value activity in the whole plan.
Around that sit the tasks that catch problems early. Off-site backups taken on a schedule, with restores tested rather than assumed. Uptime monitoring that alerts within minutes rather than when a customer emails. Performance monitoring, because sites slow down gradually and nobody notices from the inside. Broken link and error checks, since links rot as other sites change and a page returning an error can sit unnoticed for months. Form and checkout testing, because a form that silently stops delivering email is one of the most expensive faults there is and produces no visible symptom at all. Plus certificate expiry, domain renewal and database housekeeping, which are trivial to do and costly to forget.
- Core, plugin, theme and dependency updates, tested before they go live
- Off-site backups with restores actually tested, not assumed
- Uptime and performance monitoring with real alerting
- Broken link, error page and form delivery checks
- Certificate, domain and licence expiry tracked before they lapse
Why deferred maintenance compounds
Skipping maintenance does not create a steady, constant risk. It creates a growing one, because the individual problems interact.
Updates are the clearest example. Applying this month update to last month version is routine. Applying two years of updates at once is a project, because the gaps between versions have widened, extensions have made breaking changes, and the required server language version may have moved too. So the site sits on old versions, and the longer it sits the more expensive the eventual catch-up becomes, which makes deferring it again the easy decision every single month.
Security follows the same curve. Known vulnerabilities are published, and automated scanning finds unpatched sites without any interest in who owns them. The exposure window is not a fixed risk, it widens with every additional unpatched issue. Meanwhile performance drifts as content and scripts accumulate, small errors go unnoticed and become normal, and backups that were never tested turn out not to restore at exactly the moment they are needed. None of these are dramatic on their own. Together they turn a routine monthly task into an emergency rebuild, and emergency work is always the most expensive work you will ever buy.
- Update gaps widen, so catching up gets harder each month you wait
- Unpatched vulnerabilities accumulate, they do not sit still
- Untested backups tend to fail at the moment they are needed
- Small unnoticed errors become the accepted normal state
- Emergency work costs far more than the routine work it replaces
Response expectations and how to agree them
The most common source of frustration in maintenance agreements is not the work, it is the mismatch between what the client assumed about response times and what the agreement actually says.
The way to avoid it is to separate types of issue and agree a response for each. A site that is down or compromised needs immediate attention, including outside working hours if the business needs that. A broken form or checkout is urgent but usually within the working day. A visual bug or a small content change is a normal queued task. A new feature is not maintenance at all and should be quoted separately. Writing these categories down means nobody has to argue about severity while something is on fire.
Be equally clear about the difference between response and resolution. Responding within an hour means someone has acknowledged it and started work. It does not mean it is fixed, because some faults take longer to diagnose than to repair and some depend on a hosting provider or a third-party service you do not control. Also agree what counts as included: most plans carry a small allowance for minor fixes, and being explicit about where that allowance ends prevents the slow drift where an ever-growing amount of work is expected inside a fixed fee.
- Define severity levels and a response time for each
- Separate response time from resolution time, they are different promises
- Say clearly whether out-of-hours cover is included
- Set the small-fixes allowance and say where it ends
- Name who to contact and by which route, so nothing sits in an inbox
Maintenance is not improvement, and confusing them costs both
Maintenance keeps the site working as it does today. Improvement makes it do more or do it better. They need different budgets and different conversations, and blending them tends to mean neither happens properly.
The confusion usually appears as a slow expansion of the maintenance plan. New pages, campaign landing pages, redesigned sections and new features get requested inside a fee that was priced for patching and monitoring. The predictable result is that the improvement work is done in a rush and the maintenance work quietly slips, since it is the invisible half and nobody notices until something breaks.
The cleaner arrangement is a maintenance plan with a defined scope and a small fix allowance, plus improvement work quoted and scheduled separately. That gives improvement work the planning and testing it deserves, and it protects the routine tasks that prevent emergencies. A useful side effect is that the monthly maintenance report becomes a genuinely useful input into what should be improved next, because it shows where problems keep recurring rather than relying on whoever complained most recently.
- Keep maintenance scope separate from improvement work
- Quote and schedule improvements individually rather than absorbing them
- Protect routine tasks, they are the ones that get silently dropped
- Use recurring issues in the monthly report to prioritise improvements
- Review the arrangement annually as the site and business change
Backups and restores: the difference between having one and being able to use one
A backup is only worth what a restore produces. Plenty of businesses discover, at the worst possible time, that the backup was of the files but not the database, or that it ran nightly for two years and then failed silently eleven months ago.
A workable arrangement has a few properties. It is stored somewhere other than the server it is protecting, because a compromised or failed server takes its local backups with it. It includes both the files and the database, taken close enough together that they match. It keeps enough history to go back past the point where a problem started, which matters because a compromise or a data corruption is often discovered weeks after it began, and by then the recent backups have already copied the problem. And it is checked, so a failed backup job raises an alert instead of passing unnoticed.
The part that gets skipped is the practice restore. Restoring to a staging environment on a schedule proves the backup is complete, proves the process works, and tells you honestly how long a real recovery would take. That last number is worth knowing before you need it, because the difference between a two-hour recovery and a two-day one changes how the rest of the business plans around an outage.
- Store backups off the server they protect
- Capture files and database together so they stay consistent
- Keep enough history to go back before a problem started
- Alert on failed backup jobs rather than assuming they ran
- Restore to staging periodically and time it, so recovery time is known
Taking over a site somebody else built
Inheriting a site is normal and mostly routine, but it needs an honest baseline before anyone promises to keep it running. Taking on maintenance for a site nobody has reviewed is how an agency ends up responsible for problems it did not create and cannot fix within the fee.
The baseline review covers the state of the code and how far behind the platform and dependencies are, what plugins or extensions are installed and whether any are abandoned, whether the site shows signs of a previous compromise, what hosting it sits on and whether that hosting is adequate, whether backups and monitoring exist at all, and, importantly, whether you actually control every account: domain, hosting, DNS, certificates, CMS and any third-party services. Access sitting only with a previous supplier is a genuine business risk and is worth resolving before anything else.
Then be straightforward about what maintenance can and cannot achieve here. Some sites are healthy and simply need looking after. Others carry problems that no amount of patching will resolve, for example a heavily modified core that cannot be updated safely, or a theme that is no longer supported. In those cases the right answer is a plan and a cost for fixing the underlying problem, presented alongside the maintenance option, so the decision is yours and made with the facts.
- Audit code, dependencies, hosting and plugin health before committing
- Check for signs of a previous compromise
- Confirm you control domain, DNS, hosting and CMS accounts directly
- Fix urgent risks first, then start the routine plan
- Say plainly when a site has problems maintenance alone cannot solve
A clear path, step by step
- 01
Baseline
We audit the site, fix outstanding risks and document the setup before the plan starts.
- 02
Protect
Backups, monitoring and security hardening configured and verified.
- 03
Maintain
Scheduled updates tested and applied, issues fixed as monitoring surfaces them.
- 04
Report
A short monthly summary: what was updated, what was caught, what we recommend.
Why choose us for this
Updates tested before they touch your live site
We test restores, because an untested backup is a hope
Small fixes included, so you are not invoiced for ten minutes
Common questions
Why does a website need ongoing maintenance?
Because software ages. Plugins get vulnerabilities, platforms release patches, and unmaintained sites are exactly what automated attacks scan for. Regular small updates prevent the expensive emergency rebuild.
Do you maintain sites you did not build?
Yes, after a baseline audit. We review the code, plugins and hosting, fix anything urgent, and tell you plainly if the site has problems maintenance alone cannot solve.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase