How often should you update WordPress, plugins and themes?

Keep two clocks. A release that fixes a security hole goes on as soon as you reasonably can, and WordPress already installs its own security releases in the background. Everything else waits for a regular round: weekly on most sites, monthly on a store where every round goes through a staging copy first.

The one schedule that is wrong for every site is no schedule. Updates left for months arrive together, and that round is the hardest to put right.

This page is about how often. For how to carry out a round, see how to safely update WordPress.

What needs updating, and what WordPress already does by itself

The Updates screen covers WordPress itself, plugins, themes and translations, and WordPress treats them differently.

In a WordPress version number, the first two numbers name a major release: 7.0 and 7.1 are two major releases. A third number marks a minor release, such as 7.1.3. Minor releases carry the maintenance and security fixes, and they come out as needed, not on a calendar. WordPress.org's release archive shows 7.1 on August 19, 2026, followed by 7.1.1, 7.1.2 and 7.1.3 within seven weeks.

There is one exception in the plugins row. WordPress's documentation says a plugin or theme can be updated in the background "in special cases", controlled by the WordPress security team, to patch a critical vulnerability. Do not count on it for any particular plugin.

Two more things decide whether any of this happens on your site.

Settings in wp-config.php. The documentation describes two constants:

When WP_AUTO_UPDATE_CORE is set, it overrides the choice offered on the Updates screen. A plugin can change the same things with filters. The one worth knowing is auto_update_plugin: the documentation notes that returning false from it stops every automatic plugin update, including one forced by the security team. WordPress also switches its automatic updates off when it detects that the site's files are under version control.

Whether the scheduler runs. Automatic updates run twice a day through WP-Cron, WordPress's own scheduler, and WP-Cron is triggered only when someone loads a page. On a site with very few visitors an update can sit for a while before it goes on.

How to see what is set on your site

wp core check-update
wp config get WP_AUTO_UPDATE_CORE
wp config get AUTOMATIC_UPDATER_DISABLED
wp plugin auto-updates status --all
wp theme auto-updates status --all

wp core check-update prints a table of the releases waiting, with minor or major in the update_type column, or a line that says WordPress is at the latest version.

On most sites neither constant is set, and each wp config get answers with an error that says the constant "is not defined in the 'wp-config.php' file". That is the ordinary result. It means WordPress is following its defaults and the choice on the Updates screen. Where a constant is set, minor prints as the word, true prints as 1, and false prints as an empty line.

wp config get reads only wp-config.php. It cannot see a filter in a plugin, so trust the sentence on the Updates screen over the command.

How fast is fast enough for a security fix

For WordPress itself, the release announcement answers this. WordPress announces its releases on the news blog at WordPress.org, and a release with security fixes is filed under Security and often says so in its title. The post for 7.1.3, published on October 6, 2026, reports seven security fixes and four bug fixes. It recommends updating immediately, and adds that sites that support automatic background updates will begin the update by themselves.

The same post lists each hole it closes in a line or two. From the hour a security release is published, what it fixes is public. That is why the clock for security fixes is short, and it needs no statistic to make the point.

What the announcement asks of you depends on the sentence on your Updates screen.

• Minor releases install themselves: nothing, except confirming it happened. WordPress emails the site's administrator, and the Updates screen shows the new version.
• Nothing installs itself: update by hand the day the release is announced, after a backup.

Old versions are patched as a courtesy

WordPress.org's pages do not all put this the same way. The security page says only the latest version of WordPress is officially supported, and that the security team backports fixes to older versions as a courtesy. The Supported Versions page adds that there is no guarantee and no timeframe for older releases. The release archive says only the most recent release in the current series is safe to use.

In practice the reach is long. The 7.1.3 post says its fixes are being backported to every branch still eligible, currently back to 4.7, and that the backports ship as they become ready. So a site on an old branch may still get a security fix in the background, later than the current branch does and on nobody's promise. Do not plan around it. Security updates for 4.1 through 4.6 ended in July 2025.

Plugins have no single place for announcements

A plugin's author writes its changelog. The plugin directory's example readme.txt has two sections for this: Changelog, and Upgrade Notice, which says why a user should upgrade. The format does not require a security fix to be labeled, so the wording is up to each author.

• Read the changelog before each round. On the Plugins screen, follow the link that begins "View version" under any plugin with an update waiting.
• Do not wait for a warning. WordPress.org asks people who find a hole in a plugin not to post about it publicly, and says most reported plugins are closed to new downloads until the issue is resolved. You may hear nothing until the fixed version appears.
• For a store, WooCommerce's Advisories page and its changelog flag a release that includes a security fix.

What "as soon as you reasonably can" means

This is reasoning, not a quoted rule. A security fix has waited long enough once there is a current backup and someone free to look at the site afterward. On most sites that is the same day or the next working day. Do not hold it for the regular round. On a store, shorten the testing and keep the backup: WooCommerce's guide says applying a security fix promptly matters more than waiting for your normal cycle.

Choosing your regular round

Everything that is not a security fix can wait for a round. The sources that give a figure differ. WordPress.org's housekeeping article says to check for updates at least every three months, six at the most. Its hardening guide says to always keep up to date with the latest version, and its release posts say to update immediately when a release carries security fixes. WooCommerce says a monthly cadence works well for most stores.

