Regular WordPress Updates: Why They Matter and Best Practices

WordPress updates are the cheapest security work you can do on a site. Core, plugins, themes and the PHP version underneath each need attention on their own schedule, and most updates that break a site were run in the wrong order or straight on the live copy.

This guide is the plan behind the updates: why they matter, what to update and in which order, how often, which automatic updates to switch on, and the staging-first routine I use on client sites. At the time of writing the current stable release is WordPress 7.1.3, released on 6 October 2026, with 7.2 in beta.

Why do regular WordPress updates matter?

Regular WordPress updates matter because most attacks go after known holes that already have a fix. Patchstack recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins, and heavily exploited flaws were mass-attacked a median of five hours after disclosure. A site that waits weeks to update is an easy target.

Those figures come from Patchstack’s State of WordPress Security in 2026 report. The same report counted only 6 vulnerabilities in WordPress core during 2025, all low priority, and put the other 9% in themes. Most of the risk sits in the plugins and themes you add.

Updates don’t cover everything. Patchstack also found that 46% of vulnerabilities had no fix from the developer when they were made public, which is why abandoned plugins get their own section below.

There is a second reason that has nothing to do with attackers. Plugin authors drop support for old WordPress and PHP versions over time. A site that skips a year of updates ends up with several major version jumps to make at once, and that is where things break.

What needs updating in WordPress?

A WordPress site has four layers that need updating: WordPress core, plugins, themes and the PHP version on the server. Each one updates in a different place and carries a different level of risk, so treat them as separate jobs, each with its own checks.

Layer	Where it updates	Risk when updating
Core minor release (7.1.2 to 7.1.3)	Automatically, or Dashboard → Updates	Low. Security and bug fixes only.
Core major release (7.1 to 7.2)	Dashboard → Updates or WP-CLI	Medium. New features can expose old plugin and theme code.
Plugins	Plugins screen, auto-updates, ZIP upload, FTP or WP-CLI	Highest. Most vulnerabilities and the most frequent releases.
Themes	Appearance → Themes or Dashboard → Updates	Medium for the active theme, higher if its files were edited directly.
PHP	Hosting control panel or the server itself	High. A PHP change affects every plugin and theme at once.

Inactive plugins and themes still count. Their files sit on the server and can still be reached, so either keep them updated or delete them. I keep one default theme installed as a fallback and remove the rest. If your theme has been customised, read how to run WordPress theme updates without surprises before you click update.

PHP is the layer people forget because it lives outside WordPress. The PHP project’s supported versions page lists 8.2 to 8.5 as supported, and 8.2 only receives security fixes until 31 December 2026. WordPress recommends PHP 8.3 or greater. A site on PHP 8.1 or older gets no security fixes from the PHP project at all.

What order should you run WordPress updates in?

Run WordPress updates in this order: take a backup, update core, then plugins, then themes, and check the site after each layer. Treat a PHP upgrade as its own change on a different day. Working one layer at a time means that when something breaks, you know which update caused it and what to roll back.

1. Back up the files and the database, and confirm the backup finished and is stored off the server.
2. Update WordPress core. Plugin releases can declare a minimum WordPress and PHP version, and WordPress holds back updates your site doesn’t meet. Updating core first lets those plugin updates appear.
3. Update plugins. On a live site, do them one at a time. On staging, a batch is fine.
4. Update themes, including the inactive fallback theme.
5. Check the front end, a form and any checkout before you call it done.

Some guides say plugins first. When your plugins already list support for the new core version, either order works. The rule that matters more is one layer at a time with a check in between.

Change the PHP version separately, on staging first, once core and plugins are current. Plugin authors fix PHP compatibility in their newer releases, so a site with up-to-date plugins hits far fewer fatal errors after a PHP jump. My guide on why and how to upgrade PHP on WordPress covers the checks.

How often should you update WordPress?

Apply security fixes the same day, within 48 hours at most, and at once if the flaw is being actively exploited. Review plugin updates weekly, and plan major core releases for a quiet week after they come out. The plan below is the schedule I recommend as a starting point; adjust it to how much the site earns.

Update type	How often	How
Core minor and security releases	Within 24 to 48 hours	Leave automatic minor updates on
Plugin security fixes	The day you hear about them	Manual update or per-plugin auto-update
Routine plugin updates	Weekly (stores: check daily)	Staging batch, then live
Theme updates	Monthly, or sooner for a security fix	Staging first if the theme is customised
Core major releases	One to two weeks after release	Staging first, then live
PHP version	Check yearly, upgrade before security support ends	Staging first through the host
Plugin review and backup restore test	Quarterly	Remove unused plugins, test a restore

For a busy store, I often wait for the first point release of a new major version (for example 7.2.1) before updating the live site. Brochure sites with a few well-maintained plugins can move sooner.

Should you turn on automatic WordPress updates?

Yes for minor core releases and translations, which WordPress installs automatically on most sites by default. For major core releases and plugins, it depends on the site. A brochure site with a few plugins can auto-update most things. Stores and membership sites should auto-update selectively and test bigger changes on staging first.

Core auto-updates

Automatic background updates arrived in WordPress 3.7 for minor releases. According to the WordPress upgrade documentation, installs created on WordPress 5.6 or later also get major releases automatically, while older installs keep minor-only updates unless an administrator changes the setting on Dashboard → Updates. The WP_AUTO_UPDATE_CORE constant in wp-config.php overrides that setting:

// Minor (security and maintenance) releases only
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// All core releases, including major versions
define( 'WP_AUTO_UPDATE_CORE', true );

