What website maintenance plans should include, and what they should not cost you

Website maintenance plans should cover the work that keeps a site correct after launch: updates, uptime and form checks, backups you can restore, small content changes, and a person who fixes things when they break. For a B2B site the most valuable part is usually the dullest one, checking that the contact form still reaches your CRM. What a plan should not cost you is money for work your site does not need, a contract you cannot leave, or a site you do not own.

Why a website needs maintenance after launch

A website looks finished on launch day, and for a few weeks it is. Then small things move underneath it. A framework ships a security patch. The marketing manager who set up the CRM connection leaves, and someone resets the API key. A domain renewal fails because the card on file expired. The site keeps loading through all of this, so no one looks.

The cost of that drift is rarely the fix itself, which is often an hour of work. It is the time between the break and the moment someone notices. For a B2B company the expensive version is a contact form that stops delivering: enquiries don't bounce with an error, they simply stop arriving, and it can take weeks before someone in sales asks why the pipeline went quiet. A maintenance plan exists to shorten that gap, and to give you one person who already knows how the site is put together when you need something changed.

What website maintenance plans should include

Plans vary a lot in what they call maintenance. These are the parts I would expect in any plan for a B2B site, roughly in order of how much damage they prevent.

• Form and integration checks: a test submission through every form on a schedule, confirming it lands in the CRM, inbox or database it is meant to reach. It is the cheapest check on the list and the one that protects revenue most directly.
• Uptime monitoring that requests the site every few minutes from outside and alerts a person when it fails. The alert should reach whoever will fix it, not only a shared inbox.
• Dependency and security updates. On WordPress that means core, theme and plugin updates; on a custom build it means framework and package updates, tried on a preview copy first so a broken update never reaches the live site.
• Backups of content, database and code, stored somewhere other than the server itself, plus an occasional test restore.
• An allowance for small changes, such as a new team member, a price update, a case study or a rewritten homepage paragraph. The plan should say how much time is included each month and what happens to time you don't use.
• A performance check. Google's Core Web Vitals give you three numbers to watch, and web.dev sets the good thresholds at a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less and a Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of page loads.
• Analytics checks, because tracking tags break after redesigns and cookie banner changes, and a month of missing conversion data is hard to get back.
• A short monthly note saying what ran, what broke, what was fixed and what is worth doing next.

Ask about backups in particular. A backup that has never been restored is a hope, and the question of when the last test restore happened tells you a lot about how a provider works.

A website maintenance checklist for every month and quarter

If you look after the site yourself, or want to see what a provider is really doing for the fee, this is the list I would run. Once it becomes a routine, the monthly part is short for a site of ten to twenty pages.

1. Submit every form with a test entry and confirm it arrives where it should, including any automatic reply to the sender.
2. Read the uptime history for the month, including short incidents. Three five-minute outages at the same hour usually have one cause.
3. Apply pending updates on a staging or preview copy, click through the main pages, then release.
4. Confirm the latest backup exists and has a plausible size.
5. Open Google Search Console and look at the page indexing and Core Web Vitals reports for new errors.
6. Compare form submissions recorded in analytics with what actually arrived in the CRM. When those two numbers drift apart, either the tracking or the form is broken.
7. Check that the SSL certificate renews automatically and the domain is set to auto-renew on a card that is still valid.
8. Read the homepage and main service pages as a buyer would. Old prices, people who left and products you no longer sell are maintenance problems too.

Every quarter, add a broken link scan, a test restore of a backup, and a review of who has admin access. That last one is the step teams skip. Admin accounts belonging to former staff or a previous agency tend to stay active for years, and removing them takes five minutes.

What a website care plan should not cost you

Most of the money wasted on maintenance isn't the monthly fee itself. It goes on things that look like service and aren't. These are the points I would push back on when comparing quotes:

