---
title: "WordPress Automatic Updates: How to Control Them Without Breaking Your Site"
url: https://nexterwp.com/blog/wordpress-automatic-updates/
date: 2026-07-27
modified: 2026-07-27
author: "Aditya Sharma"
description: "WordPress automatic updates explained by type: what runs by default, which updates roll back on failure, and how to control core, plugin, and theme updates safely."
image: https://nexterwp.com/wp-content/uploads/2026/07/9s_4yL0BSirMLsKJkVsYFRwazW4ntKlAWHCIVaPC9h2XoNo468v1U5ZVyykxF38CkZax6WMvI6fwaLzFJrRx7Q-1024x538.png
word_count: 2157
---

# WordPress Automatic Updates: How to Control Them Without Breaking Your Site

## Key Takeaways

- WordPress 5.6 changes the default so new installations enable automatic updates for both minor and major core releases, while pre-5.6 installs keep minor core releases and translation files only.
- WordPress 6.6 adds automatic rollback for plugin auto-updates that trigger PHP fatal errors, then restores the previous version and emails the site administrator.
- Themes have no equivalent rollback for fatal errors, so theme auto-updates are the riskiest type to switch on and forget.
- Dashboard controls let administrators opt in plugin by plugin, theme by theme, and core from Dashboard > Updates, with auto-updates running twice per day rather than instantly.
- WP_AUTO_UPDATE_CORE set to 'minor' keeps minor updates enabled while disabling development and major updates, and it overrides the Updates screen toggle in wp-admin.

 

Say you log in on a Monday and something is different. A plugin you did not touch is two versions ahead. A layout block is rendering wrong. Nothing in your notes explains it, because you were not the one who made the change. WordPress was.

The usual reaction is to search for how to turn automatic updates off and paste the first snippet that looks official. That works, in the sense that a light switch works. It also throws away the security patches that automatic updates exist to deliver, and it usually disables far more than the thing that actually broke.

There is a better answer, and it starts with a fact most guides skip: WordPress does not have one automatic update setting. It has four, they behave differently, and only one of them has a safety net that catches a bad update before your visitors do. Once you can see the four separately, controlling them stops being a gamble.

Table of Contents

## What WordPress Auto-Updates Actually Do by Default

Automatic background updates arrived in WordPress 3.7, added to improve site security and take some of the manual work out of staying current. Since then the feature has grown into four distinct update types, each with its own default.

Here is the part that catches people out. The handbook notes that "Before WordPress 5.6, every site had automatic updates enabled for minor core releases and translation files only by default," while "Starting with WordPress 5.6, new installations have automatic updates enabled for both minor and major core releases by default."

Read that twice, because it means the age of your install decides your update policy. A site set up in 2019 and a site set up last month can be running identical software and still treat a major WordPress release completely differently. Nobody chose that. It is just where the default landed at the moment each site was born.

| Update type | Default on a pre-5.6 install | Default on a 5.6+ install | Where you control it |
| ----------- | ---------------------------- | ------------------------- | -------------------- |
| Core, minor (7.0 to 7.0.1) | On | On | Updates screen, constant, filter |
| Core, major (7.0 to 7.1) | Off | On | Updates screen, constant, filter |
| Plugins | Off, opt in per plugin | Off, opt in per plugin | Plugins screen, filter |
| Themes | Off, opt in per theme | Off, opt in per theme | Theme modal, filter |
| Translations | On | On | Constant, filter |
The four update types and their defaults. Plugins and themes are always opt-in, which is why most sites never auto-update them at all.

Plugins and themes are the important row here. They have never been on by default. Since WordPress 5.5 you opt in one plugin or one theme at a time, which means the components most likely to break your site are also the ones WordPress deliberately refuses to touch without permission.

