How to Downgrade WordPress Safely (And When You Actually Should)

Downgrading WordPress means rolling core back to an earlier release after an update caused a problem. It’s a less common operation than upgrading, and WordPress doesn’t build a one-click path for it the way it does for updates, which is a deliberate choice: core developers want people moving forward, not backward, and a downgrade path that’s too easy tends to get used as a substitute for actually fixing whatever broke. Still, there are real situations where rolling back is the fastest way to get a site working again while you sort out the underlying cause, and it’s worth knowing how to do it without making things worse.

Figure out if a downgrade is actually the right fix

Before touching anything, separate the two questions people usually conflate: “did something break after I updated WordPress” and “did WordPress itself cause the break.” Those aren’t the same question, and getting this wrong is the single most common reason downgrades don’t fix anything.

Core WordPress updates are tested against an enormous install base before release, and outright core regressions that break live sites are rare, a handful of true core-caused breakages happen across hundreds of releases. What’s far more common: a plugin or theme wasn’t updated to handle a change in core (a deprecated function, a new default behavior, a stricter PHP requirement), and the plugin author hasn’t shipped a compatibility fix yet. In that case, downgrading WordPress core does fix the symptom, but the actual bug lives in the plugin, and you’re now running an old, potentially insecure core version to work around someone else’s unfinished update.

A faster diagnostic than downgrading core outright: deactivate all plugins and switch to a default theme (Twenty Twenty-Four or similar), then check if the problem persists. If it clears up, reactivate plugins one at a time until it reappears, you’ve found the actual culprit, and the fix is updating or temporarily disabling that specific plugin, not rolling back core. Only downgrade core itself when you can reproduce the issue on a clean, no-plugins, default-theme install, which points at core as the genuine cause.

The database schema catch that trips people up

WordPress core updates sometimes include a database schema migration, new columns, new tables, changed indexes, tracked internally by the db_version value stored in wp_options. When you update WordPress, core runs wp_upgrade() which applies any pending schema changes and bumps that version number. Downgrading the core files does not automatically reverse a schema migration that already ran. Most of the time this is harmless because schema changes are additive (new optional columns, new tables that just sit unused by older code), but it’s worth knowing this asymmetry exists before assuming a downgrade returns you to an identical prior state. If you’re downgrading across a version gap that included a major schema change, these are noted in the release notes under “database changes”, restoring a database backup taken before the original update, alongside the file rollback, is the only way to get a truly clean prior state.

Confirming which update actually caused the problem

Your current core version is listed at the bottom of every wp-admin screen, or via wp core version in WP-CLI. That tells you where you are, not when you got there. To find out when you updated, check Dashboard → Updates for a recent update log if your host or a plugin like WP Rollback keeps one, or check the modification timestamp on wp-includes/version.php via FTP, which changes every time core updates. Cross-reference that date against when the symptom started, if the timestamps line up within a day or so, that’s a strong signal the update is the trigger, whether directly or by exposing a plugin incompatibility.

It’s also worth reading the changelog for the specific version you updated to. WordPress publishes detailed release notes for every version at wordpress.org/download/releases, including a “What’s New” summary and often a list of deprecated functions. If the symptom you’re seeing (a specific admin screen breaking, a specific block type failing to render, a specific hook no longer firing) matches something explicitly called out in the changelog, that’s much stronger evidence than a vague timing correlation, and it also tells you exactly what a plugin update would need to address to be compatible again.

Comparing the three rollback methods

WP Rollback is the right default for anyone comfortable installing a plugin and clicking through a UI, it’s free, maintained by a major hosting company, and it keeps a clean record of what it changed, which makes it easy to roll forward again later. WP-CLI is faster and more precise if you already have shell access and are comfortable with the command line; it’s also the only practical option for scripting a rollback across many sites at once, which matters if you manage a fleet of WordPress installs and discovered the same incompatibility across several of them. The manual FTP method is the fallback for the remaining case: no plugin installs allowed, no shell access, just file manager or FTP credentials. It’s the slowest and has the most opportunities for a mistake (partial folder merges, accidentally overwriting wp-config.php), so treat it as the last resort rather than the default.

