How to downgrade WordPress? (Plugin, FTP, wp-CLI)

You click “Update”, wait a moment, and suddenly see the “White Screen of Death” or a critical PHP error. Your site is down, and the client is calling.

Don’t panic. In WordPress, you can almost always revert changes. In this guide, I’ll show you three methods for a downgrade, ranging from easiest to most advanced. Before that, one step saves you from fixing the wrong thing: figure out what actually broke, so you roll back the specific component at fault instead of guessing.

#First, identify what actually broke

A rollback is only useful if you revert the right thing. If a theme update broke the layout and you downgrade WordPress core, you waste time and add risk. Spend five minutes on diagnosis first.

#Turn on WP_DEBUG and read the log

WordPress hides fatal errors behind the white screen by default. Switch on debugging so the real message is written to a file rather than shown to visitors. Edit wp-config.php, above the line that says /* That's all, stop editing! */:

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

With WP_DEBUG_LOG on, errors land in wp-content/debug.log. Open that file and read the last entries. A typical line names the exact file and function, for example a fatal error in wp-content/plugins/some-plugin/includes/class-loader.php. That path tells you which plugin is at fault before you touch anything.

If debug.log is empty or missing, check your host’s own logs. Most panels expose a PHP error log and a server (Apache or Nginx) error log under a “Logs” or “Metrics” section. The server log catches memory-limit and timeout failures that never reach the WordPress log.

#Isolate the culprit by deactivating plugins

If the log points at a plugin, or if nothing is conclusive, deactivate plugins to narrow it down. With wp-admin still reachable, deactivate them one at a time and reload the broken page after each. When the error clears, the last plugin you switched off is the cause.

If you are locked out of the dashboard, do the same over FTP or SSH. Renaming the whole wp-content/plugins folder to plugins_off deactivates every plugin at once. If the site returns, rename it back and disable plugins individually until the offender shows itself. Over WP-CLI the same check is two commands: wp plugin deactivate --all, then reactivate one by one.

#Decide what to downgrade: core, plugin, theme, or PHP

Match the symptom to the layer, because each one rolls back differently:

• A plugin is the most common cause. Downgrade that single plugin (Method 1 or 2 below) and leave everything else alone.
• A theme update usually breaks layout, styling, or the block editor rather than throwing a fatal error. Roll the theme back, or switch to a default theme like Twenty Twenty-Four to confirm.
• WordPress core is the culprit when the site broke immediately after a core update and plugins are ruled out. Core needs Method 2 or 3.
• A PHP version bump breaks the site when your host upgraded PHP (often automatically), not WordPress. The tell is a fatal error mentioning a deprecated or removed function even though you did not update anything in WordPress. That is a hosting-panel fix, covered further down.

Only once you know which layer failed does picking a rollback method make sense.

#Method 1: WP Rollback plugin (if admin works)

If you still have access to the Dashboard (wp-admin), you are saved. The best tool for reverting plugins and themes is the free WP Rollback plugin.

1. Install and activate WP Rollback.
2. Go to the plugins list (Plugins -> Installed).
3. A new link “Rollback” will appear next to each plugin.
4. Click it and choose the version you want to return to (e.g., from 5.4 to 5.3).
5. Confirm. Done!

Note: WP Rollback (free version) usually doesn’t revert WordPress Core itself, only plugins and themes. For Core, you need another plugin: Core Rollback.

#Method 2: WP-CLI (for professionals)

If you have SSH access (see our SSH guide), this is the fastest and safest method.

To downgrade WordPress Core:

wp core update --version=6.4.3 --force

The --force parameter forces installation even if you have a newer version.

To downgrade a plugin (e.g., WooCommerce):

wp plugin update woocommerce --version=8.5.0 --force

#Method 3: Manual file replacement (FTP)

If you have no access to the panel or SSH, only “open heart surgery” via FTP remains.

This is risky. Backup your database before starting!

1. Go to WordPress.org Releases and download the older WP version (zip).
2. Unzip it on your computer.
3. DELETE the wp-content folder and wp-config-sample.php file from the unzipped folder.
   • Why? So you don’t accidentally overwrite your photos, themes, and configuration!
4. Connect via FTP (FileZilla).
5. Upload the remaining files (wp-admin, wp-includes, root files) to the server, choosing “Overwrite”.

