How to update WordPress safely: a step-by-step guide

Many WordPress sites aren’t updated for months, because the owner is afraid that everything will stop working after clicking “Update”. The fear is justified, but not updating is more dangerous: outdated plugins and themes are one of the most common routes attackers use. According to Patchstack’s report for 2025, 91% of new vulnerabilities in the WordPress ecosystem concerned plugins, 9% concerned themes, and only 6 were found in the core itself.

I will show you how to update WordPress safely, in a calm order, with a backup and an emergency plan. At the end you get a 15-minute checklist that you can print and keep next to your computer.

Why updates break sites

WordPress is a core, a theme and usually a dozen or so plugins, written by different authors. Each update changes one element, and the others have to get along with it. The most common causes of failure:

• a plugin incompatible with the new version of the core or PHP,
• a theme that overrides plugin functions (especially an old one, bought a few years ago),
• changes made directly in theme files, which vanish after an update,
• too many changes at once, so you don’t know what broke the site.

All these risks can be reduced with preparation. We start with a backup.

Step 1: back up the files and the database

A website backup is two things: the files (theme, plugins, photos from the media library) and the database (content, settings, orders). If either one is missing, restoring won’t work.

Where to do it:

1. At your host. Many hosting companies make backups automatically. Check in the panel what date the last one is from and how to restore it.
2. With a backup plugin. Many plugins save the backup to an external cloud drive. This matters, because a backup on the same server can vanish together with the site.
3. Manually. Download the files over FTP and export the database in the hosting panel.

Before a major update, make a fresh backup, even if your host makes a daily one. And one important rule: a backup from which nobody has ever tried to restore a site is just hope. At least once, check that you can rebuild the site from it.

Step 2: test on a staging copy

A staging copy is an exact copy of the site at a different, hidden address. You update it there first, check that everything works, and only then repeat the changes on the live site.

Some hosts offer this in the panel as a ready-made feature, though not always in every plan. Look at your provider’s offer and search for the name “staging”, “test environment” or “site cloning”. If your host doesn’t have it, there are plugins that create a staging copy in a subdirectory.

On a simple business-card site you can skip this if you have a good backup. For a store, bookings and payments, a staging copy is a must: an error at checkout costs real orders.

Step 3: update in the right order

The order matters. I stick to this one:

1. Plugins, one by one, not all at once.
2. The theme (and the child theme, if you use one).
3. The WordPress core.
4. The PHP version on the server, if your host raises it (more on that below).

After each update, open the home page, one subpage and the contact form. It takes a minute, and if something breaks, you know exactly which change is to blame. Updating plugins one at a time is the simplest way to find faults. If for a plugin you see the message “The update will not work with your version of WordPress”, come back to it after updating the core.

Before updating the core, read what the new version changes. In the panel under Dashboard → Updates you will see whether WordPress requires a newer PHP version and whether any plugin is marked as untested with this version.

Step 4: PHP, the silent culprit

Many failures come not from WordPress itself but from a change of the PHP version on the server. Older plugins can be incompatible with newer PHP, and a newer WordPress can require a newer PHP than you have. You will find the version in the WordPress panel under Tools → Site Health, in the “Info” tab (the “Server” section).

According to wordpress.org, the current WordPress (version 7.1 in October 2026) requires at least PHP 7.4, and PHP 8.3 or newer is recommended. You can check the PHP versions available at your host in its panel. I write more about why old PHP is a problem in the guide PHP 8.2 and the end of support: check your website. Change PHP separately from updating WordPress, preferably on a staging copy.

Automatic updates: what to turn on and what not

WordPress installs minor core versions by itself, which means mainly security fixes. That is a good default and I don’t advise turning it off. Beware of major versions: on installations created since WordPress 5.6 (December 2020) they also install themselves by default. You can check this in Dashboard → Updates. The line “This site is automatically kept up to date with each new version of WordPress.” means that major versions come in automatically, and the link below it switches updates to maintenance and security releases only. Plugins and themes by default need your click, but you can turn on automatic updates for them with the “Enable auto-updates” link, separately for each plugin (in Plugins) and for the theme (in Appearance → Themes).

My rule:

If anyone is to turn off core updates completely, it should be done deliberately and with a plan for manual updates every week.

What to do when the site goes down

Even with good preparation, a failure happens. First stay calm, no blind clicking. The emergency plan:

1. Check the administrator’s mail. When a plugin or theme causes a critical error, WordPress sends a message with a link to recovery mode to the administration email address (from Settings → General), provided the server sends emails. The link is valid for a day by default. After you log in through it, the faulty plugin is paused only in your session, so deactivate it or update it in the panel. Until then, visitors still see the error.
2. Deactivate the plugin you updated last. If you can’t get into the panel, connect over FTP or a file manager and rename its folder in wp-content/plugins, for example by appending -disabled. WordPress will stop loading it.
3. Turn on error logging. In the wp-config.php file you can temporarily write the messages to a log:

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

You will find the errors in the wp-content/debug.log file. After the fix, set WP_DEBUG back to false and delete the debug.log file, because by default it sits in a directory accessible from the internet and can reveal details of the site.

4. Restore the backup. If after 30 minutes you still don’t know what is wrong, don’t fight on. Restore the backup from the day before the update and try again on a staging copy.
5. Write down what happened. The plugin name and the error message will be useful to you or to the person who helps you.

It is worth having your host’s support number in your phone. They can often restore a backup in a few minutes.

Plugins abandoned by their authors

The biggest risk is plugins that haven’t had an update for years. They don’t always cause trouble right away, but they get no security patches, and over time they stop working with new PHP.

How to find them:

• in Dashboard → Updates, see whether plugins awaiting an update carry a “Not tested” note in the compatibility with your WordPress version, and in Plugins click “View details” and check whether there is a warning that the plugin has not been tested with your version of WordPress,
• in the plugin directory on wordpress.org, check the date of the last update,
• remove plugins you no longer use. A deactivated plugin still sits on the server and can still have a vulnerability.

When a plugin is important and its author has disappeared, look for a replacement and swap it on a staging copy. If the whole site rests on an outdated theme and a dozen or so abandoned add-ons, a website redesign is sometimes cheaper than patching it every month.

A 15-minute checklist before updating

Print it and tick it off before every major update:

1. A full backup (files and database) made today and stored off the server.
2. I know how to restore it and whom to call at the host.
3. I have checked in Dashboard → Updates what exactly will be updated.
4. I have checked the PHP version (Tools → Site Health) and the requirements of the new version.
5. For a store and bookings: update first on a staging copy.
6. Plugins I don’t use are deactivated or removed.
7. Update in the order: plugins → theme → core, one change at a time.
8. After each change I have checked: the home page, a subpage, the contact form, and in a store adding to the cart.
9. At the end I have run a test order or booking, if I have them.
10. The date and the list of changes are saved in a note.

The best day is Tuesday or Wednesday morning, not Friday afternoon. If something breaks, you have a whole working day to fix it.

How to check the state of your website

If you don’t know whether your site is already neglected, start with the free tool Check your website. In 30 seconds it checks speed, SEO, security and other areas, and the result shows what needs fixing first. It won’t replace a review of the WordPress panel, but it will show the immediately visible problems.

Summary

A safe update is a backup, a staging copy where it matters, the right order and a plan in case of failure. The fear of clicking goes away when you know how to undo the changes.

If you don’t want to deal with this yourself, I can take over the updates as part of technical maintenance: backups, updates and a quick response from PLN 149 net per month. You can also write to me, and I will reply within 24 hours.