Do this on staging first if you can

If the site in question handles real transactions, real member accounts, or real traffic, don’t run your first-ever rollback attempt directly against production. Clone the site to a staging environment, most managed hosts (WP Engine, Kinsta, SiteGround, and others) offer a one-click staging clone, and run the rollback there first. Confirm the actual problem clears up and that nothing else broke as a side effect before repeating the process on the live site. This matters more for a downgrade than an upgrade, because downgrades are tested far less thoroughly by the broader WordPress ecosystem; almost everyone is moving forward, so the “downgrade from 6.5 to 6.4.3 with these specific plugins active” combination you’re running is one nobody else has necessarily verified works cleanly.

Back up before you do anything

Export your database (phpMyAdmin’s Export tab, wp db export via WP-CLI, or your host’s backup tool) and take a full file backup, or at minimum copy wp-content and note your current WordPress version. If the downgrade doesn’t solve the problem, you want a clean path back to where you started rather than being stuck between two broken states.

Method 1: WP Rollback plugin (easiest for most people)

The WP Rollback plugin, built by WP Engine and available free in the official repository, is the most reliable low-effort option. Install and activate it, then go to Plugins or Dashboard → Updates, WP Rollback adds a “Rollback” link next to WordPress core, individual plugins, and themes. Clicking it shows a version history you can pick from, and it handles the file swap cleanly without you touching FTP or a file manager. It works the same way for rolling back a specific plugin or theme version, which is often the more surgical fix compared to rolling back core itself.

Method 2: WP-CLI

If you have shell access, this is the fastest and least error-prone method:

wp core update --version=6.4.3 --force

Replace the version number with whichever release you’re targeting. The --force flag is required because WP-CLI normally refuses to “update” to a version older than the one currently installed, it treats that as a mistake by default, and the flag confirms you mean it. This command replaces core files in place without touching your database, plugins, or theme files, and it’s the same underlying mechanism WordPress uses for regular updates, just pointed backward.

Method 3: Manual file replacement

For sites without WP-CLI or plugin install access, the manual route:

1. Go to the WordPress Release Archive and download the ZIP for the target version.
2. Extract it locally. You’ll get a folder containing wp-admin, wp-includes, and the root-level PHP files.
3. Connect to your server via FTP or your host’s file manager.
4. Delete the existing wp-admin and wp-includes folders entirely, don’t merge them, replace them wholesale, since a partial merge of old and new core files inside those folders is a common source of fatal errors.
5. Upload the new wp-admin and wp-includes folders from the extracted archive.
6. Upload the root-level files (wp-load.php, wp-settings.php, and so on) but do not overwrite wp-config.php, .htaccess, or anything inside wp-content, those are yours, not part of core, and overwriting wp-config.php in particular will wipe your database credentials.
7. Do not run the /wp-admin/upgrade.php script after a downgrade the way you would after an upgrade, that script runs forward-only schema migrations and can cause more problems than it solves when pointed at an older codebase.

Picking the right version to roll back to

Don’t guess. If you know which update caused the problem, roll back to the version immediately before it, not several versions further back, the further you go, the more compatibility drift you introduce with plugins that have already updated to expect the newer core. If you’re not sure which update caused it, check your site’s update history (many hosts log this, or check file modification timestamps on wp-includes/version.php) or check the WordPress release notes for the version range to see what changed and whether it lines up with when the problem started.

Test thoroughly after rolling back

Check the admin dashboard loads without PHP warnings, check the block editor opens and saves correctly, check your most-used plugins’ admin screens, and check the front end renders as expected across a couple of page templates. If you’re running WooCommerce or BuddyPress, check checkout and core community flows specifically, these are the features most likely to surface a subtle incompatibility that a quick homepage glance won’t catch.

Check your error logs before you decide anything

PHP fatal errors, deprecation notices, and database errors all get logged if WP_DEBUG_LOG is enabled, and most hosts also keep a separate PHP error log accessible through cPanel, Plesk, or an SSH-accessible error_log file outside the WordPress install itself. Reading that log before deciding to downgrade often saves the entire exercise: a fatal error naming a specific plugin file and function tells you immediately where the problem lives, without needing the deactivate-everything diagnostic described above. Look for lines timestamped right around when the symptom started, and pay attention to any “Fatal error,” “Uncaught Error,” or “PHP Deprecated” entries that reference a path inside wp-content/plugins/, that’s a plugin problem, full stop, and downgrading core won’t be the durable fix even if it happens to suppress the symptom in the short term.

