1. Know what you are maintaining
Start with an inventory of the domain, hosting, application, database, email service and important integrations. Record the account owner, renewal arrangement and technical contact. Keep credentials securely rather than adding them to an ordinary maintenance checklist.
List the journeys that matter: sending an enquiry, requesting an appointment, placing an order or editing a page. A site can be online while one of those functions is broken. This list determines the checks that should follow an update or recovery.
For an inherited website, first review access and compatibility. A provider cannot responsibly promise routine updates before understanding the installed software and any unsupported customisations.
2. Define a backup you can actually restore
Identify the material needed for recovery. A typical database-driven website needs more than a copy of its public pages. WordPress’s backup handbook explains that both files and the database are needed for a complete restoration. Keep related backup sets identifiable by date.
Choose backup frequency around the amount of data the business can afford to recreate. A shop accepting orders and a site with occasional service edits have different needs. Agree retention, storage location, access and whether a separate copy remains available if the hosting account is affected.
Test restoration in a suitable separate environment. Confirm the important pages and functions, not just that an archive downloads. Record what was tested, the result and any missing dependencies.
3. Make updates a controlled change
Before updating a theme, plugin, framework or runtime, review compatibility and take a usable backup. For significant changes, use staging and representative data. Avoid testing real customer payments or sending real notifications accidentally from a staging copy.
- Record the current versions and the reason for the change.
- Check the update information and relevant dependencies.
- Make a recoverable backup and identify the rollback method.
- Apply the change in the appropriate environment.
- Test the affected function and important customer journeys.
- Record the result before scheduling the next change.
Maintained extensions can be appropriate; removing software merely to lower a plugin count can break needed features. Investigate whether each component is used, supported and configured correctly.
4. Use a checklist tied to business activity
| Check | Evidence to keep |
|---|---|
| Enquiry form | A test request arrives at the intended destination and can be answered. |
| Order or booking flow | The test follows the relevant success and failure paths. |
| Navigation and contact | Important links, phone actions and contact information remain correct. |
| Backups | A recent usable set exists and restoration has been tested. |
| Content | Dates, offers, staff details and policies match the current business. |
| Renewals | A responsible account owner knows which services need renewal. |
Set the interval according to risk and change frequency. A scheduled checklist is useful, but so is an extra check after a provider change, content import or significant update. Assign a person to review alerts instead of assuming that monitoring alone resolves problems.
5. Prepare a simple incident response
If a site fails, first identify the impact: the entire site, a form, checkout, an admin account or a particular page. Record when the issue was noticed and what changed recently. Preserve relevant logs and evidence without sharing private customer records in a public support request.
Stop making unrelated changes while diagnosing the problem. A rollback or restore may be suitable, but restoring an old database can lose later orders or enquiries. Review that risk and the available data before deciding. Do not overwrite live records simply because a backup is convenient.
If compromise is suspected, involve a maintainer able to assess the application and surrounding accounts. Restoring a page without addressing the entry point or exposed credentials may leave the problem unresolved. No maintenance plan can guarantee that incidents never occur.
6. Separate hosting support from application care
A host may help with the service it operates, while a developer may maintain the application and integrations. The business still controls content approval, customer communication and account ownership. Write down the boundary so an issue does not wait while everyone assumes someone else owns it.
A useful agreement describes covered tasks, response arrangements, exclusions and how extra work is approved. Routine updates, content edits, a full redesign and emergency investigation are different scopes. Ask what happens outside normal hours rather than assuming immediate support is included.
For WordPress practices, consult the official hardening handbook. For custom software, request comparable documentation of access, dependencies, updates and recovery.
7. Ask for a concise, useful maintenance report
A report should identify the work performed, checks completed, outstanding problems and decisions needed. “Everything updated” is less useful than a dated record of what changed and which important functions were tested. Avoid treating every software update as a new feature.
Keep a small change log the next maintainer can understand. Include the backup reference, versions affected, test result and follow-up owner. Store confidential details in an appropriate secure place, not in the public website files.
If performance or search visibility changes, keep those investigations separate from routine uptime. Use the performance checklist or search investigation guide to establish evidence.
8. A practical first maintenance brief
Send the site URL, its purpose, known problems, required functions and current support arrangements. Identify who controls the relevant accounts and what must keep working. Arrange account access securely after the scope is agreed; do not include passwords in the first enquiry.
Begin with a review and a recoverable baseline. Then agree a sustainable schedule and the specific checks that will make the work visible. See the maintenance service scope and ownership cost worksheet when comparing proposals.
