A website maintenance plan should answer one practical question: when something changes, breaks or quietly stops working, who notices, who fixes it and what exactly have you already paid for?
That sounds obvious, but many maintenance proposals are sold as a list of reassuring words: updates, backups, security, support. Two plans can use the same words and provide very different protection.
Before you pay, compare the operating responsibility behind the package, not the length of the feature list.
TL;DR: what a useful maintenance plan should define
For a business website, I would want the agreement to make these areas clear:
| Area | What you should be able to answer |
|---|---|
| Monitoring | What is checked automatically or manually, and how often? |
| Backups | Where are backups stored, how long are they kept and who restores them? |
| Updates | Which platform, plugins, dependencies or integrations are covered? |
| Critical journeys | Are forms, bookings, checkout or login flows tested where relevant? |
| Support | What counts as urgent, and what response time applies? |
| Small changes | Are text/image edits included, capped or separately billed? |
| Ownership | Who owns the domain, hosting/deployment, analytics and core accounts? |
| Exclusions | What requires a separate quote? |
If a proposal cannot answer those questions, the monthly price alone tells you very little.
1. Start with what the website actually does for the business
A five-page brochure site and a booking platform should not have identical maintenance plans.
List the jobs the website performs before comparing providers. That may include:
- generating enquiries;
- accepting bookings or applications;
- taking payments;
- publishing content;
- collecting newsletter subscribers;
- serving customer accounts;
- connecting to a CRM or other business system.
Then ask what failure would hurt most.
If the website’s main job is generating leads, a broken contact form can matter more than a slightly outdated footer. If it takes payments, checkout and payment confirmation deserve more attention than routine visual edits.
Maintenance should follow business risk, not a generic checklist copied from another website.
2. Ask what “monitoring” actually means
“Website monitoring” can mean anything from checking whether the homepage returns a response to actively watching important application behaviour.
Ask what is monitored and what happens after an alert.
For a simple marketing site, uptime and obvious error monitoring may be enough. For a site with forms, bookings, logins or payments, availability alone is weak evidence. A homepage can be online while the part that makes money is broken.
A stronger plan identifies the critical journeys and decides how they will be tested.
For example:
visitor → service page → enquiry form → stored lead → notification → response
or:
customer → product → checkout → payment confirmation → order record
You do not need enterprise observability for every small website. You do need clarity about what “working” means.
3. Backups should include a restoration responsibility
“Daily backups included” sounds good, but the useful question is whether the site can actually be restored when needed.
Ask:
- what is backed up;
- where the backup is stored;
- whether it is independent of the live system;
- how long versions are retained;
- who initiates a restore;
- whether restoration is included in the plan;
- how the provider knows a backup is usable.
A backup is a recovery mechanism, not a decorative checkbox.
This matters especially when a website has a database, user uploads, orders or frequently changing content. Restoring only the code may not restore the business state.
4. Separate routine updates from new development
One of the biggest sources of maintenance disputes is the word update.
A provider may mean software updates. A client may mean, “add a new services page, redesign the homepage and connect a new booking system.”
Those are different scopes.
A good agreement should distinguish at least three kinds of work:
- Routine maintenance: platform/dependency updates, monitoring, backups and small fixes.
- Content changes: replacing text, images, staff details, opening hours or similar existing content.
- New development: new pages, integrations, features, redesigns or workflow changes.
You can bundle some of these together. The important thing is that both sides know where the boundary is before a request arrives.
If you are still deciding whether your site needs maintenance, a redesign or deeper replacement, my website redesign vs rebuild guide separates those decisions.
5. Make critical forms and integrations part of the conversation
A website can look healthy while quietly losing business.
Contact forms are a good example. The visitor can see “Sent” even though the notification never reaches the business. I recently wrote a separate guide on tracing a contact form that says sent but delivers no email.
The same principle applies to booking providers, payment gateways, maps, analytics, email tools and third-party APIs.
Ask which integrations the maintenance provider is responsible for testing and which are considered third-party issues outside the plan.
A sensible provider does not need to promise control over another company’s platform. They should, however, be able to define what they will diagnose, what they will escalate and when additional work becomes billable.
6. Define response time, not just “support included”
Support without a response expectation is difficult to value.
Ask how the plan handles:
- the whole website being unavailable;
- a payment or booking flow failing;
- a lead form failing;
- a minor visual bug;
- a normal content-change request.
These should not necessarily have the same priority.
Also distinguish response time from resolution time. A provider can promise to investigate a critical problem quickly without pretending every third-party outage or complex bug can be resolved within the same fixed period.
That is a more credible service agreement than “24/7 support” with no definition behind it.
7. Keep ownership of the accounts that matter
Maintenance is management, not a transfer of business ownership.
The business should normally retain control of core assets such as:
- the domain registrar account;
- hosting or deployment ownership;
- analytics and Search Console;
- primary CMS/admin ownership;
- payment-provider ownership;
- important email or CRM accounts;
- source-code repository ownership when custom code is part of the website.
The provider can receive the access needed to do the work.
This makes handoff easier if the relationship ends and reduces the risk of discovering later that the website depends on an account only the former provider controls.
The same principle matters when hiring someone for a new build. My guide to choosing a web designer covers the ownership questions worth settling before payment.
8. Ask for the exclusions in writing
A maintenance plan becomes easier to compare when you know what it does not include.
Common items that may reasonably sit outside routine maintenance include:
- major redesigns;
- new functionality;
- copywriting and content production;
- ongoing SEO strategy;
- paid advertising;
- third-party subscription fees;
- large data migrations;
- emergency recovery from a problem that existed before the maintenance relationship began.
There is nothing wrong with exclusions. Hidden assumptions are the problem.
A cheaper plan with a precise boundary can be better value than an “unlimited” plan whose important work is later classified as extra.
9. Compare maintenance plans by risk, not by the number of tasks
Imagine two proposals.
Plan A lists 25 routine tasks but says nothing about response times, restoration or form failures.
Plan B lists 10 responsibilities, identifies the website’s lead form as business-critical, keeps recoverable backups, defines an urgent-response path and gives the business ownership of every core account.
For a lead-generation business, Plan B may be the more mature service even with the shorter feature list.
That is the standard I would use: does the maintenance arrangement preserve the business outcome the website exists to create?
When monthly maintenance may not be necessary
Not every business needs a retainer.
A simple static website that changes twice a year, has few dependencies and is owned by someone comfortable handling basic checks may be better served by occasional paid support.
A monthly plan becomes easier to justify when:
- the website directly generates revenue or enquiries;
- several systems have to keep working together;
- content changes frequently;
- downtime has a meaningful cost;
- nobody inside the business owns technical upkeep;
- the business needs predictable response when something fails.
If your main question is price rather than scope, see my existing small-business website maintenance cost guide. This article deliberately answers a different question: what should you make sure you are buying?
If you want your current website assessed before choosing between occasional repairs, ongoing maintenance or a redesign, see my web design service or contact me.
