Auto-updates are the rare WordPress feature that’s genuinely a good default. Turn them on and your site quietly patches itself while you’re doing literally anything else. Most of the WordPress sites that get hacked aren’t taken down by some exotic zero-day — they’re running a plugin version that had a public fix available months earlier.
But “just turn on auto-updates” is advice that skips the parts that actually bite. Auto-updates ride on WP-Cron, which means a quiet site can sit on a security patch for days without telling anyone. Core’s rollback safety net doesn’t cover the case most people assume it does. And the difference between a fresh install and a site you launched in 2019 is a default setting that silently disagrees with itself.
Here’s how WordPress auto-updates actually work, which switches to flip, and how to set them up so they patch you without ever handing you a white screen on a Saturday.
What WordPress Updates on Its Own Right Now
Your site is probably already auto-updating something, and there’s a decent chance you never chose it. Automatic background updates landed in WordPress 3.7, and since then, minor core releases, development versions, and translation files have updated themselves by default. That’s the mechanism that pushed 6.4.1 onto millions of sites without anyone clicking anything.
Major versions are a different story, and the split is the single most confusing thing about this feature. Per WordPress’s own developer documentation, existing installations receive minor core updates by default, while fresh installations created on WordPress 5.6 or later receive both minor and major core updates by default — unless WordPress detects a version control checkout. So two sites sitting on the same server, running the same version, can behave completely differently depending on which year they were installed. Older sites can opt in to major auto-updates, but somebody has to actually go do it.
Plugins and Themes Are Opt-In, With One Exception
Plugin and theme auto-updates are off unless you switch them on individually. The code to do it had been sitting in core for years, but it required a filter hook, so almost nobody used it. WordPress 5.5 finally shipped a real interface: an “Enable auto-updates” link in the last column of Plugins › Installed Plugins, and the same thing on the Themes screen.
There’s one carve-out worth knowing about. WordPress’s documentation notes that background updates do happen for plugins and themes in special cases, “as determined by the WordPress.org API response, which is controlled by the WordPress security team for patching critical vulnerabilities.” So when something genuinely serious lands in a widely installed plugin, a fix can be pushed to your site whether or not you opted in. It’s rare, it’s reserved for emergencies, and it has saved a lot of sites.
That per-plugin granularity is a feature, not an oversight. You probably want auto-updates on for your form plugin and your caching plugin, and you probably want a human involved before your page builder or your WooCommerce install changes underneath a live checkout.
When a WordPress plugin vulnerability goes public, the patch and the exploit become common knowledge on the same day. Automated scanners start sweeping for unpatched installs almost immediately. The window between “fix released” and “your site gets probed” is measured in hours, and a site that patches itself overnight closes that window while you sleep. Speed of patching is the whole game.
The WP-Cron Dependency Nobody Mentions
Auto-updates don’t run on a timer the way you’d assume. They run on WP-Cron, and WP-Cron is a bit of a fiction — by default it only fires when somebody loads a page on your site.
Trace it through core and the chain is explicit. The wp_version_check() function runs as a scheduled cron event to ask api.wordpress.org what’s available. Inside it, when the request is running non-interactively via cron, core fires do_action( 'wp_maybe_auto_update' ) — a hook whose own documentation reads “Fires during wp_cron, starting the auto-update process.” No page load, no cron run. No cron run, no auto-update.
For a busy site this is invisible. For a brochure site that gets nine visitors a week, or a staging environment nobody touches, your “automatic” security patch is waiting politely for someone to show up. It isn’t lost — the event stays queued and runs at the next visit — but “sometime in the next few days” is not the update policy you thought you’d configured.
The Fix Is a Real System Cron
If you control the server, hand the job to the operating system instead. Disable the page-load version in wp-config.php:
define( 'DISABLE_WP_CRON', true );Then schedule a genuine cron entry that hits wp-cron.php on a fixed interval — every fifteen minutes is a sane default. Now your scheduled events, auto-updates included, fire on a clock instead of on foot traffic. We covered the full setup in our WP-Cron guide, and it’s worth doing on any site where scheduling actually matters.
The Config Constants That Override Everything
Below the checkboxes there’s a layer of wp-config.php constants, and they win over anything set in the admin. Worth knowing about, because if a site is stubbornly refusing to auto-update, this is usually why — a host or a previous developer defined one of these and never mentioned it.
WP_AUTO_UPDATE_CORE
This is the master switch for core updates, and WordPress documents exactly three values:
true— development, minor, and major updates are all enabledfalse— development, minor, and major updates are all disabled'minor'— minor updates enabled; development and major updates disabled
When it’s defined, it overrides the user-controllable setting on the Updates screen in wp-admin. That’s the trap: someone clicks the “Enable automatic updates for all new versions” link, sees it stick, and never realizes a constant is quietly ignoring them. If a site isn’t behaving, grep wp-config.php before you go debugging anything else.
For most production sites 'minor' is the sweet spot. Security and bugfix releases apply themselves; major version jumps stay a deliberate decision you make with a staging site open.
AUTOMATIC_UPDATER_DISABLED
The nuclear option. Setting define( 'AUTOMATIC_UPDATER_DISABLED', true ); completely disables all types of automatic updates, core or otherwise. There’s a matching automatic_updater_disabled filter that does the same thing from PHP, and core’s documentation notes something easy to miss — it also disables update notification emails. Kill background updates that way and you’ve also killed the messages that would have told you an update was waiting. Silence, but not the good kind.
The auto_update_{$type} Filter
For conditional logic, WordPress exposes a dynamic filter that covers four hook names: auto_update_core, auto_update_plugin, auto_update_theme, and auto_update_translation. Each one filters whether to automatically update that type of thing, and you get the update object, so you can make decisions per item — auto-update everything except the two plugins you don’t trust, for instance. It’s the programmatic equivalent of the checkboxes, and it’s what you reach for when you’re managing a fleet of sites from a mu-plugin rather than clicking through each one.
WordPress 6.3 introduced a rollback feature for failed plugin and theme updates — but read the dev note’s title carefully, because it shipped scoped to manual updates. If an update you click fails partway through, core restores the previous version from a temporary backup. Rollback has been extended since, but it only ever catches a narrow class of failures, so don’t file it away as “auto-updates can’t break my site.” Your actual safety net for an unattended update is still a current, tested backup.
Setting It Up Without Gambling Your Site
The recipe below is roughly what we deploy on client sites. It’s opinionated, and the opinion is that automation should reduce risk rather than relocate it.
1. Get Backups Working First
An automated update with no backup is just an unsupervised change to production. Before you enable anything, make sure you’ve got automated daily backups of both the database and wp-content, stored somewhere that isn’t the same server. CISA has long promoted the 3-2-1 rule for exactly this: three copies of your data, on two different storage types, with one copy offsite.
Test a restore at least once. WP-CLI makes the database half trivial — wp db export runs the mysqldump utility using your site’s own credentials, and wp db import wraps the mysql client to bring it back. A backup you’ve never restored is a hope, not a plan.
2. Set Core to Minor-Only
In wp-config.php, above the “stop editing” comment:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Security releases land automatically. Major versions wait for you, which is what you want when a major release can change block editor behavior or deprecate something your theme leans on.
3. Enable Plugin Auto-Updates Selectively
Go through the plugin list and turn auto-updates on for anything that’s well maintained, widely installed, and not load-bearing for revenue. Leave them off for page builders, membership plugins, payment gateways, and anything custom. WP-CLI handles this faster than the admin does:
wp plugin auto-updates status
wp plugin auto-updates enable akismet wordpress-seo
wp plugin auto-updates disable elementor woocommerceThere’s an --all flag if you want to enable everything in one shot, but selective is the point of the exercise.
4. Make Sure the Emails Reach a Human
WordPress emails you after a background update runs, and after one fails. Those messages go to the admin email under Settings › General, which on a distressing number of sites is a mailbox nobody has opened since launch. Point it at an address a real person reads. And confirm your site can actually send mail — a lot of hosts drop PHP mail() silently, which means your “the update failed” notice never arrives at all.
5. Check In Monthly Anyway
Auto-updates don’t cover abandoned plugins, and abandoned plugins are the ones that hurt you. A plugin that stopped getting releases in 2021 will never auto-update, because there’s nothing to update to. It’ll just sit there looking current.
The last WordPress cleanup we did started exactly that way. The client’s site was fully patched, WordPress core current, everything green in the dashboard — and the entry point turned out to be a plugin the developer had walked away from years earlier, still installed and still active because nobody had a reason to look at it. The attacker dropped an IndoXploit-style webshell in an uploads subdirectory and used it to serve spam pages for months. Auto-updates were on the whole time. They just had nothing to install.
Backups running and tested. WP_AUTO_UPDATE_CORE set to 'minor'. Plugin auto-updates on for the safe majority, off for anything touching money or layout. A real system cron driving wp-cron.php. Admin email pointed at a human who reads it. Then a calendar reminder to actually look at the site once a month.
When to Skip Auto-Updates Entirely
There are sites where hands-off updating is the wrong call. Heavily customized builds where a plugin update has broken layout before. Sites under a maintenance contract with a staging-first workflow, where updates get tested on a clone and pushed deliberately. Anything running patched or modified plugin code, since an update will overwrite your changes without asking.
If that’s you, disable auto-updates deliberately rather than by neglect, and replace them with a scheduled human process — a monthly window where updates get applied on staging, verified, and promoted. What doesn’t work is the middle ground: auto-updates off, no process, and a dashboard slowly accumulating red bubbles nobody clicks. That’s how sites end up four years behind.
Frequently Asked Questions
Not sure what your site is actually doing when nobody’s watching it? We audit WordPress installs for exactly this kind of quiet drift — stale plugins, broken cron, backups that were never tested. Get in touch and we’ll take a look.
Built by amplifi.studio — see also Why Your Scheduled WordPress Posts Keep Missing Their Publish Time.