What a WordPress website care plan should include

Two sites can pay for “WordPress care” and get very different service. On one, someone updates plugins on staging, checks the contact form and the checkout, and can show you a restore that worked. On the other, auto-updates run unattended, a green backup icon sits in the dashboard, and nobody opens the site afterwards. Both sites appear in a listing as “updates, backups, monitoring.”

No one sets a standard for what a care plan has to include. You have to judge the work behind the list. This article explains what that work is, where it usually fails and what to ask before you pay. If you are comparing offers, our guide to what a maintenance package should cover goes further into contract scope.

What does a WordPress care plan actually cover?

A care plan is a recurring service. It nearly always covers four things: WordPress core, plugin and theme updates, backups, uptime and security monitoring, and a small amount of support time. Some plans add staging, reports, faster response or hosting. Malware cleanup, content edits, SEO and speed work are usually billed separately, so read the exclusions before the features.

Care plans are everywhere. In The Admin Bar’s 2025 survey of 1,233 WordPress professionals, 93.1% said they offer maintenance. That is why the same three-word bullet list shows up on so many pricing pages, and why the bullet list tells you so little.

A care plan is also not the same as managed hosting. Managed hosting looks after the server. A care plan looks after the site: the plugins, the theme, the forms, the checkout. Some hosts do part of both, so check for overlap before you pay twice.

Why updates are where a care plan earns its fee

Updates break sites more often than anything else on this list. One practitioner who runs automated updates across many client sites estimated on r/Wordpress that about 1 update in 20 caused a problem. That is one person’s estimate, not a measured rate, but it matches what you see in the support forums.

The fix is also not always the obvious one. In a 2026 wordpress.org support thread, MonsterInsights reported a failed update and rolled itself back, yet the “There has been a critical error on this website” message stayed. The real cause was two Avada theme plugins that had not updated properly. Rolling back the plugin that complained did nothing. Someone had to read the error log.

A safe update routine has the same steps everywhere:

1. Take a full backup of files and database.
2. Apply updates on a staging copy, in small batches, so a failure points at a short list.
3. Check the pages that matter: forms, login, checkout, key landing pages. The homepage loading is not enough.
4. Read the logs: wp-content/debug.log or the host’s error log.
5. Apply the same set on the live site, then check again.
6. Roll back only what failed.

If you need to find a conflict on a live site, the Health Check plugin’s troubleshooting mode turns off plugins and switches to a default theme for your logged-in session only. Visitors still see the normal site. WordPress.org’s support handbook explains how troubleshooting mode works. When a plugin breaks after an update, our guide to fixing plugins that stop working covers the usual causes, including the stuck “Briefly unavailable for scheduled maintenance” message.

Ask any provider how they handle this routine. If you would rather hand it off, the plugin updates and maintenance page explains how SiteSelf does the update cycle on request.

On a store, follow WooCommerce’s order

WooCommerce’s update guide suggests reviewing updates monthly for most stores and applying security fixes sooner. It sets out a store-specific sequence:

• Back up first.
• Test the same set of updates on staging.
• On staging, check product pages, cart, checkout, payments, shipping, taxes and order emails.
• On the live site, put the store in Coming soon mode.
• Let each update finish before starting the next.
• Run the WooCommerce database update if WordPress prompts for it.
• Test the store before you reopen checkout.

The common mistakes are the reverse of that list: updating live, refreshing the page halfway through, skipping the database update, or reopening checkout before anyone places a test order.

Why a backup that ran is not a backup that works

A successful backup job only proves that a file was written. It does not prove you can get the site back. WordPress.org’s backup handbook sets the minimum:

• Back up files and database together. The database holds posts, settings and orders. The files hold themes, plugins and uploads. A copy of one without the other is half a backup.
• Back up weekly for small, low-activity sites and daily for busy ones.
• Keep 3 to 5 recent copies in different locations, not all on the server they protect.
• Back up the database before an upgrade.
• Now and then, make a manual backup to check that the automated ones are working.

Backup tools fail too. UpdraftPlus’s own changelog records fixes for jobs that failed on particular server setups, such as FTP uploads under PHP-FPM and large-file restores that ran out of PHP memory. When a backup fails, the diagnosis starts in the backup log and the server details, not with guesswork. The only real test is restoring a copy to staging and clicking through it. Our explainer on what a backup plugin covers lists the gaps to look for.

One more catch: if the site was hacked, restoring a backup taken after the break-in can bring back the attacker’s accounts and files. Cleanup is its own job, covered in our guide to malware removal that does not come back.

