How to disable auto updates in WordPress safely

Key takeaways

  • WP_AUTO_UPDATE_CORE set to ‘minor’ stops major core jumps and keeps security releases. It does nothing to plugins or themes.
  • AUTOMATIC_UPDATER_DISABLED stops every background update, including security and translation updates. WordPress’s own handbook strongly discourages turning off security updates.
  • DISALLOW_FILE_MODS is not an auto-update setting. It also removes manual install and update from wp-admin.
  • Put auto_update_plugin and auto_update_theme filters in a must-use plugin, not in wp-config.php, where WordPress warns they can conflict with WP-CLI.
  • If updates keep happening after you turn them off, a host updater, a host must-use plugin or a vendor security channel is usually running them.

A plugin updates at 3 a.m. The homepage still loads, but checkout doesn’t. By morning the site owner wants one thing: no more updates nobody scheduled. That’s a fair goal. The risk is reaching for a switch that turns off more than you meant to, or one that doesn’t actually stop the update that hurt you.

WordPress updates core, plugins, themes and translations on separate schedules, and each has its own control. This guide covers which control does what, how to apply each one, how to check that it worked, and why some sites keep updating after every setting says no. If you only want to turn off auto-updates for a single plugin from the dashboard, our shorter guide on switching off automatic updates walks through those screens.

Which setting stops which kind of update?

Match the control to the update you want to stop. Most damage comes from using a control that is too broad, or one aimed at the wrong layer.

What you want to stopControlWhat it also does
One plugin or theme“Disable auto-updates” link on Plugins or ThemesNothing else. The plugin stays active.
Major core releases onlydefine( 'WP_AUTO_UPDATE_CORE', 'minor' );Keeps minor and security core releases running
All core auto-updatesdefine( 'WP_AUTO_UPDATE_CORE', false );Also stops core security releases
Specific plugins or themes, in codeauto_update_plugin / auto_update_theme filters in a must-use pluginReturning false also blocks WordPress.org’s critical security pushes for those items
Every background updatedefine( 'AUTOMATIC_UPDATER_DISABLED', true );Stops security and translation updates too

Two rules come out of this table. WP_AUTO_UPDATE_CORE covers core only, so setting it to false leaves plugin updates running. That surprises a lot of people. And none of these controls removes the Update buttons. With auto-updates off you can still update by hand from Dashboard → Updates.

What you need before you change anything

The per-item toggles need only an administrator login. The constants and filters need file access to the site root through SFTP, SSH or your host’s file manager. The theme file editor won’t reach wp-config.php.

Take a backup of the files and the database first, and make sure you know how to restore it. A typo in wp-config.php can white-screen the whole site. Then look at your hosting panel for an “automatic updates” or “autoupdate” section. If your host runs its own updater, change that setting first. Otherwise you’ll edit WordPress files and wonder why nothing changed.

How to stop one plugin or theme from auto-updating

Use this when one item has broken the site before: a page builder add-on, a payment gateway, a theme with a child theme on top. These controls have been in WordPress since version 5.5.

  1. Go to Plugins → Installed Plugins.
  2. In the Automatic Updates column, click “Disable auto-updates” next to the plugin. To change several at once, tick them and use the bulk action.
  3. For a theme, go to Appearance → Themes, open the theme’s details and click “Disable auto-updates.”

That change affects that one item. Core, translations, other plugins and your host’s updater all carry on as before. If the site holds back only one risky plugin, stop here. You don’t need any code.

How to stop major core updates but keep security releases

This is the compromise most practitioners recommend: let WordPress apply security and maintenance releases on its own, and run major version jumps yourself after testing.

  1. Open wp-config.php in the WordPress root, next to the wp-admin and wp-content folders.
  2. Search the file for WP_AUTO_UPDATE_CORE. If the line is already there, edit it. Don’t add a second one. PHP keeps the first definition and raises a warning for the duplicate.
  3. Above the line that reads /* That's all, stop editing! */, add:
    define( 'WP_AUTO_UPDATE_CORE', 'minor' );
  4. Save the file, then load the homepage and /wp-admin/. A white screen almost always means a missing quote or semicolon. Fix it or restore the file.

