Website maintenance: a practical checklist after launch

A maintenance agreement should explain what happens when a form stops delivering messages, an update breaks a page or the person who manages the website is unavailable. “Updates included” is too vague to answer those questions.

The right scope depends on what your site actually does. Here is a practical way to define it before an incident.

Start with the components you depend on

List the domain registrar, hosting account, website code, content storage, email delivery service and external tools. Record who owns each account and who receives renewal and security notices. Keep credentials in an appropriate password manager, not in a shared maintenance spreadsheet.

For a site such as LR Studios, the public journey centres on a game catalogue and download links. Useful checks include whether the site loads, whether each game points to the right store and whether support information remains current.

For MAHVU, a WordPress site with a publishing form designed for blind members, maintenance also needs to preserve the publishing workflow. A successful homepage check would not reveal that a member can no longer submit an article.

Define the routine and the urgent work separately

This is an example schedule to adapt, not a universal service commitment:

Trigger	Check	Evidence to retain
After a deployment or update	Open key pages and complete the agreed test journeys	Version, date and test result
At an agreed recurring interval	Review forms, links, backups, renewals and content accuracy	Short report and unresolved issues
After a relevant security advisory	Assess affected components and prioritise a correction	Decision, patch or temporary measure
After an outage	Restore service, check data and investigate the cause	Incident timeline and follow-up action

A monthly review does not mean a critical problem should wait until next month. Agree how urgent reports reach the maintainer, the hours covered and what response means: acknowledgement, investigation and resolution are different milestones.

Make updates reversible

Before a significant update, identify what will change and how to return to the previous working state. Test the relevant workflow on a separate environment when available. After deployment, check navigation, forms, language links and the affected functionality.

For WordPress, a recovery copy normally needs both files and the database. The WordPress backup guide explains this distinction. A code repository alone will not restore newly published posts or uploaded photographs.

For a static website, preserve the source, deployment configuration and assets. If an external service stores submissions or bookings, define its recovery arrangements separately.

Test recovery rather than counting backup files

Choose a backup, restore it in an isolated environment and verify the content and critical journey. Record the backup date, the restoration steps, the time needed and anything missing. Decide how much recent data the business could afford to lose and how long an interruption could last; those answers shape the backup frequency and recovery process.

Never overwrite a working production site merely to prove that a backup opens. Use a controlled restoration exercise with a clear destination.

Specify what the agreement includes

Ask whether the scope includes monitoring, dependency updates, restoration tests, small content changes and third-party support. Define any hour allowance, exclusions, access requirements and the process for additional work. Avoid treating a maintenance subscription as an unlimited redesign budget.

The maintenance cost guide helps frame the commercial discussion. The hosting guide covers infrastructure responsibilities, while the security checklist covers accounts and sensitive operations.

Before signing, ask for one concrete example: “If our contact form stops delivering enquiries tomorrow, how will we discover it, who investigates it and what is covered?” The answer is more useful than a long list of technical labels.