WordPress Export vs Full Backup: What Can You Actually Restore?

WordPress & Web Development / Backups / Recovery planning

WordPress’s Tools → Export file is a content export, not a full website backup. To recover a typical WordPress site, you need its database and files, a way to restore them together, and a plan for any data stored in external services.

An XML download can be useful when moving articles to another site. It should not be your only recovery copy before changing hosts, updating a busy shop, or handing a site to a new developer. The useful question is not simply whether a backup exists: it is what you can rebuild if the original site becomes unavailable.

01 / Identify the type of copy you have

A file labelled “export” could mean several different things. WordPress’s native export produces a WXR XML file containing supported content records. The Tools Export documentation lists content such as posts, pages, comments, custom fields, categories, and tags. Selecting only one content type or a date range narrows that export.

WordPress’s own export implementation explicitly describes the file as a transfer format rather than a complete site backup. Keep that distinction when someone sends you an XML file and says the website is “backed up.”

Do not judge completeness from the filename or archive size. Read the backup job’s scope and exclusions, then confirm the archive can be opened or processed by the intended restore tool.

02 / Check files, database, and media separately

The database holds more than article text

The database stores site records and settings. Depending on the plugins installed, it can also hold form entries, orders, memberships, and other application data. Check that the backup includes the tables those plugins use, rather than assuming a posts-only export captures everything. WordPress’s database backup guide explains the database export and restoration process.

The files supply software and uploaded assets

Inventory the active theme, plugins, uploads, custom files, and relevant configuration. WordPress’s files backup guide distinguishes these from the database. A copy of wp-content is valuable, but it is not automatically a complete site copy; configuration and custom files may sit elsewhere.

Some backup tools deliberately omit replaceable core files or cached files. That can be reasonable if the documented recovery procedure recreates them. What matters is whether every required component is either backed up or reliably reproducible.

Media records are not the image files themselves

An XML export is not a ZIP archive of your photos and downloads. WordPress’s import and export tutorial describes the attachment-download option during import and confirms that theme and plugin files are not included in the XML export. Fetching an image from the old site depends on that source remaining available and accessible.

03 / Map what lives outside WordPress

“Full site backup” describes a scope, not every account connected to the business. Make a short dependency list and ask whether each item is included, separately protected, or recreated during recovery.

• Media storage: identify any bucket or service holding files outside the hosting account.
• Email: distinguish website sending credentials from actual employee mailboxes and messages.
• Domain and DNS: record the registrar, DNS provider, account owner, and the records needed to reconnect the site.
• Business integrations: list payment, booking, fulfilment, CRM, and newsletter connections that need checking after recovery.

For each dependency, record who can regain access if the usual administrator is unavailable. Store recovery credentials securely, separate from a document that might be shared with contractors. Backup archives can themselves contain personal information and secrets; restrict access to them.

This inventory also prevents a false expectation that restoring WordPress will roll back a payment or restore a mailbox. Establish what each service’s own recovery process covers.

04 / Choose a schedule from the data you can lose

Start with two questions: how much recent activity could you afford to recreate, and how long could the site remain unavailable? These determine backup frequency and the restoration support you need.

Keep database and file recovery coordinated. Restoring an old database beside newly changed plugin files may not reproduce the earlier working state. WordPress’s backup guidance treats files and database as the two parts of a typical full restore and recommends retaining matching sets.

Record each set’s completion time and time zone. Keep several generations so a recently introduced problem does not leave you with only affected copies. Maintain an independent copy that remains accessible if the hosting account is unavailable, and check failures rather than relying on a schedule alone.

Take an additional recovery point before a substantial change. For a busy site, use a documented approach that handles changes during backup; do not assume two unrelated downloads form a consistent snapshot.

05 / Confirm how restoration works before choosing a tool

A download button and a restore button are different capabilities. Ask your host or backup supplier these practical questions:

• Can I download a usable copy outside this account?
• Can I restore to a separate test site, or only overwrite production?
• Does restoration require support, an administrator, or an additional service?
• Which components and locations are excluded?
• How far back do restore points go, and what happens after cancellation?
• What access will I need if WordPress itself will not load?

For example, cPanel’s official Backup documentation says full account backups cannot be automatically restored through cPanel itself; that function is available in WHM, so customers may need their hosting provider. Partial backups have a different restore workflow. Having a full account archive does not guarantee a self-service full-account restore.

If you are comparing service packages, our shared vs managed WordPress hosting guide covers the broader hosting decision. Use the questions above to examine the actual backup and recovery terms of the plan you select.

06 / Test a restore away from the live site

Use a separate destination, database, and appropriate storage isolation. Confirm the destination before starting: an exercise should not overwrite production. Follow your backup tool’s documented restore procedure and, when the test address differs, its migration procedure for URLs and configuration.

Before the restored application runs, control outbound effects. Route test email safely, use payment sandbox settings, and review scheduled jobs, webhooks, subscriptions, and fulfilment integrations as applicable. WooCommerce’s testing guidance warns that test orders can trigger email and that integrations may not distinguish them from real orders. A different hostname alone does not isolate those services.

Record what passed, what failed, and which backup set you used. A homepage loading is useful evidence, but it does not establish that forms, plugin tables, or downloadable products survived. Repeat the exercise after meaningful changes to the backup system or site architecture.

07 / Write a short recovery runbook

Keep one accessible document with the backup location, restore instructions, responsible person, provider contact route, dependency inventory, and the checklist above. It should be usable without logging into the broken WordPress site.

1. Choose the recovery point. Identify when the problem began and which snapshot is appropriate.
2. Preserve newer information where possible. Before a rollback, consider what orders, submissions, or edits arrived afterward and whether a separate current copy can be retained.
3. Agree on the overwrite. Name who authorizes restoration and who handles any missing business activity.
4. Restore and validate. Follow the documented procedure, then check the important workflows before resuming normal operations.
5. Record the result. Note the restored timestamp, remaining gaps, and follow-up work.

A backup is most useful when someone knows how to turn it into a working site. Keep the XML export if it helps your content workflow, but build the recovery plan around a verified restore.

Frequently asked questions