Website maintenance services — what you actually buy when you sign

Website maintenance services are sold as a list of tasks: updates, backups, monitoring, "minor changes included in the plan". What you actually buy is something else — a contract. And in a contract, three things matter that offers usually leave out: what you get when a promise is not kept, who owns what the provider builds, and who holds the keys when you part ways.

To see how big the gap is between "someone is looking after the site" and "someone is responsible for it", one number from WordPress's public statistics is enough.

According to WordPress.org statistics, 38% of installs today run on a PHP version that no longer receives security fixes. Another 25% run on PHP 8.2, for which the php.net schedule ends support on 31 December 2026. From 1 January that will be 63%.

The PHP version is not shown in the WordPress dashboard, and nothing notifies you about it. It is changed on the server, not with an "update" button. That makes it a good test: on many of these sites someone clicks through the plugin updates every month and invoices for it — and nobody wrote into the contract that the environment the site runs on is also their job.

This article is about the contract, not the tasks. Each task has its own article, linked where it comes up.

Maintenance, care, administration — one service, four kinds of work

Website maintenance services, website care plans, site administration, website support — in offers these names are interchangeable and none has a fixed meaning. Two firms selling "care" may put entirely different things in the package, and two selling "maintenance" and "administration" exactly the same thing. Comparing offers by the name of the service makes no sense. You compare them by which of four kinds of work are inside:

• Ongoing work — what happens without you asking: updates, backups, uptime monitoring, domain and certificate renewals. It can be described up front and priced as a flat fee.
• Response — what happens when something breaks: the site is down, the form doesn't send, the shop doesn't take payments. It cannot be predicted; you can only agree how fast and during which hours it happens.
• Changes — what you ask for: a new page, a layout fix, swapped photos, a new form field. This is development work, not maintenance, even when it is small.
• Advice — the answer to "should we?" before anyone does anything: a hosting change, a booking plugin, moving to a newer version of the system.

Most offers describe the first kind in detail — it is the easiest to write down — and the other three in a single sentence. Disputes are born in those three.

Where the scope ends

The most common dispute in website maintenance is not about an outage. It is about the sentence "that was included". It starts with a phrase found in almost every offer: "minor changes included in the plan". To you, a minor change is adding a VAT number field to a form. To the provider it may mean a change to the form, to validation, to the confirmation email template and to the export into your sales system — four places, two hours.

There are two honest ways to settle this in advance:

A pool of hours. The plan includes a set number of hours per month for changes, and the provider reports how many were used. The advantage: no argument about whether something is "minor". The condition: a report broken down by task, not a single figure on the invoice, and a clear rule on unused hours — do they roll over or expire?

A task list. The plan names what it covers — by name — and everything else is quoted separately before the work starts. The advantage: a predictable bill. The condition: the list must be concrete. "Ongoing support" is not a list item; "content updates on existing pages, up to 10 changes a month" is.

Whichever model you choose, the contract should include a list of exclusions — things that are definitely not in the plan. Typically: new features, design changes beyond content updates, integrations with new systems, fixing the consequences of changes made by someone else, moving the site to another server. Exclusions are not bad news — they are information you pay for separately and know about before signing, rather than on the first extra invoice.

What it all costs we break down in a separate article on website maintenance costs, and you can work it out for your own site in the website maintenance cost calculator. Here we care about what you get for that money.

Response time is not fix time

"We respond within an hour" is the most common promise in website maintenance offers and the most commonly misunderstood. Response time measures when someone acknowledges the ticket. Fix time measures when the site works again. A contract can guarantee the first and say nothing about the second — then within an hour you get an email saying "received, looking into it", and the site can stay down until the next day, in line with the contract.

That doesn't mean fix time can be guaranteed. It can't, because the cause may lie outside the provider — with the hosting company, the payment provider, an external service. But three things can be written down that have real value:

• Response time per priority. Priority is set by the business impact, not by what is technically broken: "the site is down or orders can't be placed" is different from "a photo is misaligned on one page", even if both need similar work.
• The hours it applies. "Within an hour" on weekdays from 9 to 5 means an outage reported on Friday at 6 pm waits until Monday. That may be fine for a company site and unacceptable for a shop, but it should be written down.
• Time to a workaround or a diagnosis. Instead of a fix guarantee — a commitment that within a set time you get a diagnosis and a plan, or a temporary workaround. That can't be promised without knowledge, which makes it a good test of whether the provider has it.

A service level agreement: what 99.9% allows and what you get when it is missed

