What a WordPress care plan actually covers (and what it shouldn’t).

Launch day is the easiest day in a website’s life. Everything is fresh. Plugins are current, the theme is built to spec, the backups are clean, and the person who built it still remembers every decision they made. From day two, that starts to decay. Plugins push updates. PHP moves a minor version on the host. Spam finds the comment form. Someone edits a page and breaks a layout nobody notices for three weeks. A payment gateway add-on quietly stops matching the WooCommerce core it depends on.

None of this is dramatic. That’s the problem. Unmaintained sites don’t fall over on a Tuesday. They rot slowly, then fail all at once, usually at the worst possible time. A care plan is the thing that keeps the rot from compounding. After nine years and 100-plus sites, most of them still on their original build, we have strong opinions about what that plan should contain and what it has no business pretending to be.

Entropy is the default, not the exception

A WordPress site is not a finished object. It’s a running system sitting on top of other running systems: PHP, MySQL or MariaDB, a web server, a CDN, dozens of plugins each on their own release cadence, and WordPress core itself. All of those move independently. Nobody coordinates their schedules around your launch.

The common failure pattern we get called in to fix is the same every time. A founder pays well for a good build, the site launches clean, and then nothing touches it for eight months. By the time something visibly breaks, there are forty pending plugin updates, a PHP deprecation warning leaking into the page source, an expired SSL on a subdomain, and a backup system that’s been silently failing since March. The fix is no longer a fifteen-minute update. It’s a recovery project.

Maintenance is cheap when it’s a rhythm and expensive when it’s a rescue. That is the entire argument for a care plan in one sentence.

The cadence we run on every maintained site

We don’t maintain sites by waiting for tickets. We run a calendar. The work is split across weekly, monthly, and quarterly cycles so nothing accumulates quietly in a corner.

Weekly

• Plugin and theme updates, applied on staging first, then production. Never blind, never bulk-clicked.
• A backup verification check. Did the scheduled backups actually run, and are the files the size they should be.
• Uptime and security scan review. Wordfence or the host’s malware scanning, plus the uptime monitor log.
• Spam and comment queue sweep on sites that take comments.

Monthly

• WordPress core updates where a point release has landed and we’ve let it sit long enough to be sure.
• A test restore. Not “we have backups.” A backup you have never restored is a rumor, not a backup.
• Performance review against the numbers we set at launch: Core Web Vitals, LCP, INP, page weight. We run WP Rocket and Cloudflare on most builds, and caching configs drift as content grows.
• A short human pass through the live site on a real device. Click the nav, submit the contact form, add something to cart, check the checkout. Automated monitoring catches a dead server. It does not catch a checkout button that silently stopped firing its conversion event.
• Small content edits and the monthly summary: what we updated, what we held back and why, what we’re watching.

Quarterly

• PHP version planning. Hosts like Kinsta move PHP forward on a schedule, and we’d rather move you on staging on our timeline than be surprised by theirs.
• A plugin audit. Anything abandoned by its developer, anything overlapping in function, anything that was a stopgap two years ago and is now just attack surface.
• A database housekeeping pass: expired transients, orphaned post revisions, bloated option tables.
• A security posture review and a license check, so nothing critical lapses without anyone noticing.

Every update goes to staging first

This is the rule we won’t bend on. No update touches production until it has been applied on a staging copy and clicked through by a person.

The reason is simple. A plugin update is a code change written by someone who has never seen your specific combination of plugins, theme, and custom code. It was tested against their assumptions, not your site. Most updates are fine. Some are not, and the ones that aren’t tend to break exactly the things that matter: a WooCommerce update that changes how a shipping plugin calculates rates, a form plugin update that breaks a custom field, a builder update that shifts spacing across forty pages built in Bricks.

On staging, a bad update is a non-event. You roll it back, you flag the plugin, you wait for the next release or you find a replacement. On production, the same bad update is a customer-facing outage and a frantic afternoon. The cost of running staging is a few minutes per update. The cost of skipping it is the one time it bites you, and it only has to bite once to erase a year of “saved” time.

For stores this is not optional. A broken checkout doesn’t announce itself. It just quietly stops taking money while the homepage looks perfectly healthy. We’ve seen sites lose two days of orders to an update nobody tested, and nobody noticed until the daily revenue number looked wrong.

