WordPress has offered automatic updates since 2013, but most operators still treat the feature like a binary choice: all on or all off. That’s a mistake. The auto-update system has four distinct layers, and each one carries different risk and reward.
Here’s how to configure them without waking up to a broken site.
Core updates: three tiers, three strategies
WordPress core has three update types, and the defaults are smarter than most people realize.
Minor releases (e.g., 6.4.1 to 6.4.2) auto-update by default. These are security and critical bug fixes. Leave this enabled. The risk of a minor version breaking your site is vanishingly small compared to the risk of running unpatched software. In eight years of managing client sites, I’ve seen exactly one minor update cause a conflict—and it was with a plugin that was already deprecated.
Major releases (e.g., 6.4 to 6.5) are disabled by default, and you should keep them that way unless you’re running a very simple site with minimal plugins. Major versions introduce new features and can break theme or plugin compatibility. Schedule these manually, ideally in a staging environment first.
Development and beta builds are off by default. Never enable these on a production site. They’re for testing only.
You can control core auto-updates in Dashboard → Updates → Advanced Options, or via the WP_AUTO_UPDATE_CORE constant in wp-config.php.
Plugin auto-updates: the risk matrix
Since WordPress 5.5, you can toggle auto-updates per plugin. This is where most operators get it wrong—they either enable everything or nothing.
The correct approach is risk-based. Enable auto-updates for:
- Security plugins (Wordfence, Solid Security, etc.). Delaying a security patch is worse than the small chance of a bad update.
- Actively maintained utilities with narrow scope—contact forms, analytics snippets, small performance helpers. If a plugin does one thing and is updated frequently, auto-update is usually safe.
- Plugins from established vendors with good release practices. WooCommerce, Yoast, Jetpack, and similar have staged rollouts and rarely ship breaking changes in patches.
Disable auto-updates for:
- Page builders and theme frameworks. Elementor, Divi, Advanced Custom Fields, WPBakery—anything that touches your front-end rendering or content structure. Updates here can cascade across hundreds of pages.
- Plugins you’ve customized via hooks or filters. Auto-updates will overwrite nothing, but new versions may deprecate the functions you’re relying on.
- Anything that hasn’t been updated in over a year. If the developer isn’t actively maintaining it, the next update could be panicked, untested, or abandoned entirely.
On a typical content site, I’ll have auto-updates enabled for about 60% of installed plugins. On a membership site with custom checkout flows, closer to 30%.
Theme auto-updates: almost never
Themes control your entire front-end. A bad update can break layouts, remove custom CSS, or interfere with child theme overrides.
Disable auto-updates for your active theme. Period. The only exception: you’re using a bare-bones starter theme (like GeneratePress or Astra) with zero customizations, and all your design work lives in a child theme or site-specific plugin.
You can leave auto-updates enabled for inactive themes if you want to keep them patched for security, but the smarter move is just to delete any theme you’re not using. An inactive theme is still executable code that can be exploited.
Translation auto-updates: safe to enable
Translation files auto-update by default, and there’s no reason to turn this off. They’re low-risk, non-executable, and keeping them current improves localization accuracy. Leave it alone.
What happens when an auto-update fails
WordPress has a rollback mechanism. If a plugin or theme update triggers a fatal error during activation, the system will attempt to restore the previous version and send you an email with the error log.
This works—most of the time. But it’s not a substitute for backups. If you’re enabling auto-updates for anything beyond minor core releases, you need automated daily backups with off-site storage. Most managed WordPress hosts (including BigScoots) include this. If you’re on unmanaged hosting, use UpdraftPlus, BlogVault, or a server-level solution.
The notification problem
Auto-updates are only useful if you know they happened. WordPress sends email notifications for core updates and failed plugin updates, but successful plugin updates are silent by default unless you enable the auto_plugin_update_send_email filter.
Add this to your theme’s functions.php or a site-specific plugin:
add_filter( 'auto_plugin_update_send_email', '__return_true' );
Now you’ll get an email every time a plugin auto-updates. If you’re running multiple sites, route these to a dedicated email address or a Slack channel via Zapier.
One non-obvious tip: staging auto-updates
If you’re using a host with staging environments, configure your staging site to auto-update everything—core, plugins, themes. Then schedule a weekly automated check (via uptime monitor or a simple cron job) to verify the staging site still loads.
If staging breaks, you’ll know before the same update hits production. If it doesn’t, you can manually push the updates live with confidence. This is the closest you’ll get to zero-touch maintenance without the risk.
Got a WordPress setup question we should cover? Reply to this email—we read every one.