A WordPress export and a full site backup are not two versions of the same thing. The export gives you content; the backup gives you the site. Tools → Export writes one XML file of posts, pages and taxonomy data, while a real recovery needs that plus the database, the `wp-content` directory, and the configuration files that tell WordPress where it lives.
The gap matters most on the day you need it. A site rebuilt from XML alone comes back with its words intact and almost nothing else: no images, no widget layout, no plugin settings, no theme, and possibly the wrong domain. Knowing exactly which pieces sit in which container is the difference between a two-hour restore and a week of reconstruction.
Table of Contents
- What the export file actually contains
- Where the images go
- The settings that only exist in the database
- The file that can send your site to the wrong domain
- A recovery checklist that actually covers the site
- Frequently Asked Questions
What the export file actually contains
Tools → Export produces a single file in the WordPress eXtended RSS format, usually shortened to WXR. According to WordPress's documentation for the Export screen, that file holds posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, navigation menus and users. It contains no themes, no plugins, no core files and no server configuration. The import side confirms the limit rather than softening it.
The Tools → Import screen describes the WordPress importer as bringing in posts, comments, custom fields, pages and categories from an export file. Media files, plugin settings, theme files and site options are absent from that description. That makes WXR a content transfer format. It is excellent for moving articles between installs, seeding a staging site, or handing a writer's archive to a new platform. It was never designed as a disaster recovery artifact, and treating it as one is the single most common WordPress backup mistake.
Where the images go
Uploaded media is the first thing people notice missing. Images live on the filesystem, not inside the database and not inside the XML. WordPress's Media Settings documentation notes that since WordPress 3.5 the default upload path is `wp-content/uploads`, and with month- and year-based folders enabled, a file uploaded in June 2018 is written to `wp-content/uploads/2018/06`. Restore from XML alone and every one of those paths resolves to nothing.
The post body still carries the `<img>` reference, the URL still points at `/wp-content/uploads/2018/06/`, and the file is not there. You get a complete article with a broken image in the middle of it. Copying the uploads folder fixes half of it. The other half is metadata: the Media Library screen documentation lists alt text, caption, description, title, the uploading user and the post each file is attached to as per-attachment data held in the database. Restore the files without the database and you have a directory of images with no alt text and no attachment relationships — which means broken accessibility, broken image SEO, and a gallery block that no longer knows what belongs to it.
The settings that only exist in the database
Most of what makes a site look and behave like itself is stored as options rows, not as content. WordPress's General Settings documentation states that saving that screen writes to your database, and lists what it saves: Site Title, Tagline, WordPress Address (URL), Site Address (URL), admin email, membership and default role, site language, timezone, and date and time formats. Media dimensions live in the same place. The thumbnail, medium and large image sizes plus the month/year folder toggle are database-held settings, so a content-only recovery regenerates images at whatever the fresh install defaults to.
If your theme expected a 1200-pixel large size and the new install produces 1024, every featured image is subtly wrong across the archive. Widgets are the third category people forget. WordPress's widgets documentation advises dragging a widget to Inactive Widgets when you want to remove it but keep its settings — which confirms that placement, titles, item counts and Text widget HTML are site state, not exportable content. A WXR import brings back zero of it.
The file that can send your site to the wrong domain
There is one recovery failure that looks like a database problem and is not. WordPress address settings can be locked in a file instead of the database: the General Settings documentation explains that if `WP_SITEURL` or `WP_HOME` are defined in `wp-config.php`, those values appear in General Settings and cannot be edited from the admin. The practical consequence is sharp.
Restore the database to a new host but not `wp-config.php`, and the site comes back on whatever URL the old database row holds. Restore `wp-config.php` from a staging server, and a production restore quietly points at the staging domain — with the admin screen showing the value greyed out and unfixable. Check that file first when a restored site redirects somewhere unexpected. If the constants are defined there, editing Settings → General will not help, because the file wins.
A recovery checklist that actually covers the site
Use this as the inventory before you trust any backup routine: A WXR export still earns a place in that routine, just not as the backup. Keep it as the portable, human-readable copy of your writing: it survives a host that disappears, it opens without a MySQL server, and it imports into an install that shares none of the original's infrastructure. Run it alongside the full backup, not instead of it.
The test that settles the question is a restore rehearsal. Take your backup to a clean install on a spare subdomain, restore it, and walk the site — front page, an archive, a post with images, the sidebar, one plugin's settings screen. Whatever is missing there is exactly what will be missing on the day it counts.
- **Database dump** — posts, options, widget placement, attachment metadata, users, and all plugin settings that store themselves as options or in custom tables.
- **`wp-content/uploads`** — every image, PDF and video, with its year/month folder structure intact.
- **`wp-content/themes`** — including any child theme, plus any file a developer edited directly.
- **`wp-content/plugins`** — the code; the settings come back from the database, not from this folder.
- **`wp-config.php`** — database credentials, salts, and any `WP_SITEURL` / `WP_HOME` constants. Review it before restoring rather than after.
Frequently Asked Questions
Does the WordPress export include my media files?
No. The export lists attachments as content, but the actual image files sit in `wp-content/uploads` on the server and must be copied separately or every image URL breaks.
Will my plugins work again after importing a WXR file?
Only if you reinstall the plugins and restore the database. The plugin code lives in `wp-content/plugins` and its settings are database options; neither travels in the export file.
Why is my restored site loading the wrong domain?
Check `wp-config.php` for `WP_SITEURL` or `WP_HOME`. When those constants are defined in the file, they override what the admin shows and cannot be changed from Settings → General.
Is an export ever the right tool?
Yes, for moving content between installs or keeping a platform-independent copy of your writing. It is a content transfer format, not a recovery image.
You Might Also Like
- WordPress Maintenance: Recovery Admin Accounts: How to Test Access Without Disabling the Main Login
- WordPress Maintenance: Google Sign-In Error Messages: How to Help Users Distinguish Site Problems From Account Problems
- WordPress Maintenance: Google Sheets Integrations After Account Restoration: How to Test Permissions Before Resuming Sync