Turn off automatic updates while you sort this out

Once you’ve rolled back, WordPress’s automatic background updates for minor releases will try to bring you forward again unless you disable them, which defeats the point of the rollback. Add this to wp-config.php to disable all automatic core updates temporarily:

define( 'WP_AUTO_UPDATE_CORE', false );

Treat this as a temporary measure, not a permanent setting, leaving core updates permanently disabled means missing security patches, which is a worse outcome than the original problem in most cases. Re-enable it once the actual incompatibility (usually a plugin) has shipped a fix or you’ve found an alternative.

What to do instead of staying downgraded long-term

A downgrade is a stopgap, not a destination. While you’re on the older version, do the actual diagnostic work: check the changelog of the version you rolled back from for anything that touches the area where you saw problems, check whether the plugin or theme causing friction has an open support thread or GitHub issue about the same symptom, and check whether a newer version of that plugin has already shipped a fix since you first hit the problem. Re-attempt the core update once you’ve either fixed the underlying incompatibility or confirmed it’s been resolved upstream, staying on an old core version indefinitely means missing security fixes for vulnerabilities that get actively exploited once they’re publicly known.

Common questions

Can I downgrade across major versions, like from 6.5 back to 5.9?

Technically yes, using the same methods above, but the risk of plugin and theme incompatibility increases sharply the further back you go, since most actively maintained plugins are tested against recent core versions, not ones from a year or more back. If you genuinely need to run a much older core version, expect to also need older versions of several plugins, and understand you’re accepting real security exposure by doing this on a public-facing site.

Will downgrading fix a fatal error caused by a PHP version mismatch?

Sometimes, if the fatal error is specifically triggered by core using a PHP function or syntax feature your hosting’s PHP version doesn’t support yet. But it’s usually cleaner to fix the actual mismatch, either update your hosting account’s PHP version if it’s genuinely outdated, or confirm with your host which PHP version current WordPress core requires and align to that, rather than permanently downgrading WordPress to match an old PHP version.

Does downgrading remove security patches from newer releases?

Yes, and this is the main reason to treat any downgrade as temporary. If a newer release included a security fix, rolling back removes that fix along with whatever else changed. Check the release notes for the versions between your rollback target and your original version for any flagged security fixes before deciding how long you’re comfortable staying downgraded.

Is there a risk of data loss from downgrading?

The core file rollback itself doesn’t touch your content in the database. The risk is indirect: if a plugin wrote data in a format the older core or an older version of that same plugin doesn’t understand, you can end up with orphaned or unreadable data. This is rare but is another reason to take a full backup first and test thoroughly before considering the rollback complete.

Can I roll back just a plugin instead of all of WordPress core?

Yes, and in most cases this is the better move if you’ve confirmed the plugin, not core, is the actual source of the problem. WP Rollback handles individual plugin and theme rollbacks through the same interface as core, and the WordPress.org plugin repository keeps every published version of a plugin available under its “Advanced View” page, so you can download and manually install a specific older version even without WP Rollback installed. Rolling back one plugin rather than all of core is lower risk and keeps you on a current, security-patched core version while you wait for the plugin author to ship a fix.

What if the version I need isn’t in the official release archive?

Every publicly released WordPress core version, including minor and security releases, is preserved in the release archive going back to version 2.5. If a specific version genuinely isn’t listed there, it likely wasn’t a public release (a beta, release candidate, or nightly build), and rolling back to a non-public build on a production site isn’t something to attempt.

Should I downgrade if the site is a large multisite network?

Be more cautious here than on a single site. A network-wide core downgrade affects every subsite simultaneously, and any subsite running plugins tuned to the newer core can break as a side effect of a fix aimed at just one problem subsite. Test on a staging clone of the full network, not just the affected subsite, before rolling back a production multisite install.