How to Update WordPress Plugins, Themes and Core Safely

You have a page of plugin updates waiting and you are nervous about clicking Update all. Maybe the last time you did, the site showed a critical error, the page builder stopped loading or the checkout broke. Or you look after client sites and want a routine you can follow every time, and explain to clients, rather than a hopeful click.

Leaving updates alone is not safe either. Outdated plugins are one of the most common ways WordPress sites get hacked, which is why the vulnerable plugin guide exists. The answer is a routine: back up, update in a sensible order, test the things that make you money, and know how to roll back one plugin in two minutes. This guide covers that routine, what WordPress’s own auto-update and rollback features actually protect you from, and where they stop.

What is happening

An update replaces a plugin’s, theme’s or WordPress core’s files with a new version, and sometimes runs a database upgrade. Things break for a handful of reasons:

• The new version has a bug, or a change that conflicts with another plugin or your theme.
• The new version needs a newer PHP or WordPress version than you run.
• The update ran a database migration that the old version cannot undo.
• The update stopped halfway because of a timeout, permissions or disk space, leaving the site in maintenance mode. See stuck in maintenance mode.
• Caches still serve old CSS or JavaScript, so the site looks broken when the code is fine. See changes not showing.

What WordPress already does for you

Feature	What it does	What it does not do
Core minor auto-updates	Installs maintenance and security releases of WordPress core automatically by default	Major versions are not automatic unless you opt in
Plugin and theme auto-updates	Optional per plugin and per theme, switched on from the Plugins and Themes screens. WordPress emails the admin address about results.	Nothing is tested on your site before it updates
Temporary backup during updates (since WordPress 6.3)	Moves the old plugin or theme into wp-content/upgrade-temp-backup during the update and puts it back if the update fails to install	Does not help if the update installs fine but breaks the site
Auto-update rollback (since WordPress 6.6)	After an automatic update of an active plugin, WordPress requests the home page; if that shows a PHP fatal error, it restores the previous version and records “The update for ‘…’ contained a fatal error. The previously installed version has been restored.”	Only covers plugin auto-updates, only active plugins, and only PHP fatal errors. Broken layouts, failed checkouts and JavaScript errors are not detected, and themes are not rolled back.
Fatal error protection (recovery mode)	When a plugin causes a fatal error, WordPress shows a critical error message and emails the admin a recovery mode link	The site is still down for visitors until you fix it. See the critical error guide.

The rollback check relies on the site being able to request its own home page, the same loopback request Site Health tests. If loopback requests fail, for example because a firewall or cache blocks them, WordPress can treat the update as failed and roll it back even though nothing was wrong. If plugin auto-updates keep reverting, check loopback request failed.

Before you start

• A recent backup you can restore, made today, of files and database. Your host’s backup, a plugin backup or a manual export all count, as long as you know how to restore it. See the backup plan checklist.
• Admin access and, ideally, SSH and SFTP. If an update causes a critical error, you may not be able to reach wp-admin.
• Where commands run. Commands starting with wp are WP-CLI, run over SSH in the site folder (the one containing wp-config.php). Some hosts name it wp-cli. The WP-CLI cheat sheet covers the basics.
• A quiet time. Not Friday evening, not during a sale, not when you have to leave in ten minutes.

Step 1: See what is waiting, and sort by risk

Go to Dashboard, Updates, which lists core, plugin, theme and translation updates in one place. Or over SSH:

wp plugin list --update=available --fields=name,status,version,update_version,auto_update

--update=available shows only plugins with an update, and --fields chooses the columns: the slug, whether it is active, the installed version, the new version and whether auto-updates are on. Use wp theme list --update=available for themes and wp core check-update for WordPress itself.

Then sort the list into three groups:

Risk	Typical examples	How to update
High	Page builders and their add-ons, WooCommerce and payment gateways, membership and LMS plugins, your theme or theme framework, a major version jump (for example 3.x to 4.0), anything that changes the database	One at a time, staging first where possible, test after each
Medium	Forms, SEO, caching and performance plugins, security plugins	A few at a time, test key features after
Low	Small utility plugins with minor version bumps, translations	Together, quick check after

Security fixes jump the queue. If a plugin’s changelog or a vulnerability alert mentions an actively exploited flaw, update that plugin today, with a backup, even if you skip the rest of the routine.

Step 2: Read the changelog for anything high risk

On the Plugins screen, click View details next to an update to open the changelog for plugins from WordPress.org. Premium plugins usually link to a changelog on the vendor’s site. You are looking for:

• A new minimum PHP or WordPress version. Check yours under Tools, Site Health, Info. Upgrading PHP has its own routine: see upgrading PHP safely.
• Words such as “database update”, “migration”, “breaking change”, “removed” or “deprecated”.
• Notes that add-ons must be updated at the same time, which is common with builders and WooCommerce extensions.

For a new WordPress major version, read this site’s release guides first, such as WordPress 7.1 known issues. For WooCommerce, see WooCommerce update broke my store.

Step 3: Test high-risk updates on staging

A staging site is a private copy of your site where you can update and test without visitors seeing anything. Many hosts offer one-click staging in the control panel. Update the high-risk items there first, run the Step 5 tests, and only then update live.

Staging is worth most for builders, WooCommerce and major versions. If you have no staging, you can still reduce risk by updating one high-risk item at a time on live, straight after a backup, at a quiet time. When you push staging changes back, do not overwrite the live database on a shop; follow staging to live without losing orders, or simply repeat the updates on live.

Step 4: Update in a sensible order