An SLA (service level agreement) is the part of a contract that expresses the availability of a service as a percentage. It sounds like a guarantee, but it is worth working out what the percentage means in hours, because intuition says something different from arithmetic.

99.9% availability allows 44 minutes of downtime every month — and for those 44 minutes you are owed nothing, because the contract has been met. 99% is already more than seven hours a month. If an offer gives a percentage without a word on how it is calculated, it lacks three things that decide what that percentage is worth:

• The measurement period. 99.9% measured per year allows almost nine hours of downtime on a single day, as long as the rest of the year is clean. Measured per month, it doesn't.
• Who measures, and with what. The provider measuring from its own server may not notice that the site doesn't respond from outside. The simplest answer is independent monitoring that you can see.
• What is excluded. Planned and announced work usually doesn't count as downtime. That is reasonable — as long as the contract says how far in advance it must be announced and during which hours it may take place.

The second question matters more than the first: what happens when the SLA is missed? The market standard is a partial refund of the service fee. You can see this clearly in one of the most-cited public SLAs — the Amazon EC2 agreement. Amazon commits to 99.99% availability per region. When it misses, the customer gets a 10% refund of the fee; below 99% — 30%; below 95% — 100%. And the agreement states that this is its "sole and exclusive remedies".

This is not a complaint about Amazon — that is how the mechanism works. But applied to a company website, it is worth doing the sum before you sign: a whole day offline means availability of about 96.7% for the month, which on that scale of refunds is 30% of the fee. On a plan costing a few hundred euros a month, the entire compensation for a day without sales is roughly one or two hundred euros. Your lost revenue is not part of the calculation. An SLA is therefore mainly information — a measurable commitment that lets you establish that the service is bad — rather than insurance.

If you need more than information, contract law offers a tool that works differently: a contractual penalty. In Germany it is set out in § 339 BGB (Vertragsstrafe): the debtor promises a sum of money as a penalty for not performing, or not performing properly, and the penalty becomes due when they default. Other EU countries have equivalent clauses under their own names. A penalty works both ways — the provider will price it into the service — so it makes sense where downtime genuinely costs money, not as a bargaining point on principle.

Who holds the keys

The most expensive problem in website maintenance doesn't happen during the relationship but at its end — when it turns out the domain is registered to the provider, the hosting account was set up by one of their employees, and the password to the dashboard is known to one person who no longer works there. Each of these can be recovered, but each costs time, and some cost the goodwill of the party you are parting from.

There is one rule: everything that makes up "the site" should be registered to your company, and the provider should have access granted to them — not access of their own. The difference is that granted access can be revoked with a click.

The domain is the most serious item on the list, because it is the only one that can pass to a complete stranger — what happens after a missed renewal we cover under maintenance costs. The rest of the table needs no technical knowledge: when you sign, ask, for each row, who it is registered to today, and write down the answer.

Who owns what the provider builds — and who owns the data

The second half of the same problem is not about access but about rights. You paid for the site, so intuition says it is yours. The law can say something else, and the rules differ from country to country. We quote the relevant provisions; this is not legal advice, and for a contract of significant value it is worth showing it to a lawyer.

In some countries copyright cannot be transferred at all. Germany is the clearest example: under § 29 UrhG copyright is not transferable — the author can only grant rights of use (Nutzungsrechte, § 31). An invoice, or a clause saying "all rights pass to the client", therefore cannot mean what it seems to mean. What the contract can and should do is grant rights of use that are broad enough.

What is not named may not be included. Under § 31(5) UrhG, if the types of use are not expressly listed, their scope is determined by the purpose both parties assumed in the contract. A clause without a list of what you may do with the work — copy it, publish it online, modify it — may cover less than it seems. For a website, the right to modify matters most, because without it another provider should not, formally, change that code.

Fixing errors is the exception, across the EU. The EU Software Directive, 2009/24/EC, Article 5(1), allows the lawful acquirer of a computer program to do what is necessary to use it for its intended purpose, "including for error correction" — without the rightholder's authorisation, "in the absence of specific contractual provisions". That protects routine fixes after a change of provider, but not further development. And the contract can exclude this exception, so it is worth checking that yours doesn't.

In practice this comes down to one clause to check in the contract for building the site: does it grant rights of use in writing, with the types of use listed, including modification? In a maintenance contract, the same applies to everything the provider adds along the way — new pages, features, graphics.

