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.

#Capture the current state before you roll back

A rollback destroys evidence. Before you replace a single file, record what the site is running right now, so you can move forward again once the bug is patched and so you can compare states if the rollback does not help.

With WP-CLI it takes under a minute:

wp core version --extra
wp plugin list --fields=name,status,version,update_version --format=csv > plugins-before.csv
wp theme list --fields=name,status,version --format=csv > themes-before.csv
wp db export backup-before-rollback.sql

wp core version --extra prints the core version together with the database revision that the running code expects. Compare it with wp option get db_version, the revision actually stored in the database: if the stored number is higher than the one your target release expects, the database has already migrated forward and a file-only rollback will not match it. The two CSV files give you the exact versions to return to afterwards, instead of guessing from memory at midnight.

Two plugin headers decide whether a core downgrade is even possible. A plugin can declare Requires at least and Requires PHP in its main file header, and where those headers are present WordPress blocks activation when the running core or PHP version does not meet them. So if a plugin declares WordPress 6.6 and you drop core to 6.4, you cannot reactivate it after the downgrade, and its code may call core functions that the older release does not ship. Read the headers before you pick a target version:

grep -RE "Requires (at least|PHP)" wp-content/plugins/*/*.php

Finally, put the site behind maintenance mode so visitors and crawlers get a 503 instead of a half-replaced install: wp maintenance-mode activate, and wp maintenance-mode deactivate when the work is done. A 503 with a short retry window is the response Google expects during maintenance, so it does not treat the outage as a permanent change.

#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.

#How to tell whether the rollback actually worked

“The homepage loads” is not verification. A rollback can leave a half-copied file tree, a stale bytecode cache, or a broken admin path while the front page still renders from cache.

Start by checking the version that is actually in place, not the one you intended to install:

wp core version
wp plugin get woocommerce --field=version
wp core verify-checksums
wp plugin verify-checksums --all

verify-checksums compares every file on disk against the checksums published on wordpress.org for that exact release. It is the fastest way to catch the classic FTP failure, a transfer that dropped or truncated a handful of files without reporting an error. A clean run means the file tree matches the version you meant to have. The plugin variant only covers plugins hosted on wordpress.org, so premium plugins still need a manual file comparison.

Next, clear every cache that can keep serving the code you just removed:

• Object cache: wp cache flush (Redis or Memcached keeps serialized objects created by the newer code).
• Page cache and CDN: purge the full cache, not a single URL, because a fatal error may have been cached as a 500 response.
• PHP OPcache: the one most people miss. On hosts that run opcache.validate_timestamps=0 for performance, the compiled bytecode of the newer files stays in memory until the PHP-FPM pool is reloaded, so the older files sit on disk while the newer code keeps executing. Reload PHP from the hosting panel, or run a script that calls opcache_reset().

Then test more than the homepage. Fatal errors after an update usually live in admin-ajax, the REST API, or checkout rather than on a cached front page:

curl -o /dev/null -s -w "%{http_code}\n" https://your-domain.tld/
curl -o /dev/null -s -w "%{http_code}\n" https://your-domain.tld/wp-json/

Log in, open the rolled-back plugin’s own settings screen, and run one write operation: save a post, submit the contact form, place a test order. Read operations pass on plenty of broken installs.

Empty wp-content/debug.log before that test run and read it again afterwards. A log that stays empty is a stronger signal than a page that merely looks correct, because it also rules out the warnings and deprecation notices that turn into fatal errors on the next release. Finish in Tools -> Site Health, whose status tests flag a core version that is behind on security releases and a server PHP version that WordPress no longer considers supported.

#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.

#Stop WordPress from reinstalling the version you removed

Nothing about a downgrade tells WordPress to stay downgraded. Auto-updates run from the wp_version_check, wp_update_plugins, wp_update_themes, and wp_maybe_auto_update cron events, so a plugin you rolled back in the morning can be back on the broken release the same day. That is the usual explanation when a site “breaks again on its own” hours after a successful rollback.

Pin the specific plugin first:

wp plugin auto-updates disable woocommerce
wp plugin auto-updates status

That flag is stored in the auto_update_plugins option as a list of plugin file paths, which matters for one reason: if you later restore a database backup taken before you set the flag, the pin disappears with it. Set it again after any database restore.

For core, use wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_CORE accepts true, false, or 'minor'. Keeping 'minor' lets security releases through while blocking the major version that broke the site, which is the setting to land on once the emergency is over. AUTOMATIC_UPDATER_DISABLED and the automatic_updater_disabled filter switch off the entire updater, translations included, so use them only for the hours you are investigating.

Confirm nothing is still queued with wp cron event list, and check the panel as well: managed hosts run their own update scheduler outside WordPress, and it ignores the constants in wp-config.php. If the site is built with Composer, pin the exact version there ("wpackagist-plugin/woocommerce": "8.5.0") so the deployment itself enforces the pin rather than a flag someone can clear from the dashboard.

Treat every pin as temporary. Note the version you are avoiding and the reason, watch the plugin’s changelog, and lift the pin as soon as a fixed release is out. A permanently pinned plugin becomes the security hole that the update was supposed to close.

#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.