The constant overrides the core auto-update setting on the Updates screen. Setting it to false turns off all core auto-updates, security releases included. The developer handbook advises against that, and it’s hard to justify on a site where nobody is assigned to apply security releases by hand.

How to hold specific plugins in code with a must-use plugin

Use code when you manage several sites, when you want the policy kept in version control, or when clients shouldn’t be able to switch it back from the dashboard. WordPress’s handbook says these filters belong in a must-use plugin. Added to wp-config.php, they can cause conflicts, including with WP-CLI.

Create wp-content/mu-plugins/update-policy.php. Make the mu-plugins folder if it doesn’t exist. This example holds two plugins by folder name and leaves every other plugin as configured in the dashboard:

<?php
/**
 * Plugin Name: Update policy
 * Description: Holds named plugins back from auto-updates.
 */
add_filter( 'auto_update_plugin', function ( $update, $item ) {
    $hold = array( 'woocommerce', 'your-payment-gateway' );
    if ( isset( $item->slug ) && in_array( $item->slug, $hold, true ) ) {
        return false;
    }
    return $update;
}, 10, 2 );

To stop all plugin or theme auto-updates, the single-line versions are add_filter( 'auto_update_plugin', '__return_false' ); and add_filter( 'auto_update_theme', '__return_false' );.

Know what you’re giving up. The handbook says the WordPress.org security team can trigger background updates of plugins and themes in special cases, to fix a critical vulnerability. Returning false from these filters blocks those updates too. Keep the hold list short and review it.

How to turn off every background update, and when that’s right

One line in wp-config.php stops all automatic updates, “core or otherwise,” in the handbook’s words:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

This is a legitimate choice for teams that already patch on a real schedule: a large multisite with server-side security, a site deployed from version control, a staging-first agency workflow. It’s a poor choice as a reaction to one bad night. It turns off security and translation updates along with everything else, and the handbook strongly discourages switching off security updates.

If you set it, also set a recurring calendar entry with a named person on it. Turning off auto-updates is safe only when someone actually does the manual updates. Practitioners who do this well run updates on a fixed rhythm, weekly or every ten days, not when they happen to remember.

Don’t stack the filters on top of this constant. The constant already stops everything, so the filters will look broken, and the next person who reads the code won’t know which rule is in charge.

Why DISALLOW_FILE_MODS is the wrong switch

Some guides suggest define( 'DISALLOW_FILE_MODS', true );. It’s a hardening setting, not an auto-update setting. The wp-config handbook says it blocks plugin and theme installation and updates in the admin, along with the file editor. You lose the manual updates you were trying to keep.

Plugins that disable update checks have a similar problem. Disable All WordPress Updates, for example, turns off the checks and hides the notices, so updates you’ve missed never show up. Its author still tells users to keep everything current. Turning off automatic installs is a policy. Hiding available updates means nobody can see what the site is missing.

How to confirm the change worked

Go to Tools → Site Health. The Status tab warns when background updates are disabled and names the constant or filter responsible. That warning is expected if you set AUTOMATIC_UPDATER_DISABLED. If you expected it and it’s missing, the constant didn’t load. Check for a duplicate or a typo. If you see the warning but didn’t set anything, something else did. The next section covers what.

On the Info tab, open the Must-Use Plugins panel. Everything listed there runs on every request and can override your settings. Then check Dashboard → Updates, which shows the core auto-update mode in effect. Finally, wait for one real update cycle. Plugin and theme auto-updates run on WP-Cron, twice a day by default. Confirm that the held item stayed pending and that everything else behaved as before.

Why WordPress keeps updating after you turned it off

When the settings say off and updates still arrive, find out which updater ran before you change anything else. These are the usual sources, most common first.

Your host runs its own updater

