The useful test of a backup is whether you can recover your shop from it. Start in your hosting dashboard: find the backup, ask how to restore it into a separate test site, and confirm that doing so cannot overwrite the live shop. A “backup completed” email is only the start.
In this guide
Know what the backup contains
A normal WordPress recovery needs the database and the site files. The database contains content and shop records; files include uploads, plugins, themes and configuration. Ask what your host’s backup includes, when it was taken and how you can recover it if the hosting account itself becomes unavailable. WordPress’s backup guidance explains the two parts.
A WordPress Tools → Export content file is not a complete recoverable site backup. Nor is a product CSV. They can be useful for moving selected content, but they do not reproduce the installed files, configuration and whole shop state. WooCommerce distinguishes these exports from backups in its backup guidance.
For example, imagine a nightly backup taken at 02:00 and a failure at 15:00. A successful restore of that backup would still leave the orders received since 02:00 to reconcile. Record this recovery gap; do not overwrite a trading shop with an old copy without a plan for newer orders and payments.
Isolate the test shop first
Before the restored copy starts running, have your host or developer confirm a separate database and files, access protection and the test URL. A different hostname alone does not prevent a copied shop from contacting live services.
- Disable live payment credentials and use the gateway’s documented sandbox or test mode.
- Block or capture outbound customer email at the test environment’s mail layer; use controlled test recipients. Switching off one WooCommerce email setting may not cover every plugin.
- Disable or isolate live webhooks, scheduled jobs, subscription renewals, stock/ERP synchronisation and fulfilment integrations before allowing the copy to run.
- Keep customer data access restricted and prevent public indexing. Search exclusion is not access protection.
WooCommerce warns that test orders can trigger emails and appear in analytics. Its Subscriptions staging safeguards are specific to that extension; do not assume every integration recognises staging automatically.
Use the supported restore route
Use your host or backup tool’s documented “restore to staging” procedure, checking the destination at the final confirmation. If it only offers a production restore, ask the host for a separate recovery test instead. Keep the backup set intact and follow that tool’s required restore order.
A copied database may still contain the live site’s URLs. Use the host’s migration process or have a developer perform a WordPress-aware replacement and check links, media, login and checkout afterwards. A blanket text replacement in a database dump can damage serialised data; WordPress’s migration guidance explains the issue.
For a developer handling a manual restore
Inspect the archive’s directory structure before extracting it: an archive already containing wp-content/ must not accidentally be unpacked into another wp-content/. Confirm the target database and credentials are test-only before importing. Use the actual backup format and provider instructions rather than a generic extraction or SQL command. The WordPress database restore guide covers import methods. A file checksum detects changes to that file; it does not prove the shop can be restored.
Check a buying journey
Once isolation is confirmed, check the restored copy as an owner and a customer:
- Log in and open the homepage, a category and a representative product. Check images and selected variation details.
- Compare known products and a recent pre-backup order with your expected records. Confirm the backup includes the order storage your shop actually uses, including HPOS where enabled.
- Add the product to the cart, check delivery calculations and complete a sandbox order with test details.
- Confirm the test order is recorded and its email is captured by the test setup. Check that no live charge, fulfilment request or customer email was triggered.
- Review restore and application errors. Record anything missing or different and repeat the affected check after fixing it.
A homepage loading successfully is useful evidence, but it is not the same as a working checkout.
Record what worked
Keep a private note with the backup timestamp, test destination, restore method, elapsed time, checks completed and unresolved problems. Redact customer details from screenshots. Store the recovery instructions and protected backup copies somewhere available if the shop is down.
Choose your latest backup and ask your host for its separate-site restore procedure today. Use the resulting test before a significant change, such as removing a plugin. If test notifications are missing, the email-tracing guide explains how to follow a message through the system.