Website maintenance: what should a support plan include?

A website maintenance plan should define four things: which systems are covered, what the supplier does routinely, how problems are handled and what evidence the owner receives. A promise of "updates and support" is too vague. It does not tell you whether anyone tests the enquiry form after a change, can restore a backup or will respond when the site goes down.

A good proposal does not need every possible task. It must separate technical maintenance, hosting, warranty work, content requests and development, allowing you to compare scope rather than monthly prices alone.

Maintenance, hosting, warranty and development are different

Hosting provides the environment in which the website runs. A warranty covers defects within the agreed delivery scope. Maintenance consists of recurring work after launch, while development introduces new functionality or larger changes.

An enquiry form may fail because of a defect present at handover. That could be warranty work. If it stops after an external provider changes its API, the issue may fall under maintenance or a separate request. Adding a CRM integration is development.

The proposal should make those boundaries explicit. Otherwise, the customer may expect unlimited changes while the supplier treats the plan as software updates only. Before maintenance begins, complete a website handover and access review.

Start with an inventory of the website

Maintenance cannot be estimated responsibly until everyone knows what must be maintained. A simple website with one form needs a different plan from a store with payments, warehouse synchronisation and transactional email.

The inventory should cover:

• the technology, CMS, framework, runtime version and dependencies,
• hosting, database, domain, DNS and SSL certificate,
• forms, transactional email, payments and integrations,
• analytics tools, advertising tags and consent management,
• admin accounts, the code repository and deployment process,
• licences, subscriptions and renewal dates,
• business-critical functions that need testing after a change.

Taking over a website from another supplier may require an entry audit. A monthly plan should not automatically absorb historic defects, undocumented modifications and expired licences. Document the starting condition and agree how the site will become maintainable.

An update is a process, not a click

Updates may affect the CMS, plugins, theme, libraries, runtime and hosting configuration. The NIST guide to enterprise patch management describes patching as identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades. OWASP also recommends an inventory of components, vulnerability monitoring and compatibility testing in its guidance on vulnerable and outdated components.

In practical terms, the update procedure should answer:

1. Who assesses the urgency and risk?
2. Is a current backup created before the change?
3. Which updates are tested in a non-production environment first?
4. Which business functions are checked after deployment?
5. When will the supplier roll back a change?
6. Where is the work recorded?

The official WordPress update documentation recommends making a backup first and describes restoring it if an update causes a problem. Automatic updates can be appropriate for part of the stack, but they do not replace testing the functions that matter to the individual business.

A backup needs to lead to a restore

The phrase "daily backup" does not prove the website can be recovered. Specify:

• whether files, the database, configuration and required assets are included,
• how often copies are created and how long versions are retained,
• where they are stored and whether a hosting failure could remove them too,
• who can access them and how they are protected,
• how often a test restore is performed,
• how much data the business can afford to lose and how quickly it needs service restored.

The WordPress backup handbook explains that restoring a typical installation requires both the files and the database. It also stresses regular backups and copies in different locations. The same practical principle applies to other technology: identify the complete recovery set and test the procedure before an incident.

Monitoring must result in an action

An automated alert does not repair a website. The proposal should identify what is monitored, who receives the alert and what happens next. Useful checks can cover:

• availability of important URLs,
• application errors and scheduled background jobs,
• domain and certificate expiry,
• forms, message delivery and enquiry confirmation,
• basket, payment and store integrations,
• unusual changes in performance or error volume,
• signs of a security incident.

Checking the homepage alone may miss a form that displays a success message but delivers no email. Critical journeys need their own checks. Our guide to website contact forms and better enquiries provides a useful test scope for lead-generation sites.

Response targets are not guaranteed repair times

An SLA, or a simpler support policy, should define the reporting channel, service hours, severity levels and initial response target. Response and resolution are different. A supplier can begin diagnosis quickly but may not control the hosting provider, payment gateway or an external API.

A useful incident classification might be:

• critical: the site or purchase process fails for every visitor,
• high: an important function fails but a workaround exists,
• standard: a defect does not block the main journey,
• change request: new content, a view or functionality to be planned.

The agreement should state who assigns severity, when the clock pauses and how escalation works. A claim of round-the-clock support is meaningful only when nights and weekends are genuinely staffed through a defined on-call process.

Security needs a plan for the full service life

Maintenance cannot guarantee that an attack will never occur. It should reduce exposure and define the response. The appropriate controls depend on the technology and data, but the plan should consider:

• account and permission reviews, including removal of unused access,
• monitoring vulnerabilities in the components being used,
• a process for urgent security updates,
• protection of admin accounts and multi-factor authentication,
• log storage and retention,
• people who must be notified when an incident is detected,
• isolation, recovery and verification steps.

Do not accept "website security" as an undefined line item. Ask for actions, responsibility and exclusions. The same applies to data protection because hosting, backups and monitoring may involve different providers.

Small changes need clear boundaries

A plan may include a time allowance for copy edits, blog publishing or image replacement. Define what counts as a small change, how requests are submitted, whether unused time carries forward and when a separate estimate is required.

Changing a phone number is not the same as adding a form field connected to a CRM. The second request affects validation, privacy, analytics, integration and testing. A new language version or payment method is also development, even if the admin interface presents it as one setting.

The owner should retain control

The business should know who owns the domain registration, hosting, repository, analytics accounts and licences. The maintenance agreement should specify:

• which accounts belong to the customer and which belong to the supplier,
• who pays for and renews external services,
• how access and documentation are transferred,
• what happens to backups and data when the relationship ends,
• how long handover to a new provider takes.

Lack of owner-level access is not a convenience. It is a risk that becomes visible when the supplier changes or a service fails.

What should the maintenance report show?

A concise report should list updates, test results, backup status, incidents, time used and open risks. The owner needs to know whether critical functions were checked and which decisions remain.

Ask ten questions before signing:

1. Which systems, accounts and integrations are covered?
2. What happens routinely and how often?
3. How are updates tested and rolled back?
4. What does the backup contain and when was recovery last tested?
5. Which journeys are monitored beyond the homepage?
6. How do I report an outage and when will someone first respond?
7. What counts as a fix, a small change or separate development?
8. Who pays for the domain, hosting, licences and tools?
9. What report will I receive and how is included time recorded?
10. How does termination and access handover work?

The supplier should also know how to communicate planned downtime. For a short full-site closure, Google recommends a 503 Service Unavailable response and an optional Retry-After header instead of returning a false success status or a 404. Its guidance on temporarily disabling a website explains the implementation and its search implications.

If you are commissioning a new website, agree the maintenance scope before handover. Review AMCompany services and selected projects. To assess an existing site or define a support plan, tell us about its technology, integrations and critical functions. That provides enough information to separate necessary safeguards from extras that do not justify their cost.