18 min read

What a WordPress Care Plan Should Include, and What to Ask Before You Pay

Varun Dubey

Founder, Wbcom Designs · Published Nov 11, 2026 · Updated Nov 11, 2026

A WordPress care plan is a monthly service where a team keeps your site updated, backed up, monitored and fixed when something breaks. A good WordPress care plan includes six things you can check: off-site backups with restores that have been tested, updates tried on a staging copy before they reach your live site, same-day action when a critical plugin flaw is announced, uptime and security monitoring, a plan for upgrading PHP before it runs out of support, and a written report each month. Before you pay, ask how each one works, how fast the team responds, and who does the work. This guide gives you the questions, built around real incidents from the last few months.

It is written for site owners and managers who are not developers. Where a technical detail helps you judge an answer, we mark it. Every date and number below comes from a page we read on 10 or 11 November 2026, and we link to it. We run care plans ourselves, so we say plainly what we do, and we do not quote prices for our own plans here. The current plans are on our maintenance page.

What a WordPress care plan is, and what it is not

Your site is made of WordPress itself, a theme, and usually a dozen or more plugins, running on a server with a particular version of PHP. Each of those pieces gets updates, and some of those updates fix security holes. A care plan is the routine that applies those updates safely, watches for trouble and cleans up after it.

It is not the same as hosting. Your host keeps the server running. A care plan keeps the site software healthy. Some hosts bundle a little of both, so ask which parts of your host’s plan are really about your WordPress software and which are only about the server.

It is also not a promise that nothing will ever go wrong. Sites get hacked, updates break layouts, and payment forms fail. What you are buying is a shorter, calmer response to those events, and a lower chance that they happen. That is why most of this checklist is about what happens on a bad day.

If you want the broader argument for why clients still pay for this kind of service even as AI site builders get better, we covered it in What Clients Still Pay an Agency For After AI Site Builders: Support, Off-Site Backups and Tested Restores. This post goes a step further and gives you the buyer’s checklist.

The care plan checklist at a glance

What to look for	The question to ask	A good answer sounds like
Same-day patching	What happens when a critical flaw is announced in a plugin I use?	A named process, a time target, and a plan for when no fix exists yet
Update testing	Where are updates tried before my live site?	On a staging copy, with checks on the pages that make money
Backups	Where are copies stored, and when was a restore last tested?	A different provider from your host, and a dated restore test
PHP version	Which PHP version do I run, and when does it lose support?	A date, and a plan to move before it
Uptime	How do you know my site is down, and who is told?	Outside checks from more than one place, alerts to a person
Security monitoring	What do you watch for, and what happens if the site is infected?	File and login monitoring, with cleanup included or priced up front
Response time	How fast do you reply, and what counts as urgent?	Written targets that separate urgent from routine
Reporting	What do I receive each month?	A short plain-language report of what changed
Scope	What is included and what is billed extra?	A written list, with edits and emergencies clearly placed
Access and exit	Who owns the accounts, and how do I leave?	You own everything, and leaving is simple

The rest of this post explains each row.

1. Same-day patching: what a real critical flaw looks like

The first test of a care plan is what it does when a serious security flaw is announced in a plugin on your site. Here is a recent example, from Wordfence’s public vulnerability database.

On 24 August 2026, Wordfence published CVE-2026-19718, rated 9.8 out of 10, which it classes as Critical. It affected three plugins: the WP Remote plugin, MalCare Security and BlogVault Backup & Staging, in all versions before 6.65. Wordfence’s description says a weak random number generator let attackers guess their way into the plugin’s remote connection feature, so unauthenticated attackers could connect a site to their own remote management software and take it over. The fix was version 6.65. The rating’s own vector says an attacker needs no account and no help from a user.

Two things stand out for a buyer. First, two of those three plugins are security and backup products. The tools people install to protect a site can themselves be the way in, so a care plan cannot simply assume that having a security plugin means being safe. Second, the fix existed, and the only thing between a site and a takeover was how fast someone applied it.

So ask: When a critical flaw is announced in a plugin I use, how soon is it patched, who decides, and what do you do while you test it? A strong answer has three parts. It names how the team hears about flaws, for example by scanning your plugin list against a vulnerability database every day. It gives a time target for critical issues, in hours not days. And it explains how the patch is applied without breaking the site, usually a fast test on a staging copy followed by a release to the live site in a quiet window.