Data is a separate agreement. If the provider has access to a dashboard holding form submissions, customer accounts or orders, it processes personal data on your behalf. The GDPR requires a data processing agreement for that (Article 28), which we cover under privacy rules for websites. For maintenance, one point of it matters most — Article 28(3)(g): at the end of the service the processor, at your choice, deletes or returns all the personal data and deletes existing copies. That is an exit clause, written before the relationship starts.

Changing the company that maintains your site

If the previous two sections are in order, changing provider is a procedure, not a crisis. Five steps, in this order:

1. Inventory. The list from the table above, with an answer in each row: registered to whom, who has access, where it lives. Plus a list of plugins, integrations and external services paid for separately — these are what most often surface only after the handover, when they stop working.
2. Export. Code (repository or a full copy of the files), database, user-uploaded files, server configuration, documentation if it exists. Plus a written grant of rights of use, if there wasn't one.
3. Restore test. The new provider builds a copy of the site from what it received. Only a working copy proves the export is complete — a bundle of files proves nothing, which we explain under backups.
4. Overlap period. A week or two in which the old provider still answers questions. The cheapest thing in this work is the answer to "why was this done this way?".
5. Closing access. Change the passwords to everything in the inventory, remove the previous provider's accounts, revoke their permissions in Search Console and the tag manager. And written confirmation that the data has been deleted, as Article 28 of the GDPR requires.

With well-run maintenance, step one takes an hour, because the inventory already exists. With badly run maintenance, it takes the longest — and that is the best measure of what you were really buying all those years.

WordPress maintenance services — what is different

WordPress maintenance is, in practice, two things, and neither of them is "maintaining WordPress".

The first is plugins. According to the report we break down under updates, 91% of vulnerabilities found in the WordPress ecosystem in 2025 were in plugins, and in the core itself — six, all low priority. Looking after WordPress is therefore mostly plugin discipline: how many there are, which are still maintained, in what order to update them and what to do when one has a flaw with no fix. Since version 5.5 WordPress can update plugins automatically, but automation doesn't replace that decision — when something breaks, you don't know which update caused it.

The second is PHP — the chart at the start of this article. The PHP version is a layer the site owner doesn't see, and it decides whether the server gets security fixes. For 38% of installs it no longer does. Changing the PHP version is not an update but a change of environment: it can break an older plugin or theme, so it needs a backup, a test and someone who knows what to check. The deadline for PHP 8.2 and what it means for the whole site we cover in the article on when a website needs modernising.

This gives a simple test for any offer of WordPress website maintenance services. Ask the provider two things: which PHP version your site runs on today and when it loses support, and how many plugins are installed and which have not been updated in a year. A provider who looks after the site will answer in a few minutes, from memory or from a report. A provider who clicks updates will have to check — and that is an answer too.

WordPress administration also covers dashboard accounts. After a few years the list of users with administrator rights usually looks different from what anyone remembers — that is security, but checking that list should be an item in every maintenance plan.

An in-house administrator or an outside firm

The question "hire or outsource" has one property in website maintenance that usually settles it faster than any calculation: one employee cannot provide on-call cover. They fall ill, go on holiday, sleep. A 99.9% availability SLA — 44 minutes of downtime a month — cannot be met by one person, however skilled: an outage that waits a single day for them to come back from holiday exceeds the monthly allowance more than thirty times over.

It is worth doing the sums on your own numbers rather than on figures that circulate: the salary of an in-house web administrator, plus employer costs, equipment, licences and training, set against the monthly fee for an outside plan. Salary levels differ too much between countries and regions for one European figure to mean anything, so we don't quote one.

What follows is a boundary, not a verdict. A position in-house makes sense when the site is part of the company's daily work — a shop with daily changes to the range, a portal, a system your customers work in — and when there is enough work for a full role, with someone else covering out-of-hours incidents. An outside firm makes sense when the work amounts to a few hours a month, which is true of most company websites: you then pay for a team's availability, not for one person's time. A hybrid model — someone in the company collects requests and manages content, while the provider handles the technical side and on-call cover — combines the advantages of both, provided the split is written down.

What this article deliberately leaves out

• Prices and ranges — see website maintenance costs, broken into four layers of the bill, and the calculator for your own case.
• How to update — website updates, with an order that doesn't break the site.
• How to back up and test backups — website backups.
• How to set up monitoring — separately.
• Site speed — that is Core Web Vitals, the metrics Google actually uses.

The shortest summary: before signing a contract for website maintenance services, check not the task list but three clauses — what you get when the provider breaks a promise, who owns what they build, and who the domain, hosting and accounts are registered to. Any firm will do the tasks. Those three clauses separate a service someone is responsible for from a service someone merely performs.