What website maintenance actually covers
“Maintenance” is a vague word covering a wide range of arrangements. At one end it means a monthly plugin update and a backup. At the other it means a team that owns your site: shipping changes, watching performance, and treating the website as a working part of marketing rather than an asset that was delivered once.
The distinction matters commercially, because the two are priced very differently and buyers routinely compare them as though they were the same purchase.
The three things a plan should always include
Security and dependency updates. Every site accumulates risk. Frameworks release patches, plugins go unmaintained, certificates expire, and access lists drift as people leave. The work is unglamorous and the cost of skipping it is not linear: nothing happens for months, then everything happens at once. Updates belong on a schedule, tested before production, not applied reactively after an incident.
Monitoring you do not have to think about. If you learn the site is down because a customer emailed you, you do not have monitoring. Availability checks, error-rate tracking, and log review turn outages into alerts. This is the cheapest part of any maintenance arrangement and the most commonly missing.
Change capacity. This is what buyers feel week to week. A landing page for a campaign, a copy correction, a tracking change, a form that needs another field. With no plan in place these queue behind whoever built the site, and marketing ends up moving at the speed of somebody else’s backlog.
What separates a plan from a support contract
A support contract is reactive: something breaks, you raise a ticket, it gets fixed. A maintenance plan is capacity: a predictable amount of engineering attention each month, spent on whatever most needs it.
The practical test is whether proactive work happens. If nobody is watching Core Web Vitals, checking for broken redirects, or clearing the tag-manager sprawl that accumulates on every live site, you have a support contract regardless of what the invoice says.
How much website maintenance should cost
Pricing ranges from roughly $50 a month to several thousand, and the spread is wide because the products are genuinely different.
Under $200 a month generally buys automated updates and backups, usually on WordPress, with no human attention unless you raise a ticket. Appropriate for a brochure site that rarely changes.
$500 to $1,500 a month buys that plus a few hours of human time. Reasonable for a small site with occasional changes, though those hours are often consumed by the update work itself.
$4,000 to $6,000 a month, where our plans sit, buys ongoing engineering capacity: the security and monitoring baseline, and then the substantive work. New pages, campaign landing pages, performance, tracking, technical SEO implementation, and infrastructure changes. It makes sense when the website is a working sales asset and marketing needs to ship without raising a ticket.
Work backwards from change frequency. If you need something on the site most weeks, capacity pricing is cheaper than paying project rates per request. If you change the site twice a year, it is not.
When a maintenance plan is the wrong purchase
We would rather say this upfront than discover it three months in.
If the site genuinely does not change and has no marketing function, a low-cost automated plan fits better, and we will say so. If you are about to replace the site, maintaining the old one is usually wasted spend and the real conversation is about the rebuild. And if the problem is that the site does not generate leads, maintenance alone will not fix it: that is a positioning, content, and conversion problem which maintenance supports rather than replaces.
Taking over a site somebody else built
Most sites we maintain, we did not build. That is normal, and worth explaining, because the fear that nobody else will understand the codebase keeps a lot of companies tied to an agency they have outgrown.
We start with an audit: what the site runs on, the state of its dependencies, how it is hosted, what tracking exists, and what is likely to break. That produces two things. An honest assessment of whether the site is worth maintaining or worth rebuilding, and a documented picture of the system so the knowledge stops living in one person’s head.
Handover is rarely as hard as people expect. The difficulty is almost never the code, it is missing access: hosting credentials, DNS control, analytics ownership, repository access. Those are worth collecting before you need them, whoever maintains your site.