WordPress Updates and Auto-Updates: Defaults, Settings and a Safe Process

A WordPress site has three layers that need updates: WordPress core, plugins and themes. Each one updates on a different schedule, and each has different auto-update defaults. Knowing which layer updates itself, and which waits for you, is the first step to keeping a site secure without breaking it.

Here is the short version. As of October 2026, existing WordPress installs automatically apply minor (maintenance and security) core releases and translation files. New installs created since WordPress 5.6 also apply major core releases automatically. Plugin and theme auto-updates are opt-in, one item at a time, unless your host or a plugin turns them on for you.

The current release is WordPress 7.1.2 (22 September 2026), and WordPress.org states that only the most recent version in the 7.1 series is actively maintained. Three major releases are planned for 2026: 7.0 shipped on 20 May, 7.1 on 19 August, and 7.2 is targeted for early December. That pace means more major updates to plan for than in recent years.

This guide covers what each type of update is, the default settings, how to change them, a safe update routine, and what "rollback" really means in WordPress today.

The three kinds of WordPress updates

Core updates

Core updates change WordPress itself. They come in two sizes. Major releases (7.0, 7.1, 7.2) add features and can change the editor, the admin screens and developer APIs. Minor releases (7.1.1, 7.1.2) fix bugs and security issues and are designed to be safe to apply quickly. For example, 7.1.1 (17 September 2026) contained 11 security fixes, and 7.0.2 (17 July 2026) fixed one critical and one high-severity issue.

WordPress.org also backports security fixes to older branches. The 7.1.1 fixes went back as far as the 4.7 branch, and WordPress.org states that 4.6 and earlier no longer receive security updates. Even so, only the newest version is considered actively supported, so an old branch is a stopgap, not a plan.

Plugin updates

Plugin updates come from each plugin's developer, on that developer's schedule. A plugin from the WordPress.org directory updates through the dashboard. Premium plugins usually update through the dashboard too, but only while your license is active. If a license lapses, the plugin may quietly stop receiving security fixes.

Theme updates

Theme updates work like plugin updates. The main trap is editing a theme's files directly: an update replaces those files and your changes disappear. Put customizations in a child theme, the Site Editor or a small custom plugin instead. Our guide to WordPress child themes explains the pattern.

Translation files for core, plugins and themes also update, and they are included in the default automatic updates.

Auto-update defaults in 2026

The table below summarizes the defaults documented in the official WordPress upgrading guide and the plugin and theme auto-updates documentation. Your host may change them, so check your own dashboard.

A few details matter in practice:

• Background updates run on WP-Cron. Plugin and theme auto-updates run twice per day by default. If WP-Cron is broken on your server, auto-updates silently stop. Tools > Site Health reports cron problems.
• WordPress emails you. By default the site emails the admin address after plugin and theme auto-update attempts, whether they succeeded, failed or partly failed. Make sure that address is a monitored inbox.
• Security can override your settings. For the 7.0.2 security release, the WordPress.org team enabled forced updates through the auto-update system for affected versions. The official upgrading guide also notes that, by default, plugin and theme updates can be pushed automatically for security vulnerabilities.

How to change auto-update settings

From the dashboard

• Core: Dashboard > Updates shows whether the site is set to update for all new versions or only maintenance and security releases, with a link to switch.
• Plugins: on the Plugins screen, each row has an "Enable auto-updates" link. You can also select several plugins and use the bulk action.
• Themes: go to Appearance > Themes, click a theme, and use the "Enable auto-updates" link under the author name.

If these controls are missing, your host or a management plugin has probably taken them over. That is common on managed WordPress hosting, where the host runs updates for you.

From wp-config.php

Developers can set core behavior with a constant. WP_AUTO_UPDATE_CORE accepts three values:

• true: development, minor and major updates are all enabled.
• false: all core auto-updates are disabled.
• 'minor': only minor updates are enabled.

When this constant is set, it overrides the setting on the Updates screen. There is also AUTOMATIC_UPDATER_DISABLED, which switches off every automatic update. The official documentation says disabling updates is "strongly discouraged," and we agree: turning off minor updates means you also turn off the fastest route for security fixes.

With code filters

Plugin and theme auto-updates can be controlled with the auto_update_plugin and auto_update_theme filters, including per-slug rules. This is how agencies enable auto-updates for low-risk plugins while holding back complex ones such as page builders or ecommerce extensions.

Which updates should run automatically?

There is no single right answer, but a sensible default for most business sites looks like this:

