How to Restore WordPress From Backup, Step by Step

You are here because something went wrong, or you are reading this on a calm day so you are ready for one. Either way, good. Knowing how to restore WordPress from backup is the difference between a bad hour and a bad week.

This guide covers when a restore is the right move, what to check before you start (this part is easy to skip and expensive to skip), how to do it by hand, and how to do it with a safety net.

When You Should Restore WordPress From Backup

A restore is a big hammer. It puts your site back to the way it was at a moment in the past, which also means it throws away what happened since. Use it when the cost of the problem is bigger than the cost of that rewind.

Common reasons:

• The site was hacked. Cleaning is sometimes slower and riskier than going back to a clean copy.
• An update broke something. A plugin or theme update takes the site down or wrecks the layout, and rolling back is quicker than debugging.
• A mistake. Someone deleted pages, ran the wrong database query or changed a setting they should not have.
• A move went wrong. A migration left the site half working.

When not to restore: if the problem is small and you know exactly what caused it, fix that. A one-line error from a plugin can often be solved by deactivating the plugin, no rewind needed.

If you are not sure whether you are dealing with a hack, our list of signs a WordPress site has been hacked helps you tell.

What to Check Before You Restore

Take five minutes here. It saves hours.

1. Work Out Which Backup Is Clean

If you are restoring because of a hack, the date matters more than anything. Restoring a backup that already contains the hack puts it right back, and you will be back at square one with a fresh sense of annoyance.

Ask:

• When did the problem start? Look at the dates of the first strange file, user or page you found.
• Which backup is from before that? Pick the newest one that is older than the problem.
• Is it complete? It should have both files and database.

If you can open the backup somewhere safe, scan it. Malware scanning on a copy of the backup tells you whether known malware signatures are in it. A scan finds known malware and does not prove a backup is safe, but it is a cheap check.

Key takeaway: restoring is easy to undo only if you saved the current state first.

2. Save the Current State First

Even a broken site holds things you may want: orders, comments or posts made since the backup. Before you overwrite anything, make a backup of the site as it is now.

You will probably never use it. On the day you need one thing from it, you will be very glad you made it.

3. Close the Door

If a hack caused this, restoring does not fix how they got in. Before or straight after the restore, update everything, change all passwords and remove users you do not recognise. The full list is in our guide to recovering a hacked WordPress site.

4. Make a Note of What You Will Lose

A restore brings back the site as of the backup date. Anything newer, like comments, orders or edits, is gone unless you export it first. For a shop, check whether there were orders since the backup, and keep a note so you can handle them by hand. The backup section of our WooCommerce security checklist goes deeper.

Restore WordPress From Backup by Hand

This is the manual route. It works with any backup that has your files and a database export, and it is what you do when no plugin is available.

Step 1: Put the Site in Maintenance Mode

If it is live, tell visitors you are working. A simple maintenance page, or a holding message from your host, stops people placing orders into a site you are about to overwrite.

Step 2: Restore the Files

1. Connect to your server with an SFTP client (a file transfer tool that uses a secure connection).
2. Move the current wp-content folder aside, for example to wp-content-old, rather than deleting it.
3. Upload the wp-content folder from your backup.
4. If WordPress core files were damaged, upload fresh core files from wordpress.org too, keeping your own wp-config.php.

If you are restoring onto the same site, check that wp-config.php still has the right database details. If you are restoring onto a new host, update the database name, user and password in it.

Step 3: Import the Database

Choose one:

phpMyAdmin. Open it from your hosting panel, select the WordPress database, click Import, choose your .sql file and run it. If the file is large and the import times out, ask your host to raise the limits, or use the command line.

WP-CLI. If you have SSH access, this is more reliable for big files:

wp db import mysite-2026-09-05.sql

Importing replaces the tables that are in the file. If you want to be careful, export the current database first (wp db export) so you have the "before" copy.

Step 4: Fix the Site Address if It Changed

If you restored onto the same address, skip this. If the address is different, for example you moved from a staging site to the live one, WordPress still has the old address stored all over the database. Update it with a search-replace:

wp search-replace 'https://old-address.example' 'https://new-address.example' --dry-run

Check the dry run output, then run the command again without --dry-run. Use the search-replace command rather than a plain find and replace in the SQL file, because WordPress stores some values in a format that breaks if the text length changes. WP-CLI's search-replace command handles that format for you.

Step 5: Clear Every Cache

An old cache can make a restored site look broken, or still show the problem you just fixed. Clear:

• Your caching plugin's cache.
• Your host's server cache, if it has one.
• Your CDN's cache (Cloudflare or similar).
• Your browser, or try a private window.

Then go to Settings, Permalinks in the admin and click Save without changing anything. That rewrites the rewrite rules and fixes the odd "page not found" after a restore.

Step 6: Check the Site

Do not just load the home page. Walk through:

• The home page and a few inner pages.
• Images and media.
• Logging in and out.
• Forms and checkout, if you have them.
• Your most important plugin's main screen.

When you are happy, take down the maintenance page. Keep the wp-content-old folder and the pre-restore backup for a week or so, then delete them.

Restore With Stack Guard

If you made your backups with Stack Guard, the restore is designed to be hard to get wrong. Everything below is in the Free plan. The restore documentation has the full detail, and the Backups and Restore page shows the whole picture.

One Click, Staged and Checked

On the Backups tab, click Restore on the backup you want. You choose what comes back: database and files, database only, or files only.

Here is the clever part. Before touching your live site, Stack Guard unpacks the backup into a separate folder and loads the database into separate tables, then counts every row. If anything does not match, the restore stops and the site is not changed at all. Only when everything checks out is the new copy swapped in, which takes seconds. Visitors see a short maintenance message during the swap.

That means the site ends up either fully the old one or fully the restored one, never a mix.

Keep or Roll Back for 7 Days

After the swap, the site as it was before is kept on the server. Look around. Then:

• Click Keep the Restore to tidy up and make it final.
• Click Roll Back to put everything back exactly as it was just before the restore.

If you do not choose, the restore is kept automatically after 7 days and the old copy is removed. A reminder shows on every admin screen until you decide.

Back Up the Current Site First

By default the restore panel has Back up the site as it is now first ticked, which is the "save the current state" step from earlier, done for you. Leave it ticked unless you made a backup very recently.

Restoring the database signs you out, because the users and sign-ins now come from the backup. That is normal. Sign in again and check the site.

Page Caches Are Cleared for You

After the swap, and after a Roll Back, Stack Guard clears the page caches of WP Rocket, W3 Total Cache, WP Super Cache, LiteSpeed Cache, SiteGround and WP Fastest Cache when they are installed. A CDN such as Cloudflare is not cleared, so purge it yourself.

Restore From Uploaded Files

What if the server copy is gone, perhaps because the whole site was lost? Use Restore from downloaded files on the Backups tab. Choose every part of the downloaded backup at once, each zip file and manifest.json, then click Upload Backup. The files go up in small pieces, so large backups work on any host, and the whole backup is checked on arrival. It shows as Verified only if it passes.

A backup made by this site carries a signature only this site can create. A backup from somewhere else is treated more carefully: its code files are checked against the malware scanner's signatures, you are asked for your password (and authenticator code if you use one), and the alert recipients get an email. The check finds known malware only. It is a helpful safety net and not a guarantee.

Things Worth Knowing

• A backup can only be restored onto the same site address it was made from. Moving a site to a new address is not supported yet.
• wp-config.php, Stack Guard itself, the backups and the activity log are never changed by a restore.
• Before it starts, the restore checks that the backup has not changed since it was verified and that there is enough free disk space. If a check fails, it stops with the reason.

If you do not have Stack Guard backups yet, how to back up a WordPress site covers every way to make one, and you can download Stack Guard Free to start.

Common Problems When You Restore WordPress From Backup

Even a clean restore can hand you a surprise or two. These are the usual suspects.

A white screen or "error establishing a database connection." (For a blank page that is not about the database, see the WordPress white screen of death.) The details in wp-config.php no longer match the database. Check the database name, user, password and host, especially if you restored onto a different server.

Every page except the home page shows "not found." Save your permalinks again, as described above, and clear caches.

Images are missing. The uploads folder did not come across, or only part of it did. Compare the file counts on both sides.

You are redirected to the old address. The database still points at the old site. Run the search-replace step.

Logins stop working. If you restored the database, the users are the ones from the backup. Anyone who signed up after the backup date is gone, and so are their passwords. Reset them or ask them to register again.

The restore was fine but the site is slow. Caches are cold after a restore and need a few page views to warm up. Give it a few minutes before you panic.

If none of these fits, your host's error log usually names the culprit in one line. Read it before you change anything else.

After the Restore

Do not stop when the site loads. A few follow-ups make the difference between a fix and a repeat:

• If it was a hack, scan again and look for anything left. Update everything, change all passwords and turn on two-factor sign-in for admins.
• If it was an update, find out which update broke it before you try again. Test updates on a staging copy first.
• If it was a mistake, consider limiting who has administrator accounts.
• Make a new backup now that the site is in a good state.

Then write down what you did. Next time you will be glad the steps are on paper.

One last habit worth building: test your backups before you need them. A restore under pressure is a bad time to learn that the database file is empty. Stack Guard checks every backup after it is made, and our guide to making a WordPress backup explains how to practise a restore on a spare site. If a restore ever follows an infection, run a malware scan afterwards and read what to do when a site is hacked once more, to be sure nothing was missed. The people who restore WordPress from backup calmly are almost always the ones who rehearsed it once.