Be wary of the answer “we update everything on the first of the month.” Monthly batches are fine for routine updates. They are too slow for a flaw rated 9.8.

When there is no fix yet

Updating is not always possible, because a patch does not always exist. Wordfence’s weekly report for 7 to 13 September 2026 lists 259 vulnerabilities disclosed in 207 WordPress plugins in that single week. Of those, 228 were patched, 1 was partially patched and 30 were unpatched. By severity, 10 were Critical, 66 High and 183 Medium.

Those 30 unpatched ones are the ones to ask about. If a plugin on your site has a serious flaw and the author has not fixed it, a good care team has options: switch the plugin off, replace it, restrict access to the vulnerable feature, or add a rule at the firewall. Ask which of these they would use and who decides. The wrong answer is silence, or “we will wait for the update.”

Why plugins are the main risk

It helps to know where flaws come from. Patchstack’s public statistics page for 2025 shows plugins accounted for 10,230 of the published vulnerabilities, 91 percent, against 1,009 for themes (9 percent) and 2 for WordPress core. The same page shows 4,702 of the published entries, 42 percent, marked as not patched. Patchstack labels that figure as the patch status of published vulnerabilities, so it describes where the database stands today, not the moment each one was disclosed. We read both figures straight from the page and did not recalculate them.

The plain message for an owner: your risk grows with the number of plugins, and core WordPress is rarely the problem. A care plan that talks only about updating WordPress core is skipping the part that matters. It is also a reason to remove plugins you no longer use, and our post on the impact of outdated plugins on your WordPress website looks at that side of the problem.

2. Update testing: staging before production

The opposite risk to being slow is being careless. An update that fixes one thing can break another, and a checkout that fails for an afternoon costs real money.

Ask: Where are updates tested before they reach my live site? The right answer is a staging copy, which is a private duplicate of your site where changes are tried first. Developer detail: a better team also runs an automated visual comparison, taking screenshots before and after and flagging differences, and checks the paths that earn money by hand, such as a test purchase, a contact form and a login.

Then ask about the failure case. If an update breaks something on the live site, how do you undo it, and how long does that take? A team that has thought about it will describe a rollback, not an apology.

Our own approach, as stated on our maintenance page, is that updates go to staging first, get a visual regression check, and then ship to production in a low-traffic window.

3. Backups, and the restore test that proves them

Backups are the single most misunderstood item on any care plan. Almost every plan promises them. The question is whether they work when you need them. We went through this in detail in our earlier post on off-site backups and tested restores, so here is the short buyer’s version.

Where are the copies stored? A backup kept on the same server as the site disappears with it. Ask for storage at a different provider.
How often are they taken? Daily is a common baseline. A site that takes orders or member sign-ups all day may need more.
How long are they kept? A problem is sometimes noticed days late. A single copy from last night may already contain the damage.
When was a restore last tested, and can I see the date? A backup nobody has restored is a hope, not a backup.
How long does a restore take? Ask for a number, even a range. “Hours, not days” is a start. Treat a refusal to estimate as information.

For reference, our maintenance page describes daily incremental backups to S3 or B2 storage in a region separate from your host, and a restore drill every quarter, with recovery time measured in hours, not days. Judge any provider, ours included, on whether they can show you the last test.

4. PHP: the quiet deadline

PHP is the programming language WordPress runs on, and each version is supported for a limited time. When a version loses support, it stops getting security fixes, and so does every site running on it. Many owners have never heard of this deadline, and hosts rarely announce it loudly. A care plan should track it for you.

The PHP supported versions page, as of 10 November 2026, shows:

PHP version	Released	Active support until	Security fixes until	Status
8.1	Not on the page	Not on the page	Ended	End of life since 31 Dec 2025, per the PHP end-of-life page
8.2	8 Dec 2022	31 Dec 2024	31 Dec 2026	Security fixes only
8.3	23 Nov 2023	31 Dec 2025	31 Dec 2027	Security fixes only
8.4	21 Nov 2024	31 Dec 2026	31 Dec 2028	Active support
8.5	20 Nov 2025	31 Dec 2027	31 Dec 2029	Active support

The PHP project’s end-of-life page lists PHP 8.1 as ended on 31 December 2025 and PHP 8.0 as ended on 26 November 2023.

Here is what that means for you. If your site runs PHP 8.1 or older, it is already getting no security fixes from the PHP project. If it runs PHP 8.2, security fixes end on 31 December 2026, which is about seven weeks after we write this. A care plan worth paying for tells you in advance, tests your site on a newer version on staging, and schedules the move.

