A website can look online while forms deliver nothing, updates remain unreviewed or nobody can restore a backup. A maintenance checklist should state who checks each task, what evidence counts and who decides when it fails.
Use the English maintenance register. It defines responsibilities and evidence; it does not promise a maintenance package or response time.
Inventory the actual website tasks
Begin with forms, domain and certificate, CMS and extensions, backups, restore tests, user access, content and important integrations. Add only what the actual site needs. Record dependencies and consequences: domain renewal has a different deadline from updating a project description.
Refer to provider portals and controlled access locations without copying passwords into the register. A generic monthly tick box is not an agreement about who acts.
Name the operator, decision-maker and substitute
| Role | Responsibility to establish |
|---|---|
| Operator | Performs and records the check |
| Decision-maker | Accepts risk, authorises recovery or escalates |
| Substitute | Takes over when the primary person is unavailable |
| Recipient | Receives the failure report and verifies follow-up |
A host, supplier and business owner can each hold different tasks. A contract's title does not establish that every check is included. Confirm the boundaries explicitly.
Define schedules and change triggers
Choose intervals appropriate to the site's consequences and use. Add checks after relevant changes: a form may need retesting after an update, and a changed backup configuration may require a new restore exercise.
These are planning choices for the particular site, not universal frequencies or OmniTechs service-level commitments. Updates need review for urgency and compatibility rather than indefinite postponement.
Specify the evidence for each task
Form evidence is an identifiable test reaching the controlled destination. Update evidence compares agreed functions before and after. Backup evidence is a restore in a separate environment, not just a completion notification.
Distinguish a signal from final proof
A dashboard can indicate a condition without proving the final user outcome. Record the object, time, tested version where relevant and result. Decide appropriate retention for handover and investigation.
Plan escalation and temporary measures
Set severity, contact route, decision timing and required access. A broken contact form may need a visible alternative route while the owner investigates whether enquiries were missed.
An illustrative monthly review has six tasks: four have current evidence, one form fails delivery and one restore test is overdue under the agreed schedule. Four accepted plus two open is six. The homepage loading cannot make the whole review complete.
The fictional owner assigns a temporary phone route, a form retest and a protected restore exercise. These are example actions, not measured results or a promised response agreement.
Handover the record and open work
Transfer the task register, latest evidence, unresolved deviations, provider boundaries and safe access routes. Revoke departed users and check critical tasks after handover. Keep prior results attached to the combination they actually tested.
For WordPress, connect the register to the update and recovery checklist. Separate the operator installing an update from the person accepting the required functions afterwards.
Use the maintenance cost guide to scope recurring work. A new website development project is a different decision from assigning maintenance to an existing site.