Since WordPress 3.7, the platform updates parts of itself automatically without anyone clicking anything. Most site owners are vaguely aware of this but few have a clear picture of exactly what gets updated, when, and how to change the default. This guide goes through the four levels of automatic updates that WordPress core supports, what each level actually does, and which one is the right choice depending on whether you run a single site, an agency portfolio or a managed hosting setup.
What WordPress updates automatically by default
Out of the box, every WordPress install in 2026 does the following without asking:
- Minor core updates. Going from 6.5.1 to 6.5.2 happens automatically, in the background, the same day the release is published. These releases are bug fixes and security patches. They are explicitly designed to be safe to install without testing.
- Translation file updates. Language packs refresh automatically.
- Core security releases for older branches. Even if your site is still on 6.4 because you have not done a major update, security fixes are backported and applied automatically.
What does not happen automatically by default:
- Major core updates. Going from 6.5 to 6.6 requires a manual click. WordPress shows the banner in the admin but does not install it on its own.
- Plugin and theme updates. Both can be enabled per item via the admin UI (since WordPress 5.5), but neither is on by default. They are a separate topic and not controlled by
WP_AUTO_UPDATE_CORE.
The reason for this split is good engineering: minor releases ship behind a strict policy of "no breaking changes", so updating them silently is genuinely low risk. Major releases occasionally introduce new APIs or change behavior that themes and plugins might rely on, and silently moving up a major version on production has caused enough breakage historically that the project chose the conservative default.
The four levels of automatic core updates
The constant WP_AUTO_UPDATE_CORE in wp-config.php controls all of this. It accepts four values:
true: All core updates are installed automatically, both minor and major. The aggressive option.'minor': The default if the constant is not defined at all. Only minor and security releases are installed automatically. Major releases stay manual.'beta'and'rc': Used by sites that want pre release builds. Realistic only on a staging or test environment, never on production.false: All automatic core updates are disabled. The site does nothing on its own. You are responsible for every patch, including security fixes.
Setting any of these is a single line in wp-config.php, anywhere above the /* That's all, stop editing! Happy publishing. */ comment:
define('WP_AUTO_UPDATE_CORE', true);or
define('WP_AUTO_UPDATE_CORE', 'minor');Save the file, no restart needed. WordPress checks for updates on a schedule (twice a day by default) and applies whatever the current setting allows.
Which setting makes sense for which kind of site?
The honest answer depends on three things: how much testing happens before a release goes live, who notices when something breaks, and how good the backup story is.
Standard production site, no dedicated maintenance contract
Recommended setting: true (all updates automatic).
The intuition that "automatic major updates are dangerous" is largely outdated. WordPress major updates have been stable for years, and the realistic alternative is "no one updates the site for six months because there is no contract for it, and a known security hole stays open". An unmaintained WordPress site is a worse outcome than the very rare auto update that breaks something. If a major release breaks the site, restoring from a backup is faster than the time you would otherwise spend chasing the manual update later. The automation is the win.
Managed hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)
Recommended setting: whatever the host's dashboard does, usually 'minor' at the WordPress level.
Most managed hosts run their own update flow on top of WordPress. They take a snapshot first, install the major release on a staging clone, run a basic visual diff and only then apply it to production. That is meaningfully safer than vanilla auto updates. If you are on this kind of host, setting WP_AUTO_UPDATE_CORE to anything other than the default usually fights with the host's own logic. Leave it alone, let the host do its thing, and check the host dashboard for the update history.
Agency portfolio with a maintenance contract
Recommended setting: 'minor' on production, true on staging.
If a maintenance contract specifies that you test updates before they go live, the agency is the safety net. Production should still get minor and security releases automatically (those are not optional from a security standpoint), but major updates go through the agency's testing flow. Staging environments are the right place to set the more aggressive value, so testers catch breakage early.
Custom WordPress build with heavy theme or plugin customization
Recommended setting: 'minor', plus a real testing process for major updates.
Sites that have been heavily customized (rebuilt headers, custom Gutenberg blocks, weird page builder integrations, custom REST endpoints) are exactly the case where a major update can break something subtle. The default 'minor' setting is the right floor: do not give up the security patches, but treat majors as a separate task with a real test pass.
High availability site that absolutely cannot break
Recommended setting: false for core, plus a real release process.
This is the only case where turning off automatic core updates entirely makes sense. Banking, healthcare, regulated environments where every change goes through a release process. Note that you accept full responsibility for applying security patches manually within hours of a release, on every site. Most teams that pick this setting also have monitoring on the WordPress security mailing list and a deployment pipeline that can ship patches the same day.
How to verify your setting is active
- In the WordPress admin, go to Tools, Site Health, Info.
- Expand the WordPress Constants section.
- Look for
WP_AUTO_UPDATE_CORE. If it shows your value, the constant is being read. - For a deeper check, look at Updates in the admin sidebar. Recent automatic updates show up there with timestamps.
If the constant value does not show up in Site Health, the most likely cause is that it was set after the file already defined it earlier (the first define wins, and PHP issues a notice you might not see), or that you edited the wrong wp-config.php.
What can go wrong with automatic core updates
Three failure modes are realistic and worth knowing about:
- Update partially fails. The download or extraction breaks halfway through, often because the host has not enough disk space, has hit an inode limit, or because of a temporary network issue. WordPress drops a
.maintenancefile in the root and the site shows "Briefly unavailable for scheduled maintenance" forever. Fix: SFTP into the root and delete the.maintenancefile, then re run the update from the admin. - Update succeeds but a plugin starts throwing errors. Especially after a major update, an unmaintained plugin can break against new core APIs. Fix: have a backup ready, identify the broken plugin from the error log (or by deactivating plugins one by one), and either update the plugin or replace it.
- Update is silently skipped. Common reasons:
DISALLOW_FILE_MODSis set inwp-config.php(which blocks all updates, automatic or not), file permissions on the WordPress directory prevent PHP from writing, or the site uses Git for version control and WordPress detects the.gitdirectory and disables updates as a safety measure. The Site Health page typically flags these cases.
Auto updates and DISALLOW_FILE_MODS
The two constants interact in a way that catches people out. DISALLOW_FILE_MODS (covered in our knowledge base under the file editor topic) blocks all file modifications from the WordPress side, including automatic core updates. If both constants are set:
define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);The result is that DISALLOW_FILE_MODS wins. WordPress will not auto update anything. This is rarely what people intend. Either you want a locked down site that updates from outside (deploy pipeline, WP CLI), in which case DISALLOW_FILE_MODS = true is right and WP_AUTO_UPDATE_CORE is irrelevant. Or you want the site to update itself, in which case DISALLOW_FILE_MODS should not be set.
What about automatic plugin and theme updates?
Plugin and theme auto updates are a separate mechanism that landed in WordPress 5.5. They are configured per item in the admin (Plugins list, the "Enable auto updates" link in each row) or globally via filters. The general recommendation: turn auto updates on for any plugin where you trust the maintainer's release discipline, leave them off for plugins that ship breaking changes regularly. WooCommerce major releases, in particular, are often worth holding back for a manual update with a quick test.
If you want to enable plugin auto updates programmatically for every plugin, this filter does it:
add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');Drop that into a small must use plugin under wp-content/mu-plugins/ rather than into functions.php, so a theme switch does not turn it off.
The bottom line for core updates: for most sites in 2026, the default 'minor' setting is conservative in the wrong direction. Either set WP_AUTO_UPDATE_CORE to true and let the platform keep itself current, or commit to a real maintenance process that handles majors manually within reasonable time. The middle ground of "default settings plus no one watching" is what produces unpatched WordPress sites two versions behind, and that is the actual high risk state.