Ask: Which PHP version is my site on, and what is your plan for moving it before support ends? You can also check yourself. In the WordPress admin, open Tools, then Site Health, then the Info tab, and look under Server. Do not move the version by yourself on a live site without a backup and a test, because old plugins and themes sometimes break on newer PHP.

One honest caveat: some hosts keep patching old PHP versions on their own, which changes the risk. Ask your host in writing if you are on one of the older versions.

5. Uptime monitoring

You should not be the first person to notice your site is down. Ask how the team finds out. A good answer is an outside service that checks your site every few minutes from more than one location and sends an alert to a named person. A weak answer is “your host monitors it.” A host knows if its server is running. It does not know if your checkout page is showing an error.

Ask what the alert triggers. An alert that lands in an inbox nobody reads overnight is not monitoring. Our maintenance page describes external checks from several regions, with alerts to Slack, email or PagerDuty depending on the plan.

Ask also about speed. Slow is a kind of down. If the plan includes performance monitoring, ask what it measures and what is done with the result. Our own page mentions real-user Core Web Vitals monitoring and a monthly PageSpeed check.

6. Security monitoring and cleanup

Monitoring is the part of a care plan that notices trouble early. Ask what is watched. Useful answers include changes to core files, failed login attempts, new admin users appearing, and a regular scan of your plugin list against a vulnerability database. Our own page lists file integrity monitoring, failed-login alerts and a vulnerability scan of the active plugin list every 24 hours.

Then ask the question owners forget: If my site is infected, is the cleanup included, and what does it cost if not? Plans differ widely. Some include malware removal. Some charge per incident. Get the answer in writing before you need it.

Ask, too, about the opposite problem, a false alarm. A team that reports every scan as an emergency trains you to ignore it.

7. Response times and what counts as urgent

“24/7 support” on a pricing page can mean anything. Ask for the response time in writing, and ask what it measures. A reply that says “we have received your ticket” is an acknowledgement, not a fix. You want to know both numbers: how fast someone looks, and how fast they work on it.

Ask them to define urgent. A good definition is concrete: the site is down, checkout is broken, the site is showing spam or a hacked page. Everything else is routine. Then ask what happens outside business hours, because that is when sites tend to fail. Do not rely on one headline number from a marketing page. Ask for the response targets in the contract or service description, and keep a copy.

There is a human side to this too. A fast reply that does not help feels slow. We wrote about that in Why Support Tickets Feel Slow: The Hidden, Surprising Reason, and it is worth reading before you judge any support team by one number.

8. Reporting you will actually read

A report is how you know the work happened. Ask for a sample. A useful monthly report is short and plain: what was updated, what was patched, what changed, what broke and how it was fixed, and what the team recommends next. A long export from a plugin dashboard is not a report. If you cannot understand it in five minutes, ask for a simpler one.

Our maintenance page describes one monthly report covering what was updated, patched and changed, and what we recommend next. Whatever team you pick, ask to see last month’s report for another client with the names removed.

9. Scope: what is included, and what costs extra

Most disputes about care plans come from a gap between what the owner assumed and what the plan covered. Before you sign, get a written list that answers these questions:

Content edits. Are small text and image changes included? How many a month?
Development hours. Does the plan include any, or is every fix billed separately?
Emergency work. Is fixing a hacked or broken site included, or billed per incident?
Plugin licences. Who pays for premium plugin renewals, and who renews them? A lapsed licence is one reason updates stop appearing.
Multiple sites. What counts as a site, and are staging copies included?
Third-party breakage. What happens when a plugin author ships a bad update?
Performance work. Is speed tuning part of the plan, or a separate project?

The licence question deserves a moment. A plan can promise updates and still skip any plugin whose licence has lapsed, because the update never arrives. If you run premium plugins, our guide to licence risk for site owners shows what to track, and it is a good thing to hand to whoever runs your care plan.

10. Access, ownership and leaving

Ask who owns the accounts. You should own your domain, your hosting account, your backup storage and your plugin licences, with the care team added as users. If a provider holds those in its own name, leaving becomes hard, and you should know that before you start.

Ask what the notice period is, and whether there is a minimum term. Read the cancellation terms before you read the feature list. Ask what you receive when you leave: a full backup, a list of every plugin and licence, and documentation of anything custom.