***Also Read:** [Why update WordPress core, themes and plugins](https://nexterwp.com/blog/why-update-wordpress-core-themes-and-plugins-to-the-latest-version/) if you want the case for staying current before you decide how much to automate.*

## The Safety Net That Only Covers Plugins

This is the detail that should drive your whole policy, and it is missing from almost every guide on the topic.

WordPress 6.6 shipped what the official field guide calls "the automatic rollback of plugin auto-updates upon detecting PHP fatal errors." If a plugin auto-updates and the new version throws a fatal error, WordPress notices, restores the previous version, and emails the site administrator. Your visitors never see the white screen.

![WordPress 6.6 Field Guide on Make WordPress Core describing automatic rollback of plugin auto-updates on PHP fatal errors](https://nexterwp.com/wp-content/uploads/2026/07/3YEOUyuZhAmIig9WRejh5QEDolOWFj8ZBj-GN61ycdOvVNo-sOZOHPCMKiZQ8ruwAW2O7xtg0kGRCFznEKnAsQ-scaled.png)The WordPress 6.6 Field Guide confirming automatic rollback for plugin auto-updates that trigger PHP fatal errors.

Core has had its own protections since automatic updates launched. Themes have neither. There is no equivalent rollback for a theme auto-update that fatals, which makes theme auto-updates the riskiest of the three to switch on and forget.

So the honest ranking, from safest to least safe to automate, is core minor releases first, then plugins, then themes, then core major releases. That ordering is not a matter of taste. It follows directly from which types WordPress will actually rescue for you.

One caveat worth stating plainly: rollback catches PHP fatal errors. It does not catch a plugin that updates cleanly and quietly changes your markup, breaks a layout, or drops a feature you depended on. For that class of problem the answer is still a backup and somewhere safe to test.

## How to Control Auto-Updates From the Dashboard

Most sites never need to touch a config file. Since WordPress 5.5, per the official documentation, "websites Administrators can manually opt-in for automatic updates theme by theme and plugin by plugin."

![WordPress.org documentation page showing how to enable auto-updates for plugins and themes since WordPress 5.5](https://nexterwp.com/wp-content/uploads/2026/07/70CcDmePm7RescFVQdVRMcgNFogW7tE4EaVuUlSWG0Ns3aqdZXPG1qcUefnCyNnFWIVnZ2ETDtVoHIzohPLBwQ-scaled.png)The official WordPress documentation for plugin and theme auto-updates, including the per-item opt-in introduced in WordPress 5.5.

### Plugins

Go to Plugins. The documentation describes it exactly: "For each plugin, there is an 'Automatic update' column with an action link used to enable/disable auto-updates plugin by plugin." Click the link to toggle it. Click it again to reverse.

To do several at once, tick the checkboxes in the first column and use the bulk action selector at the top of the table, then click Apply. That is the fastest way to enable auto-updates for a set of well-behaved utility plugins while leaving your page builder, commerce, and membership plugins on manual.

### Themes

Go to Appearance and click a theme thumbnail. Inside the theme modal, just below the theme author, there is an "Enable auto-updates" action link. Themes have to be handled one at a time, with no bulk equivalent.

### Core

Go to Dashboard and then Updates. Near the top you will find a line telling you whether the site keeps itself updated to maintenance and security releases only, or to every new version of WordPress, with a link to switch between the two.

One timing note that explains a lot of confusion: WordPress runs auto-updates twice per day, not the instant a release lands. When an update is pending, the time until the next scheduled run is shown right under the toggle link.

## How to Control Auto-Updates With wp-config.php Constants

Constants are the blunt instrument. They are the right tool when you want a site-wide rule that no admin can casually click away, which is typical on client sites and managed environments.

![WordPress Advanced Administration Handbook page documenting the AUTOMATIC_UPDATER_DISABLED and WP_AUTO_UPDATE_CORE constants](https://nexterwp.com/wp-content/uploads/2026/07/LlPcyAoOgozwFlgsL7mk-UMdFKQwKmaTf3iLYMsXMU8_Ky_3t2gVyniMaECP_MDiVwDIFVlc7VJ-pgg3iYoIDA-scaled.png)The Advanced Administration Handbook section covering the two constants that govern automatic updates site-wide.

### Turn Every Automatic Update Off

Add this to wp-config.php, above the line that says to stop editing:

`define( 'AUTOMATIC_UPDATER_DISABLED', true );`

That kills all four types at once. The handbook does not hedge about how it feels on this: enabling minor and translation updates was "a conscious decision" by the core team, and "disabling these updates is strongly discouraged." Reach for this only when something else in your stack owns updates, such as a managed host or a version-controlled deployment pipeline.

### Set a Core Update Policy

The more useful constant is the one that targets core alone:

`define( 'WP_AUTO_UPDATE_CORE', 'minor' );`

It accepts three values, and the handbook spells out each behaviour:

- **true** gives you "Development, minor, and major updates are all enabled"- **false** gives you "Development, minor, and major updates are all disabled"- **'minor'** gives you "Minor updates are enabled, development, and major updates are disabled"

For most production sites, 'minor' is the setting you want. Security and maintenance releases land on their own, while a major version upgrade stays a decision you make deliberately, after you have tested it.

Be aware of the side effect. The handbook is explicit that when the constant is set, it "overrides the user-controllable automatic update setting provided on the Updates screen in wp-admin." The toggle in the dashboard stops doing anything. If a teammate later wonders why clicking it has no effect, this is why, so leave a comment in wp-config.php explaining the decision.

***Also Read:** [How to set up a WordPress staging site](https://nexterwp.com/blog/wordpress-staging-site/) so major core releases and risky plugin updates get tested somewhere that is not production.*

## How to Control Auto-Updates With Filters, and Where to Put Them

Filters give you rules instead of switches. Before the code, one correction that matters more than any snippet on this page.

A great deal of advice online tells you to drop add_filter() calls straight into wp-config.php. The official handbook says not to, in as many words: "Do not add add_filter() calls directly in wp-config.php. WordPress isn't fully loaded and can cause conflicts with other applications such as WP-CLI." The handbook's own recommendation is that "The best place to put these filters is in a must-use plugin."

A must-use plugin is a single PHP file in wp-content/mu-plugins/ that WordPress always loads and nobody can deactivate by accident. Create the folder if it does not exist, add a file such as update-policy.php, open it with a PHP tag, and put your filters there.

![WordPress developer reference page for the auto_update_type dynamic hook listing auto_update_plugin and auto_update_theme](https://nexterwp.com/wp-content/uploads/2026/07/euv2lSj4130yw-_DkubBB3oe0YWmfBIjaHzlrmsJnyYzOuZc3QJwUnxjxgm2carasA56gEsVFfE85R1-pe2gjg-scaled.png)The developer reference for the dynamic auto_update_type hook, which expands into auto_update_core, auto_update_plugin, auto_update_theme, and auto_update_translation.

### Disable Everything, or Just Core

`add_filter( 'automatic_updater_disabled', '__return_true' );

add_filter( 'auto_update_core', '__return_true' );`

The first is the filter equivalent of the AUTOMATIC_UPDATER_DISABLED constant. The second enables all core update types on their own.

### Split Core by Release Type

For finer control, WordPress exposes three separate filters. Swap __return_true for __return_false to disable instead:

`add_filter( 'allow_dev_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_true' );
add_filter( 'allow_major_auto_core_updates', '__return_false' );`

That trio is the same policy as WP_AUTO_UPDATE_CORE set to 'minor', written so a future reader can see each decision on its own line.

### Target Individual Plugins and Themes

The dynamic auto_update_{$type} hook, introduced in WordPress 3.7.0, expands into auto_update_core, auto_update_plugin, auto_update_theme, and auto_update_translation. It passes two parameters: whether to update, and the update offer itself. Because you receive the offer object, you can decide per item rather than per type.

`add_filter( 'auto_update_plugin', function( $update, $item ) {
$never_auto_update = array(
'woocommerce/woocommerce.php',
);

if ( in_array( $item->plugin, $never_auto_update, true ) ) {
return false;
}

return $update;
}, 10, 2 );`

This is the pattern worth keeping. Leave auto-updates on across the board so security fixes arrive without you, and maintain a short deny list of the two or three plugins that genuinely touch revenue or layout. Since WordPress 5.5 the $update parameter also accepts null, which core uses to detect whether anything has hooked in at all, so return $update rather than a hardcoded true when you want to defer to the existing setting.

## A Sane Auto-Update Policy for a Production Site

Putting the pieces together, here is a policy that keeps the security benefit and removes most of the risk.

| Type | Setting | Reasoning |
| ---- | ------- | --------- |
| Core, minor | Automatic | Security and maintenance fixes. Core has had update protection since 3.7. |
| Core, major | Manual | Test on staging first. No rollback safety net for a bad major upgrade. |
| Translations | Automatic | Text files. Close to zero risk. |
| Plugins, low risk | Automatic | WordPress 6.6 rolls back a plugin update that throws a PHP fatal error. |
| Plugins, business critical | Manual, via deny list | Rollback catches fatals, not silent layout or feature regressions. |
| Themes | Manual | No automatic rollback exists for themes. A broken theme is highly visible. |
A per-type auto-update policy for a production WordPress site, based on which types WordPress will actually recover for you.

Two habits make this policy hold up. Keep working backups, because rollback covers one specific failure mode and not the rest. And when you do run a batch of manual updates, put the site behind a maintenance page so nobody lands mid-update on a half-rendered page.

If you use [Nexter Extension](https://nexterwp.com/nexter-extension/), the maintenance and coming soon mode covers that update window, and its security features handle hardening tasks like hiding the WordPress version, a custom login URL, and two-factor authentication. To be clear about what it is not: it is not a backup plugin and it is not an update manager, so pair it with a dedicated backup tool rather than treating it as one.

## When Auto-Updates Silently Stop Working

A common support thread goes like this: auto-updates are enabled, the toggle says so, and nothing ever updates.

Almost always the cause is scheduling rather than the update system. The official documentation is clear that auto-updates "rely on WordPress Cron tasks to actually perform the update." If WP-Cron is not firing, the toggles are accurate and inert at the same time. Go to Tools and then Site Health, and look for a cron-related error there first.

Two other causes are worth ruling out. If the auto-update controls are missing entirely, confirm you are on WordPress 5.5 or later, then check whether your host or a security plugin has switched the feature off, which the documentation flags as the usual explanation. And if a constant is set in wp-config.php, remember it overrides the dashboard, so the screen can show one thing while the site does another.

On the reporting side, WordPress emails the site administrator after auto-update attempts, whether they succeeded, failed, or partly succeeded. Those emails are the cheapest monitoring you will ever get. Make sure they reach a mailbox someone actually reads.

## Suggested Reading

- [Best WordPress backup plugins](https://nexterwp.com/blog/best-wordpress-backup-plugin/) for the safety net that rollback does not provide.- [How to put WordPress in maintenance mode](https://nexterwp.com/blog/how-to-put-wordpress-in-maintenance-mode/) before a batch of manual updates.- [How to check and update your WordPress PHP version](https://nexterwp.com/blog/how-to-check-and-update-wordpress-php-version/), a common reason updates fail.- [WordPress 7.1: what is new and what got deferred](https://nexterwp.com/blog/wordpress-7-1/) before you allow major core auto-updates.- [Best WordPress security plugins](https://nexterwp.com/blog/best-wordpress-security-plugins/) to pair with a current, patched install.

#### Stay updated with Helpful WordPress Tips, Insider Insights, and Exclusive Updates – Subscribe now to keep up with Everything Happening on WordPress!

Subscribe