How to restore a WordPress site

Restoring WordPress brings a damaged or replaced site back to one known-good recovery point. The database and file tree must come from the same snapshot so posts, options, users, plugins, themes, uploads, and configuration return to the same moment instead of mixing old and new state.

The restore path uses a paired SQL dump and file archive, then imports the database through WP-CLI after wp-config.php points at the target database. Moving the current document root aside before extraction keeps orphaned plugins, uploads, or custom drop-ins from surviving under the restored tree.

Start with shell access, a working wp command, a database user that can write to the target database, and enough disk space to hold the backup bundle and a rollback copy of the current site. Keep URL changes as a separate migration task unless the recovery point intentionally belongs on a new hostname.

Steps to restore a WordPress site:

Change into the target WordPress document root.
```
$ cd /var/www/html
```
Run wp commands from the directory that contains the active wp-config.php file. Skip the pre-restore WP-CLI checks when the target is empty or too damaged to bootstrap.
Related: How to install WP-CLI on Ubuntu or Debian
Related: How to install WP-CLI on Fedora or RHEL-compatible Linux
Record the current home URL when the existing site can still bootstrap.
```
$ wp option get home
https://www.example.com
```
Record the current siteurl value.
```
$ wp option get siteurl
https://www.example.com
```
home and siteurl can differ on subdirectory installs. Preserve that known state unless the restore is also part of a planned migration.

Confirm that the SQL dump is present before touching the live tree.

$ ls -lh /srv/backups/wordpress/site.sql
-rw-r----- 1 root root 14M Mar 29 02:15 /srv/backups/wordpress/site.sql

List the file archive contents and check for wp-config.php plus the wp-content trees.
```
$ tar -tzf /srv/backups/wordpress/site-files.tar.gz
./
./wp-admin/
./wp-content/
./wp-content/plugins/
./wp-content/themes/
./wp-content/uploads/
##### snipped #####
./wp-config.php
```
Stop if the SQL dump and file archive are not from the same recovery point. Restoring mismatched files and database rows can leave plugins, serialized options, uploads, or theme code out of sync.
Create a private rollback directory outside the public document root.
```
$ mkdir -p ~/backups/wordpress
```
Export a last-chance rollback copy of the current database when WP-CLI can still reach it.
```
$ wp db export ~/backups/wordpress/pre-restore-2026-03-29-100215.sql
Success: Exported to '/home/user/backups/wordpress/pre-restore-2026-03-29-100215.sql'.
```
Skip this step only when the target database is already empty or the damaged site cannot connect to the database.
Related: How to back up a WordPress site
Move the current document root aside.
```
$ sudo mv /var/www/html /var/www/html-pre-restore-20260329-100215
```
Do not extract a backup archive over an existing WordPress tree. Mixed old and restored files are harder to diagnose than a clean rollback directory.
Create a clean document root for the restore.
```
$ sudo mkdir -p /var/www/html
```
Extract the known-good file archive into the clean document root.
```
$ sudo tar -xzf /srv/backups/wordpress/site-files.tar.gz -C /var/www/html
```
Reapply the web server owner or group after extraction when the host requires it for uploads, plugin updates, or cache writes.
Remove any copied maintenance marker.
```
$ sudo rm -f /var/www/html/.maintenance
```
WordPress shows maintenance mode when .maintenance exists in the document root. A stale marker can make a restored site look offline after the files and database are already recovered.

Create the target database when the restore is landing in a new database.

$ mysql -u dbadmin -p -e "CREATE DATABASE wp_restore CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Grant the WordPress database user access to the target database.
```
$ mysql -u dbadmin -p -e "GRANT ALL PRIVILEGES ON wp_restore.* TO 'wpuser'@'localhost'; FLUSH PRIVILEGES;"
```
Skip the database creation and grant steps when a hosting panel or DBA has already provisioned the empty target database and user. Adjust the quoted host part when DB_HOST uses a remote database host.
Update wp-config.php so the restored files point at the target database.
```
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 SQL dump after the active database settings are correct.
```
$ wp db import /srv/backups/wordpress/site.sql
Success: Imported from '/srv/backups/wordpress/site.sql'.
```
wp db import uses the database credentials from wp-config.php and does not create the database by itself. Re-check the active file before importing because the command can overwrite the selected database quickly.
Confirm that WordPress reports the expected home URL.
```
$ wp option get home
https://www.example.com
```
Confirm that WordPress reports the expected siteurl value.
```
$ wp option get siteurl
https://www.example.com
```
If the restored site should move to a different hostname or protocol, finish the restore first, then run the migration or URL replacement workflow deliberately.
Related: How to migrate a WordPress site to a new host

Check the restored database tables.

$ 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_usermeta                             OK
wp_restore.wp_users                                OK
Success: Database checked.

wp db check calls the host mysqlcheck utility through the credentials in wp-config.php. On minimal or managed shells, use the host's supported MySQL or MariaDB check tool when mysqlcheck is not available.

Verify the restored WordPress core files against the expected release checksums.
```
$ wp core verify-checksums
Success: WordPress installation verifies against checksums.
```
Pass --version or --locale when the restored core release or locale differs from what WP-CLI detects. Use --exclude=readme.html only for a known host-added file, not for unexpected core changes.

Spot-check restored pages from the command line.

$ 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

Open the restored site in a browser before returning traffic to it.

Check wp-login.php, the front page, a media-heavy page, and any order, form, membership, or cache-sensitive path that matters to the site owner.

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.