Managed hosts often update sites from their own control panel, and WordPress settings don’t control those jobs. Kinsta’s documentation says enabling its automatic updates disables WordPress’s plugin auto-updates, and it advises against running competing update systems. You can switch Kinsta to manual under Sites → your site → Plugins and themes → Automatic updates. Other hosts document updaters that override wp-config.php or can be paused but not fully turned off. Read your host’s documentation, or ask support which system is running.

A host must-use plugin forces the setting

In one resolved WordPress.org support thread, Site Health reported that automatic_updater_disabled was on. Deactivating normal plugins didn’t help, because the cause was a must-use plugin the host had installed. When the host removed it, the per-plugin toggles came back. The same mechanism can force updates on as easily as off.

A vendor or WordPress.org pushes a security fix

WooCommerce’s FAQ says a store connected to WooCommerce.com with an active subscription, on WooCommerce 11.2 or later, may receive a developer-published security fix even when auto-updates weren’t enabled. If the site blocks automatic updates, the fix won’t install, and you can apply it manually from Plugins. Separately, WordPress.org can push critical plugin and theme fixes, as described above.

A second update manager is running

An update-management plugin, a maintenance dashboard you connected years ago, or a premium plugin’s own updater can each run updates on a separate schedule. Check the update manager’s logs and remove any update system you don’t use. Run one at a time.

What to do instead of turning updates off

Turning off auto-updates stops the surprises. You still have to do the updates. Updates that fail on their own, from cron, file ownership or a leftover .maintenance file, keep failing when you run them by hand. Our guide to why WordPress updates fail covers those faults.

WordPress already softens some of the risk. Its plugin team introduced phased releases in 2025, which delay plugin automatic updates by 24 hours while still allowing manual updates. That gives early reports of a bad release a day to come in. For anything higher-risk, the routine that works is short:

  1. Back up the database and wp-content, and know the restore works.
  2. Run major core, WooCommerce and heavily customized plugin updates on a WordPress staging site first.
  3. Update one thing at a time, so a break points to one cause.
  4. Test what the site exists to do. WooCommerce’s update guide lists product pages, cart, checkout, payment, shipping, tax and emails, and says to complete any database update notice.
  5. Write down what changed, when and who checked it.

Rollback restores service. It isn’t somewhere to stay. An older version keeps whatever vulnerability the update fixed. Use it to bring the site back up, fix the conflict on staging, then move forward. If you’d rather not run that routine yourself, SiteSelf handles WordPress plugin updates on request: it says what it’s about to change, checks the updated page and reports back. Editing wp-config.php needs hosting (SSH) access.

Frequently asked questions

Does disabling auto-updates hurt SEO?

Google doesn’t publish a ranking penalty for turning off auto-updates. The SEO risk comes through security. A hacked site can be flagged, and Google points owners to the Security Issues report in Search Console. Unpatched plugins make that more likely, which is a reason to keep security updates running.

How do I turn auto-updates back on?

Reverse the change you made. Remove the constant or the filter, or click “Enable auto-updates” on the item. Search wp-config.php for leftover AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE lines, including ones a previous developer or host added, and check the mu-plugins folder.

Can I keep updates off on staging but on in production?

WordPress has no built-in setting for that. Teams usually handle it with a separate wp-config.php per environment, which keeps the setting out of the database that gets copied between environments. Check that your staging tool doesn’t overwrite wp-config.php when it pushes to live.

How do I stop translation updates only?

WordPress’s documented controls don’t offer a simple translation-only switch. AUTOMATIC_UPDATER_DISABLED stops translations along with everything else. If you need finer control, some update-management plugins have a separate translation setting. Check the plugin’s listing before relying on it.

Will a failed automatic update roll itself back?

WordPress has added rollback for failed automatic plugin updates, which restores the previous version when an update causes a fatal error. It doesn’t catch a checkout that quietly stops working, and restoring files doesn’t undo database changes. A backup taken before the update is still what lets you fully undo it.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *