After launch, a website may need component updates, enquiry checks, recovery from an error or copy changes. The work depends on how it is built and used. Even if content rarely changes, the website still has code, hosting, a domain and connected services.
This guide helps you distinguish regular maintenance from individual changes and agree responsibilities. The tasks below form a discussion checklist, not a promise that every support service automatically includes them all.
First describe what needs maintaining
Prepare a brief website inventory: technology, hosting, domain, forms, email provider, external integrations and the agreed content update process. Identify the actions that are critical to the business and who would notice if they stopped working.
- Assign responsibility for component updates and data preservation if the website collects data.
- Clarify support for code, builds, publication and required external services.
- For booking, payment or customer accounts, describe checks for those journeys and their data separately.
- Keep the domain, hosting and paid services in a separate list of charges and renewals.
Paying for hosting does not establish who checks the enquiry form or changes content. List those duties separately, even if one supplier handles both the work and the bills.
Agree technical updates and the checks that follow
Identify who follows suppliers’ security fixes and version compatibility notices. Record the components covered by support, how updates are checked and how urgent notices are handled. A universal schedule says little without considering the underlying technology.
Confirm recovery is possible before a change. Check significant updates on a separate version of the site first where the infrastructure allows it. After publication, check agreed pages, forms and integrations and record the result. A major version upgrade requiring code changes may need a separate estimate.
Follow an enquiry through to receipt
A homepage loading successfully does not prove that the site receives enquiries. Agree a form test: open it on a phone, check fields and errors, submit test details and confirm that the responsible person receives the message. Include a visitor receipt or CRM in the checks where agreed.
Choose a recipient and label test enquiries so they are not treated as real leads. If a test fails, record the time, page and visible error. Do not paste customers’ personal details into public tasks or screenshots.
A schedule for manual checks and automated monitoring are separate arrangements. Specify which events are monitored, where alerts go and who responds to them.
Define what is backed up and how to restore it
A backup should cover important data, and its owner should know how to restore it and check its contents. The NCSC’s backup guidance also stresses these points.
For your website, list the code, images, database if present, and settings needed for recovery. A repository copy may omit files stored separately. Returning to a previous deployment does not necessarily restore data held by an external service.
- What is copied, where is it stored and who has access?
- How often is the copy updated, and which recent changes could be lost during recovery?
- How is restoration checked in a separate environment without overwriting live data?
- Who starts recovery, what do they check afterwards and how do they report the result?
Separate content changes from new functionality
| Request | What to agree | How to define the scope |
|---|---|---|
| Replace copy or a photo | Material, pages and language versions | Content change in an existing template |
| Add a service | Whether the current template fits | Content work or a separate structure task |
| Fix a form error | Expected behaviour and reproduction steps | Diagnosis and repair under the support terms |
| Add a calculator or payment | Logic, states, data and integrations | A separate development task with an estimate |
| Rework the entire site | New journeys, content and migration | A separate redesign project |
Calling something a small change does not establish the effort. Clarify who supplies copy, translations and images, how many pages change and how the result is accepted. New business logic needs its own agreement, even if it appears as a single button.
Keep account control with the business
Check who owns the domain, hosting, repository and email delivery account. Name a contact for billing and account recovery. Give the supplier the permissions required for the task through an individual invitation where supported, and agree how access will be revoked when the engagement ends.
A website address and a description of available access are enough for an initial assessment. Do not send passwords or secret keys through a public enquiry form. Agree a channel for sensitive information separately, and establish whether access to real enquiries is needed at all.
Agree tasks, timelines and evidence of completed work
Choose one request channel, a business contact and support working hours. Distinguish the first response, the start of work and resolution: they are different events. Dependencies on another provider or missing access should be visible in the task status.
- A task includes the page, current and desired behaviour, and material required for the change.
- The supplier confirms the scope, priority, timeline and payment arrangement before agreed work begins.
- Changes are shown for review first where the task calls for it.
- Completion comes with a brief report: what changed, what was checked and what remains unresolved.
Individual tasks suit occasional changes. An ongoing arrangement makes sense for recurring checks or a steady stream of updates. Specify included work, limits and how extra tasks are estimated; the word support does not imply an around-the-clock service.
Agree how support starts and how the site is handed over
Taking over an existing site may require an initial review of its code, access and main journeys. Record existing faults separately from future changes. Not every old problem can be included in routine work without an assessment.
When the engagement ends, the business needs the current version, a service inventory, task status and agreed recovery instructions. Terms for correcting defects in the original project should also be distinguished from ongoing maintenance. Our website support service describes the working format.
For broader structural changes, read when a website needs a redesign. To discuss maintenance, send XEVOR your website address and a list of tasks.
Frequently asked questions
Does a rarely updated website need maintenance?
It may need form checks, code updates, content changes and service oversight. Base the checklist on how the site is built and used; each task should relate to a real component or need.
Is a monthly fee compulsory?
The arrangement depends on the tasks. Occasional changes can be agreed individually, while recurring checks and updates can be planned for a defined period. Clarify which work and expenses the arrangement covers.
Does support include new features?
Only when explicitly included in the agreed scope. A calculator, booking journey or new integration usually needs a separate description, estimate and acceptance criteria.
How quickly will a problem be fixed?
Timing depends on the failure, access, external services and agreed working hours. Record response timing separately from the process for estimating a fix. Agree the specific terms before support begins.