WordPress Auto-Updates: What to Turn On and What to Leave Off

The short version: let WordPress auto-updates handle minor core releases on every site, without exception. Let them handle plugins and themes on simple sites that nobody tests anyway. Keep them away from the store plugin, the LMS, the payment gateway and anything your own code hooks into, and update those by hand after a test.

Below: where each switch lives, how to lock the choice in code so a colleague cannot undo it with one click, and what the built-in safety net does and does not catch.

What WordPress updates by itself out of the box

Background updates cover core, translations, plugins and themes, and the defaults are not the same for each:

• Minor core releases (7.1.1 to 7.1.2) and translation files install automatically on every site.
• Major core releases (7.0 to 7.1) install automatically on sites first installed with WordPress 5.6 or later. Sites older than that keep the minor-only behavior until an administrator changes it.
• Plugins and themes never update themselves until you enable it, one item at a time.

All of it runs through WP-Cron, about twice a day. That detail matters. If DISABLE_WP_CRON is set and no server cron job calls wp-cron.php, no automatic update will ever run, whatever the settings say. Tools > Site Health has a "Background updates" test that reports this and other blockers such as file permissions.

A sensible setting for each kind of site

Site	Core, minor	Core, major	Plugins and themes
Brochure site or blog on standard plugins	On	On	On, provided someone reads the update emails
Online store	On	Off	Off for the store plugin, gateways and extensions. On for small utilities.
LMS or membership site	On	Off	Off for anything that controls enrollment, access or payments
Site with custom plugins or a custom theme	On	Off	Off for plugins your code extends. Decide the rest one by one.
Site deployed from a Git repository	Through the repository	Through the repository	Through the repository

One honest exception to the cautious rows. If nobody is going to maintain the site at all, switch everything on. A layout that breaks after an update is a smaller problem than a known vulnerability left open for months.

Setting core updates with the dashboard link or a constant

Under Dashboard > Updates, WordPress states its current behavior in one sentence and offers a link to change it: either "Enable automatic updates for all new versions of WordPress" or "Switch to automatic updates for maintenance and security releases only".

That link is fine for a site with one administrator. Where several people have admin access, fix the policy in wp-config.php, above the line that says to stop editing:

// Minor releases only. Major releases are applied by hand after testing.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

The constant accepts three values. 'minor' allows maintenance and security releases only. true allows minor, major and development builds. false switches off all core updates, including security releases, which is almost never what you want. When the constant is defined it wins over the dashboard link.

A second constant, AUTOMATIC_UPDATER_DISABLED, turns off every background update at once: core, plugins, themes and translations. Reserve it for sites where another system does the updating.

Deciding plugins and themes item by item

On the Plugins screen, the "Automatic Updates" column has an "Enable auto-updates" link for each plugin, and the bulk actions menu can switch several at once. For a theme, click its thumbnail under Appearance > Themes and use the link below the author name. The screens are described in the official guide to plugin and theme auto-updates. With WP-CLI:

wp plugin auto-updates status --all
wp plugin auto-updates enable akismet
wp plugin auto-updates disable woocommerce

A reasonable way to sort a plugin list:

• Safe to automate: small, single-purpose plugins with no data of their own, such as an SMTP connector, a redirect manager or a cookie notice.
• Update by hand: the plugin the business runs on (store, LMS, membership, booking), payment gateways, page builders, and any plugin that announces a "database update" after major versions.
• Update by hand, with a developer: any plugin that your custom code extends through hooks or template overrides, and the parent of your child theme if the child overrides its templates.

To make the decision stick, put the rule in a must-use plugin. A filter beats the links on the Plugins screen, which then show the forced state:

<?php
// wp-content/mu-plugins/auto-update-rules.php
add_filter( 'auto_update_plugin', function ( $update, $item ) {
    $never = array( 'woocommerce', 'lifterlms' );
    if ( isset( $item->slug ) && in_array( $item->slug, $never, true ) ) {
        return false;
    }
    return $update;
}, 10, 2 );

The matching filter for themes is auto_update_theme. Keep add_filter() calls out of wp-config.php, because WordPress is not fully loaded there. The WordPress documentation on updates lists every constant and filter.

Premium plugins take part only when their license is active and their updater is wired into the standard update screen. Check each one. An expired license is a common reason a "fully automatic" site turns out to be running a plugin version from years ago.

What the built-in rollback catches and what it misses

Current versions of WordPress protect plugin auto-updates with a simple test. The site goes into maintenance mode for the duration, WordPress updates the plugin, requests the home page from itself and looks for a PHP fatal error. If it finds one, it puts the previous version of the plugin back and emails the administrator.

That is a real improvement, and it is narrow. The test sees a crash on one page load. It does not see a checkout button that stopped responding because of a JavaScript error, a course page that lost its lesson list, a broken layout, or a fatal error that only happens when a logged-in customer opens the account page. Those are exactly the failures that cost money on a store or a learning site, which is why the table above keeps their main plugins on manual updates.

Keep the update emails and send them somewhere useful

After a background update WordPress emails the address under Settings > General > Administration Email Address: after core updates, and after plugin or theme updates whether they succeeded, failed or did a bit of both. On an automated site that email is the only record of what changed and when. If a customer reports a problem on Tuesday, the Monday night email tells you where to look.

Two mistakes are common. The address belongs to someone who left, or the emails were filtered away because there were too many. Point the address at a mailbox that is read. If the volume is the problem, silence only the success messages for core and keep the failures:

add_filter( 'auto_core_update_send_email', function ( $send, $type ) {
    return 'success' === $type ? false : $send;
}, 10, 2 );

The equivalent switches for plugin and theme emails are auto_plugin_update_send_email and auto_theme_update_send_email. Think twice before turning those off. They are your change log.

Where WordPress auto-updates are the wrong tool

In three situations, automatic is the wrong default for anything beyond minor core releases.

Sites that take money or hold learner records. An update that runs at night with nobody watching can leave checkout or enrollment broken until morning. On a WooCommerce store or a WordPress LMS, the plugins behind those paths belong in a scheduled window, after a pass on a staging site.

Sites deployed from version control. WordPress detects a .git or similar folder and switches background updates off by itself. Leave it that way. If the server updates code the repository does not know about, the next deployment silently reverts it. The automatic_updates_is_vcs_checkout filter can override the check, and it rarely should.

Sites on a host that runs its own updater. Two systems updating the same files produce confusing results. Pick one and disable the other.

If your site falls in one of these groups and nobody on the team has time for a monthly update window, that is the gap a WordPress maintenance plan fills: a person applies the updates, tests the paths that matter and rolls back when needed.

Frequently asked questions

Are WordPress automatic updates safe for a business site?

For minor core releases, yes, and you should never switch those off. For plugins it depends on the plugin. Small utilities are fine to automate, while the plugins that run checkout, courses or memberships should be updated by a person who tests afterwards.

Can a plugin auto-update for security fixes only?

No. Core separates minor releases from major ones, but a plugin has a single stream of versions. Auto-updates install whatever the newest version is, whether it contains a security fix, a new feature or a redesign of the settings screen.

Why did my site not update automatically?

Start with the "Background updates" test in Site Health. The usual causes are WP-Cron not running, files the web server cannot write to, a constant such as DISALLOW_FILE_MODS or AUTOMATIC_UPDATER_DISABLED in wp-config.php, a version control folder in the site root, or a host that manages updates itself.

Can I choose the time of day auto-updates run?

Not from the WordPress settings. The check runs roughly twice a day through WP-Cron, and the Plugins screen shows the time until the next one. If timing matters, keep auto-updates off for those plugins and run the updates yourself in a quiet hour.