How to restore a WordPress site

Restoring WordPress is the controlled way to recover after a bad deployment, a compromised document root, data loss, or a failed change window. A clean restore brings the site back to one known-good recovery point instead of leaving mismatched files, themes, plugins, uploads, and database rows from different moments in time.

WordPress state spans the database and the document root that contains /wp-config.php/, core files, plugins, themes, uploads, and any custom drop-ins. A successful restore puts the matching file archive back in place, points /wp-config.php/ at the intended MySQL or MariaDB database, and imports the paired SQL dump before browser or WP-CLI checks confirm that the site is coherent again.

Examples assume a restore bundle that contains both site.sql and site-files.tar.gz from the same snapshot, shell access on the target host, and a working WP-CLI installation. When the damaged site still has data worth preserving, take a last-chance rollback copy before overwriting it, move the existing document root aside instead of extracting on top of it, and treat URL changes as a separate migration job rather than a restore shortcut. On minimal container images, wp db check can fail when the host does not provide mysqlcheck, so validate the imported database with the host's supported MySQL or MariaDB client tools if needed.

Steps to restore a WordPress site:

Open a terminal session in the target WordPress document root and confirm the current site URLs before overwriting anything.
```
$ cd /var/www/html
$ wp option get home
http://old.example.com
$ wp option get siteurl
http://old.example.com
```
Skip the URL checks when the target is empty or when the current tree cannot bootstrap WordPress. Run the remaining wp commands from the directory that contains the restored /wp-config.php/ file.

Related: How to install WP-CLI on Ubuntu or Debian
Related: How to install WP-CLI on CentOS, Fedora, or Red Hat

Confirm that the restore bundle contains both the SQL dump and the matching file archive before touching the live tree.

$ ls -lh /srv/backups/wordpress/site.sql /srv/backups/wordpress/site-files.tar.gz
-rw-r----- 1 root root  14M Mar 29 02:15 /srv/backups/wordpress/site.sql
-rw-r----- 1 root root 842M Mar 29 02:15 /srv/backups/wordpress/site-files.tar.gz
$ tar -tzf /srv/backups/wordpress/site-files.tar.gz | rg 'wp-config.php|wp-content/uploads/'
./wp-config.php
./wp-content/uploads/2026/03/restore-check.png

Use grep -E instead of rg when ripgrep is not installed.

Export a last-chance rollback copy of the current database when the existing site is still reachable through WP-CLI.
```
$ ROLLBACK_DIR=~/backups/wordpress/pre-restore-$(date +%F-%H%M%S)
$ mkdir -p "$ROLLBACK_DIR"
$ wp db export "$ROLLBACK_DIR/current-site.sql"
Success: Exported to '/home/user/backups/wordpress/pre-restore-2026-03-29-100215/current-site.sql'.
```
Skip this step when the target is already empty or when the current site is too damaged for wp to reach the database.

Related: How to back up a WordPress site
Move the current document root aside and create a clean restore target so stale files do not survive the recovery.
```
$ sudo mv /var/www/html /var/www/html-pre-restore-$(date +%F-%H%M%S)
$ sudo mkdir -p /var/www/html
```
Do not extract a backup archive over an existing WordPress tree. Orphaned plugins, mu-plugins, uploads, or custom drop-ins can leave the restored site in a mixed state that is hard to debug.
Extract the known-good file archive into the target document root.
```
$ sudo tar -xzf /srv/backups/wordpress/site-files.tar.gz -C /var/www/html
```
If the web server expects a specific owner or group, reapply that ownership after extraction and before reopening traffic.
Remove any stale maintenance marker copied with the restored files.
```
$ sudo rm -f /var/www/html/.maintenance
```
WordPress treats a .maintenance file in the document root as maintenance mode. Removing a stale copy prevents the restored site from coming back online behind an old upgrade lock.
Create an empty target database when the restore is landing in a new database instead of the original one.
```
$ mysql -u dbadmin -p -e "CREATE DATABASE wp_restore CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
```
wp db import does not create the database by itself. Skip this step when the host panel or DBA has already provisioned an empty database for the restore.
Update /wp-config.php/ so the restored files point at the target database before importing the SQL dump.
```
define( 'DB_NAME', 'wp_restore' );
define( 'DB_USER', 'wpuser' );
define( 'DB_PASSWORD', 'strong-password' );
define( 'DB_HOST', '127.0.0.1:3306' );
```
Keep the existing table_prefix unless the restore intentionally targets a different table set.
Import the backup SQL only after the live database settings in /wp-config.php/ are correct.
```
$ wp db import /srv/backups/wordpress/site.sql
Success: Imported from '/srv/backups/wordpress/site.sql'.
```
Importing into the wrong database overwrites data quickly. Re-check the active /wp-config.php/ values before running the command.
Confirm that the restored site now reports the expected primary URLs.
```
$ wp option get home
http://www.example.com
$ wp option get siteurl
http://www.example.com
```
If the restore intentionally lands on a different hostname or protocol, treat that as a separate migration step instead of rewriting URLs blindly during the restore.

Related: How to migrate a WordPress site to a new host

Check the restored database tables for corruption or import errors.

$ wp db check
wp_restore.wp_commentmeta                          OK
wp_restore.wp_comments                             OK
wp_restore.wp_links                                OK
wp_restore.wp_options                              OK
##### snipped #####
wp_restore.wp_users                                OK
Success: Database checked.

On minimal containers or managed shells, wp db check can fail when mysqlcheck is not installed. Use the host's supported MySQL or MariaDB client utilities instead of assuming that the restore itself failed.

Verify the restored core files against the expected WordPress release checksums.
```
$ wp core verify-checksums
Success: WordPress installation verifies against checksums.
```
Some containerized or managed environments add a known extra file in the WordPress root. If the command warns only about that expected platform file, rerun it with --exclude=<file> for that file instead of treating the core restore as corrupted.
Spot-check restored content from the command line before reopening traffic.
```
$ wp post list --post_type='page' --fields='ID,post_title,post_name' --format=table
ID	post_title	post_name
4	About	about
2	Sample Page	sample-page
3	Privacy Policy	privacy-policy
```
After the CLI checks pass, open wp-login.php, the front page, and a few media-heavy or transaction-critical URLs in a browser to confirm logins, links, uploads, and cached assets all match the recovery point.

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.