---
title: 'What a WordPress maintenance plan should actually cover (and what most leave out)'
url: 'https://mountainairweb.com/blog/what-a-wordpress-maintenance-plan-should-cover'
markdown: 'https://mountainairweb.com/blog/what-a-wordpress-maintenance-plan-should-cover.md'
date: '2026-09-09'
description: 'Short answer: A WordPress maintenance plan should cover six things: updates that are tested before they reach production, security monitoring with virtual patching for the gap between a disclosure and a fix, backups that someone has actually restored, performance and accessibility checks per templa…'
taxonomy:
  category:
    - WordPress
  tag:
    - maintenance
    - 'care plans'
    - hosting
---

[WordPress](https://mountainairweb.com/blog/category:WordPress) September 9, 2026 11 min read 

# What a WordPress maintenance plan should actually cover (and what most leave out)

Three very different things are sold under one name. Here is how to tell which one you are buying.

  Nicholas Murray Author  

**Short answer:** A WordPress maintenance plan should cover six things: updates that are tested before they reach production, security monitoring with virtual patching for the gap between a disclosure and a fix, backups that someone has actually restored, performance and accessibility checks per template rather than per launch, a block of time each month for the small changes that otherwise never happen, and a written response target with a named person behind it. Managed hosting covers the first item partially and the second at the network level; a cheap "updates and backups" subscription covers the first two on paper and the rest not at all; a developer-led care plan is the only one of the three where someone who knows your codebase is on the hook for all six. Most plans leave out the two that cause the expensive failures: restore testing and regression checks. The comparison table and the signing checklist are below.

## Why "maintenance" means three different things

When a marketing manager asks us to quote a WordPress maintenance service, they are usually comparing three offers that look similar on a pricing page and are not similar in practice.

**The hosting-company plan.** WP Engine, Kinsta, Pressable and the rest sell a platform: servers, CDN, a network firewall, daily backups, staging and a support desk. Much of it is excellent, but the scope documents draw clear edges. Kinsta lists "changes to the appearance of your website", "changes to the content of your website" and "changes to the functionality of your site's theme and plugins" as out of scope, and says plainly, "We don't provide updates for WordPress core" ([Kinsta scope of support](https://kinsta.com/docs/support/scope-of-support/managed-wordpress-scope-of-support/), [Kinsta on core updates](https://kinsta.com/knowledgebase/wordpress-core/)); plugin and theme auto-updates are a paid add-on. WP Engine's Smart Plugin Manager checks for plugin and theme updates daily, runs a visual regression test and rolls back on failure, but it cannot update "private themes or themes that require manual updates directly from a developer", and it is included on some plans and an add-on on others ([WP Engine](https://wpengine.com/support/smart-plugin-manager/)). We put most WordPress clients on WP Engine and we are an Agency Partner, so this is not a complaint about the host. It is a description of where the host stops.

**The "updates and backups" subscription.** A fixed monthly fee from a volume provider: weekly updates, a backup, a malware scan, a monthly report. The updates are run by a script or a junior technician across hundreds of sites at once, and nobody on that plan has read your theme. When an update breaks the layout, you find out from a customer, and the fix is "we restored last week's backup", which also restored last week's content.

**The developer-led care plan.** A studio or freelancer who built the site, or audited it on takeover, keeps it running under a written agreement with response targets and a monthly block of hours. It costs more than the subscription and less than an in-house developer. Whether the difference is worth paying depends on what the subscription leaves out.

## What the numbers say about the job

Patchstack logged 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than the year before, with 91% in plugins, 9% in themes and six in core, all low priority. 46% had no vendor patch at the moment of disclosure, and for the most heavily exploited flaws the median time from disclosure to mass exploitation was five hours ([Patchstack, State of WordPress Security in 2026](https://www.patchstack.com/whitepaper/state-of-wordpress-security-in-2026/)). That one figure sets the bar for any maintenance plan: a weekly update run is not a security control when the exploit lands in hours. The control is virtual patching, which blocks the exploit pattern at the application layer before the vendor fix exists. We covered how that works, and what managed hosting does and does not catch, in [WordPress security in 2026](https://mountainairweb.com/blog/wordpress-security-for-marketing-teams); this post is about the plan around it.

The second number is quieter. PHP supports each release for four years, and as of this month PHP 8.2 has under three months of security fixes left (ending 31 December 2026), 8.3 ends at the close of 2027, and only 8.4 and 8.5 are in active support ([php.net](https://www.php.net/supported-versions.php)). WordPress 7.0 raised its minimum to PHP 7.4 and its recommended version to 8.3 ([Make WordPress Core](https://make.wordpress.org/core/2026/01/09/dropping-support-for-php-7-2-and-7-3/)). Hosts move you forward on their own schedule, and when they do, a plugin last updated in 2022 can throw a fatal error. This is dependency drift: nothing broke at launch, but every month the versions underneath the site move further from what the code was written against. A plan that only applies updates never looks at drift. A developer does, because they get the call.

## The comparison

Here is how the three models usually line up. "Usually" is doing work in that sentence; the checklist further down is how you confirm it for a specific vendor.

| What you need | Hosting-company plan | "Updates and backups" subscription | Developer-led care plan |
|---|---|---|---|
| Core, plugin and theme updates | Core auto-updates; plugin/theme updates automated on some plans or as an add-on, repository plugins only | Weekly or monthly, usually scripted; premium and private plugins often skipped | Scheduled, tested on staging first, premium and custom code included |
| Security monitoring | Network WAF, malware scanning, DDoS mitigation | Malware scan plus a security plugin | Vulnerability feed matched to your installed plugins, virtual patching same day, host WAF still in place |
| Backups, and are they tested? | Daily, off-site, 30-day window on WP Engine ([docs](https://wpengine.com/support/restore/)); restores are self-serve, never tested for you | Daily or weekly, often to the same server; tested rarely | Host backups plus an independent off-site copy; restore rehearsed on staging on a schedule, recovery time written down |
| Performance | Fast servers and a CDN; "optimization of your website for improved performance on website speed tests" is out of scope at Kinsta | A caching plugin and a PageSpeed screenshot in the report | Core Web Vitals tracked per template from field data; regressions traced to the plugin or deploy that caused them |
| Accessibility regressions | Not monitored | Not monitored | Automated checks on key templates after updates; manual review when a plugin changes markup |
| Dependency drift and PHP version | PHP upgraded by the host on their timeline, with notice | Not tracked | PHP end-of-life tracked, compatibility tested on staging before the host moves you |
| Content changes and small fixes | Out of scope | Out of scope, or a small ticket allowance with no one who knows the site | Monthly hours for landing pages, forms, tracking and fixes |
| Response targets | Platform uptime SLA (WP Engine: 99.95%, credits of 5% of the month's fee per hour of excess downtime, claimed within 30 days, [SLA](https://wpengine.com/legal/sla/)); support tickets have no fix-time commitment for your code | "Best effort" during business hours, sometimes a vague "priority support" tier | Severity-based targets in the agreement: critical, high, normal, planned |
| Who you talk to | A support desk, rotating staff, good at the platform and not allowed to touch your code | A ticket queue | The developer who built or audited the site |

Three rows deserve a closer look, because they are where plans get sold and where they fail.

### Backups that have never been restored

A backup you have never restored is a hypothesis. WP Engine's backups are solid: daily, encrypted, off-site on S3 in your region, 30 days of checkpoints, and a restore the docs honestly describe as "destructive" because it overwrites everything ([WP Engine](https://wpengine.com/support/restore/)). What no host does is rehearse a restore for you, time it, and confirm the uploads folder, the form entries and the product database came back intact. In our experience the first time most teams restore a backup is during an incident, which is when they learn the backup plugin had been failing silently for months, or that the subscription provider was backing up to the server that was just compromised. A care plan should put a restore test on the calendar and report the recovery time.

### Regressions nobody is watching for

A plugin update changes a form's markup and the labels stop being announced by screen readers. A new hero slider pushes Largest Contentful Paint from 2.1 seconds to 3.4. Neither triggers an error or a malware alert, and both will be waiting at the next accessibility complaint or ranking review. Google grades Core Web Vitals at the 75th percentile of real visits, with "good" meaning LCP within 2.5 seconds, INP within 200 milliseconds and CLS under 0.1 ([web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds)). A monthly PageSpeed screenshot of the homepage does not tell you a blog template has drifted into "poor". Tracking by template, from field data, does.

### Who answers the phone

A hosting support desk is excellent at the platform and is prohibited, by its own scope document, from editing your code. A subscription queue fixes what the script can fix. A developer who knows the site can tell you in five minutes that the checkout failure is Tuesday's payment-plugin update and roll it back from staging. That difference is what response targets are for. Ours are published on the [Trust page](https://mountainairweb.com/trust) by severity, from critical (site down or compromised) through planned work, and written into each care agreement rather than left as marketing copy.

## What our care plans actually include

For the sake of a concrete example, this is the baseline on every plan we run, on WP Engine for WordPress or on managed hosting for our flat-file sites:

- Core, plugin and theme updates tested on staging before production, including premium and custom code.
- Virtual patching (Patchstack via WP Umbrella) applied the same day a plugin vulnerability is disclosed, with the real update following inside the plan's window.
- Daily off-site backups on top of the host's, with restore tests on a schedule.
- Uptime and SSL expiry monitoring from outside the host's network.
- Core Web Vitals and page weight tracked per template on the plans that include monitoring.
- A monthly or quarterly health report that lists what changed, what was patched and what we recommend.

Above that baseline, plans differ by the depth of monitoring and the hours set aside for requests. Hours are what make a care plan different from insurance: the tracking pixel, the new landing page, the hidden form field for the CRM, the redirect list after a campaign. Those tasks are too small to justify a project and too important to leave undone. Details are on the [Care and hosting](https://mountainairweb.com/services/care-hosting) page. Hosting is billed separately and stays in your name, so you can see what you pay for and leave with your site intact.

## Questions to ask before signing

Take these to any vendor, including us. A good provider will have short answers; a weak one will have long ones.

1. **Which updates are excluded?** Private themes, premium plugins with licence keys, anything custom. Who handles those, and how often?
2. **Where do updates run first?** If the answer is "production, with a backup beforehand", you are buying a rollback service, not a testing service.
3. **What happens between a plugin vulnerability being disclosed and your next update run?** Listen for "virtual patching". If you hear "our firewall", ask whether it is the host's network WAF or an application-layer rule set.
4. **When did you last restore one of our backups, and how long did it take?** "Our host keeps 30 days" is not an answer.
5. **Where are the backups stored?** Same server, same account, or genuinely off-site?
6. **What is monitored, and from where?** Uptime from outside the host, Core Web Vitals from field data, accessibility checks on key templates, or just a malware scan?
7. **Which PHP version are we on, when does it reach end of life, and who tests the upgrade?**
8. **What are the response targets, by severity, and are they in the contract?** Ask what "response" means versus "resolution".
9. **Who does the work?** Named people, their seniority, whether they have read the codebase, and what happens when they are on holiday.
10. **What does a month of hours cover, and what happens to unused ones?**
11. **What do we get if we leave?** Repository access, hosting account in our name, documentation, credentials revoked on a checklist.
12. **What is explicitly not included?** Honest vendors have this list ready; the hosts' scope-of-support pages are a good model of how clearly it should be written.

## Choosing between the three

If your site is a brochure that changes twice a year and runs eight well-maintained plugins, a managed host with its update add-on on and someone internal who checks in monthly is defensible. You are accepting that nobody tests restores, nobody watches for regressions and nobody is contractually on the hook when a plugin breaks the contact form, and deciding that is fine for the stakes.

If your site publishes weekly, runs campaigns, carries gated content or a CRM integration, and is owned by marketing rather than IT, the cheap subscription is the option we would avoid. It has the appearance of coverage without the person, and the person is the product. Pay for the host, and pay a developer who knows the site to run it, with hours for the small things and targets written down. Agencies with a portfolio of client sites face the same decision at scale: white-labelled, hours that pool sensibly, a developer reachable in the tools your account team already uses.

## What to do next

If you are comparing plans right now, send us the proposals and the current plugin list and we will tell you honestly which gaps matter for your site, including the case where the host's own plan is enough. [Book a call](https://mountainairweb.com/contact).

## More from the journal

 [See all posts](https://mountainairweb.com/blog) 

WordPressSep 16, 2026

### Headless WordPress in 2026: why we usually say no (and what we recommend instead)

Headless WordPress doubles your systems, drops the editor preview and most plugins, and the reasons people wanted it…

[Headless WordPress in 2026: why we usually say no (and what we recommend instea…](https://mountainairweb.com/blog/headless-wordpress-in-2026)

WordPressAug 5, 2026

### WordPress security in 2026: what your IT team will ask, and the honest answers

11,334 WordPress vulnerabilities in 2025, 91% of them in plugins, median five hours from disclosure to exploitation. Here…

[WordPress security in 2026: what your IT team will ask, and the honest answers](https://mountainairweb.com/blog/wordpress-security-for-marketing-teams)

WordPressJul 22, 2026

### WordPress or flat-file: how to choose for a marketing site in 2026

A practical decision guide for marketing teams and agencies: when a flat-file CMS like Grav beats WordPress, when…

[WordPress or flat-file: how to choose for a marketing site in 2026](https://mountainairweb.com/blog/wordpress-or-flat-file-for-a-marketing-site)

---

## Navigation

- Parent: [Blog](https://mountainairweb.com/blog.md)
- Previous: [Headless WordPress in 2026: why we usually say no (and what we recommend instead)](https://mountainairweb.com/blog/headless-wordpress-in-2026.md)
- Next: [The website migration SEO checklist: before, launch day, and the 90 days after](https://mountainairweb.com/blog/website-migration-seo-checklist.md)