A WordPress maintenance retainer worth paying for includes six things: updates tested on staging before they touch production, monitoring that tells the provider before it tells you, backups that have been restored at least once, a defined response when the site is compromised, a development allowance for the small changes every site needs, and a report you can read. Most proposals include the word for each of these. Far fewer include the thing. The way to tell them apart is to ask how each one is done, not whether it is done.
Why outsource maintenance at all
Because maintenance is interrupt-driven and skilled, and that combination is expensive to staff. WordPress ships several core releases a year; the plugins on a typical store update weekly; PHP versions reach end of life and hosts force the upgrade on a schedule you did not choose. Each event is small. Together they need someone who can test an update, read a PHP error and roll back a bad deploy, available on the day it happens. In-house, that is either a developer being pulled off project work or a non-developer clicking "update all" and hoping. Outsourced, it is a monthly line and a named person.
The six things a retainer must include
Updates that are tested, not just applied
"Tested" means applied to a staging copy first, key pages compared, and for a store a real test order placed after anything that touches WooCommerce, the payment gateway or the shipping plugins. Ask what the test is. If the answer is "we check the site loads", that is not a test. The failures that hurt are a checkout that renders but does not charge, a cron that stopped, a form that submits to nowhere.
Monitoring beyond uptime
Uptime pings are the minimum. A store also needs PHP error monitoring, SSL expiry alerts, and ideally an alert on a run of failed payments or a gap in orders longer than usual for that store. The provider should learn about a problem from a monitor, not from your customer's email.
Backups that have been restored
Off-site, on a schedule matching how often the site changes (daily for a store, more often for a busy one), retained long enough to reach back past a problem you did not notice for a week, and restored on a test server at least once so everyone knows the restore works and how long it takes. Ask when the last restore test happened. A backup that has never been restored is an assumption.
A security response, not just security plugins
Hardening and login protection are the baseline. What separates providers is what happens after a compromise: who is contacted, how fast, what the containment steps are, who cleans the site and whether that is inside the retainer or quoted. A security plugin does not stop a compromise that arrives through an abandoned plugin or a reused password, and many compromised sites had one installed the whole time. If your provider's answer to "what if we get hacked" is a plugin name, the site will eventually be rescue work for someone.
A development allowance
Every site generates small requests: a new form, a banner, a plugin swap, a change to a shipping rule. A retainer with no development allowance either bills each of those separately (fine, if agreed) or quietly refuses them (common). Specify the allowance, the rate beyond it, and the rule that anything beyond the allowance is quoted before it is done.
A report you would actually read
Monthly, per site, in plain language: what was updated, what broke and was fixed, what the monitor caught, what the provider recommends. If you are an agency reselling maintenance, the report should be written so you can forward it to your client under your own name. That is the model behind our white-label maintenance for agencies.
What is usually missing
Four things drop out of most proposals. A staging environment, because it costs hosting money and time, so updates go straight to production. A restore test, because nobody asks. A named developer, so each month a different person opens the site cold. And a definition of "emergency", so the retainer promises "priority support" without saying what happens at 17:30 on a Friday when the checkout stops charging cards.
Ask for each of the four by name. The answers tell you more than the price does.
Red flags
- Update-and-pray. Updates applied on production, on a schedule, with no test. This is automation, not maintenance, and WordPress can do it for free.
- No staging. If the provider cannot show you a staging URL for your site, there is no staging.
- No restore test. "We back up daily" without "and we restored it on the 14th" is half an answer.
- Unlimited everything. Unlimited requests at a low monthly price means a queue, a junior, or a definition of "request" that excludes what you need.
- Hosting lock-in. Maintenance only available if you move to the provider's hosting, with no stated exit process.
- No mention of PHP. A provider who does not talk about PHP versions has not been through a forced host upgrade with a client.
How to compare two proposals
Put them side by side on the questions that matter, not on the feature list. This is the shape of the comparison we use when an agency sends us a competing proposal to read:
| Ask | Good answer | Weak answer |
|---|---|---|
| Where are updates tested? | Staging copy, then production, with a test order on stores | Production, with a rollback "if needed" |
| When was a restore last tested? | A date, and how long it took | "Backups are automatic" |
| Who is my developer? | A name, and the same one each month | "Our support team" |
| What counts as urgent, and what happens? | Defined, with a phone number and a target | "Priority support" |
| What is the development allowance? | Hours or scope per month, overage rate stated | "Unlimited small tasks" |
| What do I get if I leave? | Credentials, documentation, latest backup | Not addressed |
Price the difference last. A proposal that is cheaper by a modest amount and has no staging will cost more than the difference the first time an update takes the checkout down.
When a retainer is not worth it
Three cases. A static brochure site with two plugins and no forms can be maintained by a competent host's managed WordPress plan plus an annual check. A site you plan to rebuild within six months should get a minimal safety net and no development allowance. And a site with a full-time in-house WordPress developer who has time for it does not need a retainer, though it usually needs a second pair of eyes on security.
The case for a retainer is strongest where the site earns money directly. A WooCommerce store's maintenance risk is measured in lost orders per hour of downtime, and an hour is a normal recovery time for a site with no staging and an untested backup. Stores also carry problems that build slowly. WooCommerce keeps product data in posts and postmeta, which gets slow to filter as the catalog grows, and a good retainer notices that trend in the monitoring and points you to speed work before customers notice it at the checkout.
Common questions
How much development should be included in a maintenance retainer?
Enough to cover the routine "can you just" requests without a separate quote each time, and no more. A stated number of hours per month, rolling over or not (say which), with a rate beyond that. Retainers that bundle large development allowances are usually charging you for idle time.
Can a retainer cover a site built by someone else?
Yes, but it should start with an audit. The provider needs to know what state the site is in before taking responsibility for it, and a site with modified plugin files, an old PHP version or an unknown backdoor is a rescue first and a retainer second.
Should an agency outsource maintenance or hire for it?
Outsource if the site count is modest or the work is uneven. Hiring makes sense when maintenance alone fills a senior developer's week, and it rarely does. Most agencies land on a white-label retainer per site, with the agency's name on the report.
What does "tested up to" on a plugin have to do with maintenance?
It is the plugin author's statement of which WordPress version they have checked their plugin against. A maintenance provider should look at it before updating core, and should tell you which of your plugins are lagging. Plugins abandoned by their authors are the most common source of a broken site after a core update.
Next step
If you have a proposal in hand and want a second opinion on what it leaves out, or you want one from us, send the site list and what has been going wrong.
Want a senior developer to look at your site?
Tell us what you need. You get a written scope and a fixed price, usually within one business day.
