A maintenance contract matters on exactly one day - the day something stops working. Until then it sits in a folder nobody opens, because the work is going fine, the invoices add up and the site is up. It is only when the store goes down on a Friday evening, or when you part ways with the person looking after it, that you find out what the document was missing. So when someone searches for a website maintenance contract template, they are rarely after a pretty file to sign. They are after not being left with nothing at the worst possible moment.
I write this from the other side of the table: I run maintenance for websites and stores, so I know both the clauses that protect both parties and the ones that are pure decoration. One caveat first - this is not legal advice. I am showing you what a contract needs in order to be enforceable in day-to-day technical practice; have a lawyer read the finished document before you sign it, because liability, penalties and data protection are their ground, not mine.
Why “we look after the site” in an email is not enough
Most website maintenance runs on email arrangements. Someone wrote “we will handle updates and backups”, someone replied “sounds good”, and that has held for three years. As long as nobody has a complaint, it works. The trouble starts at the first disagreement: the client assumes the monthly fee covers rebuilding a product page, the contractor assumes it covers clicking “Update”.
A contract is not there so you can sue each other. It is there so that conversation never has to happen, because both sides have in writing what is included, how fast someone responds and what happens when the scope runs out. A good maintenance contract is short and boring. All of its value sits in the annex listing the actual tasks, not in the paragraphs about force majeure.
The task list annex - the heart of the contract
If I had to keep one page out of the whole contract, this would be it. It is a list of specific, repeatable tasks with a frequency attached - not slogans. The difference looks like this:
- “We take care of your site’s security” means nothing and cannot be checked against reality.
- “WordPress, theme and plugins updated every two weeks, with a backup taken beforehand and the homepage, contact form and checkout tested afterwards” means exactly what it says, and after a month you can see whether it happened.
The minimum that belongs in that annex: updates with a stated frequency, backups with a stated frequency and storage location, a restore test at set intervals, uptime monitoring, a security scan, a monthly report and a pool of hours for small changes. What each of those actually involves I have covered separately in the post on what WordPress maintenance includes - that one is about the substance, this one is about getting the substance into a document.
On backups, add one sentence almost nobody has: where the copy is stored and who can reach it after the engagement ends. A backup that only lives in your contractor’s account is yours on trust alone. How to set that up properly is in the post on WordPress backups that actually restore.
Response time and resolution time are two different promises
This is the most commonly confused pair in the whole subject, and the source of most disappointment.
Response time is how long it takes for someone to confirm they have seen your ticket and are working on it. That can be promised honestly, because it depends only on the contractor’s discipline.
Resolution time is how long it takes for the problem to disappear. That cannot be promised honestly in every situation, because plenty of outages are not the contractor’s doing - a host with a dead server, a plugin pulled by its author, a payment gateway blocking transactions. Anyone promising a fixed resolution time for everything either has not thought the contract through or has written in so many exceptions that the promise is empty.
A sensible clause separates the two and grades them by severity. Three levels are usually enough: critical outage (site down, checkout not taking orders), defect (something works badly but sales continue) and routine change (a content fix, a small new feature). Each level gets its own response time and its own coverage window - and that is the second thing to write down: during which hours that clock actually runs. “Four-hour response” with no note on whether that means business days from 9 to 5 or Sundays too is a promise that falls apart on the first weekend.
The hour pool and what sits outside the contract
Almost every maintenance plan includes a pool of hours for small changes. Three sentences have to sit next to it in the contract:
- How many hours a month and what they cover - small fixes and advice are not the same thing as building a new feature.
- Whether unused hours roll over. The honest answer is usually “no” or “for one month”, because part of what you pay for is availability. The point is that it is written down rather than assumed.
- What happens once the pool is used up - the hourly rate for overage, plus a rule that nothing beyond the pool starts without written approval. That second part mostly protects you: without it, an invoice can arrive for work you never knew about.
It is equally worth listing what the monthly fee does not cover: rebuilds, new pages, server migrations, cleaning up after a hack, integrations with outside systems, out-of-hours work on request. That is not narrowing the scope, it is saving both sides an awkward conversation. Costs outside the contractor’s control - hosting, domain, premium plugin licences - belong in a separate line, because they change every year and should not hide inside one lump sum. I broke those down in the post on what website maintenance costs.
Access, passwords and ownership - who holds the keys
This is where most of the pain shows up, and people only think about it when the relationship ends. The contract should name three things plainly.
First, whose accounts these are. The domain, the hosting and any third-party services should be registered to you, with your contractor holding access - not the other way round. A domain registered to the contractor is the most expensive convenience I know of.
Second, who has which permissions and what happens to them afterwards. A healthy clause says that within a few days of termination the contractor’s access is revoked and you receive the full set of credentials plus a current copy of the site.
Third, who owns the code and the content. Maintenance quietly produces small assets along the way - a custom plugin, a theme tweak, an email template. One sentence transferring rights to whatever was created under the contract settles that for good. Separately, you want a data processing clause, because whoever maintains the site usually has access to a database full of customer records - and that is precisely the paragraph your lawyer or data protection person reads before you sign.
What a website maintenance contract template usually misses
Ready-made templates circulate freely and they make a decent starting point - the formal skeleton (parties, subject, fee, term, termination, confidentiality) is normally fine. The catch is that the skeleton is the easy part. Everything that actually decides the outcome is the material a generic template cannot contain, because it is specific to your site.
What is missing most often:
- The task list with frequencies - there is a line about “maintenance services” and no annex.
- The split between response time and resolution time, and the hours during which they run.
- Rules for the hour pool - how many, whether they roll over, what happens after.
- An exit procedure - who hands over access, backups and documentation, and when.
- A clause about changes made on your side - if you install a plugin yourself and it breaks something, that should not be on the contractor; it cuts fairly in both directions.
A practical way to work with a template: take the skeleton, cut the platitudes about “professional service” and attach Annex 1 with the task list and Annex 2 with a table of severity levels and response times. Two extra pages do more than ten pages of clauses.
Termination and exit - the part people skip
Read the contract from the back. It has to answer three questions: what term it runs for, what notice ends it and what exactly you receive when it does.
A monthly contract with short notice is safer for the client than a twelve-month commitment at a discount, because maintenance should be judged by whether you see the work, not by how hard it is to leave. I work on a monthly contract with thirty days’ notice and consider that the fair standard for both sides.
The exit package is a set: current file and database backups in a format anyone can restore, a list of credentials, an inventory of paid plugins including whose licences they are, and a short note on anything unusual about the site. If a contractor resists that clause, this is the moment to ask why - because otherwise the next person starts by reconstructing knowledge instead of doing the work, and you pay for that time. What taking over someone else’s site looks like in practice is in the post on who can fix your WordPress site.
How I handle it
Before I sign anything I run a free review of the site and say plainly whether ongoing maintenance makes sense here or whether a one-off clean-up is enough. If we do work together, you get the task list with frequencies up front, a response time table, a clearly described hour pool and the rule that nothing beyond it starts without your written approval.
If you already have a maintenance contract and cannot tell whether real work sits behind it, send it over along with a link to the site. I will tell you what is missing and what is worth adding, before you need it.
Frequently asked questions
Does a website maintenance contract have to be in writing? For the arrangement to hold, often not - but without writing there is nothing to enforce. What matters is that both sides work from the same task list, the same response times and the same rules for billing hours. Confirm the legal form and effects of your specific document with a lawyer; I look at this from the technical side.
What belongs in the annex to a maintenance contract? A list of tasks with frequencies: updates, backups including storage location and restore tests, monitoring, security scanning, a monthly report and a pool of hours for fixes. Plus a table of severity levels with a response time for each and the hours during which that clock runs.
Do unused hours from the monthly plan expire? That depends on the clause, which is exactly why it has to be spelled out. The most common model is hours that do not accumulate, or that carry over for one month, since part of what you pay for is availability rather than completed tasks. The worst option is no clause at all, because then each side remembers something different.
What should I watch for when ending a maintenance contract? Three things: the notice period, whose name the domain and hosting are registered in, and what exactly you receive on the way out. If there is no sentence about handing over access and a current copy of the site, leaving can cost more than several months of the fee.
Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. Tell me what you run and I will send back scope and price.