After uploading, try accessing wp-admin. WordPress might ask for a “Database Update” - agree to it.

#Rolling back through your hosting panel

Before you touch a single file, check whether your host can undo the update for you. On managed WordPress hosting this is often the fastest route, and it needs no command line at all.

Most managed hosts keep automatic daily restore points and expose a one-click restore in the control panel, usually under a “Backups” or “Restore” tab. You pick a snapshot from before the update and confirm. The host rebuilds the site (files and database together) to that moment. Because both layers move back in sync, this sidesteps the schema-mismatch trap described in the next section.

Two things to check first. Some hosts restore files and database separately, so read the labels and choose the full snapshot, not files-only. And a restore overwrites everything since the snapshot, so any orders, comments, or posts created after that point are lost. On a busy store, weigh that against a targeted plugin rollback. For a brochure site that changed nothing overnight, the one-click restore is usually the cleanest option.

#When rolling back files is not enough

Sometimes reverting files does nothing, because the damage is in the database, not the code.

Many plugins run a database migration when they update. WooCommerce is the clearest example. Its High-Performance Order Storage (HPOS) moves orders out of the wp_posts table into dedicated custom tables, and a major version can add or rename columns during the update. Membership, LMS, and page-builder plugins do the same with their own custom tables.

Here is the trap. You downgrade the plugin files from 9.0 back to 8.9, but the database is still in the 9.0 structure. The older code expects the old schema, queries a column that no longer exists (or now exists under a different shape), and the site throws a fatal error or corrupts data on write. You reverted the code against a schema it does not understand, so the rollback makes things worse, not better.

When a plugin has already migrated the database, replacing files is not enough. The only clean fix is to restore a full backup, files and database together, from a point before the update ran. That is why the pre-update backup matters more than any rollback trick: it is the one action that returns both layers to a state where they actually match each other.

If you did not take a manual backup, this is where the hosting panel’s daily snapshot (above) earns its keep. And if security services manage your site, a tested backup routine is part of the package. Learn more about WordPress security services at WPPoland.

#Which rollback method should you use?

The right method depends on the access you have and on what broke. Use this table to choose quickly.

If two rows fit, prefer the one higher up: a targeted plugin rollback is always less disruptive than a full restore, and a full restore is the safety net for the cases where a targeted rollback cannot work.

#Rolling back a PHP version

Not every post-update failure is WordPress’s fault. Hosts periodically bump the server’s PHP version, sometimes automatically, and a plugin or theme that was never tested on the newer PHP can break the moment the switch happens. The symptom is a fatal error naming a deprecated or removed function (for example a call to a function that PHP 8.2 dropped) even though you did not update anything inside WordPress.

The fix is not a WordPress downgrade at all. It is a PHP version change in the hosting panel. Most panels (cPanel, Plesk, and the dashboards of managed hosts) have a “Select PHP Version” or “PHP settings” tool. Switch back to the version your site ran on before, reload, and confirm the error clears.

Treat that as breathing space, not a fix. Running an end-of-life PHP version leaves security holes open. Use the reprieve to update the plugin or theme to a release that supports the newer PHP, test it on staging, then move the live site forward again.

#How to avoid this next time

Every emergency rollback in this guide is a symptom of updating without a net. A few habits remove almost all of them.

• Use a staging environment. Never update a live site first. Most managed hosts create a one-click staging copy. Run the update there, click through the site, and only push to production once it is clean.
• Turn on WP_DEBUG on staging. With debugging active on the copy, a broken update shows its error to you instead of to a visitor, and you catch it before it ships.
• Update in small batches. Do not update core, ten plugins, and the theme in one click. Update a few at a time and check the site between batches, so when something breaks you already know which change caused it.
• Read the changelog before major updates. For plugins that own custom tables (WooCommerce, LMS, membership, and page builders), the changelog flags database migrations and breaking changes. That warning tells you to take a full backup first rather than assume a file rollback will save you.
• Automate backups, then test the restore. Schedule backups every 24 hours, and more often for a busy store. A backup you have never restored is a guess, so restore one to staging occasionally and confirm it actually rebuilds the site.

Updates matter for security, so do not skip them. But do them on a copy, in small steps, with a backup you have proven works. That way a bad update is a five-minute rollback, not a lost afternoon.