The usual answers to this are monthly, or as soon as updates appear. Both are wrong, in opposite directions, and treating every update the same is what causes the two failure modes people actually experience: sites broken by an update, and sites breached by one they did not apply.
The useful distinction is not how often. It is what kind of update it is.
Why monthly is too slow
When a serious vulnerability is disclosed in a widely installed plugin, automated scanning follows quickly. Attackers are not hand picking targets, they are running scripts against every WordPress site they can find, checking for the version that carries the flaw.
A monthly maintenance window means a site can sit exposed for up to four weeks with a publicly documented flaw and a fix already available. The vulnerability is public: that is what disclosure means. The instructions are effectively published.
For security releases in anything reachable by the public, the reasonable target is days, not weeks.
Why same day for everything is also wrong
The opposite habit, switching on automatic updates for everything and never thinking about it again, trades one risk for another.
Plugin updates are not only security fixes. Most are feature work, and feature work breaks things. A page builder update can change how a layout renders. A form plugin update can stop submissions reaching your inbox, which is the worst kind of failure because nothing looks broken. An ecommerce update can break checkout.
None of these announce themselves. A site can be quietly failing to deliver enquiries for a fortnight before anyone works out why the phone went quiet.
A cadence that separates the two
Sort updates by what they are, not by when they arrived.
Security releases: within days
If a changelog mentions a security fix, or the plugin is one the public can interact with, apply it promptly. The risk of the update is almost always lower than the risk of the flaw.
This is the category where the usual caution is misplaced. Waiting to see whether an update causes problems means waiting while a public vulnerability sits open.
WordPress core: leave automatic updates on
Core minor releases are the safest updates in the ecosystem. They are security and maintenance only, tested against an enormous installed base, and rarely break anything. Automatic updates for these should stay switched on.
Major core versions are a different matter and belong in the scheduled window below, with a backup taken first.
Everything else: a fortnightly window
Feature and maintenance updates do not need to be same day. A regular slot every week or two, done deliberately with a backup taken first and the site checked afterwards, is far safer than either extreme.
Deliberately means at a time when someone can look at the site afterwards. Friday afternoon is the wrong slot for anything you will not notice until Monday.
Major versions of the things that matter most
A major version of an ecommerce platform, a page builder or a membership system deserves a staging site rather than optimism. These are the updates that produce a bad afternoon.
The step people skip
Checking the site afterwards. Not glancing at the home page, actually testing the things that make you money.
- Submit the contact form and confirm the email arrives, because a silent form is the most expensive failure on a business site
- Load the site on a phone, not just the desktop you updated from
- Complete a test purchase or booking if you take them
- Check a page built with your page builder, not just a plain one
- Look at the site logged out, because a caching or display problem often only shows to visitors
This takes five minutes and is the difference between an update process and simply clicking a button.
The prerequisite nobody enjoys discussing
None of this is safe without backups you have actually tested. An update process without a working restore is a coin toss with your website.
A backup you have never restored is a hope, not a backup. Restore one to a staging site occasionally and confirm the result is a working website. Plenty of businesses discover the flaw in their backup arrangement at the exact moment they need it.
Retention matters as much as frequency. If the only copy is from last night and the problem started a fortnight ago, nightly backups have not helped.
When updating is not enough
Worth knowing, because it changes what you can expect from diligence alone. Of the WordPress vulnerabilities disclosed during 2025, Patchstack found that 46 per cent had no patch available at the point they were made public.
For nearly half of disclosed flaws, the most diligent update schedule in the world would not have helped, because there was nothing to install. That is the gap a firewall covers, by blocking the attack pattern while the fix does not yet exist.
Updating is the foundation. It is not the whole structure.
The short version
Security fixes within days. Core minor updates automatic. Everything else on a fortnightly window with a backup first and a proper check afterwards. Major versions on staging. If that sounds like a standing commitment rather than a task, that is because it is, and it is the part most businesses stop doing by about month three. Handing it to a WordPress care plan is usually cheaper than the afternoon spent fixing what got missed.
