Quick answer: For most business sites, turn on WordPress auto updates for small, well-maintained plugins that do one job, and keep manual control over the plugins your revenue depends on: ecommerce, payments, memberships, forms that feed your CRM, and page builders. Pair that split with daily backups, uptime monitoring and a quick weekly check of the update emails. Auto-updates are a good default for security patches, not a replacement for a maintenance routine.
What changed in WordPress 5.5
WordPress has updated its own core files automatically for minor security releases since version 3.7. Plugins and themes were a different story. You could force them to update with a filter in code or a third-party plugin, but there was no switch in the admin.
WordPress 5.5, released in August 2020, added that switch. On the Plugins screen there is now an “Automatic Updates” column with an “Enable auto-updates” link next to each plugin. The Themes screen has the same option inside each theme’s details. You can also select several plugins and use the bulk actions menu to enable or disable auto-updates in one go.
When an update runs, WordPress sends an email to the site admin address listing what was updated and whether anything failed. The Site Health screen also reports on the update setup, which is worth a look if you have never opened it (our guide to the WordPress Site Health screen explains the checks).
Everything is off by default. Nothing on your site starts updating itself until someone clicks the link or a developer turns it on in code.
Why auto-updates are tempting
The case for switching them on is simple: a common pattern behind hacked WordPress sites is an outdated plugin with a known, already-fixed vulnerability. The patch existed. Nobody applied it. Attackers scan for those version numbers within days of a fix being announced.
Auto-updates close that gap. If a plugin author ships a security fix at 2 a.m., your site can have it by morning instead of waiting for someone to log in. That matters most on sites that nobody actively manages, such as a brochure site that was launched two years ago and only gets touched when something breaks.
Our routine for keeping plugins and themes patched covers why speed matters so much once a vulnerability is public.
Why some sites should hold back
The risk runs the other way too. An update can change behavior, conflict with another plugin, or rely on a newer PHP version than your host runs. When you click “Update” yourself, you are around to notice the broken checkout. When it happens at 3 a.m., a customer might be the first to notice.
WordPress 5.5 itself is a live example. It stopped loading the jQuery Migrate helper script by default, and a number of older themes and plugins that depended on it broke after the upgrade. The fix was easy (the core team released a helper plugin to restore it while authors caught up), but sites that updated without anyone watching had broken sliders and menus for a while.
Watch for these warning signs that a plugin should stay on manual updates:
- It handles money: WooCommerce, payment gateways, subscriptions, booking systems
- It controls layout across the whole site, like a page builder or a heavily customized theme
- It has been customized directly, or another plugin extends it in ways the author does not know about
- It ships major version jumps often, with notes that mention database changes
- It is a premium plugin with its own license checker or updater
A sensible split for most business sites
You do not have to choose all or nothing. The per-plugin toggle is the whole point. Here is the split we usually recommend.
Good candidates for auto-updates
- Security plugins and firewalls, where speed matters more than anything else
- Small utility plugins: redirects, SMTP mailers, cookie notices, sitemaps
- SEO plugins from established authors with a steady release history
- Themes you have not edited directly (a child theme carries your changes, so the parent can update; see our guide to WordPress child themes)
Keep on manual updates
- WooCommerce and its extensions
- Membership, LMS and booking plugins
- Page builders and theme frameworks
- Anything with custom code built on top of it
- Any plugin whose last update broke something
For the manual group, apply updates on a schedule: once a week is common, or within a day or two when the changelog mentions a security fix. Test on a staging copy first if the plugin is central to sales. Our article on website staging and deployment shows how that flow works in practice.
Controlling auto-updates in code
If you manage several sites, or you do not want clients flipping switches, developers can control auto-updates with filters. These go in a small custom plugin or a must-use plugin rather than in the theme’s functions.php, so they survive a theme change.
To enable auto-updates for a specific list of plugins only:
add_filter( 'auto_update_plugin', function ( $update, $item ) {
$allowed = array( 'wordfence', 'redirection', 'wp-mail-smtp' );
if ( isset( $item->slug ) && in_array( $item->slug, $allowed, true ) ) {
return true;
}
return $update;
}, 10, 2 );
The auto_update_theme filter works the same way for themes. If a filter forces a value, the admin screen shows that the setting is controlled elsewhere, so editors are not confused.
A few other options are worth knowing:
add_filter( 'plugins_auto_update_enabled', '__return_false' );hides the auto-update UI for plugins entirely. There is a matchingthemes_auto_update_enabledfilter.- The
auto_plugin_update_send_emailandauto_theme_update_send_emailfilters let you turn off the notification emails if you monitor updates another way. - Setting
AUTOMATIC_UPDATER_DISABLEDto true in wp-config.php switches off all automatic updates, including core security releases. Only do this if a person or a deployment process genuinely applies updates every week. DISALLOW_FILE_MODSblocks all plugin and theme installs and updates from the admin. Sites deployed from version control often use it, and it also hides the auto-update links.
If you are new to filters, our explainer on WordPress hooks covers how they work without assuming you write code every day.
How the updates actually run
Auto-updates run through WP-Cron, which by default fires when someone visits the site. On a low-traffic site that can mean updates arrive later than expected. On a busy site with page caching, WP-Cron may not trigger reliably at all. Many hosts let you disable the visitor-triggered version and run a real server cron job every few minutes instead, which makes updates (and scheduled posts) more predictable. Our guide to WordPress cron jobs walks through that change.
Updates also need WordPress to be able to write to its own files. If file ownership on the server is set up so the web server cannot write to wp-content, auto-updates will fail and the email will tell you so.
Safety nets you need either way
Auto-updates are only as safe as your ability to recover from a bad one. Before turning them on, make sure you have:
- Daily backups stored off the server, with a restore you have actually tested.
- Uptime monitoring that alerts you when the homepage or checkout stops responding.
- Someone reading the update emails. Route them to a shared inbox, not the address of a developer who left last year.
- A short rollback plan. Know how to deactivate a plugin by renaming its folder over SFTP, or with a single command if you have shell access.
- A record of what is enabled. A short note in your maintenance log saves guesswork when something changes.
FAQ
Will auto-updates also update WordPress core to the next major version?
Not by default. Core still auto-updates for minor and security releases only (for example 5.5 to 5.5.1). Major releases need a click, a constant in wp-config.php, or a filter.
Do premium plugins support the auto-update toggle?
Only if they use the standard WordPress update system. Some premium plugins check licenses with their own updater, and the toggle may do nothing for them. Check with the vendor.
Should a WooCommerce store turn on auto-updates?
For small helper plugins, often yes. For WooCommerce itself, payment gateways and shipping extensions, we prefer scheduled manual updates tested on staging first.
What if an auto-update breaks the site?
Restore the plugin’s previous version from backup, or deactivate it by renaming its folder, then switch that plugin back to manual updates until the author ships a fix.
The bottom line
WordPress auto updates are a welcome addition, and for low-risk plugins they are an easy win for security. Treat them as a per-plugin decision, back them with backups and monitoring, and keep the plugins that run your sales on a tested, manual schedule. If you want a site that stays patched without surprises at checkout, our WordPress development team can set up the right mix for you.