// No automatic core updates (strongly discouraged)
define( 'WP_AUTO_UPDATE_CORE', false );

On stores and sites with custom code I set 'minor' and run major releases through staging. On simple sites with a recent backup, I leave major auto-updates on.

Plugin and theme auto-updates

Since WordPress 5.5 you can switch auto-updates on plugin by plugin and theme by theme. WordPress runs them twice a day and emails the site owner after each attempt, as the auto-updates documentation explains. They depend on WP-Cron, so a low-traffic site may run them late.

The policy I recommend:

• Turn auto-updates on for small, single-purpose plugins with a steady release record, and for security plugins.
• Leave them off for WooCommerce and its extensions, page builders, membership and LMS plugins, and anything that changes database tables. Those go through staging.
• Never auto-update a plugin whose files someone has edited directly. The update will wipe the edits.

To set this in code, the WordPress docs recommend a filter in a must-use plugin (a PHP file in wp-content/mu-plugins/). This one auto-updates only the plugins you list:

function ak_auto_update_selected_plugins( $update, $item ) {
    $allowed = array( 'akismet', 'wordfence' );
    if ( isset( $item->slug ) && in_array( $item->slug, $allowed, true ) ) {
        return true;
    }
    return $update;
}
add_filter( 'auto_update_plugin', 'ak_auto_update_selected_plugins', 10, 2 );

What is a safe WordPress update workflow?

A safe WordPress update workflow runs every update on a staging copy before the live site. Take a backup, refresh staging from live, apply the updates there, test the pages that earn money, then repeat the same updates on live and check again. Problems show up on staging, where they cost nothing.

1. Take a fresh backup of files and database and confirm it is stored off the server. The WordPress backup and disaster recovery guide covers what a usable backup looks like.
2. Refresh staging from live so it runs the same plugins, theme and PHP version. If you don’t have one yet, here is how to create a WordPress staging site.
3. Apply the updates on staging in the order above, and read the changelog for any major version.
4. Test the homepage, one key landing page, a form submission, logins and a test order if you sell online. Check the browser console and the PHP error log.
5. Apply the same updates on live during a low-traffic hour.
6. Clear the page cache and CDN, recheck the same pages, and keep the pre-update backup for at least a week.

For a small brochure site with a handful of plugins, a fresh backup plus one-at-a-time updates on live is a fair shortcut. For a store, I don’t skip staging.

How do you update WordPress core, plugins and themes?

Most updates run from Dashboard → Updates, which lists pending core, plugin, theme and translation updates on one screen. Core has its own update button, and plugins and themes can be ticked and updated in a batch. When the dashboard can’t do the job, you can replace files manually or use WP-CLI over SSH.

To update WordPress core manually, the official steps are: back up, deactivate plugins, download the latest package from wordpress.org/download, delete the old core files while keeping wp-config.php, the wp-content folder and any custom .htaccess or robots.txt, upload the new files, then run the upgrade screen WordPress shows you and reactivate plugins.

With WP-CLI, core takes three commands:

wp core check-update
wp core update
wp core update-db

Add --minor to wp core update to take only point releases. Plugins have more routes: the Plugins screen, bulk updates, per-plugin auto-updates, a ZIP upload, FTP and WP-CLI. My step-by-step guide on how to update WordPress plugins walks through each one, including premium plugins with licence keys and fixing an update that fails halfway.

What should you do if a WordPress update breaks your site?

If an update breaks your site, restore first and debug later. Put back the backup you took before updating, or roll back only the plugin or theme that failed, then reproduce the problem on staging. WordPress has a few built-in safety nets for plugin updates, but they only catch some kinds of failure.

Since WordPress 6.3, a failed manual plugin or theme update restores the previous copy automatically, according to the 6.3 rollback dev note. Since 6.6, plugin auto-updates roll back on their own when they cause a PHP fatal error, as the 6.6 field guide describes. Neither helps when the update installs cleanly but breaks your layout, a form or checkout.

Core is different. The WordPress documentation advises against rolling core back to an older version and says a rollback is near impossible without a full backup made before the upgrade. Restore that backup instead.

I keep a short log of each update run: the date, what was updated, and the old and new version numbers. When something breaks two days later, that log tells you where to look.

How do you spot abandoned WordPress plugins?

An abandoned plugin is one its author has stopped updating, so the next security hole in it may never get a fix. Check the “Last updated” date and the “Tested up to” version on its WordPress.org page. Twelve months without a release is a warning sign, and two years means it is time to replace it.

• “Tested up to” more than two major WordPress versions behind means the author isn’t checking compatibility.
• A falling active install count suggests other site owners are moving away from it.
• Unanswered security reports in the support forum, or open entries in the Patchstack or WPScan databases, are a red flag.
• A plugin closed on WordPress.org stops receiving updates through the dashboard entirely.

With WP-CLI you can check every plugin at once:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

When you find one, move to a maintained alternative on staging before a vulnerability is published. Replacing a plugin on your schedule is far easier than replacing it during a clean-up.

When should you hand WordPress updates to a maintenance plan?

Hand updates to someone else when a broken page costs you real money, or when nobody on your team could restore a backup under pressure. A good WordPress update service includes staging-first updates, a backup before every run, testing after each update and a named person who fixes whatever breaks.

Ask any provider how they handle a failed update, how long they keep backups, and whether they test checkout and forms or only check that the homepage loads. If the answers are vague, the updates are probably being run in bulk on live.

My WordPress maintenance and care plans follow the workflow in this guide: backup, staging, test, live, verify, on a fixed schedule.