Yes for minor releases, sometimes for major ones. Existing WordPress installs receive minor core updates automatically by default. Fresh installs created on WordPress 5.6 or later also receive major updates, unless a version control checkout is detected. A setting in wp-config.php can tighten or loosen this.
Minor versus major
Minor releases are mostly maintenance and security fixes. Major releases add features and change more code, so a site with a heavy plugin stack may need testing first. WordPress treats them differently for that reason.
| Update type | Existing install | Fresh install on 5.6 or later |
|---|---|---|
| Core minor | Automatic by default | Automatic |
| Core major | Not automatic | Automatic, except version controlled sites |
| Plugins and themes | Special cases only | Special cases only |
| Translation files | Automatic | Automatic |
The special cases for plugins and themes are flagged by the WordPress.org API. Do not assume your plugins are updating just because core is.
Controlling it with wp-config.php
The WP_AUTO_UPDATE_CORE constant sets core behaviour. Three values matter:
- true enables all core updates, including major releases and development builds
- false disables all core updates
- minor enables only minor releases, which is the documented default
When the constant is set it overrides the setting on the Updates screen. A second constant, AUTOMATIC_UPDATER_DISABLED, stops the site from auto-updating at all. The documentation suggests it for sites with customisations, host-supplied updates, or a requirement to test in staging first.
Which setting should you pick?
Pick minor for sites you cannot test every release on. It keeps security fixes flowing with low breakage risk. Pick true only if you have backups, monitoring and a plugin set you trust. Pick false only if something else, such as a deployment pipeline or your host, handles core updates, and write down who is responsible.
The risky pattern is false with nobody applying updates. Sites end up pinned to a release for years because someone once disabled updates to avoid a breakage.
Version controlled sites
If your site lives in a git checkout, WordPress may skip automatic updates because it detects the checkout. That is deliberate. In that setup, core updates should arrive through your normal change process: a pull request, a test run, a deploy.
Check what you actually run
The WordPress version appears on the Dashboard and in the command line. Compare it against the latest release for your branch each month. If you cannot say which person or system updates core on a given site, that is the finding to fix first.
A short monthly routine
- List each site with its core version and its update setting.
- Mark sites where WP_AUTO_UPDATE_CORE or AUTOMATIC_UPDATER_DISABLED is set, and note who set it and why.
- Check that the owner of each site can restore a backup, because automatic updates assume you can.
- Confirm that plugins and themes have an update path too, since core is only one part of the stack.
This takes minutes per site and removes the most common surprise: a site that everyone thought was updating itself. Safeguard can scan a repository for dependency manifests and produce an SBOM, and there is a free scan at gold.safeguard.sh/scan.
Quick check
Does WP_AUTO_UPDATE_CORE override the dashboard setting?
Yes. When the constant is defined in wp-config.php it takes precedence over the Updates screen.
Do I still need backups if updates are automatic?
Yes. Automatic updates reduce delay but cannot guarantee a clean result on every site.
Sources
Last reviewed: 19 October 2026.
