Article URL Copied to Clipboard!
Home Blog Web Development What a Website Maintenance Plan Should I...
Web Development

What a Website Maintenance Plan Should Include (and What to Question)

Most businesses pay for website maintenance without ever seeing what they are paying for. The invoice says "monthly maintenance", the site stays up, and nobody asks questions until the day...

codesalen
codesalen
September 30th 2026 • 9 mins, 1723 words
What a Website Maintenance Plan Should Include (and What to Question)

Most businesses pay for website maintenance without ever seeing what they are paying for. The invoice says "monthly maintenance", the site stays up, and nobody asks questions until the day a plugin update breaks the contact form or the host suspends the account for malware. A good website maintenance plan is not a vague retainer. It is a short list of specific jobs, done on a schedule, with proof that they were done.

This guide covers what those jobs are, how to tell a real plan from a padded one, and when you may not need a plan at all.

The four jobs maintenance covers

Strip away the packaging and every maintenance arrangement does some mix of four things:

  1. Keep it running. Someone notices when the site goes down, the SSL certificate expires or the domain is about to lapse, and fixes it before customers notice.
  2. Keep it safe. Software is patched, logins are protected, and old accounts and unused plugins are removed.
  3. Keep it recoverable. If the worst happens, there is a recent, working copy of the site and its data somewhere else.
  4. Keep it current. Small content changes, new pages, and the slow drift of browsers, hosting and third-party services are handled as they come.

When you read a quote, map every line item to one of these. Anything that does not fit is either an extra you may not need or a vague promise you should ask about.

What a website maintenance plan should include

These are the items we would expect in any plan for a business site that takes inquiries, bookings or orders. The details change with the platform. The list does not change much.

Updates, including the ones nobody sees

Everyone thinks of plugin and theme updates. Fewer people think about the layer underneath: the PHP or Node.js version on the server, the database, the framework the site is built on. These have end-of-life dates too. PHP, for example, gives each release branch two years of active support and then two more years of security fixes only, according to the official PHP supported versions page. At the time of writing, PHP 8.2 receives security fixes only until December 31, 2026. A site still running 8.2 needs an upgrade plan now, not in January.

Ask how updates are applied. The answer you want: tested on a staging copy first, then applied to the live site, with a backup taken just before. "We update everything automatically" is fine for low-risk items, but not for the plugin that runs your checkout. Since version 5.5, WordPress has let administrators opt in to automatic updates plugin by plugin and theme by theme, which is useful precisely because you can choose which ones are safe to automate and which need a human to test them.

Backups you have actually restored

A backup that has never been restored is a hope, not a backup. The US Cybersecurity and Infrastructure Security Agency's guidance on backing up business data uses the 3-2-1 rule: three copies of important files, on two different types of storage, with one copy kept off-site. It also recommends testing that you can restore data both fully and partially, and that you can roll back at least seven days.

For a website, that turns into three questions for your provider:

  • Where are the backups stored? If the only copy sits on the same server as the site, one server failure or one hacked hosting account takes out both.
  • How far back can you go? Malware often sits unnoticed for weeks, so yesterday's backup may already be infected.
  • When did you last do a test restore, and how long did it take?

Monitoring and a named response time

Uptime monitoring is cheap, and every plan should include it. What matters more is what happens after the alert. A plan should say who responds, within what time, and what counts as an emergency. "Site down" and "checkout broken" are emergencies. "Change the photo on the About page" is not. If the plan does not separate the two, you will either pay for urgency you do not need or wait two days while your forms quietly fail.

Security basics

For most small sites this does not need to be elaborate: strong passwords and two-factor login for admin accounts, removal of former staff and old agency accounts, a regular malware scan, a web application firewall in front of the site, and a check that forms are not being abused for spam. If you handle payments, health information or large customer lists, a maintenance plan is not enough on its own, and a dedicated security review is worth budgeting for separately.

Functional checks after every change

Many site failures are not outages. The page loads, but the inquiry form stopped sending email three weeks ago, or the payment step throws an error on one browser. A good plan includes a short scripted check after each update: submit the contact form, place a test order, log in as a customer. It takes minutes and catches the failures that uptime monitoring cannot see.

Red flags in a maintenance quote

