What a Website Support Plan Should Actually Include

A website support plan is one of the few recurring costs a business signs without ever seeing what it buys. The invoice says “maintenance” and arrives monthly. What actually happens in exchange varies from a genuine operational service to somebody clicking “update all” once a quarter, and from the outside those two look identical until the month something breaks.

The market price range is wide enough to make that ambiguity expensive. Published 2026 figures put typical small-business care plans in the region of $200 to $600 a month, with agency retainers running from roughly $500 to $2,500 and enterprise arrangements well above that. A tenfold spread means price alone tells you almost nothing. The scope statement does.

The four things a plan is actually made of

Nearly every honest support plan decomposes into four separate services. They are frequently sold as one line item, which is where the confusion starts, because a supplier can be excellent at one and absent on the others.

1. Keeping it safe. Patching, dependency updates, access control, malware scanning, certificate renewal.
2. Keeping it alive. Uptime monitoring, backups that have been restored at least once, and a defined response when the site is down.
3. Keeping it current. Content edits, small changes, new pages. This is the part clients think they are buying.
4. Keeping it improving. Performance work, accessibility fixes, analytics review. Almost never included by default, and the first thing to disappear when hours get tight.

What belongs in the scope, line by line

Response times: the clause that decides everything else

Support plans live or die on this and it is the section clients skim. Industry convention has settled on tiers: a standard arrangement might commit to one business hour for a first response on a critical incident and 24 hours for a routine request, against a 99.9% monthly uptime target. Mission-critical setups push uptime commitments to 99.95% or 99.99%.

Two things are worth understanding before you accept any of those numbers.

First, response time is not resolution time, and suppliers rarely volunteer the difference. A one-hour response commitment means somebody acknowledges the ticket within an hour. It says nothing about when the site works again. Ask for both, and accept that a resolution commitment will be wider and conditional.

Second, uptime percentages are smaller than they sound. 99.9% permits roughly 43 minutes of downtime a month. 99.5%, which appears in plenty of contracts, permits about three and a half hours. Whether that matters depends entirely on whether your revenue arrives through the site, which is the same calculation behind what the site is worth per hour in the first place.

Why patching is the part you cannot skip

Of the four services, patching is the one where absence produces a binary outcome rather than a gradual decline. The 2026 vulnerability data is unambiguous about where the risk sits: the overwhelming majority of disclosed WordPress holes are in plugins rather than core, and the window between disclosure and mass exploitation is measured in hours, not weeks.

That timing breaks the common arrangement where updates are applied on a monthly visit. A monthly cycle is adequate for feature releases and inadequate for critical security fixes, so a plan needs both: a routine interval and an out-of-cycle trigger with a stated maximum delay. If the contract does not distinguish between the two, it is describing housekeeping rather than security, and the rest of your baseline security measures are carrying weight they were not designed for.

Backups: the item most often present and least often working

Almost every plan lists backups. Far fewer specify the three properties that make them useful.

• Off-site. A backup on the same server as the site is protection against a mistake, not against a compromise or a hosting failure.
• Retention. Seven days of backups is useless against a compromise discovered in week three, and site owners typically discover these things late.
• Tested. A restore that has never been performed is a hypothesis. Ask when the last one was done, on what, and how long it took. The answer to “how long” is your real recovery time, whatever the contract says.

Where those copies physically live is worth knowing too, because backups are one of the places a site quietly scatters data into jurisdictions nobody chose deliberately, which is the practical core of where your website data actually lives.

What is not included, and should be priced separately

These are the items that turn into arguments in month four, because both sides assumed differently.

1. New functionality. A new form is a change. A new booking system is a project. The boundary should be written down, ideally as an hours threshold rather than an adjective.
2. Redesign work. Support keeps the current design working. Changing it is separate, and the decision belongs in a yearly plan rather than a retainer.
3. Third-party breakage. When a payment provider changes its API, someone has to fix the integration. That work is real and it is nobody’s fault, which is exactly why it needs a clause.
4. Content production. Publishing supplied text is maintenance. Writing it is not.
5. Emergency out-of-hours work. Either it is covered at a stated rate or it is not covered. Both are acceptable; ambiguity is not.

How to price it against doing nothing

The honest comparison is not plan A against plan B. It is the plan against the cost of the events it prevents, which is a small number of large, infrequent losses.

Three figures make the case concrete for a specific business: revenue per day through the site, the cost of a clean-up after a compromise including lost trading time, and the cost of an emergency developer who has never seen your codebase. For most small businesses the third figure alone approaches a year of a modest retainer, because unfamiliarity is expensive and urgency removes any negotiating position.

This is also why the cheapest plan is frequently the worst value. A retainer with no included hours and no monitoring costs less than it appears until the first incident, when you discover you are buying emergency work at emergency rates from a supplier who has not looked at the site since launch.

Auditing the plan you already pay for, in an hour

Most readers of this already have a plan and want to know whether it is real. Five requests settle it, and none of them require technical knowledge to interpret. Send them in one email and judge the answers by how long they take to arrive as much as by their content.

1. “Send me the list of updates applied in the last three months, with dates.” A supplier doing the work has this in a log. One who does not will produce a summary written after receiving your email.
2. “When was a backup last restored, and how long did it take?” The only question in this list with a factual answer that cannot be improvised.
3. “Which accounts are the licences and the monitoring in?” This tells you what you keep if the relationship ends tomorrow.
4. “What did you decide not to do, and why?” Every maintained site has deferred items. A supplier with none is not looking.
5. “Who covers this when the usual person is on holiday?” Single-person dependency is the most common structural weakness in small retainers and the easiest to fix once named.

Answers that arrive within a day, with specifics and at least one uncomfortable admission, describe a working service. Answers that arrive after a week, in general terms, describe an invoice.

A plan worth signing, in one paragraph

Named owner for patching, with a routine interval and an out-of-cycle rule for critical fixes. Off-site backups with stated retention and a restore tested at a stated frequency. External uptime monitoring that alerts a person, with tiered response times separated from resolution times. A defined number of included hours, a rate beyond them, and a written boundary between a change and a project. Licences in accounts you own. A staging copy. A monthly note describing what was done and what needs a decision. If those items are present and specific, the price is a commercial question. If they are absent, the price is irrelevant, because you are not buying a service, you are buying an intention.

The short version

Support plans span roughly $200 to $2,500 a month for work that can differ by an order of magnitude, so scope is the only meaningful comparison. Split any plan into four services: safety, availability, changes and improvement. Insist on the distinction between response and resolution, and read uptime percentages as minutes rather than nines. Patching is the non-negotiable component because the exploitation window on plugin vulnerabilities is measured in hours, which makes a monthly-only update cycle a security gap rather than a schedule. Backups need to be off-site, retained long enough to outlast a late discovery, and restored at least once so the recovery time is a fact rather than an assumption. Write down what is excluded, especially new functionality and third-party breakage. Then judge the price against the cost of an emergency, not against a cheaper plan that quietly excludes the same work.