The table is reasoning from two questions: how much on the site can break, and what a break costs.

A store is slower on purpose, for three reasons. A round costs more: WooCommerce's guide says to test on a staging site and not on the live store, to check the cart, checkout, payments, shipping, taxes and order emails there, and then to apply the same set to the live store. A failure costs more, and it can hide: the checkout can stop working while every page still looks right. And the pieces move together: the guide updates WooCommerce, its extensions, the payment gateways and the theme in one window.

So weekly and monthly are both right. A weekly round is small, and suits a site where a look at the pages is enough of a check. A monthly round is larger and goes through staging first. What does not work is a monthly round with no staging copy on a site that needs one, or a weekly round that nobody looks at afterward.

The maintenance checklist puts the weekly round beside the other routine jobs. A store has its own routine. If you have no staging copy yet, see how to set one up.

Automatic updates: which to turn on

Minor releases of WordPress: on. They are the security releases. WordPress's documentation calls them one of the best ways to keep a site secure and strongly discourages disabling them.

Major releases of WordPress: it depends on the site. On a simple site, leave them on. On a store, or a site with a page builder or many plugins, choose "Switch to automatic updates for maintenance and security releases only." on the Updates screen, and apply each major release in a round. WordPress's own documentation gives time for testing on a staging site as a reason to hold a major release back.

Plugins and themes: decide one by one. In favor: WordPress checks twice a day, so an update goes on soon after it is released and the plugin does not fall behind. Against: it runs when the scheduler fires and not at your quiet hour, nobody looks at the site afterward, and it does not take a backup first. WordPress's documentation advises making sure you can go back to a previous version of the site before enabling auto-updates.

The table below is reasoning, like the one above.

What happens when an automatic plugin update breaks the site

Since WordPress 6.6 there is a safety net. The proposal that added it describes how it works. During an automatic plugin update, WordPress requests the site's own home page and looks for a PHP fatal error. If it finds one, it restores the version of the plugin that was installed before. It emails the site's administration address to say which plugins failed to update, and it carries on with the other updates in the queue. At the next check it tries the same plugin again. The site stays in maintenance mode for the length of the run.

The net's limits follow from how it works. It looks at the home page, and it looks for a fatal error. A checkout that fails, a form that stops sending or a layout that has moved is neither, and the update stays in place.

So two habits go with automatic updates. Keep scheduled backups running, kept off the server. And make sure the update emails reach someone: they go to the "Administration Email Address" under Settings, then General, and report updates that succeeded, failed, or both. If the site's mail is not arriving, fix that first.

PHP is on a clock too

PHP is not on the Updates screen and nothing updates it for you. You change it in your hosting control panel, or your host does.

php.net supports each PHP branch for four years: two of active support, then two of fixes for critical security issues only. After that the branch is end of life. As of October 8, 2026, its Supported Versions page shows:

PHP 8.1 reached end of life on December 31, 2025, and every older branch before it. WordPress.org recommends PHP 8.3 or greater. It says WordPress also works with PHP 7.4 and later, and that those older versions have reached end of life and may expose a site to security vulnerabilities.

Plugins move their minimum too: WooCommerce has announced that version 11.6 will require PHP 8.1 or later. A site left on an old PHP eventually cannot take the updates it needs.

Check PHP every few months, and before a branch's last date, not after. The end-of-life checker shows whether your PHP and WordPress versions still get security fixes, and until when. Change PHP on a staging copy first, with every plugin up to date.

What "too long" looks like

Updates do break things now and then. That is a reason for small rounds and a way back. It is not a reason to stop. Waiting changes what a break looks like.

• Many suspects. WordPress's troubleshooting advice for a fault is to disable plugins one at a time until you find the source. After a round of three updates, that is three candidates. After a year of updates in one sitting, it is everything on the site.
• Bigger jumps. WordPress's upgrade instructions say that if you plan to cross more than two major releases, you should consider upgrading in steps, to avoid conflicts and lower the risk of damage to the database. WooCommerce's guide says to avoid running several major store updates at once unless that exact set was tried on staging.
• Everything at once. WordPress drops old PHP versions as it goes: 7.0 dropped PHP 7.2 and 7.3. A site far behind cannot update one thing without the others, so the round that finally happens moves PHP, WordPress and the plugins together.

If a round has already gone wrong, the failed update runbook gives the order to work in.

The rule to keep

Leave WordPress's automatic maintenance and security releases on, and read the sentence on the Updates screen to be sure they are. When a release of anything on the site fixes a security hole, apply it the same day or the next working day, after a backup. Put everything else in a round on a fixed day: weekly for most sites, monthly for a store that tests on a staging copy first. Turn on automatic updates for the small plugins and keep the ones that draw pages or take money for the round. Look at the site after every round, check PHP every few months, and never let the list wait for months.

If you would rather hand the round over, our WordPress update service is part of every care plan: weekly updates to WordPress core, plugins and themes, a visual check afterward, and a rollback if something breaks. Updates run weekly, not on the day a release comes out.