How to Update WordPress Safely: A Pre-Update Checklist

Most broken WordPress updates are not caused by WordPress. They come from pressing "Update all" on a live site with no backup that has ever been restored, no idea which plugin changed what, and no plan for going back. To update WordPress safely you need about thirty minutes of preparation and a fixed order of work.

This is the checklist our maintenance team follows. It works for a brochure site and for a store taking orders, and the only thing that changes with the size of the site is how much you test.

Know what you are about to change

Open Dashboard > Updates and write down what is pending: the core version, each plugin and each theme, with the version you are on and the version you are going to. A screenshot is enough. If something breaks later, this list tells you where to look.

Then sort the list into three groups:

• Security and maintenance releases (a change in the third number, such as 6.8.1 to 6.8.2). Low risk, apply them quickly.
• Feature releases of core or of a plugin your site depends on: the store, the LMS, the membership plugin, the page builder. These deserve a staging pass.
• Everything else: small plugins with small changes.

For anything in the second group, read the changelog. You are looking for three phrases: "breaking change", "minimum PHP version" and "database update". A plugin that migrates its own tables on update cannot always be rolled back by reinstalling the old files, so that is the one you test first. The official guide to updating WordPress covers the core part of the process.

Check the server before the software

Go to Tools > Site Health > Info > Server and note the PHP version and the database version. Compare them with the requirements of the new releases. A plugin that now needs a newer PHP version will fail on activation, and you want to find that out on staging.

Also check free disk space. Updates unpack into a temporary folder, and a full disk is one of the quieter reasons for a half-finished update and a site stuck in maintenance mode.

Take a backup you have actually restored

A backup counts only if you know it restores. Before any feature update, take a fresh one that includes both parts of the site:

• the database (posts, orders, users, settings), and
• the files: wp-content at minimum, which holds plugins, themes and uploads.

Store it somewhere other than the web server. If the host offers snapshots, take one as well: a snapshot is the fastest way back, and the off-site copy covers you if the hosting account itself is the problem.

If you have WP-CLI, a database export takes one line:

wp db export before-update.sql --add-drop-table

If you have never restored one of your backups, do it once on a staging copy before you rely on it. We cover what to keep and for how long in a WordPress backup strategy you can restore from.

Run the update on staging first

Staging is a private copy of the live site on the same hosting stack. Many hosts create one with a button. Apply the pending updates there, in the order below, and test the things that earn the site its keep:

• the home page, one inner page and one post, logged out;
• every form, with a real submission that should reach your inbox;
• on a store: add to cart, checkout with a test payment, the order email;
• on a learning site: enroll, open a lesson, complete a quiz, view the certificate;
• login, password reset and the account pages;
• the editor: open a page built with your page builder and save it.

Keep the browser console open while you click through. A new JavaScript error after an update is the usual cause of buttons that stop responding. On the server, switch on logging in wp-config.php so warnings go to a file and not to visitors:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

The log is written to wp-content/debug.log. Read it after the test and switch debugging off again when you are done.

Update in the right order

On staging, and again on the live site, work in this order and reload the site between steps:

1. Plugins, one at a time for the important ones. If the site breaks, you know which update did it. Small plugins can go in a batch afterwards.
2. Themes. If the site runs a child theme, your changes are safe. If someone edited the parent theme directly, an update will overwrite that work: move the changes into a child theme first.
3. WordPress core. Plugin authors ship compatibility releases ahead of a new core version, so current plugins on old core is the safer middle state than new core with old plugins.
4. The database step. If WordPress or a plugin shows "database update required", run it and wait for it to finish. Do not close the tab on a large store.
5. Translations, last.

With WP-CLI the same sequence is:

wp plugin update --all
wp theme update --all
wp core update
wp core update-db

Pick a quiet hour and tell people

Do the live update when traffic is lowest, and never right before a campaign, a course launch or a weekend when nobody is watching the site. On a store, check that no payment or subscription renewal batch is running. Tell the people who edit content to stay out of the admin for the half hour it takes, so nobody loses a draft.

Check the live site before you call it done

Repeat the short version of the staging test on the live site. Then:

• clear the page cache, the object cache and the CDN cache, or visitors will get old CSS with new HTML;
• look at the site logged out and on a phone;
• open Tools > Site Health and read any new warning;
• check that scheduled tasks still run (a store's emails and renewals depend on them);
• watch the error log and your uptime monitor for the next day.

Have the way back ready

Decide before you start what "going back" means. For a single plugin it is reinstalling the previous version, which you can download from the plugin's page on WordPress.org or from the vendor's account area. For core or for a plugin that changed its database tables, it is restoring the backup or the host snapshot, and that means losing whatever happened on the site in between. On a busy store that is the reason to test on staging first and to keep the update window short. There is a fuller walkthrough in how to roll back a WordPress update.

When to hand updates to someone else

A simple site with a dozen well-known plugins is safe to update yourself with this checklist. It becomes a job for a developer when the site has custom plugins or a heavily modified theme, when it takes payments or holds learner records, or when it has not been updated for a year or more and several major versions have to be crossed in one go. In those cases the work is mostly testing and fixing what the update exposes, which is what a WordPress maintenance plan pays for. If an update has already exposed an old customization that no longer works, moving it into a proper plugin is usually the lasting fix.

Frequently asked questions

Should I update plugins or WordPress core first?

Plugins and themes first, then core. Plugin developers release compatible versions before a new core version ships, so updated plugins run fine on the old core, while old plugins on new core is where most errors appear.

How often should a WordPress site be updated?

Check weekly. Apply security releases within a day or two, and feature releases within a couple of weeks once they have been tested on staging. Leaving updates for months makes each one riskier, because more changes land at once.

Is it safe to click "Update all"?

On a small site with a current backup it usually works. The problem is that when something does break, you cannot tell which of fifteen updates caused it. Updating the plugins your site depends on one at a time costs a few minutes and saves hours of guessing.

Do I need a staging site for minor updates?

Not for security and maintenance releases of core, which are designed to be safe to apply directly. Use staging for feature releases, for anything that touches checkout, enrollment or login, and for every update on a site that has custom code.