How Often Should a WordPress Site Be Updated?

In this guide

1. 01Work out what you actually have.
2. 02Set the cadence and apply it.
3. 03Confirm it held.

What “keeping WordPress updated” actually means

WordPress core, plugins, and themes do not run on the same update mechanism, and that gap is where most of the confusion about update frequency comes from.

Core minor releases, the point releases that fix security holes and bugs, install themselves automatically on any WordPress site running a reasonably current version, with no admin action required. Core major releases, roughly one every four months, do not install themselves on an existing site unless the owner opts in.

Plugins and themes are manual by default, unless the WordPress security team decides a vulnerability is severe enough to force a patch through the update API. Outside that forced-patch exception, every plugin and theme update is something the site owner has to apply.

That split gives a practical rule: a security-flagged release gets a short, defined window. A feature or maintenance release gets batched with the rest and applied on a schedule. NoDrama patches security releases with key pages photographed before and after, and puts back anything that breaks.

Check what you have now

Two things to check before setting a policy. First, whether WP_AUTO_UPDATE_CORE is set to minor, true, or false in wp-config.php, since that constant governs core only. Second, which plugins and themes already have auto-updates toggled on, under the Plugins and Themes screens in the dashboard.

Working out how often to update WordPress plugins on a given site starts with what is already switched on, not with a fixed number.

Start with a free audit of your current update settings to see where the site actually stands.

Choose the right cadence

A workable WordPress update schedule has two real values, not one.

Anything security-flagged gets a short, defined window, commonly discussed as 24 to 48 hours once it has passed staging. That is industry-common practice, not a NoDrama response-time commitment: NoDrama’s confirmed response times are 4 hours on The Standard, 2 hours on The Higher Standard and 1 hour on The Highest Standard, if a site is down or hacked, and that is a different clock from how fast a patch itself gets classified and tested.

Everything else, a feature release, a maintenance update, a routine plugin bump, runs on a batch: weekly for most sites, monthly for sites with very little at stake.

The advice this replaces is “update everything the moment a notification appears.” That is the habit that breaks sites, because it skips the step that matters: classify first, security or feature, then apply on the clock that matches. The major release cycle runs on roughly a four-month scoping-to-launch cadence, one more reason a single interval was never going to cover everything WordPress ships.

For a low-traffic, no-commerce site

The defaults are a reasonable position here: core minor auto-on, plugins and themes manual, checked monthly. There is not much for an untested update to break, and not much riding on catching it fast.

For a site with checkout, forms, or client data

The case for a tighter cadence and staging gets stronger, not because the site is more exposed in the abstract, but because there is more attached to an update going wrong: a broken checkout, a form that silently stops submitting, and a customer finding out before the owner does.

Apply the change

To prevent a theme from being able to update on its own, without turning off updates everywhere, WordPress gives you a filter rather than a blanket setting. The auto_update_theme filter is the documented route, and the call that disables it for a single theme is:

add_filter( 'auto_update_theme', '__return_false' );

Place that in a plugin file, not directly in wp-config.php. The WP_AUTO_UPDATE_CORE constant in wp-config.php governs core only and does not touch theme auto-updates at all.

For per-theme control instead of a blanket switch, check $item->slug inside a custom callback on the same filter, rather than returning false for every theme on the site.

The core-only equivalent lives in wp-config.php: the WP_AUTO_UPDATE_CORE constant, set to false, true, or the string ‘minor’.

Via code

For an owner comfortable editing a plugin file or wp-config.php, the filter and the constant above are the whole job.

Via a managed maintenance plan

The alternative is having the classify-then-stage-then-test sequence run on the owner’s behalf rather than by the owner: someone else watches for the release, decides whether it is security or routine, and applies it on the matching clock.

See how NoDrama classifies and patches WordPress updates, with key pages checked before and after.

Verify safely

Verifying an update safely means testing on staging, not checking the live site after the fact. Apply the update on a copy of the site, not a preview mode on the same install, then load the front page, the key templates, any forms, checkout if the site has one, and the admin login before promoting the change to production.

The rollback path only works if a backup was taken immediately before the update, restoring files and the database together, not one without the other. Here’s how backups and rollback actually work once a change needs undoing.

Troubleshoot

What this does not solve

Uptime and error monitoring tells you the site is down or throwing an error. It does not tell you an update quietly slowed the site down or broke one form without triggering an error. Catching that needs the staging and test step, not a monitoring alert.

The short answer, restated

So, how often should WordPress be updated? Core patches its own security releases without anyone touching it. Everything else, plugins and themes, runs on a policy: fast for anything security-flagged once it is tested, batched weekly or monthly for the rest, and tested on staging before it goes live either way. See the three plans and what each covers if a managed policy is the simpler route.