A WooCommerce store is more than a collection of product pages. Its themes, extensions, uploaded media, products, orders, settings and other content are stored across two connected layers: WordPress files and the database. A dependable WooCommerce store backup must protect both. Saving only a database export leaves files unprotected, while downloading only the site files does not preserve orders or settings.
This guide presents a manual WooCommerce backup workflow based on those two layers. It explains what belongs in wp-content, how to create an SQL database export, why a WordPress XML file is not a complete store backup, and why HPOS changes the way order storage should be considered. It also covers secure storage, basic integrity checks and controlled restoration tests, so a successfully downloaded archive is not mistaken for proof that recovery will work.
What a WooCommerce Store Backup Must Protect
Files and database are separate responsibilities
Plan the backup as two responsibilities that must be handled together. The first is the wp-content folder. It contains the themes, plugins or extensions and uploaded media used by the WordPress website. These files are necessary for recreating the site’s presentation, functionality and media library.
The second responsibility is the WordPress database. It contains structured WordPress and WooCommerce data, including products, orders, settings, posts and pages. A database backup protects this information, but it does not include themes, plugins, uploads or wp-config.php. Conversely, a file download does not preserve database content.
What a complete backup means in practice
In practical terms, a complete WooCommerce backup combines the relevant WordPress files, especially wp-content, with a complete database export from the corresponding backup point. Exact coverage can vary with the store’s configuration, active extensions, custom data storage and hosting architecture, so a standard list of tables should not be treated as universal.
Backup archives may contain customer names, email addresses, addresses, order details and other sensitive store data. Restrict access to them, do not publish them through publicly accessible URLs and do not keep the only copy on the same hosting account as the live store. Keep the corresponding file backup and database dump together, with enough information to identify what each copy contains.
Why a WordPress XML Export Is Not Enough
What WXR/XML is intended to export
The WordPress Tools > Export function creates a WXR/XML file. WordPress documentation describes this export as containing posts, pages, custom post types, comments, custom fields, taxonomies and users. It is designed as a content-portability tool that can be imported through the WordPress importer.
That makes XML useful as an additional export in some workflows, especially when content portability is part of the plan. However, it should be kept conceptually separate from a database backup. An XML file is not a copy of the WordPress database and should not be used as evidence that the entire store can be restored.
The WooCommerce data gap
The reviewed WooCommerce documentation states that the XML export does not include the database tables used for WooCommerce orders, products or WooCommerce settings. Therefore, the answer to whether a WordPress XML export is enough to preserve WooCommerce orders and products is no—not as a complete store backup.
Use XML only as a supplementary export when it serves a content or portability purpose. For a migration, upgrade, database change or incident recovery, create a database backup as well as a file backup. Do not assume that every product or order configuration will be represented in a restorable way through XML.
Manual Backup: Download wp-content
File coverage checklist
A manual file backup can be created by connecting to the hosting account through FTP or an equivalent hosting file-management method and downloading the wp-content folder. This protects the principal WordPress file layer used by the store.
Before considering the file step complete, check that the download covers the areas expected for the website:
- Themes used by the WordPress site.
- Plugins and WooCommerce extensions active in the store.
- Uploaded media stored within the WordPress content directory.
Associate this file backup with the database export created from the same backup point. A file archive from one state of the store and a database dump from another may not represent the same configuration, content or order data.
Secure handling of the archive
Move the downloaded files to a secure off-site or cloud location rather than leaving the only copy on the live hosting account. Apply access controls to the archive and avoid exposing it through a public URL. The archive may include uploaded material and files connected with store operations, so it should be handled as sensitive website data.
Do not treat wp-content as a complete recovery package by itself. It protects themes, extensions and media, but products, orders, settings, posts and pages remain in the database. Record the relationship between the file archive and its matching SQL export before moving both copies into storage.
Manual WooCommerce Database Backup
Quick export versus Custom export
A manual WooCommerce database backup can be created in phpMyAdmin or an equivalent database tool provided by the hosting environment. First select the correct WordPress database. Then choose Export, select an export method and use SQL as the format before downloading the resulting database dump.
Quick export is appropriate when a broad export of the database is required. Custom export can be used when a controlled selection is understood and the selected data covers the store’s configuration. A selective table list should not be assumed to cover every extension or custom data structure. When the goal is full-store recovery, a complete database backup is the safer scope described by the planning approach in this guide.
Confirm the target database before exporting. Keep the SQL file with the corresponding wp-content backup and transfer both to secure off-site or cloud storage. A database dump can contain customer and order information, so access must be restricted.
SQL export verification
After downloading the SQL file, confirm that the export completed and is not corrupt. WooCommerce documentation describes checking that an exported dump is complete; a basic inspection can include confirming that the file ends with a dump-completion line. This is a useful file-level check, but it is not equivalent to proving that the store can be restored.
Do not import or overwrite a production database merely to test the archive. Before any production import, confirm the target database, create a current backup and understand that the operation can replace or conflict with live data. Use a staging site or isolated environment where possible. A restoration test should verify that the site loads and that important store data and workflows are available.
WooCommerce Orders, HPOS and Custom Data
HPOS and order storage
WooCommerce High-Performance Order Storage, or HPOS, uses dedicated WooCommerce tables for order-related data. The documented groups include order, address, operational-data and order-meta tables. This means order data should not automatically be assumed to exist only in the traditional WordPress posts and postmeta tables.
Legacy stores may use WordPress posts and postmeta tables for order data, while stores using HPOS use the dedicated order storage described above. The practical backup rule is not to copy only a presumed set of traditional post tables. Use a complete database backup that captures the active store configuration, then test whether orders and related data restore correctly.
Extensions and custom tables
Active extensions, payment integrations, multilingual tools, subscriptions, bookings and other store components can affect the exact data that matters during recovery. The reviewed documentation does not establish one universal table checklist for every configuration. Consequently, copying a standard subset of tables can leave important data outside the backup.
For stores using HPOS or extensions with custom data storage, verify that the selected method captures the complete database. In a controlled restoration test, check products, orders, customer records, settings and critical WooCommerce workflows. This does not require treating the documented HPOS table groups as a universal checklist; it requires matching the backup scope to the store’s actual configuration.
When to Back Up, Test and Secure the Recovery Process
A risk-based backup and testing schedule
Back up regularly, but do not assume that one fixed interval is suitable for every WooCommerce store. The reviewed documentation does not prescribe a universal frequency. Instead, make the schedule a risk-based operating decision that reflects the store’s data, changes and recovery needs.
Create a current backup before upgrades, migrations, database changes and other operations that could affect the store. WordPress documentation recommends regular database backups and backups before upgrades, while WooCommerce documentation highlights the potential effects of database changes. These are moments when a matching wp-content copy and complete database export are particularly important.
Test a new backup process after setting it up, before relying on it for a migration or major update, and periodically thereafter. Test restoration on staging or in an isolated environment where possible. Do not use the live store as the test environment when a controlled alternative is available.
Separate three checks that are often confused:
- File availability: the archive exists and can be accessed by an authorised person.
- SQL integrity: the database dump appears complete and is not corrupt.
- Restoration readiness: the files and database can be restored together and the important store functions work.
The first two checks are useful, but only the third demonstrates practical recoverability. Keep backup copies off-site or in cloud storage, restrict access and document what each backup contains. Avoid publishing raw SQL dumps, customer exports or backup archives in tutorials or public locations.
Final recovery checklist
Before relying on a WooCommerce store backup, confirm the following:
- The backup includes the relevant
wp-contentfiles, including themes, extensions and uploaded media. - The backup includes a complete database export containing WooCommerce and WordPress data.
- The file archive and SQL dump correspond to the same backup point.
- The copies are stored away from the live hosting account and access is controlled.
- The store configuration, including HPOS where applicable, is covered by the selected method.
- A controlled restoration test has checked products, orders, customer records, settings and critical workflows.
If a production import becomes necessary, confirm the target database first, create a current backup and understand the effect of the import on live data. A downloaded file is only a starting point; the recovery process must be understood and tested.
A dependable WooCommerce store backup combines WordPress files, especially wp-content, with the complete database. The XML export is supplementary, not a replacement for either layer. HPOS and extensions make configuration awareness important, while secure off-site storage protects against losing the only copy. Most importantly, a controlled restoration test—not merely a successful download or basic SQL inspection—shows whether the backup is usable. Plan the two layers together, protect sensitive archives and test before a migration, major update or recovery event. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.