Website maintenance: what to demand and how to verify it

You pay every month, but what exactly for?

The invoice says "website maintenance." When the site fails, the provider answers that it’s the hosting; when you request a change, they say that’s development; when you ask about backups, they say those weren’t included. None of those answers need be bad faith: often nobody documented what each service covered.

Five distinct services

The columns describe common uses, not rules. What matters is what is written in your contract or plan. What a project’s warranty covers, and for how long, is defined by the project or plan conditions and the applicable terms; review them before signing.

What to demand from maintenance

• List of what is updated and at what frequency: core, plugins or apps, themes, language/runtime version. WordPress documents how and why to update.
• Backups: frequency, where they are stored and whether restores have been tested.
• Basic security review according to best practices, such as WordPress hardening.
• Periodic report of what was done and what remains pending.
• Responsible person and contact channel.

How to verify it

You don’t need technical access to verify. Ask for evidence: the monthly report with versions before and after, the date of the latest backup and of the latest restore test, and the list of incidents handled. If the provider cannot provide them, the maintenance is probably not being done methodically.

Procedure

1. Gather your hosting, maintenance and support contracts or plans.
2. Fill the "Included?" column of the checklist with what is written in those documents.
3. Request the provider’s evidence for the last month.
4. Mark what is verified and what is not.
5. Discuss the gaps and decide whether to adjust the scope.

Applied example

Limits

Good maintenance reduces risks, but does not eliminate the possibility of failures. Each party’s obligations are those established by the contracted scope.

How to use the downloadable checklist

1. Fill the scope with what your documents state.
2. Ask the provider for the last month’s evidence.
3. Mark what has been verified.
4. Turn the gaps into actions.

Criteria to evaluate your maintenance

Complete synthetic example

Synthetic example. A fictional company has paid monthly maintenance for its online store for two years. Using the checklist, it discovers the contract states "comprehensive maintenance" without details and that it has never received any report.

It asks the provider, in writing, what is included each month. The answer: plugin updates and daily backups. It requests evidence for the last month and the date of the last tested restore: there is none. It agrees with the provider on a monthly report with updates, backups and access logs, and a restore test in an isolated environment. The first test reveals that backups did not include product images; the configuration is corrected.

The company did not change provider: it changed what it demands and how it verifies it. Invented example.

Questions for your provider

• What exactly does the maintenance include each month?
• When was the last restore test and what was the result?
• Who has administrative access and since when?
• What is outside the maintenance and how is it quoted?
• What happens to my backups and access if we terminate the contract?

How to know if it worked

• You receive a monthly report with evidence.
• The last restore test has a date and result.
• Administrative access is under your company’s control.

Plan for the first four weeks

1. Week 1: gather contract and plan.
2. Week 2: request evidence for the last month.
3. Week 3: fill the checklist.
4. Week 4: agree actions for the gaps.

Diagnosis before starting

• Find your maintenance contract or plan and note what it says.
• Ask for the date of the last update and the last backup.
• List who has administrative access.

A contrasting second example

Synthetic example. A fictional company receives complete monthly reports and proven restores. Its gap is in access control: three former employees are still administrators. The checklist helps them remove those users and set a quarterly review. Unlike the first example, the provider complied; the risk was internal to the company. Invented example.

What to do when something fails

• If an update breaks the site, request restoring the previous version and record the incident.
• If there are no useful backups, treat it as top priority.
• If the provider does not provide evidence, escalate in writing.

How to measure it with your own data

• Note each month whether you received the report and on which date.
• Record the date and result of each restore test.
• Count incidents and who first detected them: your team, a customer or the provider.
• Review the list of administrators quarterly.

With a quarter of records you will know whether maintenance is being fulfilled. If incidents are always detected by your customers, monitoring is not working. If restores are not performed, backups are not verified. Bring these data to the conversation with the provider instead of broad impressions.

Common mistakes

• Assuming hosting includes maintenance.
• Not requesting reports.
• Confusing warranty with indefinite support.
• Paying for evolution as if it were maintenance, or vice versa.
• Not knowing who holds access credentials.

Checklist

• Services separated and documented.
• Monthly report received.
• Backups verified.
• Access under your company’s control.
• Gaps with actions and responsible parties.