Website support vs maintenance: the difference, and why it's worth getting right

When a business commissions a new website — or a serious rebuild of an old one — the attention goes, understandably, to the visible part. The design. The messaging. The launch day. What gets far less attention is the question of what happens on day two, and every day after that.

Yet a website is not a brochure that gets printed once and filed. It is a live system, exposed to the internet, running on software that other people keep changing underneath it. From the moment it goes live it needs looking after — and "looking after" is two distinct jobs, not one: two of the four elements of website management, alongside hosting and content. We see the cost of blurring them often enough that it is worth setting out plainly. This is what we tell our own clients.

Two words, used as if they're one

"Support and maintenance" is almost always quoted as a single line item. Sometimes it is a flat monthly fee. Sometimes it is a pot of hours. Sometimes it is nothing at all, because nobody raised it. Whichever way it is sold, the phrase hides the fact that it describes two genuinely different kinds of work.

The simplest way to hold the distinction in your head: support is reactive, and maintenance is planned. Support is what happens when something breaks. Maintenance is the work you schedule so that fewer things break — and so the site keeps pace with a moving world. One is measured in response time. The other is measured in a forward plan. A business that understands which is which can check, in a sentence, whether it is actually buying both.

Support: keeping the site standing

Support is the ad-hoc, reactive work needed to keep a website running in the face of a breaking fault. A breaking fault is anything with immediate, visible consequences for the business: the site is down, the contact form is silently failing, the checkout will not take payment, a key page is throwing an error, the site has been defaced or compromised.

These are not problems you schedule. They are problems you respond to, and the number that matters most is how quickly. A good support arrangement is defined by a service-level agreement — an SLA — that sets out, in writing, how fast a fault of a given severity will be acknowledged and worked. A site-down incident on a Tuesday morning is not the same as a misaligned button, and the agreement should say so explicitly, with response times to match.

Support is also, by its nature, unpredictable. You cannot forecast when a hosting provider will have an outage, or when a third-party payment or booking integration will change something without warning. What you can do is decide in advance who picks up the phone, how fast they respond, and what counts as urgent. And once the immediate fire is out, there is often follow-up work to do — a proper, considered fix rather than the quick patch that simply restored service. That follow-up work is real, but it is not an emergency. It belongs in the other category.

Maintenance: keeping the site current

Maintenance is the scheduled work that keeps a website healthy, current and secure over time. It is not driven by something breaking today. It is driven by the fact that a website sits on a stack of software — a content management system, plugins or modules, a framework, a hosting environment, security certificates, analytics — and every layer of that stack is being updated, deprecated and patched by someone else, continuously.

Left alone, a website does not stay still; it slowly falls behind. Maintenance is the work that keeps it level: applying CMS and plugin updates, installing security patches, renewing certificates before they lapse, checking the site still renders correctly as browsers and devices move on, keeping page speed and Core Web Vitals in good order, fixing the non-breaking faults that are irritating but not urgent, and making the steady stream of small content and page changes the business actually needs.

The defining feature of maintenance is that it is planned. Updates are batched, tested on a staging copy of the site, and released on a known cadence — so the work is predictable, low-risk, and aligned with what the business is doing rather than dropped in at random. A non-breaking bug does not need a nine o'clock response. It needs a place in the queue.

Most of the security incidents we are called in to clean up were not sophisticated attacks. They were a known vulnerability in an out-of-date plugin — the kind of thing a maintenance schedule would have closed months earlier.

Why the distinction matters

Businesses understandably want both, so the two get ordered together and the terms start to be used interchangeably. As shorthand, that is harmless. It stops being harmless when it hides a gap.

The common failure looks like this. A business pays a monthly fee that it believes covers everything, and assumes the site is therefore being looked after. In practice the fee covers reactive support only — someone will answer when the site goes down — and no maintenance is actually happening. The CMS is three major versions behind. Plugins have not been touched in two years. Nobody has looked at page speed since launch. Nothing is "broken", so nothing is raised, and the site degrades quietly until the day it does break. At that point it becomes a support incident, billed as a fire — and very often a worse fault than steady maintenance would ever have allowed to develop.

The opposite gap is rarer, but real: a business buys a tidy maintenance retainer and discovers, the first time the site goes down hard on a Friday afternoon, that nothing in the arrangement commits anyone to a fast response.

Knowing which one you are buying — and confirming you are buying both — is most of the practical value of understanding the difference at all.

The trap of paying by the hour

A common way to sell ongoing website work is a simple hourly rate: something needs doing, you are billed for the time, you pay the invoice. It looks fair, and for genuinely occasional work it can be. As the standing arrangement for a website a business depends on, it tends to fail — for a few predictable reasons.

It quietly discourages maintenance. Every preventative task — the plugin update, the speed check, the security patch — now arrives as a discretionary invoice for work that fixes nothing visible. Faced with that, a busy finance director defers it, reasonably enough. The maintenance that does not happen is invisible, right up until it becomes a support incident that is not.

It makes good people hard to schedule. The developers best placed to look after your site are usually busy on larger, newer projects. Pulling someone off that work for an occasional two-hour ticket is disruptive in both directions — the new project loses momentum, and your job waits in a queue behind it. Ad-hoc hourly work is nobody's priority, because it is nobody's plan.

It underprices what a website actually needs to be looked after well. Doing this properly is not just a developer's billed time. It is a staging environment that mirrors production, uptime and performance monitoring, somewhere to test updates safely before they reach live visitors, security tooling, and someone keeping half an eye on the site between jobs. An hourly ticket prices the fix and ignores all of that — so either it is not in place, or it is being quietly absorbed by the supplier. Neither is a stable footing.

And it leaves the website without an owner. Paid by the ticket, a supplier responds to what you raise and no more. Nobody is watching the site as a whole — noticing the certificate that expires next month, or the framework heading for end-of-life next quarter. The website becomes a series of disconnected jobs rather than something being actively looked after by someone who knows it.

How we structure website care

We think website care should be planned, not improvised — and that the support and the maintenance should both be named, so you can see plainly that you are getting both.

In practice that means a clear SLA for support, with response times that match severity, so a genuine emergency is met as an emergency. It means maintenance on a defined cadence — updates and patches batched, tested on staging, released on a schedule, with a forward plan you can actually see. It means the environments, monitoring and tooling that proper care depends on are part of the arrangement rather than an afterthought. And it means one team holding the whole picture, so the work compounds over time instead of scattering into unconnected tickets.

For most of the established businesses we work with, that care sits inside a broader marketing retainer — alongside the SEO, the content and the campaigns — because a website that is well looked after technically is also the website your marketing is busy trying to send people to. For long, the two are not separable.

The point is not that hourly work is never appropriate. It is that a website your business genuinely relies on deserves better than to be looked after only in the moments it is already failing. Get the distinction right, make sure both halves are covered, and the site stops being a recurring surprise.

If you are not certain which of the two you are currently paying for — or you suspect the honest answer is "neither, really" — that is worth a conversation. Thirty minutes, no pitch deck: hello@ninestones.co.uk.