On a store, a restore can delete orders

Restoring a full backup, or pushing a staging database to live, overwrites everything created since the copy was made. On a store, that includes orders. Kinsta’s push documentation warns that its database push cannot tell new WooCommerce orders from old ones. It offers a files-only push, a selective push that leaves out the WooCommerce tables, or syncing live to staging first. These options are specific to Kinsta, but the risk applies on any host.

A store owner raised exactly this fear on r/woocommerce. The replies gave the practical rule: treat code rollback and database restore as separate operations. Ask a provider how they roll back an update without touching orders. A vague answer tells you something.

Why “the site is up” misses the failures that cost money

Uptime monitoring checks that the server answers. A site can answer perfectly while it loses money. Practitioners in a 2026 r/Wordpress thread listed the failures that slipped past their monitoring:

• Contact forms stopped sending because the SMTP login expired.
• Checkout failed only in Safari because of a JavaScript error.
• An SEO plugin change added noindex to pages that should rank.
• Caching problems went unnoticed until clients reported them.

The fix is to test the site the way a stranger uses it, not as a logged-in admin. After changes, submit a real form, place a test order, open the browser console, and check that key pages are not set to noindex. Admin sessions skip caches and hide permission problems, so a logged-in admin sees a healthier site than visitors do.

What a care plan costs, and why prices don’t compare

Prices quoted by providers in Reddit threads run from about 50 euros a month for bare version updates to 375 or 400 dollars a month for larger packages. Those numbers cover very different work, so an average means nothing. One r/woocommerce commenter put the small end plainly: a 40 to 50 dollar retainer buys less than an hour of work. In The Admin Bar’s survey, the average hourly rate was $96.36 and the median $95.

The condition of the site matters more than the plan tier. Sites with 20 or 30 plugins, an old theme or a build inherited from someone else take far more time. One freelancer described spending 5 to 10 hours a week on maintenance. Another described about an hour a month overseeing 60-plus well-kept sites. Deleting plugins you no longer use is the cheapest maintenance there is.

Owners mostly complain about not seeing the work. A widely discussed r/smallbusiness post described an owner paying $400 a month whose site still had pending updates and unused plugins. Whatever the plan, ask for a record of what was done each month.

When is a care plan worth paying for?

It depends on what a broken afternoon costs you. A plan is worth the most when:

• the site takes orders, bookings or leads;
• it changes often;
• nobody in-house can read an error log.

A brochure site that changes twice a year is a different case. Its owner may do better with Site Health (Tools, then Site Health), a reliable host backup, and paying for an hour of work when something comes up. The tradeoff is real, though: without someone who already knows the site, each problem means finding help from scratch.

What to ask before you sign

• Are updates tested on staging first, or applied directly to the live site?
• What gets checked after an update: the homepage, or forms and checkout too?
• Where are backups stored, how many are kept, and when was a restore last tested?
• On a store, how does a rollback avoid wiping new orders?
• Is fixing a broken update included, or billed as extra work?
• Is malware cleanup included, or only scanning?
• How many hours of small changes are included, and what is the rate after that?
• What report do I get each month?
• If I cancel, who holds the backups, licences and admin access?

How the work changes when an agent does it

Most maintenance work is small. The process around it often isn’t: a ticket, a wait, someone who has to learn the site again, and a “done” email with no detail. SiteSelf is an AI agent for existing WordPress sites. You tell it what needs doing in chat, it does the work on the live site, and it reports what changed and what it checked.

Example request: “Update the plugins on our site. Do WooCommerce last, tell me if anything needs the database update, and check the contact page and checkout afterwards.”

The agent lists the pending updates. Before each change, it says what is about to change and whether it can be undone. It applies the updates, runs the WooCommerce database update if one is needed, then fetches the changed pages and reports back in plain language. The work is recorded, so next month you can see what happened this month.

Access depends on the task. The SiteSelf Connector plugin from the WordPress.org directory covers content and settings work. Reading debug.log, removing a stuck .maintenance file or other file and code work needs hosting (SSH) access.

The limits are part of the answer. The check is a fetch of the changed page and a written report. It is not a screenshot or a test on every device, so a Safari-only checkout bug can still get through, and a real test order is still your job. Nothing is scheduled and nothing runs unattended, so SiteSelf does not monitor the site between requests. It also does not confirm your backups. Check that a recent restore point exists before a big update cycle. Pages built with Elementor, Divi or Beaver Builder are refused at the moment of work, with the reason. The update and maintenance page shows the rest, and pricing is credit-based.