1. Back up and confirm the backup finished.
2. WordPress core first if a new version is waiting, because plugin updates are usually built and tested against current core. For a major version, many people wait for the first maintenance release.
3. High-risk plugins one by one: the builder and its add-ons together, then WooCommerce, then gateways. After each, load the site and wp-admin. If a plugin asks to run a database update, take note: rolling that plugin back later may need the database backup as well.
4. Medium and low-risk plugins in small groups.
5. Theme last, after confirming your customizations live in a child theme. See child theme problems.
6. Translations, which are low risk.
7. Clear caches: the page cache plugin, server cache, CDN and any builder CSS cache.

Over SSH, the same order looks like this:

wp core update
wp core update-db
wp plugin update woocommerce
wp plugin update --all --dry-run

wp core update updates WordPress core to the latest version, and wp core update-db runs any core database upgrade. wp plugin update woocommerce updates one plugin by its slug. wp plugin update --all --dry-run lists what would be updated without changing anything; run it again without --dry-run when you are ready for the low-risk batch. Good output ends with a Success: line. An Error: line names the plugin that failed, and your site may be left in maintenance mode, which the maintenance mode guide fixes.

Step 5: Test what makes you money

A home page that loads is not enough. Keep a short test list for each site and run it after every update session:

• Load the home page and two other key pages in a private window, on a phone and on a desktop.
• Open the browser console and look for new red errors (the DevTools cheat sheet shows how).
• Submit the main contact form and confirm the email arrives.
• On a shop: add to cart, reach checkout, and place a test order if your gateway has a test mode.
• Log in to wp-admin, open the page builder on one page, and save a harmless change.
• Check the PHP error log for new warnings and fatal errors since the update.

Check again the next day. Some problems, such as scheduled tasks, emails and caching, only show up after a while.

Step 6: Decide which auto-updates to trust

Auto-updates are a trade-off: you get security fixes quickly, but nothing is tested before the update lands. A reasonable policy for most small sites:

• Core minor releases: on. This is the WordPress default. Maintenance and security releases are small and rarely break sites.
• Low-risk plugins: on, especially security-sensitive small plugins that are actively maintained.
• Builders, WooCommerce, gateways, memberships and your theme: off, updated by hand on your update day.
• Sites nobody watches: if no one will run the routine, auto-updates on most plugins with good backups are usually safer than never updating.

Switch auto-updates per plugin with the Enable auto-updates link in the Automatic Updates column of the Plugins screen, or over SSH:

wp plugin auto-updates status --all
wp plugin auto-updates enable PLUGIN_SLUG
wp plugin auto-updates disable woocommerce

The first command shows which plugins have auto-updates on. enable and disable switch it for the plugin slug you name. Core behavior is controlled on Dashboard, Updates, or with the WP_AUTO_UPDATE_CORE constant in wp-config.php: 'minor' is the default, true includes major versions, and false turns core auto-updates off. If none of your auto-updates ever happen, look for AUTOMATIC_UPDATER_DISABLED in wp-config.php, which switches off all automatic updates, or a management plugin that controls them. The wp-config constants reference lists both.

Step 7: Roll back one plugin

If an update broke something and the previous version worked, roll back just that plugin rather than restoring the whole site.

Plugins from WordPress.org

wp plugin install PLUGIN_SLUG --version=1.2.3 --force

PLUGIN_SLUG is the plugin’s folder name (shown by wp plugin list), --version is the last version that worked, and --force overwrites the installed copy. Good output ends with Success: Installed 1 of 1 plugins. An error about the version not being found means that version is not available from WordPress.org. Then turn off auto-updates for that plugin so it does not update again overnight, and check its support forum for a fix.

Without SSH, plugin pages on WordPress.org have an Advanced View with older versions to download; upload the zip under Plugins, Add New, Upload Plugin, and WordPress offers to replace the current version. Third-party rollback plugins exist too.

Premium plugins and themes

Premium products usually offer older versions in your account on the vendor’s site, and some builders have a rollback tool in their settings. Keep the previous zip of every premium plugin you update, because some vendors only offer the latest version.

When a rollback is not enough

If the update ran a database migration, the old plugin version may not work with the new database structure. That is when you need the database backup from Step 4, and on a shop you must think about orders placed since. Follow restoring from a backup and the WooCommerce rollback section.

Advanced: confirm file integrity and keep a record

After a messy update, check that core and plugin files match the official versions:

wp core verify-checksums
wp plugin verify-checksums --all

These compare your files with checksums published by WordPress.org. Good output is a Success: line. Lists of files that “should not exist” or do not match mean a partial update or tampering; reinstall the affected plugin, and if you did not expect changes, read the hacked site guide. Premium plugins cannot be checked this way and are reported as skipped.

Keep an update log: date, what was updated from which version to which, who did it, and anything that broke. For client sites it doubles as proof of work for the maintenance plan. The monthly maintenance checklist and the incident log template give you a format.

Plugin developers may also come across the official Plugin Check tool. It reviews a plugin’s code against WordPress.org guidelines; it is not a way for site owners to test whether an update is safe on their site.

If an update broke your site

Start with the symptom:

• “There has been a critical error on this website”: critical error guide.
• Stuck on “Briefly unavailable for scheduled maintenance”: maintenance mode guide.
• Builder will not load or layout broken: page builder broke after an update.
• Everything else: the update broke my site triage page.

When you contact your host or the plugin vendor, send the plugin name, the old and new version numbers, the time of the update, the exact error message and the matching lines from the PHP error log.