Website Maintenance Contract: What to Include and Check
Short answer: A website maintenance contract should spell out updates for the CMS, plugins and PHP, off-site backups with a documented restore test, uptime and security monitoring, separate response and fix times by severity, a set number of hours for small changes and a monthly report. You should also keep your own access to the code, server and backups at all times.
On 31 December 2026, security support for PHP 8.2 ends. After that date the PHP project issues no more security fixes for that version, not even for critical vulnerabilities. Every site still running on it needs an upgrade before then, and with older themes and plugins that is rarely a single click.
That’s what maintenance contracts are for. The trouble is the contracts themselves. “Ongoing maintenance and support, £149 a month” says nothing about what the agency will actually do.
What the contract should name explicitly
- CMS, theme and plugin updates: frequency, and how security patches are handled
- Server software updates, especially PHP version upgrades, tested before switching
- Backups: frequency, off-server storage, retention period
- A documented restore test at least once a year
- Uptime monitoring with alerts
- Security monitoring: malware scans, login protection, alerts on unexpected file changes
- Response times by severity, separate from fix times
- Hours for small changes, with a rule for unused hours
- Monthly report: what was updated, what was noticed
- Your own access to code, server and backups at all times
The item that matters most sits in the middle: the restore test. Any backup that has never been restored is a hope, not a plan. Sometimes it only emerges during an emergency that the database was never included or the uploaded images were skipped.
PHP, WordPress and the dates that matter
On WordPress sites, much depends on the PHP version running on the server. WordPress’s official requirements currently recommend PHP 8.3 or newer, plus MariaDB 10.11 or MySQL 8.0 or newer. The PHP project publishes its support windows on php.net:
- 31 Dec 2026PHP 8.2: no further security fixes
- 31 Dec 2027PHP 8.3: end of security support
- 31 Dec 2028PHP 8.4: end of security support
- 31 Dec 2029PHP 8.5: end of security support
Source: php.net, Supported Versions (as of October 2026)
A good maintenance contract plans for these switches. Ask your agency which PHP version your site runs on today and when it will move to 8.3 or 8.4. Hesitation in the reply tells you where you stand.
PHP upgrades are usually small jobs, but they can break plugins or an old theme. Each one belongs on a staging copy before it goes live. Whether that testing is covered by the monthly fee or billed extra should be written down.
Automatic updates: convenient, not sufficient
WordPress and many other systems can update themselves. That’s better than nothing. It doesn’t replace maintenance, because nobody checks afterwards whether the contact form still sends, the basket still adds up and the mobile layout still holds.
The sensible approach combines both. Security patches go in automatically and immediately, because hours count. Larger plugin and theme updates go onto a copy of the site first, the main journeys get tested, and only then does the update reach production. Ask whether that copy exists. Without staging, every update is surgery on a live patient.
Response time isn’t fix time
Plenty of contracts promise a “four-hour response”. Often that means someone acknowledges your ticket within four hours. When the problem is actually solved is written somewhere else, or nowhere.
So separate the two:
| Severity | Example | Response time | Target for fix or workaround |
|---|---|---|---|
| Critical | Site down, shop not taking orders | 1 hour in business hours | 4 hours |
| High | Contact form not sending emails | 4 hours | 1 business day |
| Normal | Layout glitch on one page | 1 business day | 5 business days |
These values are examples for a mid-sized business site, not a standard. High-revenue shops need tighter targets; a blog can live with looser ones. What matters is that both columns are in the contract and that business hours are defined.
What an uptime promise really allows
Hosting and maintenance contracts often quote an availability figure, such as 99.5%. It sounds like always. Do the maths:
- Hours per month (365 × 24 ÷ 12)
- 730 h
- Permitted downtime: 0.5%
- 3.65 h per month
- Over a year
- 43.8 h
- At 99.9% instead
- about 8.8 h per year
Whether planned maintenance windows count depends on the contract. Check whether they are excluded.
Almost two full days of downtime a year is within contract at 99.5%. That’s fine for a brochure site and possibly not for a shop. Check what happens when the target is missed, too. Without service credits or a right to terminate, the number is decoration.
What isn’t maintenance
Maintenance preserves the current state. It doesn’t improve it. New features, a new page layout or another integration are development, commissioned separately or paid from the hours bank. Content updates, adding new copy, images or products, are a separate service as well.
That’s fine as long as both sides know it. Trouble starts when the client believes £149 a month covers “everything” and the agency bills every small text change. One sentence separating maintenance from development prevents that argument.
Data protection duties stay with you
Whatever the contract says, you remain responsible as the site operator. If your site handles personal data in the EU or UK, through forms or customer accounts, Article 32 of the GDPR requires appropriate technical and organisational security measures that take the state of the art into account. Running software that no longer gets security fixes sits badly with that. The maintenance contract is one of the ways you meet the duty, and a data processing agreement belongs alongside it if the agency can access that data.
What maintenance costs
Price follows scope. You can derive a fair monthly fee from the services: updates and checks, backup verification, a report and a bank of hours. If you assume two to three hours a month for a small WordPress site, a shop with many extensions will sit well above that. Multiply by the agency’s hourly rate. Our guide to agency hourly rates helps you judge that rate.
Be wary of very low flat fees. “Complete care” for a few pounds a month usually means automatic updates with no testing. That can work fine, right up until a plugin update breaks your checkout.
Term and exit
Check the minimum term, automatic renewal and notice period. Twelve months, then monthly, is a fair shape. What matters more than the term is being able to leave without depending on the agency: credentials in your name and code in your repository. See who owns the source code and switching agencies.
If you’d like operations and hosting under one roof, providers with their own infrastructure often bundle maintenance in, for example hosting from OnlineBuilders. Ask them for an itemised list of services too.
Your next step: ask your agency or host today which PHP version your site runs on and when a backup was last restored as a test. Two questions, and you’ll know whether your contract does what it says.
Questions people ask
Does a small website really need a maintenance contract?
Not if you reliably apply updates yourself and check your backups. If that keeps slipping down your to-do list, a lean contract covering only updates and backups usually costs less than cleaning up after a hack.
What happens to unused support hours?
The contract decides. Some agencies roll them over for a month or two; others let them expire. Expiring hours make a monthly bank more expensive than ad-hoc billing if your needs are uneven.
How long should the minimum term be?
Twelve months is reasonable for both sides, and shorter is better. Terms of two years or more with a vague service description are a warning sign. Watch for automatic renewal and the notice period that goes with it.
Are automatic updates enough?
They are better than no updates, but nobody checks afterwards whether forms, checkout and layout still work. A sensible setup applies security patches automatically and tests larger updates on a staging copy first.
