Free tools Windows power users keep installed
One-click scans. No signup required.
WordPress separates automatic updates for core, plugins, themes, and translations. You can control plugins and themes from the dashboard, set a broad core policy in wp-config.php, and use update filters for item-level exceptions. The safe approach is to keep current backups, test risky changes on staging, and reserve a complete shutdown of automation for specific, documented reasons.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What WordPress auto-updates actually control
“WordPress auto-updates” is not one switch. Four update paths can affect a site independently:
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Core: the WordPress software itself, including maintenance and security releases.
- Plugins: extensions that add features such as forms, caching, payments, or membership functions.
- Themes: the active design and any installed themes you choose to manage automatically.
- Translations: language files distributed separately from the main software, plugins, and themes.
That separation matters because the right policy is rarely “everything on” or “everything off.” A small brochure site may tolerate automatic updates for well-maintained plugins, while a customized commerce or membership site may need a test window before changing a high-impact component. WordPress gives you dashboard controls for plugins and themes, configuration constants for broad core behavior, and filters for more precise decisions.
Check the site before changing update settings
Changing an update policy without knowing what is installed can create a preventable outage. Start with an inventory and a rollback plan.
#1 Best Overall
Record the current environment
- Write down the installed WordPress core version.
- Identify the active theme and note whether it has been customized.
- List active plugins, especially those that handle payments, accounts, memberships, forms, caching, security, or scheduled jobs.
- Record custom code in a child theme, a site-specific plugin, a must-use plugin, or the hosting control panel.
- Ask whether the host performs its own WordPress, plugin, or theme updates. Host-supplied updates can overlap with dashboard settings.
Make a usable backup
Keep a recent copy of both the site files and the database before enabling plugin or theme auto-updates. A database-only export cannot restore uploaded media, theme files, or plugin code; a files-only copy cannot restore posts, settings, orders, or user data. A backup is useful only if you know where it is stored and how to restore it.
Decide whether production is the right place to test
Clone the site to staging or use a development environment when compatibility is uncertain. Custom code, ecommerce workflows, membership features, and host-level update jobs all justify testing before a production update. Staging is not a substitute for a backup: keep both, because a staging test cannot recover production data lost after an unrelated failure.
Enable or disable automatic plugin updates in the dashboard
Per-plugin controls have been available in WordPress 5.5 and later. They let you select a policy by plugin instead of applying one rule to every extension.
- Sign in to the WordPress administration area.
- Open Plugins.
- Find the Automatic update column in the plugin list.
- For a plugin you trust to update without a test window, choose Enable auto-updates. For a plugin that must be held, choose the matching disable action.
- To change several plugins together, select their checkboxes, choose the relevant automatic-update bulk action, and apply it.
Use selective automation deliberately. A plugin that is lightly used and maintained may be a good candidate, while a customized plugin or one connected to a critical workflow should normally remain under a controlled update process. If you disable a plugin’s automatic updates, assign someone to review new releases; otherwise a temporary hold can become an untracked security gap.
WordPress documentation states that eligible plugin and theme auto-updates run twice per day by default. After an attempt, WordPress sends the site owner an email reporting success or failure. Those messages are operational alerts, not proof that every visitor-facing workflow still works, so check important pages after a meaningful update.
Manage automatic theme updates
Themes are managed individually rather than with one universal dashboard switch.
Recommended Free Tools
- Open Appearance in the WordPress dashboard.
- Select the theme you want to manage.
- Choose Enable auto-updates to allow automatic updates, or use the matching disable action to hold that theme.
Do not enable automatic updates on a theme merely because it is inactive. An inactive theme can still be useful as a fallback, but it can also contain unmaintained code. Keep your theme inventory intentional, and treat a customized theme differently from an unmodified theme supplied by its developer. If customizations were made directly to the theme’s files, an update can replace those files; test the change and keep a restorable copy before proceeding.
Set the WordPress core update policy
Core behavior is controlled separately from the per-plugin and per-theme dashboard actions. The WordPress developer handbook documents the WP_AUTO_UPDATE_CORE constant with three principal values:
| Setting | Effect | When it fits |
|---|---|---|
define( 'WP_AUTO_UPDATE_CORE', false ); |
Disables automatic core updates. | Only when you have a documented testing or hosting reason and a reliable manual update owner. |
define( 'WP_AUTO_UPDATE_CORE', true ); |
Enables all core updates. | Sites that can accept automatic core changes and have a tested rollback path. |
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); |
Enables minor releases; the handbook describes this as the default core setting. | A conservative baseline that keeps routine maintenance and security coverage while avoiding an unrestricted core policy. |
Place the constant in wp-config.php before the line that says WordPress has stopped editing. Edit the file carefully: a syntax error can prevent WordPress from loading. Make one change at a time, preserve the previous copy, and verify the site after saving.
Core policy does not override every other update path. Setting WP_AUTO_UPDATE_CORE does not decide whether an individual plugin or theme updates; those are controlled from the dashboard or with their own filters.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsUse filters for finer control
When a global dashboard choice is too broad, WordPress provides documented filters. Put filter code in a normal plugin or a must-use plugin so it loads as part of WordPress’s plugin system. The developer handbook cautions against putting filter calls directly in wp-config.php, because WordPress is not fully loaded there.
Control all plugin or theme auto-updates
The auto_update_plugin and auto_update_theme filters can enable or disable an entire class of updates. A basic example in a plugin or must-use plugin is:
<?php
add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );
That example turns off automatic updates for every plugin and every theme, so it should be used only when that broad result is intentional. Replacing __return_false with __return_true creates the opposite policy for that class.
Make an item-level decision
The auto_update_$type hook supports decisions for an individual update item. The exact callback must inspect the update object and return a Boolean decision. Because the object’s properties and the matching type matter, test this code on staging and document which item it targets. Do not paste an item-level rule into wp-config.php.
Filters are powerful, but they add another policy layer that administrators must remember. If a dashboard setting appears to have no effect, check active plugins and must-use plugins for filters that override it, then check whether the host is applying its own updates.
Rank #4
When to disable all automatic updates
WordPress documents a complete switch:
define( 'AUTOMATIC_UPDATER_DISABLED', true );This disables automatic updates. Legitimate reasons include substantial customizations, host-supplied updates, or a deliberate pause while a change is tested in development or staging. It is not a general substitute for maintenance. WordPress’s upgrade guidance strongly discourages disabling automatic updates because automatic minor updates are an important way to keep sites current and secure.
WordPress security guidance says that only the latest version is officially supported, although the Security Team may backport critical fixes to older versions as a courtesy. A site that remains on an older version therefore carries more operational responsibility: someone must watch release notices, evaluate compatibility, apply updates manually, and verify the result. If you cannot name that owner and schedule, do not disable automation permanently.
A safe operating procedure for updates
Use the following sequence whenever you change policy or allow a significant update.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Inventory. Record core, active theme, plugins, custom code, and host behavior. Note which components are business-critical.
- Back up. Capture both files and the database. Confirm that the backup is recent and that restoration is possible before changing an update setting.
- Test risky changes. Clone production to staging or a development environment when custom code, ecommerce, memberships, or host coordination could affect compatibility.
- Choose scope. Keep core maintenance and security coverage in place where possible. Enable plugin and theme automation selectively for well-maintained, low-risk components; hold customized or high-impact components for a controlled window.
- Apply or allow the update. For dashboard-managed components, use the relevant automatic-update action. For core policy, make the documented configuration change. For filter-based rules, deploy the plugin or must-use plugin through your normal change process.
- Check notifications. Review the owner email reporting success or failure. A failed attempt needs investigation rather than silent retries.
- Run a functional check. Visit the homepage, sign in as an administrator, submit a key form, test checkout or membership actions when applicable, and inspect scheduled or integration-driven workflows that matter to the site.
- Document exceptions. For every disabled update, record the reason, responsible person, next review date, and restoration plan.
Choose a policy by trade-off, not by habit
There is no universally safe switch. Compare each policy against security speed, compatibility control, rollback readiness, operational effort, and interaction with the host.
| Policy | Security speed | Compatibility control | Rollback readiness | Operational effort | Hosting interaction |
|---|---|---|---|---|---|
| Broad automation: core, selected plugins, and selected themes | Fast for covered components | Lower; production may change before a manual test | Must be strong and current | Lower, but alerts still require review | Coordinate with host jobs |
| Selective automation | Fast for approved components; slower for held items | Moderate to high | Required for every update window | Moderate; someone must maintain the allow/hold list | Check which layer owns each update |
| Manual updates with core maintenance coverage retained | Fast for core maintenance; dependent on scheduled plugin/theme work | High | Strongly required | Higher and continuous | Useful when the host supplies updates, if responsibilities are clear |
| Complete automatic-updater shutdown | Slowest unless a disciplined manual process replaces it | Highest before release | Required before every change | Highest; postponement can become exposure | May avoid conflicts, but host behavior still needs confirmation |
For most sites, selective automation is a practical middle ground: retain core maintenance coverage, automate stable components, and reserve customized or high-impact code for tested windows. The more automation you disable, the more important ownership, reminders, backups, and staging become.
Troubleshoot common update-policy problems
A plugin updated even though you disabled its dashboard switch
- Check whether a bulk action changed the plugin after your individual setting.
- Inspect active and must-use plugins for an
auto_update_pluginor item-level filter. - Ask the host whether it runs its own update service.
- Review the owner email and update logs available in your hosting or administration tools to identify which process ran.
The dashboard has no Automatic update column
Per-plugin and per-theme dashboard controls are available from WordPress 5.5 onward. Confirm the core version and the account’s administrative permissions. A host-managed environment may also hide or replace dashboard controls; verify the host’s policy before adding code.
An update caused a visible or functional failure
- Keep the site’s current state and record the exact component and time of the update.
- Use the backup or rollback mechanism you verified before the change.
- Restore files and database consistently rather than mixing versions from different points in time.
- Reproduce the problem on staging, then contact the component’s maintainer or your developer with the error and version details.
- Do not leave automation disabled indefinitely; set a review date and re-enable coverage after a tested fix or replacement is available.
Core remains on an unexpected update behavior
Check for conflicting definitions of WP_AUTO_UPDATE_CORE, the complete shutdown constant, and filters in plugins or must-use plugins. Also confirm whether the host applies core updates independently. Make one policy authoritative, document it, and remove obsolete overrides.
Success emails arrive but the site is broken
A success notification means the update process completed; it does not certify every visitor or administrator workflow. Check critical paths after meaningful updates and treat failures in forms, logins, payments, memberships, scheduled jobs, or integrations as a reason to use staging and a rollback plan before the next attempt.
Keep the policy healthy over time
Auto-update management is an ongoing operating decision, not a one-time checkbox. Review the inventory when staff, hosting, themes, or major plugins change. Re-test restoration periodically, remove abandoned components, and revisit every exception on its documented review date. If a plugin or theme is held because of a customization, plan how that customization will be preserved or replaced; otherwise the exception can outlive the reason for it.
Finally, treat update notices as tasks. Twice-daily eligibility checks and success or failure emails reduce the delay between a release and your response, but they do not replace ownership. A named person or team should know which updates are automatic, which are manual, where backups are stored, and what to do when a notification reports failure.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
