A WordPress export is not the same as a website backup. Tools > Export creates an XML content-transfer file. It can help move posts and pages, but that download alone cannot rebuild your complete website after the old hosting disappears.
This matters before a hosting move, agency handover or major repair. A file called WordPress.xml may contain the words on your pages while leaving out the actual image files, theme code and working site configuration. Downloading it is useful. Treating it as your only recovery plan is the mistake.
Use this guide to identify what you have, choose the right next step and check a small example before making an irreversible change. For the separate question of proving a full recovery, use our WordPress backup restore-test guide.
WordPress export vs backup: choose by the job
Moving selected articles into another website and recovering an entire business website are different jobs. Start with the result you need, not the extension on a downloaded file.
| What you need | Suitable starting point | Evidence still needed |
|---|---|---|
| Copy selected posts or pages into another WordPress site | Tools > Export, followed by a compatible content import | The selected content, media and formatting work on the destination |
| Rebuild the website after losing its hosting | A recovery set covering the database, site files and required external dependencies | An isolated restore reaches the agreed recovery point and passes business checks |
| Move the existing website with its design and functionality | A planned full-site migration or matching files-and-database backup | The new environment supports the site, and the cutover preserves recent changes |
A ZIP is only a container, not proof of scope. It could hold an XML file, an uploads folder or a full backup set. Ask what created it and what is actually inside before accepting it as a handover.
What the WordPress XML export includes
The built-in export format is called WXR, short for WordPress eXtended RSS. WordPress’s Tools Export documentation describes content such as posts, pages, comments, categories, tags and custom fields. The available filters determine which content you request.
Do not read All content as everything on the server. The official export function only includes eligible content types. A plugin’s separate database tables are not automatically a complete part of this content export. Author information is also not a promise that the destination will reproduce every account, permission or login method.
A database dump is different. It represents database tables for restoration into a database system. The XML file from Tools > Export is intended for a content importer. Calling both files an export does not make them interchangeable.
Does WordPress export include images?
The XML can describe media and reference its source URL; it does not package the actual image binaries inside that XML. WordPress.com’s export explanation makes this distinction explicit. Its hosting-specific controls may differ from a self-hosted WordPress dashboard.
That creates an important dependency: an import that needs to fetch an image must be able to obtain that file. A page can look correct while still loading an image from the old hostname. It can then lose that image when the original hosting closes.
On the destination, open a representative image from the Media Library and check the file URL. Confirm that the new environment owns a usable copy, rather than assuming the image transferred because the page displays it. Check featured images, images inside page content and downloadable files separately. Do not make private documents public simply to help an importer retrieve them.
A worked example: two pages and one photograph
Imagine a small business site with Home and Services pages, one photograph, a theme and a contact-form plugin. This is a hypothetical comparison based on the documented formats, not a claim that we migrated a client site.
A content export may contain both page records and their saved content. An included attachment record can point to the photograph’s original URL. However, the XML does not contain the photograph itself or the executable theme and form-plugin files.
After importing into a clean installation, finding both page titles is therefore only a partial result. Next check these three questions:
- Where does the photograph load from? Inspect its destination file URL and confirm the file is present there.
- What renders the layout? Confirm that the required theme, builder or block dependency exists and that the saved content renders correctly.
- What handles the enquiry? Confirm the actual form plugin, configuration and approved delivery path. A copied shortcode on a page is not a working form.
If the old server vanished with only the XML retained, the missing files and configuration would need another recovery source or a rebuild. This is why our staging workflow separates a safe test environment from a production cutover.
Use Tools > Export for a controlled content transfer
For an ordinary self-hosted site where your account has permission to export, the native starting point is:
- Open the site’s own WordPress dashboard and go to Tools > Export.
- Choose All content or the relevant type. For posts or pages, review the available author, date and status filters.
- Record the selection and source site privately, then choose Download Export File.
- Keep the downloaded file in an approved private project folder. Do not upload it to an unreviewed online converter.
- Have the responsible developer import it into an isolated destination, using the appropriate importer and compatible content dependencies.
- Compare the requested content against the result before authorizing any live replacement or hosting cancellation.
If the screen is absent or the download fails, ask the account or hosting owner to investigate. Do not disable security controls, delete content or change live plugins merely to force an export. The XML can contain unpublished material, comments and custom fields, so treat it as potentially private even when the public site is a simple brochure.
What to request for a complete website recovery
WordPress’s backup handbook separates files from the database. Ask your provider for the scope and timestamp of both parts, plus any dependencies stored elsewhere. A backup label without those details does not answer whether your particular site can return.
For a practical handover, request a short recovery inventory: where the matching backup set is stored, who controls access, what was excluded and when a restore was last checked. Keep credentials in the approved secure system, not in the inventory itself.
For a store, membership site or booking system, also define how recent transactions will be protected during a move or restore. A generic content import is not a safe substitute for that plan. Do not overwrite live orders to make an older copy look complete.
Stop before cancelling the old host
Pause the cutover if images still depend on the old site, required plugin data is missing, the destination exposes private content or business functions cannot be checked safely. Keep the original environment and your independent recovery copy available while the responsible owner resolves those gaps.
If a test import fails, preserve its error and source selection. Return the isolated destination to its clean baseline before another controlled attempt. Avoid repeatedly importing into the live site, where duplicate content and changed relationships make recovery harder.
Webless’s WordPress maintenance services are relevant when you need to establish backup scope and recovery evidence. For a content transfer requiring layout or integration repairs, the work may instead belong to a scoped development task. The first decision is what must survive, not which download button is fastest.