• Work your site does not need. A static or framework-built site has no plugin stack, so a plan priced around weekly plugin updates is selling a WordPress routine to a site that has none.
• Automated reports presented as work. A monthly PDF of traffic charts produced by a tool is not maintenance. Ask what a person checked and what they fixed.
• Hosting bundled at a price you can't see. Bundling is fine when the cost is clear; it becomes a problem when you can't tell what the hosting costs or move it elsewhere.
• No access to your own site. You should own the domain, have admin rights on the hosting account and own the code repository. If ending the plan means losing the site, you are paying for lock-in.
• Vague change allowances. Unlimited small changes usually means someone else decides what counts as small, while a fixed amount of time per month with a log of how it was spent is easy to check.
• Long terms without a usable exit. A plan should have a notice period you can live with and a handover you could actually use.

Analytics managed services: the part most plans leave out

Many B2B websites now sit next to other systems that need the same care: a dashboard fed by the CRM, a monthly report that builds itself from the accounting package, an automation that posts a KPI alert to Teams or Slack. These drift for the same reasons a website does, and they are worse at telling you about it. An API changes version, a token expires, someone renames a column in the source system, or a new product line appears that the data model has never seen. The report still opens. It just shows numbers that are slightly off, and people stop trusting it without saying why.

Analytics managed services is the usual name for looking after that layer, and in a small company it doesn't have to be a large contract. The useful checks are short:

• Read the refresh history of every scheduled report and automation, and get an alert when one fails instead of discovering it in a meeting.
• Reconcile a few totals against the source each month (revenue, order count, lead count) so wrong figures get caught as well as failed jobs.
• Watch report speed. A report that opened in a few seconds at launch and now takes twenty usually has a model problem, and my guide on fixing a slow Power BI report covers the common causes.
• Adjust the data model when the business changes, rather than patching visuals one at a time.

If your website and your dashboards were built by different people, find out who owns each of these checks. The gap between them is where things go missing. The website collects the lead, the dashboard counts it, and neither provider checks that the two numbers agree. Whether the reporting is a live dashboard on your own data or an automated monthly pack, someone should be responsible for that match.

How website maintenance is priced, and how to compare quotes

I won't put a market price in this article. Published price ranges for maintenance plans tend to mix very different things, and a hobby blog on shared hosting ends up in the same survey as a B2B site with three integrations. What I can do is list what moves the fee, so you can compare quotes on the same basis:

• How much is covered: one site, or a site plus a client portal, three dashboards and two automations.
• How quickly you need a response, and whether that includes weekends.
• How much change time is included each month.
• How many external connections there are. Every CRM, payment provider or API is one more thing that can break.
• Whether the provider built the site. Taking over someone else's work costs more at the start, because the first weeks go on learning how it works and writing it down.

Say a 30-person engineering consultancy has a fifteen-page site, a contact form that feeds HubSpot, and a careers page the HR lead edits herself. A sensible plan for them covers form checks, uptime, updates, backups and a couple of hours of changes a month. They don't need a one-hour response at weekends, and paying for it would buy reassurance more than protection. A software company whose free-trial signup runs through its website carries a different risk, and paying for faster response there is reasonable.

When you compare two quotes, put them side by side with the rows above and fill in what each one commits to in writing. The cheaper quote often covers less than it first appears to. Sometimes the more expensive one includes hosting you were going to pay for anyway, which changes the comparison completely.

Do you need a website care plan at all?

Not always. If your site changes twice a year, has no integrations and someone in-house can run the checklist above, a plan may be buying peace of mind you could get from a free uptime monitor and a calendar reminder. Some developers also sell hours as you need them, which suits a quiet site well.

A plan makes more sense when the site produces leads you depend on, when it connects to other systems, or when no one on your team knows how it was built. It also makes sense when the same person can look after the dashboards and automations next to it, because then one person checks the numbers all the way from the form to the report. I run Intrinsiqq, a stock analysis platform I designed, built and run myself, so keeping scheduled data jobs alive is part of my own week as well.

For websites, dashboards and automations I build, I offer this as the Care plan: one monthly fee, quoted together with the project, covering the checks in this article and an agreed amount of change time. If the site itself still needs building, my page on B2B website design explains how I set sites up so there is less to maintain in the first place.

Frequently asked questions