What a real care plan actually includes

Strip away the marketing and a genuine care plan is a short, concrete list of deliverables you could audit at the end of any month:

• Managed updates. Plugins, themes, and core, staged and verified, on the cadence above.
• Monitored backups with test restores. Off-site, on a schedule, and proven to restore.
• Uptime and performance monitoring. You hear about the problem from us, ideally before you hear about it from a customer.
• Security scanning and hardening. Wordfence or equivalent, login hardening, file-integrity monitoring, and a plan for when something does get through.
• A pool of small content edits. Swap a phone number, update a price, add a team member, fix a typo. The small stuff that otherwise sits in a founder’s head for a month.
• A monthly human check and a written summary. A real person on a real device, and a few lines telling you what happened.
• A named person who answers. Not a ticket queue that routes to whoever is free. Someone who knows your site, knows its quirks, and replies when something is wrong.

That last point matters more than the rest combined. The value of a care plan shows up at 11pm on a Friday when something breaks, and the only question that matters is whether the person you message actually knows your build. Everything else is plumbing. This is what we wrap into the care plans we run, and it’s the part clients end up valuing most a year in.

What a care plan should not be

Just as important is what you should refuse to pay for. Three things get sold as “maintenance” that aren’t.

It is not “we’ll look at it if something breaks.” That’s not a care plan, that’s a phone number. Break-fix is reactive by definition, which means you only find out about problems after they’ve already cost you something. The entire point of maintenance is to catch the issue while it’s still cheap and invisible.

It is not a vague retainer with no deliverables. “X hours a month of support” with no defined scope is a way to bill you for availability while doing as little as possible. If a plan can’t tell you what it does every week, every month, and every quarter, it isn’t a plan. It’s a standing invoice. Ask for the checklist. If there isn’t one, walk.

It is not a hosting reseller markup. Some agencies buy hosting wholesale, resell it to you at a healthy margin, and call the spread a “care plan.” Hosting is not maintenance. We’re a Kinsta Agency Partner and we’ll happily put you on great managed hosting, but the hosting bill and the care of your site are two separate things, and you should be able to see both clearly. If your “maintenance fee” is mostly a hosting markup with a thin layer of nothing on top, you’re paying for a margin, not for care.

What this realistically costs

Care plans start from a few hundred US dollars a month for a straightforward marketing or content site. That covers managed updates, monitored backups with restores, monitoring, security, and a sensible pool of small edits, with a named person attached.

Stores cost more, and they should. A WooCommerce site has more moving parts, more plugins that can conflict, a checkout that has to be tested after every meaningful update, and real money flowing through it. Plan on a higher tier for ecommerce, and higher again for anything in a regulated or high-risk vertical where downtime or a failed payment path has direct financial consequences. The price tracks the cost of failure, not the size of the homepage.

Compared to the alternative, it’s not a close call. A single recovery from a hacked or broken unmaintained site routinely costs more than a year of steady maintenance, and that’s before you count the orders or leads lost while it was down.

What most unmaintained sites are already carrying

Here is the uncomfortable part. If your site hasn’t had real maintenance in the last year, it is almost certainly carrying some of these right now, quietly, today:

• A backup system that hasn’t been restored since the day it was set up, which means you don’t actually know if it works.
• An outdated PHP version that the host is about to deprecate, or a plugin three major versions behind with a known, published vulnerability.
• An abandoned plugin still installed and active, its developer gone, its code now pure attack surface.
• A contact form or checkout event that stopped firing months ago, so you’ve been losing leads or conversion data without a single error message.
• Slow page-weight creep as images and content piled on, dragging your Core Web Vitals below where you launched.
• An SSL certificate, a domain, or a plugin license drifting toward an expiry date nobody has on a calendar.

None of these will set off an alarm. That’s exactly why they’re dangerous. They sit there accumulating until one of them tips over and takes the others with it. Maintenance is not a service you buy because something is wrong. It’s the thing you buy so that the slow, silent problems never get the chance to become the loud, expensive one. If you’re not sure what your own site is carrying, that uncertainty is its own answer. Send us a brief and we’ll tell you what we find, honestly, before it finds you.