How to restore a WordPress site from a backup (without losing orders)

A restore should be the calm part of a bad day. In practice it often makes things worse: the wrong backup, lost orders, a site that comes back with the same hole it was hacked through. This guide gives you a routine to restore a WordPress client site from a backup, choose the right backup, keep the data you need, and check the result before the client does.

1. Decide what you actually need to restore

Not every problem needs a full restore. Ask first what broke and what has changed since the last good backup.

• A plugin or theme update broke the site: often you only need to put back that one plugin or theme folder. The database can stay as it is.
• Content was deleted or overwritten: you may only need the database, or even a single post from a revision.
• The site was hacked or files are missing: you need the files and usually the database too, from before the problem started.

Then list what happened on the site since the backup: new orders, form entries, comments, user accounts, edits by the client. A full restore throws all of that away.

2. Pick the right backup

The newest backup is not always the right one. You want the last backup from before the problem.

• Check the date and time against when the problem started (an update log, the first error, the first client message).
• For a hacked site, go back to before the infection window, not to yesterday. A backup of an infected site restores the infection.
• Make sure the backup is complete: both files (at least wp-content) and the database, and that the archive actually opens.

3. Back up the broken site first

Before you change anything, take a backup of the site as it is now. It costs a few minutes and it gives you a way back if the restore goes wrong, plus the orders and entries you may need to copy over later. With WP-CLI:

wp db export before-restore.sql

Also download wp-content, or let your host make a snapshot.

4. Restore on a copy first if you can

If you have a staging copy or can create one, restore there first. You see the result without the client watching, and you find out whether the backup is any good. For a small brochure site that is down anyway, restoring straight to live is acceptable. For a webshop, test on a copy.

5. Run the restore

Use the tool the backup came from. The three common routes:

• Backup plugin: use its restore function and choose files, database or both.
• Hosting panel: many hosts can restore files and database from their own snapshots. Check whether they restore the whole account or one site.
• By hand: upload the files over SFTP and import the database.

For the manual route with WP-CLI:

wp db import backup.sql
wp search-replace 'https://old-domain.test' 'https://www.client-site.com' --skip-columns=guid
wp rewrite flush
wp cache flush

You only need search-replace when the backup comes from another domain or a staging URL. Run it with --dry-run first.

6. Partial restores without losing orders

On a WooCommerce shop, restoring the database means losing every order, customer and stock change since the backup. Prefer the smallest restore that fixes the problem:

• A broken update: put back only the old version of that plugin or theme folder.
• A broken database on a shop: before you import, export the orders placed since the backup, and re-enter them or ask your developer to merge them.
• Missing content: check revisions and the trash before you touch a backup.

7. Check the site before you tell the client

A homepage that loads is not a working site. Go through this list:

1. Home page and the three most important pages, on desktop and on a phone.
2. Send a test message through the contact form and check that it arrives.
3. For a shop: add to cart and go through the checkout with a test payment method.
4. Log in to wp-admin and check that the plugins you expect are active.
5. Clear every cache: the caching plugin, the server cache and the CDN.

8. After a hack: close the hole before you reopen

A restore after a hack puts back the old, vulnerable version. Before the site is public again:

• Update the plugin, theme or core version that was used to get in.
• Change all admin passwords and the database password, and remove admin accounts you do not recognise.
• Rotate the security keys in wp-config.php (wp config shuffle-salts), which logs everyone out.
• Keep watching the site for a few days: new admin users, changed files, strange redirects.

9. Make restores boring

Most failed restores fail because nobody had ever tried one. Restore one site from backup every month, on a copy, and write down how long it took. Agree with clients in advance what a restore means for orders and form entries placed in between, so the conversation is not new on the day it happens.

How Verploy handles backups and restores

Every update is checked, and the risky ones are tested on a copy first, including the forms and the checkout, so fewer updates need a restore at all. Nightly backups come with a restore test, and if a site breaks after going live, Verploy rolls it back. More on WordPress backups for agencies.