The Cost to Maintain a Website Per Year, Over Three Years

The cost to maintain a website per year is not one number, and quoting it as one is how people end up surprised in year two. It is a set of recurring lines — hosting, the domain, certificates, CMS and plugin updates, security patching, dependency and runtime upgrades, content changes, analytics upkeep — plus an irregular one that dominates the total if you ignore the rest: the rebuild. Budget over three years rather than three months and the shape of the decision changes completely.

I have quoted a lot of websites, and the conversation I would rather have at the start is this one. A site is not a purchase. It is a subscription to its own continued existence, and the only real choice is whether you pay for it on a schedule or in emergencies.

What the cost to maintain a website per year actually covers

Here are the lines, roughly in order of how often people forget them.

Hosting, domain and certificates

The visible ones. Hosting scales with traffic and with what the site does — static pages are cheap to serve, a database-backed store under load is not. The domain renews annually and is the single cheapest item on this list and the most catastrophic to lose.

Certificates are usually invisible now, and that is the point: Let's Encrypt issues certificates at no charge with a ninety-day lifetime and expects automated renewal. Invisible until the automation breaks, at which point every visitor sees a browser warning. Whoever maintains the site should know where that renewal runs.

CMS, theme and plugin updates

If you are on WordPress, this is the largest recurring item and the one most often left undone. Updates are not optional housekeeping; the official hardening guidance starts with keeping core, themes and plugins current, because that is where the compromises come from.

The hidden cost is not the update button. It is the compatibility work when a plugin update conflicts with another one, and the day a plugin you depend on is abandoned and you have to replace something that touched every page. A site running twenty plugins has twenty independent update schedules and twenty independent abandonment risks. That is the real argument against plugin sprawl, and part of why we take a more conservative view of complex WordPress architectures than most — see the honest case against headless WordPress.

Runtime and dependency upgrades

This is the line almost nobody quotes and almost everybody eventually pays.

Whatever your site runs on has an end-of-life date that was published in advance. PHP maintains a supported versions table with dates for active support and security fixes; Node.js publishes its release and support schedule the same way. Your host will eventually retire the old version. Your framework's major releases will need migrating.

Do this in small steps and it is routine. Skip it for three years and it is a project, because by then you are not upgrading one thing, you are upgrading everything simultaneously and finding out which of your dependencies never made the jump.

Security, monitoring and backups

Three separate things that get bundled into one word.

Security patching is applying the updates above promptly, plus whatever sits in front of the site. Monitoring is knowing the site is down before a customer tells you, and knowing that the contact form stopped delivering — which, unlike downtime, produces no alarm at all and can run for months.

Backups only count if they have been restored. An untested backup is a belief, not a control. The question to ask whoever holds yours is not "do we have backups" but "when did you last restore one, and how far back does it go".

Content changes

Prices, staff, services, legal pages, the year in the footer. Small individually, constant in aggregate, and the work that actually keeps a site accurate.

The volume depends entirely on the site. Something like the multilingual product in the GeoTagImg case study, with hundreds of URLs across fifteen locales, has a content surface where a single wording change is fifteen edits. A ten-page brochure site does not. Scope your retainer to the site you have, not the one in the template.

Analytics, tracking and consent

Tracking degrades quietly. A tag gets removed during a template change, a conversion event stops firing after a form is edited, a consent banner update blocks the measurement it was meant to govern, or the analytics platform itself changes and the old configuration keeps reporting something that is no longer what you think it is.

Nobody notices, because the dashboard still shows numbers. Budget a periodic check that the conversions you are counting are the ones that happened.

Performance upkeep

Sites get slower without anyone doing anything wrong. Images get added at full resolution, a third party adds a script, a plugin loads on every page to serve one. Google publishes the Core Web Vitals thresholds openly, so this is measurable rather than a matter of opinion — and the measurement is worth repeating on a schedule, for the reasons I set out in do Core Web Vitals affect rankings.

Three years, not three months

Here is why the annual framing misleads. Year one after launch is usually the quietest: everything is current, the content is fresh, the dependencies were new when they went in. Year two, updates start conflicting and the content has drifted. Year three is where the deferred work lands all at once — the runtime is out of support, a couple of plugins are unmaintained, the design looks its age, and someone proposes a redesign.

That redesign is the largest number in the three-year total, and how big it is depends almost entirely on what happened in years one and two. A site that received continuous small improvements usually needs a refresh. A site that received nothing usually needs a replacement, because there is no incremental path from where it is to where it needs to be.

So the honest comparison is not "maintenance versus no maintenance". It is "maintenance, or the same money later as a rebuild, with a worse site in between".

What "we'll just fix it when it breaks" really costs

It is a real strategy and I understand why people choose it. These are the costs it carries, none of which appear on an invoice as such.

Emergency pricing. Unscheduled work interrupts other work. It is priced accordingly, by everyone, including us.

Worse outcomes. Fixing a compromised or broken site under time pressure, without a tested backup and with dependencies several versions behind, produces worse decisions than the same work planned.

Downtime. The part that costs most and gets counted least. If the site takes enquiries or orders, multiply what it earns in a day by however long recovery takes. That figure is usually larger than a year of maintenance, and it is your figure, not an industry one.

Compounding. Deferred updates are not neutral while you wait. Each one you skip makes the next harder, because you are eventually jumping several major versions at once.

The forced rebuild. The end state of long neglect is not a big repair bill. It is being told the site cannot be updated and has to be replaced, which is how a maintenance decision turns into a capital one.

What a maintenance retainer should actually include

If you are being offered one, it should say all of this in writing. If it does not, you are buying reassurance rather than maintenance.

Two clauses are worth arguing about specifically. First, updates should be applied to a staging copy before production on anything that takes money or enquiries. Second, the change allowance should say whether it rolls over, because a retainer with no rollover and no monthly report is indistinguishable from a subscription to nothing.

A worked example, with your figures

I am not going to publish typical costs, because a typical cost across sites this different would be a made-up number and you would budget against it. Build your own instead. It takes an afternoon and it is the only version that is true for you.

List every recurring item you already pay for: hosting, domain, CDN, email, form handling, transactional email, search, any paid plugin or app subscription, error monitoring. Add the support arrangement you have, or a realistic figure for the work you currently do yourself. Multiply by three.

Then add two things most people leave out. One: a realistic allowance in year two or three for a runtime or major framework upgrade, because the dates for those are published and you can look yours up today. Two: the redesign, scheduled where you honestly think it will fall.

The total is your three-year cost of ownership. Compare that against the quotes you are weighing, and you will often find the sites that were cheapest to build are the ones that put the largest number in year three — which is the same reason a fast, cheap build deserves more scrutiny than it usually gets, as I have argued about AI website builders versus professional development.

The rule I would use

Decide up front whether this site earns anything. If it does, maintenance is an operating cost and you should fund it like one, at whatever level keeps it current and measured. If it genuinely does not earn anything, keep it small, keep it static, keep the dependency count near zero, and accept that you are choosing a rebuild later — deliberately, rather than by surprise.

What I would avoid is the middle: a complex site with an ambitious feature set and no arrangement to look after it. That combination produces the three-year bill people remember, and it is the one thing on this page that is entirely avoidable.

If you want the same exercise applied to a build rather than a running site, the line items are laid out in what custom software actually costs. And if you would rather someone else held the schedule, that is what our web design and development and WordPress work is set up to do.