• Minor core updates: always on. They are security and bug fixes, and the WordPress project designs them to apply safely.
• Major core updates: on, if you have backups and someone checks the site afterward. On sites with heavy customization or a store, many teams prefer to apply major releases manually after testing on staging.
• Small, well-maintained plugins: on. Utility plugins with a narrow job rarely break things.
• Large plugins that touch checkout, forms, memberships or page layout: manual, after testing. A broken checkout costs more than a one-day delay.
• Themes: manual if you have customizations, on if you use a block theme with no file edits.

The reason to lean toward updating, rather than away from it, is the vulnerability data. Patchstack's State of WordPress Security in 2026 report found 11,334 new vulnerabilities in the WordPress ecosystem in 2025: 91% in plugins, 9% in themes and only 6 in core. It also reported that 46% of vulnerabilities were not fixed in time for public disclosure, and that the weighted median time to first exploit for heavily targeted vulnerabilities was 5 hours. An outdated plugin is the most common way in. Our WordPress security guide covers the rest of the picture.

A safe update process, step by step

Whether you update by hand or review auto-updates, this routine keeps surprises small:

1. Take a fresh backup of files and database, and confirm it finished. See our guide to WordPress backups for what a complete backup includes.
2. Read the changelog for major plugin and core updates. Look for words like "breaking," "requires PHP," "database update" or "migration."
3. Check compatibility. On each plugin's WordPress.org page, compare "Tested up to" with your WordPress version and "Requires PHP" with your server. Our PHP versions guide explains why this matters.
4. Test on staging first for major core releases and for large plugins. A staging site is a copy where breakage costs nothing.
5. Update in small batches. Core first, then plugins a few at a time, then themes. If something breaks, you know which batch did it.
6. Check the site. Load the home page, a post, a form, the cart and checkout if you have one, and log in to the admin. Watch for a "critical error" message or layout changes.
7. Keep the backup until you are sure everything works, including scheduled tasks like emails and order processing.

Avoid updating right before a launch, a sale or a weekend when nobody can respond. Our guide to security patching and plugin updates covers scheduling in more detail.

Rollback: what WordPress does and does not do

"Rollback" means three different things in WordPress, and only two are built in.

Failed manual plugin and theme updates (since 6.3)

Since WordPress 6.3, if a manual plugin or theme update fails during installation (for example, an empty download package or a file that cannot be moved), WordPress restores the previous version from a temporary backup. This only covers failed installs. It does not undo an update that installed successfully but broke the site.

Plugin auto-updates that cause a fatal error (since 6.6)

Since WordPress 6.6, after a plugin auto-update WordPress makes a loopback request to the home page. If it detects a PHP fatal error, it restores the previously installed version and emails the site administrator. According to the WordPress 6.6 Field Guide, this applies to plugin auto-updates. It will not catch problems that do not throw a fatal error on the home page, such as a broken checkout page or a layout change.

Rolling back core or a plugin by hand

There is no "downgrade core" button. The official upgrading guide says you can roll back, but that it is "usually not recommended," because older versions can expose you to security issues and database changes may not reverse cleanly. If a major update breaks something, the usual fixes are:

• Restore the backup you took before updating, then fix the incompatible plugin or theme on staging.
• Install the previous version of a single plugin, either from the "Advanced View" of its WordPress.org page or with a rollback plugin. WP Rollback, for example, has 300,000+ active installs on WordPress.org as of October 2026.
• Use your host's restore points if your plan includes them.

Treat any rollback as temporary. The goal is to get back to the current version once the conflict is fixed.

Managing updates across many sites

If you look after several sites, per-site dashboards become tedious. Common options:

• Managed hosting that applies updates for you, sometimes with visual checks.
• Central dashboards such as MainWP or ManageWP, which connect to each site through a child plugin.
• WP-CLI for developers, using commands such as wp core update and wp plugin update --all, run from scripts or CI.
• Multisite, where one update covers every site on the network. That has trade-offs, covered in our multisite guide.

When an update goes wrong

Most update failures look like one of these:

• "Briefly unavailable for scheduled maintenance" stuck on screen: the update was interrupted and the .maintenance file was left behind. Deleting that file from the site root fixes the message, but check that the update itself finished.
• "There has been a critical error on this website": a plugin or theme threw a fatal error. WordPress emails the admin a recovery mode link that lets you log in with the broken extension paused.
• Layout or feature changes without an error: usually a theme or page-builder update. Compare with staging and check the plugin's changelog.

Our WordPress troubleshooting guide walks through each of these in detail.

Conclusion

WordPress already applies minor core and translation updates on its own, and newer installs apply major releases too. Plugins and themes, where most vulnerabilities live, wait for you unless you opt in. Back up before every update, test big changes on staging, update in small batches, and remember that a backup, not a rollback button, is your real safety net. For more on running WordPress well, visit our WordPress hub. If you would rather hand updates to someone else, eSEOspace offers website maintenance services that include tested updates and backups.

Frequently asked questions