What website maintenance packages actually cover

Two quotes for “WordPress maintenance” can differ by a factor of ten, and both can be honest. Codeable and Pantheon each put the range at $30 to more than $5,000 a month. The word covers everything from a plugin that runs updates overnight to a developer who tests every change on a copy of your site and answers the phone when checkout stops working.

So the useful question isn’t what a package costs. It’s what work happens, how it gets checked, and who is responsible when something breaks. Get those three answers and you can compare any two quotes.

Why there is no standard maintenance package

No official definition of a maintenance package exists. WordPress.org’s site maintenance documentation lists tasks: update WordPress, check for dead links, delete spam, back up the site, keep a maintenance calendar. It never defines a product. Providers then mix those tasks with hosting, plugin licences, edit time, testing and incident response in whatever combination suits them.

That’s why “care plan”, “maintenance plan” and “retainer” mean roughly the same thing, and why plans with the same name cost wildly different amounts. A WordPress site needs upkeep whoever does it. Our look at WordPress for business websites covers why that cost often goes unbudgeted at launch. The package is just one way of buying that upkeep.

What the common line items mean in practice

Most packages list the same five or six items. Each one has a cheap version and a version that actually protects you, and the proposal rarely says which you’re getting.

Line item	Minimal version	Version that protects you
Updates	Auto-updates run blind on a schedule	Backup first, staging for risky updates, a fixed order, key pages and forms tested afterwards
Backups	A nightly job on the same server	Database and files, stored off-site, with restores actually tested
Security	A scanner that sends alerts	Scanning plus cleanup included, entry point closed, credentials rotated
Uptime monitoring	A ping that confirms the homepage loads	Checks on the things that make money: forms, checkout, logins
Reports	A list of plugins updated	What changed, what was checked, what failed, what is still open
Edits and support	“Unlimited minor edits”	A stated allowance, a definition of “minor”, an hourly rate for the rest

Read a proposal against the right-hand column. “Updates included” tells you nothing. “Updates tested on agreed pages, with a backup point and a change record” tells you what you’re buying.

Why updates are where a package earns its fee

Updates are the core routine task, and they’re also the usual reason a site breaks. Plugins, themes, core and PHP change all the time, and a mismatch shows up as a white screen or “There has been a critical error on this website.” WordPress’s Advanced Administration Handbook lists plugin compatibility problems as a cause of exactly that. WooCommerce’s self-service guide names outdated software and plugin or theme conflicts among the common causes of store problems.

The process that works is the same across WordPress’s docs, WooCommerce’s docs and practitioners who run dozens of sites:

1. Take a fresh backup of files and database, stored off the server.
2. Run updates on staging first for any site where a break costs money: stores, membership sites, builder-heavy sites.
3. Update in a consistent order, one at a time, and let each finish before starting the next.
4. Test what matters. A site that loads isn’t the same as a site that works. Submit the contact form and run a checkout.
5. Keep the rollback ready, and know before you start what rolling back would lose.

When a step fails, the cause is usually a single plugin. Our guide to fixing plugins that stop working walks through isolating it.

Two misunderstandings cause most of the damage here. First, auto-updates aren’t a maintenance plan. Kinsta’s documentation says its automatic updates take a backup beforehand and may restore it after detecting a change, and that this rollback can lose changes made during the update window. On a store, those changes are orders. Automation helps, but someone still has to notice what it did.

Second, removing the maintenance message doesn’t mean the update worked. When an update is interrupted, WordPress can leave a .maintenance file in the site root, and every visitor sees “Briefly unavailable for scheduled maintenance. Please check back in a minute.” The handbook’s fix is to delete that file over FTP. But the plugin or core files may still be half-updated afterwards, so confirm the update finished or run it again.

WooCommerce stores need a stricter routine

WooCommerce’s guide to updating says a monthly cadence suits most stores, with security fixes or broken functionality handled sooner. Its procedure asks for more than a brochure site needs:

• Back up the database as well as wp-content. A files-only backup has no orders in it.
• Stage the full set of updates together: WooCommerce, extensions, payment gateways, theme.
• Let each update finish, then run the database update if WooCommerce asks for one.
• Watch Scheduled Actions for stuck or failing background tasks.
• Test products, cart, checkout, payments, shipping, taxes and order emails before reopening checkout.

If a store is on a package that just presses “update all”, the package isn’t doing the store’s job.

Why a backup only counts if it restores

A backup job that reports success proves that a file was written. It doesn’t prove you can get the site back. WordPress.org recommends keeping a backup on the hosted site and a separate copy elsewhere, because a backup on the same server goes down with the server or the hosting account.

There are four failures to ask about:

• Same-server storage. The host fails or the account is suspended, and the backups go with it.
• Never-tested restores. WP Umbrella suggests a restore test to staging about once a quarter for revenue sites, roughly 20 minutes each. That’s a suggested effort, not a measured one.
• Restoring over new orders. Rolling a store back to last night wipes out today’s sales.
• Restoring an infected copy. A backup taken after a compromise brings the attacker’s code back.

Our explainer on what a backup plugin covers goes through where each popular approach falls short.

Why security scanning is not malware removal

Pantheon’s guide to maintenance plans says lower-cost plans often scan or alert and bill cleanup separately. You find out which kind you have on the day of a hack, at emergency rates.

A real cleanup is a short incident response job. Ben Ryan, who sells WordPress maintenance, lays it out in eight steps: isolate, back up, scan, clean the files, clean the database, rotate every credential, update everything, then verify and harden. He notes that most do-it-yourself cleanups find the malware but skip the last three steps, and the site gets reinfected within days. Our guide to malware removal that does not come back covers that sequence.

