An automatic update ran at 10pm on a Wednesday.
Nobody knew. Nobody had authorised it. Nobody was watching. The update notification had been going to an old admin email address — the one set up when the site was first launched, belonging to no one who was still involved with the site.
By Thursday morning, when the client opened their website, the home page loaded. Everything else showed an infinite loading animation and went nowhere. Internal pages were broken. The site was functionally down — but only partially, which made it harder to diagnose. The home page looked fine.
Because this was a staging environment — part of a managed hosting arrangement where updates ran on staging first — the investigation was contained. We could work through the 25 plugins that had updated simultaneously and identify the culprit. It took several hours. It was the right process. But everyone in the conversation that day knew the same thing: if those 25 plugins had updated automatically on the live site, the front-facing store would have been down for the duration of that investigation, with no one the wiser until a customer called.
That is the reality of unscheduled, automatic WordPress updates.
What “Update Immediately” Actually Means
The advice to keep WordPress and its plugins updated is correct. Outdated software is a genuine security and stability risk. Nobody who manages WordPress sites for a living would argue otherwise.
What’s wrong is the conflation of that correct advice with a specific practice: update everything, immediately, as soon as updates are available, and use WordPress’s auto-update feature to make sure nothing waits.
For a small blog with no custom code, no active e-commerce, no form integrations, and no business-critical functionality, auto-updates are probably fine. The stakes are low, the complexity is low, and the effort of a deliberate update process exceeds the risk.
But for any site where downtime costs money — a WooCommerce store, a service business with a lead capture form, a hospitality business whose booking system runs through the site — this advice is quietly dangerous. And the threshold for “business-critical” is lower than most people think. A form that stops working is a lead that doesn’t arrive. A checkout that breaks is a sale that disappears. The business rarely knows immediately. The losses accumulate before the problem surfaces.
The “update immediately” advice typically comes from one of two sources: security researchers who are specifically discussing critical vulnerability patches, and content marketers who are writing generic WordPress advice without distinguishing between site types or update categories. The security researchers are right about critical patches. The content marketers are applying that urgency to routine maintenance updates where it doesn’t belong.
There Are Two Types of Updates. Only One Should Be Rushed.
The first type is a security patch. A plugin or WordPress core has a published vulnerability — a known exploit, a public CVE entry, a Patchstack or WPScan advisory. These need to go on quickly. Hours, not days. The window between a published vulnerability and active exploitation has shrunk as the ecosystem has grown and as automated scanning for vulnerable sites has become standard.
The second type is everything else: feature updates, maintenance releases, dependency bumps, performance improvements, API changes. These need to go on at a scheduled time, on a staging environment, after a review.
The reason most sites run into trouble is not that they applied a security patch. It’s that they applied a routine maintenance update — or twelve of them simultaneously — without testing, on a live site, because they’d been told that keeping things updated is always good and always urgent.
Updating 25 plugins at once on a live site is not maintenance. It’s a dice roll. You may not notice anything wrong immediately. The breakage might be on a page nobody visits until Friday. It might be in the checkout flow that only surfaces for users with a specific combination of cart items. It might be in the custom code that someone wrote three years ago to handle a specific client requirement, and which has never been tested against the new version of the plugin it calls into.
When you discover the breakage, you have no idea which of the 25 updates caused it.
The Problem With Auto-Updates
WordPress introduced plugin and theme auto-updates in version 5.5, in August 2020. It was presented as a convenience feature. For most site operators managing multiple sites without dedicated technical support, it looked like a sensible default.
The problem is that WordPress’s auto-update mechanism has, until very recently, had no reliable rollback capability built into the core admin. A plugin auto-updates overnight. Something breaks. You need to identify which update caused it, roll back to the previous version, and work out whether the update is safe to apply after a code review or whether you need to wait for a compatibility fix.
On a well-managed site with version control and a staging environment, this is a controlled process. On the average small business WordPress site — no staging, no version control, no monitoring — it is a crisis. The site is broken, no one knows why, the person who manages the hosting is not the person who manages the content is not the person who manages the code, and the previous plugin versions may not be available without a paid backup service.
There is also a subtler problem with auto-updates: they remove the human review step. A plugin update that passes every automated check and has no reported conflicts in the WordPress repository can still break your specific site. Your combination of plugins, theme, customisations, hosting configuration, and PHP version is unique. Nobody tested that combination. The auto-update mechanism has no way to know about your custom code.
One of the client sites we inherited had been running auto-updates for an unknown period. The notification emails had been going to an address that nobody monitored. The plugins had been self-updating for months. When we took over, we had no reliable record of what had changed, when, or whether any issues had been silently introduced and resolved by subsequent auto-updates. We turned auto-updates off as the first order of business.
What a Proper Update Schedule Looks Like
The discipline of scheduled updates is straightforward. It is not glamorous. It does not require sophisticated tooling. It requires a process and the commitment to follow it.
Step 1: Auto-updates off. WordPress core minor security patches are the one category that can reasonably auto-apply — they are security-only and tightly controlled by the WordPress Security Team. Everything else — plugins, themes, WordPress major versions — should be a deliberate decision.
Step 2: A monthly update window, whatever the site’s complexity. A brochure site with five plugins and a WooCommerce store with fifteen plugins, active orders and custom code run on the same monthly cadence. What complexity changes is how much testing the window needs, not how far apart the windows sit. Anything longer than a month leaves published vulnerabilities sitting unpatched for weeks, and with automated scanning for vulnerable sites now standard, that exposure outweighs the risk of the update itself. Security patches are still handled as they arise, not held for the window.
Step 3: Staging before live. Every update runs on a staging environment first. The staging environment is a clone of the live site: same database, same files, same configuration. If something breaks on staging, it breaks there. Not in front of customers. Not at 2am on a Thursday. (Truth #10 in this series covers staging environments in detail — they are the companion discipline to scheduled updates. You cannot do one properly without the other.)
Step 4: Review what’s changing. Before updating, look at the changelog. A plugin update that changes three lines of CSS for accessibility compliance is different from a plugin update that introduces a new database migration or changes how the plugin hooks into WooCommerce’s order processing. The changelog tells you what to test. If there’s no changelog, be more cautious, not less.
Step 5: Test after deployment, not just before. The update ran on staging and looked fine. It’s on live now. Check the key functions: home page loads, products add to cart, checkout completes, contact forms submit, enquiry emails arrive, any custom functionality works. This is a ten-minute check, not a full regression suite. But ten minutes of checking after deployment catches most breakage before a customer finds it.
The WooCommerce Complexity Argument
WooCommerce deserves special attention because it changes the risk profile of updates significantly.
WooCommerce is not just a plugin. It is a platform with its own extension ecosystem, its own API, and its own release cycle. A WooCommerce update can introduce changes to internal APIs that break plugins built to extend it. A plugin that worked perfectly with WooCommerce 8.4 may behave differently with WooCommerce 9.0 — not because either is broken, but because the API changed and the extension author has not yet updated their code.
For a site with standard WooCommerce and two or three well-maintained extensions, this risk is manageable. For a site with custom code that calls into WooCommerce’s price formatting or order processing internals, a WooCommerce update requires developer review before it goes anywhere near a live site.
This is not hypothetical. A New Zealand tour operator site — WooCommerce with a custom availability table plugin — had a WooCommerce update change the price formatting API. The custom plugin stopped rendering the table correctly. The fix required a developer to wrap conditional logic around the table output to handle both the old and new API structure. The update had been deployed to staging first; the issue was caught there and resolved before it touched the live booking system.
Multiply that scenario across twenty sites. If any of them had been running WooCommerce auto-updates, the breakage would have appeared on the live booking system with no warning.
The Weekly Update Cycle Is Too Often
In many managed WordPress operations, updates run weekly. It feels professional. It feels diligent. The site is always current, never more than seven days behind the latest release.
In practice, a weekly update cycle applied to all plugins on a complex site means you are running an uncoordinated stream of changes through a system nobody has fully tested. It means the person doing the updates develops update fatigue — after doing this for six months, they stop reading changelogs and start clicking “update all.” It means that when something breaks, the investigation covers an entire week of changes rather than a bounded batch.
Monthly updates, every site. Security patches as they arise.
A site that is updated monthly with proper staging and review is significantly more stable than a site that is updated weekly without it. The version numbers may be higher on the weekly-update site. The reliability is not.
The “Borrowed Time” Problem
There is a pressure that pushes against deliberate update schedules, and it comes from inside the house: the feeling that the longer you wait to update, the more dangerous the update becomes. Versions accumulate. The gap between current and latest widens. The changelog gets longer. Eventually, updating from version 3.4 to version 4.1 feels like a major project requiring days of work and full regression testing, and so it gets deferred again.
This is a real problem. But the solution is not weekly auto-updates — it’s a monthly schedule that prevents the version gap from becoming unmanageable. If you update monthly with staging, you are updating from one minor version to another, not bridging three major releases at once. The changelog is manageable. The testing scope is bounded.
The pressure to update urgently typically comes from one of three sources: a security advisory (legitimate), a client complaint that might be update-related (investigate before updating), or general anxiety about being “behind” (not a technical justification). The first is real. The second and third are not reasons to skip the staging step.
The Positioning Is Wrong
The WordPress community has done a good job communicating that outdated plugins are a security risk. It has done a poor job communicating that the method of applying updates matters as much as the frequency.
Most site owners understand vaguely that they “should keep things updated.” They don’t understand the distinction between a security patch and a maintenance release, or why those two things warrant different urgency. They don’t understand why updating on a live site without staging is a different risk profile to updating on staging first. They don’t understand that “update all” in the WordPress dashboard is a convenience feature, not a maintenance strategy.
The conversation we have with clients about updates is not “here’s why your site is risky.” It’s “here’s how we handle this so you never have to think about it.” Scheduled update windows. Staging-first workflow. Security exceptions handled within hours. Routine maintenance handled without drama, on a cadence that matches the site’s complexity.
That’s the discipline. It’s not complicated. But it requires the confidence to push back against the urgency that’s baked into WordPress update notifications, and to replace it with a process that serves the site’s actual needs rather than the dashboard’s blinking counter.
What This Means in Practice
If you are managing your own WordPress site:
Turn off auto-updates for plugins and themes. Leave minor core security updates on auto. Review every other update before applying it, on staging if the site does anything business-critical.
If someone is managing your site for you:
Ask them when updates run. Ask them whether they run on staging first. Ask them how they handle WooCommerce updates if you have an active shop. If the answers are “whenever available,” “no,” and “same as everything else,” it is worth having a conversation about the update process before the next update cycle runs.
If you are an agency managing client sites:
The “update immediately” instinct is understandable. Outdated plugins are a real risk. But your clients are better served by a documented, scheduled, staging-first update process than by an aggressive update cadence that trades the risk of outdated code for the risk of unvalidated changes on live sites.
The goal is not to have the highest version numbers. The goal is to have a site that works.
Want us to check your update process? Start with a free hosting audit at managedhosting.partners.