Most weak plans are not dishonest. They are vague, and vagueness usually works in the seller's favor. Watch for these:

  • "Unlimited changes." Nothing is unlimited. Ask what happens in a month when you request forty hours of work. There is usually a fair-use limit somewhere; you want it written down.
  • No monthly report. You should get a short summary each month: what was updated, backup status, uptime, incidents, hours used. If you cannot see the work, you cannot judge it.
  • They hold the keys. The domain, hosting account and admin logins should be in your name, with the provider added as a user. If the provider owns the hosting account and you part ways, getting your own site back can turn into a negotiation. Our checklist for code ownership and handovers covers what you should hold at all times.
  • Updates straight to live. Acceptable for a five-page brochure site. Risky for anything with a checkout, a booking system or custom code.
  • Security described only in adjectives. "Fully secured" and "hack-proof" mean nothing. Ask which specific measures are in place and how you would know if one failed.

Estimating what your site needs

Say you run a small accounting practice with a 25-page WordPress site, 14 plugins, a consultation-request form that emails reception, and a blog you update twice a month. The monthly effort breaks down roughly like this:

  • Plugin, theme and core updates, tested on staging first: 1.5 to 2 hours
  • Backup checks, plus one test restore per quarter (averaged out): about 0.5 hours
  • Post-update checks on the consultation form and key pages: 0.5 hours
  • Security review, spam cleanup and user account review: 0.5 hours
  • Two blog posts uploaded and formatted, plus small text changes: 1 to 2 hours

That is about 4 to 5.5 hours a month, plus hosting and monitoring tools, which are usually billed separately. Multiply by the hourly rate of whoever does the work. As a rough market range, offshore teams often charge somewhere around $20 to $50 an hour, while agencies in the US, UK or Australia often charge $100 to $200 or more. So the same site could reasonably cost anywhere from about $100 to $1,100 a month, depending on who maintains it and how much content work is included. These ranges vary a lot by region, team and scope. The method is the useful part, not the number.

Now change one thing: make it an online store with 300 products and card payments. Updates get riskier, the checkout needs testing after every change, and a broken payment step costs real money every hour it stays broken. Effort might double, and response time starts to matter more than price. That is why one "standard plan" price across every kind of site rarely makes sense. If you are still at the build stage, our guide to what you pay for when a website is built explains how the platform choice shapes these running costs.

When you may not need a plan at all

Plenty of sites do not need a monthly website maintenance plan, and it is worth saying so.

  • If your site runs on a hosted builder such as Shopify, Squarespace or Wix, the platform looks after the servers and the core software. You still own your content, apps and settings, but the heavy lifting is theirs. Occasional help by the hour is often enough.
  • If you have a simple static site with no plugins, no database and a form handled by a third-party service, there is very little to update. A quarterly check and a reminder before the domain renews may cover it.
  • If someone in-house is comfortable running updates and you just want a safety net, a smaller plan covering backups, monitoring and emergency response can replace a full one.

A plan earns its cost in the middle ground: sites built on WordPress or a custom framework that take bookings, payments or leads, where nobody on staff has the time to test updates properly.

What to get in writing

Before you sign, make sure the agreement answers these in plain language:

  1. What is included each month, listed as tasks rather than adjectives.
  2. How many hours of changes are included, and the rate for extra hours.
  3. Response times for emergencies versus normal requests, and how you report each.
  4. Where backups live, how long they are kept, and how often restores are tested.
  5. What the monthly report contains.
  6. Who owns the domain, hosting, code and logins, and what the handover looks like if you end the arrangement.
  7. How platform upgrades, such as a PHP version change or a major framework update, are handled and priced, since they are bigger jobs than routine updates.

A provider that answers all seven clearly usually does the work properly. One that struggles with them is telling you something too.

The simplest next step: pull up your current website maintenance plan, or the quote you are weighing, and check it against the lists above. Log in to your domain registrar and hosting account and confirm both are in your name. Then ask your provider for a test restore. How they respond to that one request will tell you a lot.

Our website management team can also review your current setup and tell you what it needs, including when a lighter arrangement, or no plan at all, would do the job.

Author

codesalen

Senior Software Architect & Solutions Lead

Passionate about enterprise web systems, high-scale cloud infrastructure, and modern AI engineering. Leading technical innovations at Codesalen.

💬 Comments (0)

Be the first to share your thoughts on this article!

Leave a Comment

Share this article:
Need Help? Ask CodeSalen AI Online ×

CodeSalen AI

Active • Solutions Advisor
Call Solutions Lead

Search CodeSalen