A launched website is the beginning of the work
Launch day feels like the end of a website project. For the site itself, it is the first day of a long working life. Software underneath it will receive security updates. A certificate will come up for renewal. A form will quietly stop delivering enquiries because an email setting changed. Someone will leave the company holding the only password to the domain.
None of this is dramatic, and all of it is preventable. The difficulty is that each task is small and belongs to nobody by default. This guide sets out the jobs, suggests who usually does each one and gives you a table to fill in with your own names.
The seven jobs of website maintenance
| Job | What it involves | Usually done by |
|---|---|---|
| Domain and hosting | Renewals, billing, DNS records, certificates | Your organization holds the accounts. A technical partner may manage them |
| Software updates | The CMS, plugins, frameworks and server software | Technical partner or in-house developer |
| Backups | Regular copies of files and database, and test restores | Hosting provider or technical partner |
| Security | Access control, sign-in protection, scanning, response to incidents | Shared: partner for the technical side, you for accounts and staff |
| Content | Keeping pages, prices, team, legal text and news current | Your marketing or communications team |
| Forms and integrations | Checking that enquiries, CRM sync, payments and analytics still work | Shared: you test, the partner fixes |
| Monitoring | Uptime, errors, speed and search visibility | Technical partner, with reports to you |
The middle column is the scope of a maintenance agreement. If a proposal for support does not say which of these lines it covers, ask before signing.
What your organization should always hold itself
Some things should stay in your hands whoever does the daily work, because losing them means losing control of the site.
- The domain registration. Registered to the organization, on a shared company email address, with renewal reminders going to more than one person.
- The hosting or platform account. Your account, your billing details, with the partner added as a user who can be removed.
- Administrator access to the CMS. At least two people inside the organization, each with their own sign-in.
- Analytics, search and advertising accounts. Created by you and shared with others, never the reverse.
- A current copy of the code and content. Access to the repository, plus knowledge of where backups are kept.
- A written list of all of the above. Stored where it will survive a change of staff.
Ownership and licensing terms are defined in the project agreement, and that is the place to confirm what you receive for themes, custom code and licensed components.
A rhythm for the routine work
Frequencies depend on how the site is built and how much it matters to the business. A hosted builder removes most of the technical lines. A self-hosted system with many plugins needs the most attention. Use this as a starting pattern and adjust it with whoever maintains the site.
- 01
Continuously, by machine
Uptime checks, error alerts and backups should run without anyone remembering them. A person needs to receive the alerts and know what to do.
- 02
Weekly or with each release
Apply security updates for the CMS and its extensions, on a test copy first where the site is complex. Glance at the error log.
- 03
Monthly
Send a test enquiry through every form and confirm it arrives. Review speed and search reports. Check that content with dates is still current.
- 04
Quarterly
Restore a backup to a test location. Review who has access and remove people who have left. Check upcoming renewals.
- 05
Yearly
Review the whole site for outdated content, broken links, accessibility and legal text. Decide what to improve in the coming year.
A worked example
A manufacturer's website, one year after launch
This example is invented to show what an agreed table prevents. A manufacturer launches a new website and, at the agency's suggestion, fills in a responsibility table before going live.
- Before launchThe domain turns out to be registered in the name of a former employee. It is transferred to a company account, and two directors are added as contacts.
- Month twoThe monthly form test finds that distributor enquiries have stopped arriving since a change to the company's email system. It is fixed the same day. Without the test, nobody would have known.
- Month fiveA security update for the CMS is released. The agency applies it on a test copy, checks the product pages and deploys it that week under the support agreement.
- Month nineThe marketing manager leaves. Her access is removed at the quarterly review, and her replacement receives a sign-in and the written list of accounts.
Nothing remarkable happened to this website in its first year, which is the outcome good maintenance aims for. Each of the four events would have become a real problem without a named owner.
What to look for in a support agreement
A clear agreement
- Lists the jobs covered, line by line
- States how to report a problem and how soon you will hear back
- Separates routine maintenance from new work
- Includes test restores of backups
- Gives you a regular written report
- Says how either side can end it, and what is handed over
A vague one
- Promises support without saying for what
- No response times of any kind
- Updates applied straight to the live site
- Backups mentioned, restores never tested
- You only hear from the provider when the invoice arrives
Our software maintenance and support page describes how we structure this for the products we look after.
Checklist to complete before launch
Website maintenance handover checklist
0 of 10 checkedWhat to do next
Copy the seven jobs into a document and write a name beside each. Where you cannot, you have found the gap. If your site is already live, do the same exercise today and start with the domain and the backups.
If you would like a second opinion on an existing site, tell us how it is built and hosted and we will say which lines we would look at first.
Common questions
Does a website on a hosted builder still need maintenance?
Less, and of a different kind. The provider handles servers, software updates and most security. You remain responsible for content, forms, integrations, access for your staff, the domain and anything custom that was added. The monthly form test and the quarterly review of access matter as much on a hosted builder as anywhere else.
How much should website maintenance cost?
It depends on how the site is built, how many integrations it has and how quickly problems must be answered, so a figure without those facts would mislead. Ask for a proposal that lists the jobs covered and the response times. Comparing two proposals line by line tells you more than comparing their totals.
Can our own staff maintain the site?
They can usually handle content, form tests, access reviews and renewals. Software updates, backups, security and performance work need technical skill, and a mistake there can take the site offline. Many organizations keep the first group in house and place the second with a technical partner under a small agreement.
What happens if we stop updating the website software?
The site keeps working for a while, which is what makes neglect tempting. Over time, known weaknesses in old software become a common route for attacks, extensions stop being compatible and a later update becomes a larger, riskier project. Regular small updates are cheaper than one overdue large one.
Who is responsible if the website is hacked?
Responsibility follows the agreement and the cause. A provider that undertook to apply updates and did not is in a different position from one that was never asked to. Whoever is at fault, recovery depends on backups, access to the accounts and someone available to act, which is why those three are worth arranging in advance.