The question to put to a provider is simple: is cleanup included, or does it count as emergency work at an hourly rate?

Managed hosting covers the platform, not your site

Good managed hosts handle the server, often core updates and backups, and sometimes automatic plugin updates. Pantheon draws the line clearly: plugin conflicts, application testing, edits and break/fix work usually fall outside hosting. Those stay with you or with whoever maintains the site.

For a simple brochure site with few plugins, good hosting plus a monthly check of your own may be enough. Once the site has integrations, custom code or a checkout, someone has to own the application layer.

How to read a price without a going rate

No representative pricing survey exists for small businesses, so any “average” you read is a vendor’s estimate. WP Umbrella, which sells maintenance tooling, puts productized care plans at $50 to $150 per site per month, and premium or developer-led service at $240 to $1,000 or more. Those are bands, not benchmarks.

Three things move a fair price more than the plan’s name:

• Risk. A brochure site that’s offline for an afternoon costs little. A store that’s offline costs orders. Staging, human testing and fast response all cost money, and they’re what the higher tiers pay for.
• Human time included. Edit allowances in community examples run from 15 minutes to two hours a month. Check what happens when you go over.
• What sits outside the fee. Cleanup, repair after a bad update, speed projects, new pages, licences. In MainWP’s 2023 Web Care Survey, 65% of consultants said they include software or plugin licences in their plans, so some quotes bundle licences and others don’t. Codeable’s pricing guide makes the same point: compare the costs outside the fee, not the headline number.

The same MainWP survey found three tiers to be the most common structure. It had only about 64 responses, so treat that as a pattern among providers, not a rule.

Questions to ask before you sign

Ask for answers in writing. Better still, ask for a sample monthly report.

• Are updates tested on staging before production? For which sites?
• Which pages and flows do you check after updates: forms, checkout, logins?
• How often are backups taken, where are they stored, and when was a restore last tested?
• Does the plan include malware cleanup, or only scanning?
• If your update breaks the site, who pays for the repair, and does it come out of my support hours?
• What counts as a “minor edit”, how many are included, and what is the hourly rate beyond that?
• What response time do you commit to for an outage?
• Who owns the domain, the hosting account and the backups if we part ways?

Treat “zero downtime”, “fully managed” and “unlimited” as red flags unless the proposal says what work sits behind them. The same goes for any plan that updates a store with no staging.

How the work changes when an agent runs the updates

Most of what a package sells is small, repeatable work. The process around that work is where the cost goes: a ticket, a wait, someone reading the request, a report you can’t quite follow. Updating three plugins on a contact-form site shouldn’t need a support queue and a monthly invoice line you can’t verify.

SiteSelf takes a different approach. You tell the agent what you need in chat, it does the work on the live site, checks the result, and reports what changed. Here is what an update request looks like.

Example request: “Run the pending plugin updates on the shop. Do the payment gateway on its own, after the others. Tell me if WooCommerce wants a database update, and tell me what you changed and what you checked on the shop and checkout pages.”

The agent lists what’s out of date and reads the changelogs for anything that looks like a major release. Before it changes anything, it says what it’s about to change and whether that can be undone. It applies the updates in the order you asked for, reports whether the WooCommerce database update is pending, then fetches the shop, cart and checkout pages and tells you in plain language what it found. What it did is recorded. Our page on WordPress plugin updates handled in chat covers this work in more detail.

Access matters. Content and settings work goes through the SiteSelf Connector plugin from the WordPress.org directory. Updating plugin files and fixing anything that breaks needs hosting (SSH) access.

There are also limits:

• The check is a fetch of the changed page, not a full device test. It shows that checkout loads. It doesn’t prove a payment goes through, so placing a test order is still your job.
• Nothing runs unattended. There’s no monitoring and no scheduled update cycle. Work happens when you ask.
• Pages owned by Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason.
• Your backup plugin or your host’s restore points are still your safety net.

That makes it a different trade from a package. You give up a provider who watches the calendar for you. In return, each change is done when you ask, explained before it happens and reported after. Pricing is credit-based, and the details are on the pricing page.

Frequently asked questions

Is a care plan different from a maintenance plan?

Not in any consistent way. Providers use “care plan”, “maintenance plan” and “retainer” for the same kind of recurring arrangement. Compare the listed tasks, not the name.

Can I maintain a WordPress site myself?

Yes, especially a simple one. WP Umbrella estimates a manual update session at 15 to 30 minutes per site, once or twice a month. The routine part isn’t the hard part. The hard parts are tracking down a plugin conflict, restoring safely and cleaning up after a hack, and those are the moments when a package or a specialist pays for itself.

Are automatic updates enough on their own?

Not for a site that makes money. Automatic updates don’t test your forms or checkout, and rollbacks can lose data. Kinsta’s docs say its rollback can lose changes made during the update window. If you rely on auto-updates, someone still needs to check the site afterwards.

What does “unlimited edits” usually mean?

Usually small text and image swaps. Pantheon notes that new pages, content writing and functionality changes are typically excluded. Ask for the per-request limit and the hourly rate for anything bigger, in writing.

Who pays if the provider’s update breaks my site?

It depends on the contract, and many contracts don’t say. Pantheon flags that some plans bill troubleshooting of update-caused problems separately. Settle it before you sign, along with whether that repair counts against your support hours.

How often should a WordPress site be updated?

WooCommerce suggests checking monthly for most stores, and acting sooner for security fixes or broken functionality. Practitioners range from daily to monthly. The common ground is to apply security patches quickly and test major feature releases on staging first.