Website Maintenance: What It Is and What It Costs

Website maintenance is sold as vigilance — "we'll keep an eye on it" — and bought as insurance, which is why it is so often argued about. It is neither. Maintenance is a calendar that other organisations set, and every date on it is published, which means you can price the work before you sign anything and check whether a quote is real.

This guide lists what is actually on that calendar, with the source for each date, and then the part that has no deadline and still costs money.

The runtime stops being supported on a known date

Whatever your site is built on has an end-of-life date that was decided years in advance by people who have never heard of your business.

PHP gives each branch four years: two of active support, then two of security fixes only. Its supported versions page publishes the table. As of September 2026, PHP 8.1 and everything below it is end of life, 8.2 and 8.3 receive security fixes only, and 8.2 leaves security support on 31 December 2026.

Node.js is shorter. Its release schedule gives an LTS line 30 months in total, recommends that production run only Active LTS or Maintenance LTS, and has already taken Node 20 to end of life in March 2026.

Both numbers are the same kind of fact: a version upgrade is due on a date you already know. That is the single largest line in a maintenance budget and the one most often left out, because nothing breaks on the day — you simply stop receiving fixes for the things that break later.

What skipping it looks like at scale

The best evidence that this is a real cost is what happens when nobody pays it. WordPress.org publishes the PHP version distribution of installations that check in with its update service. Read it against the PHP table above and the picture is stark:

• 38.7% of WordPress installations run a PHP version with no security support at all.
• 17.1% are still on PHP 7.4, which stopped receiving fixes in 2022.

Those sites work. They serve pages, take orders and look fine. What they do not do is receive patches, and the gap between "works" and "supported" is invisible until the day it is not. The same decay happens to custom applications through their dependencies; the difference is that nobody publishes the statistic, so it stays invisible for longer.

The CMS has its own clock, and one useful lever

If you run WordPress, plugin and core security releases are the recurring item. We covered the trade-offs of that stack in custom code vs WordPress, including the part that is genuinely in its favour: in July 2026, when a chained vulnerability in core allowed unauthenticated remote code execution, the project force-enabled automatic updates for affected versions. Sites nobody had logged into were patched by WordPress itself.

A bespoke application has less attack surface and no equivalent mechanism. If a serious flaw lands in one of its dependencies, the fix reaches you when someone reads the advisory, and it ships when someone deploys. Both models need maintenance; they need different maintenance, and a plan that does not say which one you are on is not a plan.

Certificates are about to get much more frequent

This is the item most maintenance quotes have not caught up with. The CA/Browser Forum's ballot SC081v3, which passed on 11 April 2025, sets a schedule reducing the maximum validity of public TLS certificates from 398 days to 47, with reductions starting in March 2026 and concluding in March 2029.

A yearly renewal can survive being someone's calendar reminder. A renewal every six or seven weeks cannot. If your certificate process today involves a person and an email, that process has an expiry date of its own, and replacing it with automated issuance is maintenance work that should be scheduled now rather than discovered during an outage.

Backups, and the test everyone skips

A backup that has never been restored is a belief, not a backup. The only version of this item worth paying for includes a restore performed on purpose, to a scratch environment, at a stated interval — and a note of how long it took, because that number is your actual recovery time.

Ask for the date of the last successful restore. The answer tells you more about a maintenance provider than the rest of the proposal.

The half with no deadline

Everything above is externally imposed and therefore estimable. The other half is not:

• Content and page changes the business asks for.
• Third-party integrations that change their API on their schedule.
• Analytics, consent and tracking, which move when regulations or vendors move.
• Performance regressions introduced by the site's own growth — a page that was fast with 40 products and is not with 4,000. Sometimes that is a fix and sometimes it is the argument for a rebuild. Our Core Web Vitals guide covers what to watch.

This half is where maintenance retainers go wrong in both directions: priced as unlimited, they become a queue nobody manages; priced as zero, every small change becomes a negotiation. The workable version states an included allowance and what happens above it.

What we do

We quote maintenance against the dates above rather than as a percentage of the build. That means the number changes depending on which runtime you are on and how far it is from end of life, which is the honest way round — a site on a branch with three years left genuinely costs less to keep alive than one with three months.

We also say when the answer is no maintenance plan. A brochure site on managed hosting, with no forms, no integrations and no CMS, does not need a monthly retainer; it needs someone to renew the domain and check it once a quarter. Selling that client a plan would be revenue rather than work. Our web development page sets out what we do include.

Five questions for any maintenance quote

1. Which runtime version are we on, and when is its end of life? If the answer is not a date, the quote has not been costed.
2. Who applies security updates, and within how long? "As needed" is not an answer; "within 72 hours of release" is.
3. When was a backup last restored, and how long did it take? Not taken. Restored.
4. How do certificates renew, and is it automated? With validity heading to 47 days, a manual process is a scheduled outage.
5. What counts as an included change? Get the allowance and the overage rate in writing, so neither side is arguing about a heading change in month four.

If you want a maintenance figure that maps onto published dates rather than a percentage someone picked, tell us what the site runs on and we will cost it against the calendar.