A client called me on a Thursday afternoon in a panic. Their WooCommerce store looked fine, but nobody could buy anything. An automatic plugin update had run, two plugins conflicted, and the checkout process broke silently. No alert. No backup they could actually use. With the client in a different time zone, it took almost four hours for anyone to notice, and they found out when a customer emailed them. Based on their average sales for that time of day, those four hours cost around CAD$400.
They'd been running that store for four years without a maintenance plan. "It's just been working," was how they explained it.
That's the thing about WordPress maintenance: you don't notice it when it's going well. You only notice it when it isn't.
What maintenance actually means in 2026
WordPress runs about 40% of all websites, according to W3Techs, which makes it the default target for automated scanners. They don't check how small your site is. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins. For the most heavily targeted flaws, the weighted median time between disclosure and first exploit was five hours. A plugin you meant to update next week can be someone's target this afternoon.
Maintenance is three things, in practice: keeping the attack surface small, making sure recovery is possible when something goes wrong, and preventing the slow performance loss that builds up when nobody is paying attention.
The abstract version only goes so far. Here's what failure actually looked like.
Five ways WordPress sites actually fail
Four of these happened on sites I worked on. The fifth I've managed to avoid so far, and the numbers above are why I don't take that for granted. Each one has its own post with the full fix; this is the short version, plus the routine that would have caught it.
An update breaks the site, halfway
On one team I worked with, an intern ran a scheduled plugin update. The new plugin version wasn't compatible with the old PHP version the server was running, so it threw a fatal error in the middle of rendering some pages. The site didn't go down, which made it worse. Pages loaded with broken layouts, and it took us almost a day to trace the malformed markup back to a PHP fatal error from one plugin.
We didn't fix it by finding a better intern. We moved to a CI/CD flow: every update goes to staging first, gets tested, someone reads the logs, and only then does it reach production. That flow would have caught this one before a single visitor saw it. The recovery order I use when an update takes a site down is in WordPress site down after update.
Checkout breaks, and the site stays up
That's the story from the top of this post. The conflict itself was a normal plugin problem. What cost money was the four hours, and an uptime monitor wouldn't have shortened them, because the site was up the whole time. Every page loaded. Only the part that takes money was broken.
The monitor that matters on a store watches orders, not pages: an alert when orders stop during hours when they normally come in, or a scheduled test purchase through the real checkout. The diagnosis steps are in WooCommerce checkout not working.
A plugin vulnerability gets exploited
I've never had a client site exploited through a plugin. With a five-hour median on the worst flaws, that's a result of the routine, and it only holds as long as the routine does.
Not every update is equally urgent. A security fix in a plugin that anyone can reach without logging in, like a form, a file upload, or anything exposing a REST endpoint, should skip the weekly queue and go through staging the same day. A feature update to an admin-only plugin can wait for the normal cycle. The wp2shell post shows what the fast kind looks like in practice.
Payments fail quietly in the background
In 2024 I was brought in by a Canadian store selling regulated products because its subscription renewals kept failing, and they had been failing for more than six months. The previous developers kept responding with more elaborate fixes, and every layer they added sat between the payment gateway and WooCommerce without touching the actual cause. The gateway said the orders were paid. WooCommerce said otherwise.
Six months is how long a failure lasts when nobody compares the two logs. Checking the gateway's webhook log against WooCommerce's on a schedule, instead of when a customer complains, turns that into days. The full diagnosis is in WooCommerce subscription webhook failures.
The site slowly gets slower
On one store, the database had quietly filled up with expired transients, the temporary cached values plugins create and often never clean up. No single day was noticeably worse than the one before, so nobody noticed at all. Cleaning them out got the site loading in under two seconds, and even then there were asset and caching problems left to fix.
Slow creep never triggers an alert. That's why it needs a calendar entry. The rest of the performance work is in the WordPress speed guide.
The routine that catches them
Updates: staging, tests, logs, then production
Most plugin updates are security patches, and skipping them means running known vulnerabilities on a public server. Updating directly on production is the other half of the same mistake. The flow from the first story is the whole method: update on staging, test the pages and the checkout, read the PHP error log, check that the server's PHP version is one the new plugin supports, then push to production. For major updates (core WordPress versions, WooCommerce, your theme framework) give it a week and let other people find the conflict bugs first.
On the security stack: Wordfence for the application-layer firewall, combined with Cloudflare's WAF in front of it. Two-factor authentication on every admin account, no exceptions. If someone in your organization pushes back on 2FA, they don't understand what the alternative looks like.
Backups: the fire drill problem
Most WordPress sites have some kind of backup configured. Most of those backups have never been tested.
A backup you've never restored is a file sitting somewhere that you hope works when you need it. Hosting-level backups from your provider are a safety net for their infrastructure problems, not yours. They won't help you if you accidentally delete a database table, and some providers only keep them for 24 to 48 hours.
The setup I recommend: daily automated backups to an off-site location (Amazon S3, Backblaze B2, or even Dropbox for smaller sites) using UpdraftPlus or a similar tool. And once a year, actually restore one of those backups on a staging environment. Treat it like a fire drill. If you can't restore the site from scratch, your backup process has a problem you want to find now, not during an incident.
Performance: the slow accumulation problem
A database fills up with things that made sense at the time. Post revisions from 2019. Spam comments that never got cleared. Thousands of expired transients, like the ones in the last story. None of these break anything immediately, but every database query gets a little slower.
The practical ceiling on post revisions: 5. There is no scenario where you need 200 saved versions of a page. Set it with a line in your wp-config.php or a plugin like WP Optimize, and run a database cleanup monthly. It takes about two minutes.
The DIY ceiling
Some maintenance tasks are manageable without professional help: running the monthly cleanup, keeping plugins updated on a staging environment, monitoring uptime with a free tool like UptimeRobot. If you're technical and your site is informational, that's probably enough.
If your site generates revenue, the math changes. The question stops being "can I do this myself?" and becomes "what do four hours of broken checkout cost me, compared to a monthly maintenance retainer?" For the store in the first story, the answer was CAD$400 in one afternoon.
The other thing that shifts is conflict resolution. When an update breaks something non-obvious, tracing it to its root cause means knowing what changed, in what order, and why. The PHP fatal error in the first story took a team that knew WordPress well almost a day to find. Someone doing it alone for the first time can lose a lot more than that, which is most of the case for WordPress maintenance and support on a revenue site.
The practical maintenance schedule
Weekly: apply available updates to staging, test the key pages and the checkout, read the error log, then push to production. Security fixes in plugins that are reachable without logging in don't wait for the weekly slot.
Monthly: database cleanup (revisions, expired transients, spam), compare the payment gateway's webhook log with WooCommerce's if you sell subscriptions, and check that staging still matches production.
Continuously: an uptime monitor for the site, and an order alert for the store.
Annually: restore from a backup on a staging environment. Audit user accounts and remove anyone who no longer needs access. Review security scan logs for anything that wasn't caught automatically.
That's the whole thing. None of it is complicated. It just has to happen on a schedule, which is the part most sites skip.
When did someone last read your error log?
Looking for someone to handle managed WordPress maintenance so you stop thinking about it? Tell me what's running and I'll tell you what the schedule should look like.