Start here: A website maintenance plan should define updates, recovery, customer-journey checks, content changes, support coverage, reporting, and ownership. Use the maintenance scope worksheet (CSV) (opens in a new tab) to compare what each provider actually includes.
A website maintenance plan should make the ongoing work understandable. It should say which parts of the website are covered, who keeps them current, how important functions are checked, and what happens when something breaks.
“Maintenance included” is not enough to compare proposals. One agreement may cover software updates. Another may include content changes and form checks. Both can be useful, but they create different expectations.
Start with the website you have and the business tasks it supports. Then use the comparison worksheet below to turn a general offer into a scope you can review.
Separate hosting, maintenance, and growth work
Hosting is the environment that serves the site. Maintenance is the agreed work to keep it usable and current. Growth work changes what the site says or does to support a business objective, such as introducing a service or improving an inquiry journey.
Providers may bundle those activities, so read the scope rather than relying on the plan's name. A hosting bill does not establish that somebody is checking your contact form. A maintenance agreement does not automatically include a new campaign or a redesigned service page.
Ask which tasks happen routinely and which begin only when you request them. You should also know what requires a separate estimate before work starts.
Match the tasks to the platform
A maintenance checklist should reflect how the website is built.
A self-managed content management system can involve software, extension, and theme updates alongside the site's content and database. For example, WordPress documents both its update process (opens in a new tab) and the need to account for files and database content in backups (opens in a new tab). A provider's agreement should explain which of those responsibilities it accepts.
A hosted website platform divides responsibility between the platform, the account owner, and any outside provider. Ask what the platform handles and what still depends on your account settings, connected tools, content, and access. Verify those boundaries for the particular service you use.
A custom or static site may have no editable database on the web server, yet still depend on source files, build tools, domain settings, forms, and external services. Its care plan should describe those dependencies rather than copying a list of WordPress tasks.
You do not need to become the technical operator. You do need an explanation of what is being maintained and why it matters to your business.
Website maintenance checklist: what happens when?
A plan needs a cadence as well as a task list. The schedule below is a starting point for an ordinary business website. Adjust it to the platform, how often content or data changes, and the consequences of an outage. A busy store and a largely static brochure site should not inherit identical schedules.
| When | Suggested work | What the business should be able to see |
|---|---|---|
| Ongoing automated monitoring, where included | Watch availability and relevant failures; route alerts to a named responder | What is monitored, alert destination, and coverage hours |
| According to acceptable data loss | Back up or export the changing data and assets needed for recovery | Backup scope, retention, and whether scheduled jobs succeeded |
| After a relevant release or configuration change | Test the affected customer journey, mobile layout, and receiving integration | Change record and a completed end-to-end check |
| Weekly review, or another agreed interval | Review failed jobs, urgent vendor notices, and pending support items | Open items with an owner and priority |
| Monthly | Check key forms and links, review updates, inspect business information, and report completed work | A concise care report with evidence and unresolved decisions |
| Quarterly, or after a material platform change | Rehearse recovery, review access and dependencies, and reassess the support scope | Recovery result and updated ownership record |
| Ahead of renewals | Confirm domain, hosting, licenses, and connected-service ownership | Renewal owner, due date, and expected action |
Do not wait for the monthly report to evaluate an urgent security notice or a failed contact form. Conversely, a monthly content review does not imply that every page needs to be rewritten each month. The work should follow a real change, failure, or business need.
For backups, start with a plain question: How much newly created information could we afford to lose? If requests or orders change throughout the day, a monthly copy will not meet a one-day tolerance. Also confirm how quickly recovery is expected, what can realistically be restored, and when the method was last tested. Those are separate decisions from how often a backup file is created.
Make recovery a specific responsibility
Ask what can be recovered if a change goes wrong or an account becomes unavailable. The answer may involve backups, version history, a previous deployment, an export, or a combination of methods.
Those mechanisms can cover different things. Restoring the website's design may not restore recent form submissions held by another service. A copy of source code may not include uploaded images or current business data.
Record who performs recovery, where the required material is kept, and when the process was last exercised. Ask what a recovery would omit and how the business would handle that gap.
The agreement should also distinguish normal maintenance from incident response. Do not assume emergency work or continuous availability is included unless the provider states it.
Check the functions customers actually use
List the website's important customer tasks: send an inquiry, call, book, request an estimate, view a service, or complete a purchase. Decide which checks belong in ongoing care and when they should occur.
A working homepage does not establish that every connected service is working. A booking link can lead to an outdated destination; a form can accept a request while its notification goes to the wrong person.
Where testing is included, agree on how it is done without creating unwanted bookings, orders, or messages. Clearly labeled tests should be coordinated with the people who receive them.
Ask what the provider records when a check fails. A useful note identifies the affected task, what was observed, who is handling it, and what remains unresolved.
Define content changes and support boundaries
“Small updates” can mean different things to different people. Use examples from your business: replacing an approved photograph, changing opening hours, adding a team biography, or creating a new service page.
Clarify who supplies the material, who approves it, and whether writing, image preparation, or layout changes are included. A change that seems small in words can affect several pages or an external integration.
Support timing needs similar precision. A response time describes when someone acknowledges or begins handling a request. It does not necessarily describe when the problem will be resolved. Ask how urgent issues are classified and what coverage exists outside the normal schedule.
Compare support promises using a realistic incident
Imagine the main contact form stops accepting requests on a Friday evening. “Support included” does not tell you what happens next. Ask each provider to walk through detection, acknowledgment, investigation, communication, and recovery.
| Term in a proposal | Clarification to request |
|---|---|
| 24/7 monitoring | Is only the automated check continuous, or is a person available to act outside business hours? |
| One-business-day response | When does the clock start, which time zone applies, and does response mean acknowledgment or active investigation? |
| Emergency support | Which failures qualify, how do you report one, and are additional fees possible? |
| Resolution target | What happens when the fix depends on a hosting, email, or booking provider? |
| Unlimited edits | Which changes qualify, what is the queue or capacity limit, and are new layouts or integrations excluded? |
These are comparison questions, not recommended universal service levels. Choose coverage based on what a broken website function would prevent your business from doing. If continuous response matters, have it stated and priced explicitly in the written agreement.
Copy this scope comparison worksheet
For each row, enter included, excluded, or separately scoped. Replace general assurances with a named responsibility and an observable check. The worksheet describes questions to ask; it is not a list of services automatically included in every care plan.
| Work area | Included or excluded? | Responsible party | Cadence or trigger | Verification |
|---|---|---|---|---|
| Domain and account renewals | Record the boundary | Name the account owner | Renewal dates | Renewal and access confirmed |
| Platform and software updates | List the covered components | Name the operator | Agreed schedule and urgent-change process | Change record and functional checks |
| Recovery | Identify covered files, content, and data | Name the recovery owner | Before relevant changes and at agreed intervals | Restore exercise or equivalent recovery check |
| Forms and booking paths | Name the journeys covered | Name the tester and receiving contact | Agreed interval and relevant releases | Labeled test reaches the intended destination |
| Content changes | Give examples and exclusions | Name the writer, editor, and approver | Request process | Approved change appears correctly |
| Performance and accessibility review | State the depth of review | Name the reviewer | Agreed scope | Findings and completed actions |
| Incident support | Define severity and availability | Name the responder | Incident process | Acknowledgment, updates, and resolution record |
| Reporting and handover | List required records | Name the provider and business contact | Review dates or end of agreement | Work history, access, and open issues transferred |
Compare promises with reporting
A care report should let you understand what happened. Useful entries describe changes made, checks performed, problems found, and decisions requiring your input.
Treat a report full of activity counts as a starting point for questions. “Updates completed” is more useful when you know which components changed and whether the customer journeys still work. A clean automated scan is not a guarantee of security, accessibility, or future availability.
Ask how unresolved issues are carried forward. If a task is excluded from the agreement, the report should make that boundary clear enough for you to decide whether to commission it separately.
What a useful monthly maintenance report looks like
The following is an illustrative report for an imaginary service website. It shows the level of specificity to request, not work performed for a client.
- Completed: Updated the approved team biography and replaced the outdated service PDF. Recorded the release and checked both pages on mobile.
- Customer journey checked: A labeled inquiry reached the stored-request system and the designated receiving inbox. The business contact confirmed receipt.
- Recovery checked: Restored the latest website backup in an isolated environment. Recent form records are held by a separate service and were outside that restore test.
- Issue still open: A booking provider displays an old cancellation message. The provider ticket is open; the account owner must approve the corrected wording.
- Decision requested: A proposed new service page requires copy and layout work beyond the existing content-change allowance. No additional work has started.
A report like this gives you something to review and helps prevent “everything is green” from hiding a gap between providers.
Decide what to handle internally and what to outsource
Internal maintenance can work when a named person has the access, time, and skill to complete the checklist and recover from a failed change. A shared reminder that “marketing handles the website” is less useful than an actual owner and backup contact.
An outside provider can take on defined technical or content responsibilities. Your business still supplies accurate service information, approves changes, and makes decisions about scope. Outsourcing does not remove those business responsibilities.
To compare website maintenance costs, ask each provider to price the same inventory and workload: platform, connected services, update responsibilities, recovery needs, expected content requests, and support coverage. A low base price with excluded recovery work may not cover the problem you are trying to solve. A larger plan may include work you do not need. The comparison is the total agreed responsibility, including any separate subscriptions and incident charges.
Revisit the plan when the site starts taking payments, receives sensitive information, adds a customer portal, or becomes a more important sales channel. Those changes can alter the operating needs even if the visual design barely changes.
Keep ownership clear from the start
Identify who controls the domain, hosting, content, connected accounts, and source files where applicable. Agree on how access is granted and how the site can be handed over if the relationship ends. Share credentials only through an appropriate secure process, not a public form or an ordinary planning document.
The right care arrangement is one you can explain: these are the systems covered, these are the tasks, these people are responsible, and this is how additional work is agreed.
If you are also considering a rebuild, the redesign preparation guide can help collect the information needed for that conversation. For the site you already have, discuss ongoing website care. At Cleland & Co., the included updates, request process, and additional-work boundaries are agreed in the written scope.
If the site works technically but inquiries remain weak, the website lead-diagnosis guide helps separate maintenance issues from offer and traffic problems.