Red flags to watch for

No dates. No date for the last restore test, no date for the PHP upgrade, no date for the last report.
Only the hosting company’s backups. A backup in the same place as the site is not a backup of the whole system.
“Unlimited” everything. Unlimited edits, unlimited support, unlimited sites. Something is limited, and you want to find out what before an incident.
One big monthly update batch. Fine for routine updates, wrong for critical flaws.
No staging. Updates tried on your live site are tested on your customers.
Vague answers about cleanup. If the answer to “what if I am hacked” is “it depends,” ask for the price list.
Locked-in accounts. The provider owns your domain, hosting or licences.
Prices with no scope. A low monthly fee that excludes everything you actually need.

Questions to ask before you pay, in one list

How do you hear about a critical flaw in one of my plugins, and how soon do you patch it?
What do you do when a flaw has no fix yet?
Where do updates get tested before my live site?
How do you undo an update that breaks something?
Where are backups stored, how often, and for how long?
When did you last test a restore, and how long did it take?
Which PHP version is my site on, and when will you move it?
How do you monitor uptime, and who gets the alert?
What security monitoring do you run, and is cleanup included?
What are your response targets, and what counts as urgent?
Can I see a sample monthly report?
What is included, what is billed extra, and who pays for plugin licences?
Who owns the accounts, and how do I leave?

A provider that answers these plainly, with dates and numbers, is probably worth the fee. A provider that cannot, or will not, has told you something useful.

Do you need a care plan at all?

Not every site does. If you have a small brochure site with few plugins, a good host with its own backups, and the time and comfort to update safely, you may manage on your own. The checklist above still helps, because you can run it on yourself: do you have off-site backups, have you tested a restore, do you know your PHP version, and who gets the alert at night?

A care plan earns its fee when the site earns money, takes orders, holds members, or runs many plugins, and when nobody on your team has the time to watch it. The cost of a plan is easier to judge against the cost of a bad week than against zero.

How Wbcom can help

We build WordPress sites and plugins, and we look after sites after launch. Our care plans are built around the checklist in this post. As described on our maintenance page, that includes daily off-site backups with a restore drill every quarter, updates tested on staging with a visual check before release, a daily scan of your active plugins against vulnerability data, file and login monitoring, external uptime checks, and one monthly report in plain language. Which of those you get, and the support level that goes with it, depends on the plan, so read the page for the current details.

The next step is simple. Talk to the team about a care plan for your site. Bring your site address, the list of plugins you run, and the questions from this post. We will tell you what your site needs, what it does not, and where we think the real risks are, including your PHP version. If you already have a provider, we are happy to review their answers with you.

Common questions

What does a WordPress care plan include?

A good plan includes off-site backups with tested restores, updates tried on staging, fast patching of critical security flaws, uptime and security monitoring, PHP version management and a monthly report. Scope for edits, development hours and emergencies varies, so get it in writing.

How much should a WordPress care plan cost?

Prices vary widely with scope, response times and the number of sites, and we do not quote a market average because we could not verify one. Compare plans by what they include and how fast they respond, not only by the monthly fee.

Is my host’s backup enough?

Usually not on its own. A backup stored at the same provider as the site can be lost with it, and few hosts test a restore for you. Ask where copies live and when a restore was last tested.

How fast should a critical plugin flaw be patched?

As fast as the fix can be tested. For a flaw rated Critical, such as the 9.8 rated one above, hours are a reasonable target and weeks are not. Ask the provider for their target in writing.

What happens if no patch exists?

A good team can switch the plugin off, replace it, restrict the feature or add a firewall rule. In one Wordfence weekly report, 30 of 259 disclosed vulnerabilities were unpatched, so this is not rare.

Do I need to worry about my PHP version?

Yes. PHP 8.1 reached end of life on 31 December 2025, and PHP 8.2 gets security fixes only until 31 December 2026. Ask your provider or host which version you run and when it will move.

What we could not verify

A market average price for WordPress care plans. We did not find a source we trust, so we give none.
Whether your own host backports security fixes to older PHP versions. That varies by host.
The Patchstack share of unpatched vulnerabilities at the moment of disclosure. The page we read reports patch status today, so we describe it that way.
Wordfence data for November 2026. The most recent weekly report we could read in full was for 7 to 13 September 2026, so we cite that and the 24 August advisory.
How any provider other than ourselves actually performs. We describe what to ask, not who to trust.