WordPress Update and Rollback: How to Revert to the Previous Version if an Update Fails

When a WordPress site malfunctions, the most common trigger is not an attack or traffic spike, but an update—whether it’s a core update, plugin update, or theme update. Updates are generally beneficial (most are security fixes), but the distance between “updating” and “seeing a white screen afterward” is just one version.

Therefore, what you really need to prepare for is not how to update, but how to roll back. Below is a guide following the sequence of “Before Update → During Update → Post-Failure Rollback”.

Before Update: Three Essential Steps

# ① Backup the database (the credential for rollback)
wp db export backup-$(date +%F).sql

# ② Backup files
tar -czf wp-$(date +%F).tar.gz -C /var/www html

# ③ Record current versions (you need to know where to roll back to)
wp core version
wp plugin list --fields=name,version
wp theme  list --fields=name,version

Recording version numbers is non-negotiable. When things go wrong, you need to answer not just “roll back,” but “roll back to which version”—without records, you’re left guessing.

Comparison of Update Methods

# WP-CLI Update (Recommended, controllable)
wp core update
wp plugin update --all
wp theme  update --all

# Update only specific plugins
wp plugin update woocommerce

# Verify status after update
wp core version
wp plugin list --update=available

Stuck on “Briefly Unavailable for Scheduled Maintenance”

This is the most common symptom of a failed update: after an admin update times out or is interrupted, the site remains on the maintenance page, inaccessible via both frontend and backend.

# Cause: .maintenance file remains in the root directory
ls -la /var/www/html/.maintenance

# Solution: Delete it directly
rm -f /var/www/html/.maintenance

# Confirm accessibility again
curl -I https://example.com/

This file itself is harmless; its purpose is to display a maintenance page during updates. The problem is that it is not automatically cleaned up when an update is interrupted, leaving the site permanently in maintenance mode. Deleting it restores access—but note that this only restores access; you still need to verify whether the update was successful.

Rollback: Plugins and Themes

# ① Deactivate the problematic plugin (fastest way to stop bleeding, data remains intact)
wp plugin deactivate plugin-name

# ② Roll back to a specific version
wp plugin install plugin-name --version=3.5.2 --force

# ③ Confirm the version has been rolled back
wp plugin list --fields=name,version | grep plugin-name

# Same applies to themes
wp theme install theme-name --version=1.2.3 --force

Deactivate first, then roll back. The goal of deactivation is to immediately restore access; rolling back is a subsequent step—do not reinstall immediately. If network issues occur during reinstallation, the site will be down longer.

Rollback: Core

# Roll back to a specific core version
wp core update --version=6.4.3 --force

# Verify
wp core version

# Verify core file integrity
wp core verify-checksums

When Database Rollback is Also Required

This is the most easily overlooked point: some plugin updates modify the database structure. Simply rolling back the plugin to an older version while the database retains the new structure may still result in errors.

# Only needed if you confirm the plugin update changed the database
# Import the pre-update backup (this will lose data added after the update, so weigh carefully)
wp db import backup-2026-10-01.sql

Decision criterion: If errors persist after rolling back the plugin, and the errors relate to database fields, consider this step. The cost is losing data changes made after the update, so first confirm if any new content was added during that period.

Controlling Automatic Updates

// wp-config.php

// Completely disable automatic updates
define( 'AUTOMATIC_UPDATER_DISABLED', true );

// Disable only core automatic updates (keep plugin/theme security updates)
define( 'WP_AUTO_UPDATE_CORE', false );

// Auto-update only minor versions (security patches), not major versions
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

We recommend using 'minor': Security patches are applied automatically (this is the greatest value of updates), while major version upgrades are decided by humans. This prevents vulnerabilities from unpatched systems while avoiding issues caused by major version changes when no one is watching.

Decision Tree

Site abnormal after update
├─ Displays "Briefly Unavailable for Scheduled Maintenance"
│  └─ rm .maintenance → Restore access → Then verify if update succeeded
├─ Frontend White Screen
│  ├─ Enable WP_DEBUG to check debug.log → Identify problematic plugin/theme
│  ├─ wp plugin deactivate --all → Confirm if it's a plugin issue
│  └─ Enable one by one to isolate → Roll back that plugin's version
├─ Backend Accessible, Frontend Abnormal
│  └─ Likely a theme issue → Switch to default theme to verify → Roll back theme version
└─ Errors persist after rolling back plugins
   └─ Update modified database structure → Consider importing pre-update database backup

Scenario Simulation: Site Down After Update, Backup is Three Days Old

Symptom: After a routine program/component update, the site becomes inaccessible. Upon checking, the available backup is three days old, with no record of content changes in between.

1. First, determine if the error is due to the update process itself or incomplete post-update state → Signs of interruption during the update process suggest some files are new versions while others remain old, causing loading failures due to mixed versions.
2. Do not rush to a full rollback → First confirm the coverage time of the backup and clearly identify what content would be lost. This step determines if rollback is the only option.
3. Determine if only program files can be rolled back → Since this was a program/component update without database structure changes, you can restore files while preserving data to avoid content loss.
4. Execute file-level rollback → Replace the core program directory with the version directory, keeping configuration and upload directories intact.
5. Immediately perform a full backup once the site recovers → The recovered state is a new baseline that must be solidified immediately.
6. Standardize pre-update actions into a fixed workflow → Perform an immediate backup before every update and record the current version number.

# Fixed pre-update action: Backup files and database + record current version
wp core version --allow-root
wp plugin list --allow-root
mysqldump -uuser -ppassword dbname > backup-$(date +%F-%H%M).sql
tar czf web-$(date +%F-%H%M).tar.gz /website-directory

# Rollback: Restore only program files, keep wp-content/uploads and configs
tar czf rollback-$(date +%F-%H%M).tar.gz /website-directory     # Backup current state first
tar xzf previous-file-backup.tar.gz -C / --exclude='wp-content/uploads'

# Verify versions after recovery
wp core version --allow-root
curl -sS -o /dev/null -w '%{http_code}n' https://example.com/

Root Cause: No immediate backup was made before the update, only periodic backups, leading to inevitable loss of three days’ content upon rollback. The real issue is treating “updates” as low-risk operations.

Two key takeaways:

• Pre-update backups must be immediate; periodic backups cannot save you from update failures. They serve different purposes: periodic backups handle long-term faults, while immediate backups specifically address “errors from recent changes.”
• Prioritize “rolling back only program files” over full site restoration. Most updates do not involve data changes; restoring only files avoids rolling back updated content along with the code.

8 Common Pitfalls

1. No backup before update: Without rollback credentials, you’re forced to fix things forward.
2. Didn’t record original version number: Don’t know which version to revert to when issues arise.
3. Panic when stuck on maintenance page: Simply deleting .maintenance resolves this minor issue.
4. Reinstalling plugins immediately: Deactivate first to restore access, then handle versioning.
5. Rolling back plugins without updating the database: Errors persist if the plugin update changed table structures.
6. Enabling auto-updates for everything: Major versions triggered when no one is around can cause unnoticed issues.
7. Neglecting updates for too long: The other extreme. Security patches should be applied promptly; use 'minor' to balance.
8. No staging environment: Important sites should be verified in a test environment before going live.

Real Customer Feedback (From Cloud Marketplace Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar O&M services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Market (service providers include our store and competitors, provided solely for reference of real feedback, not fictitious tickets from our site):

10***09 2024-03-18 5.0 Convenient and stable | Clean interface | Comprehensive after-sales service (User did not fill in review content)