Quick Answer
A WordPress export import checklist should treat the XML file as a content-transfer artifact, not a full site backup. The practical operator flow is to back up the source and destination sites, choose the smallest useful export scope, record users, categories, tags, custom post types, media assumptions, and permalink risks, import into staging first when possible, verify representative posts and attachments, then document any redirect, sitemap, cache, or Search Console follow-up before the public site changes.
Decision Map
| Situation | Better choice | Operator risk to control |
|---|---|---|
| Moving selected posts to another WordPress site | WordPress Tools > Export with a narrow content scope | Missing media files, users, categories, or internal links |
| Moving an entire production site | Full migration or host backup workflow | XML export does not replace files, database, plugins, themes, or settings |
| Testing a redesign with sample content | Export a small set of posts, pages, and media references | Test content can be mistaken for a verified migration |
| Rebuilding a small content site | Export/import plus backup, permalink, media, and redirect review | Old URLs, authors, and attachments can drift |
| Recovering from a failed site change | Restore from backup first | Importing content can duplicate posts instead of restoring state |
Who Should Use This Checklist?
Use this checklist when a WordPress publisher, editor, site operator, freelancer, or small content team needs to move posts, pages, comments, categories, tags, custom taxonomies, or custom post types between WordPress installs without turning the task into an undocumented migration.
This is site-operations guidance, not a managed-hosting migration service, legal records policy, privacy request workflow, disaster-recovery guarantee, affiliate recommendation, or claim that any private WordPress dashboard was tested. The guidance is source-derived operator analysis from public WordPress and Google documentation.
Step 1: Define What The Export Is For
WordPress Tools Export creates a WordPress eXtended RSS file, commonly called a WXR file. WordPress documentation describes it as a way to export site content such as posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users. That makes it useful, but it also defines the boundary: it is not a complete clone of a WordPress installation.
Before exporting, choose one purpose:
- [ ] Move a small content set to a new WordPress site.
- [ ] Seed a staging or redesign environment with representative posts.
- [ ] Transfer a category, author archive, or custom post type to another install.
- [ ] Preserve a content snapshot before a cleanup project.
- [ ] Rebuild editorial content after a controlled site restructuring.
Do not use this workflow as the only recovery plan for a broken production site. If the goal is rollback, start with a full backup and restore workflow that covers both database and files.
Step 2: Back Up Before Touching Either Site
Official WordPress backup documentation separates database content from files. Export/import can change the destination database and may create duplicate posts, changed user assignments, changed media references, or different taxonomy structure. A backup is the recovery point if the import does not behave as expected.
Record this before starting:
| Evidence field | Why it matters |
|---|---|
| Source backup timestamp | Confirms the old site can be recovered if export work exposes a problem |
| Destination backup timestamp | Allows rollback if the import creates duplicates or wrong assignments |
| File backup status | Media, themes, plugins, and uploads are not replaced by a content XML file alone |
| Database backup status | Posts, terms, comments, options, users, and many plugin settings live in the database |
| Restore owner | Someone must know how the backup becomes a working site again |
Keep backup locations, credentials, database names, and server paths out of the public article or public checklist. They belong in the private operations runbook.
Step 3: Choose The Smallest Useful Export Scope
The Tools Export screen can export all content or a selected content type. A smaller export is easier to verify because the operator can predict which records should appear after import.
Use this scope table:
| Export scope | Use this when | Review after import |
|---|---|---|
| All content | Rebuilding a small site or moving a full editorial archive | Posts, pages, menus, categories, tags, comments, authors, and media references |
| Posts | Moving an article set, category, date range, or author set | Slugs, categories, tags, authors, comments, featured images, and internal links |
| Pages | Moving static pages or editorial landing pages | Parent pages, templates, slugs, menus, and embedded media |
| Custom post types | Moving a plugin or theme-supported content type | Plugin availability, fields, templates, archives, and rewrite behavior |
| Media | Moving attachment records or reviewing media references | File availability, attachment titles, alt text, and URL paths |
If the source site has heavy custom fields, page-builder content, custom taxonomies, or plugin-owned records, record that dependency before the export. The import can move content records, but the destination site still needs compatible plugins, theme support, and settings to render that content correctly.
Step 4: Inventory Users, Taxonomies, And URLs
Imports become messy when the operator only checks post titles. Build a small inventory before exporting:
- [ ] Author names and expected user mapping.
- [ ] Categories and tags that should exist on the destination.
- [ ] Custom post types and custom taxonomies in scope.
- [ ] Published, draft, private, scheduled, and pending post counts.
- [ ] Featured image expectations for sampled posts.
- [ ] Comment import expectations if comments matter.
- [ ] Internal links that point to old slugs or old hosts.
- [ ] Public URLs that need redirect or canonical review.
This inventory does not need to be fancy. A spreadsheet with expected counts and a few sample URLs is enough for a small site. The point is to know what success looks like before clicking Import.
Step 5: Prepare The Destination Site
The Tools Import screen lists importers for WordPress and other systems. For a WordPress-to-WordPress content move, the destination needs the WordPress importer path available, enough upload capacity for the file, and the relevant theme or plugin features in place before content is reviewed.
Before import:
- [ ] Confirm the destination site is backed up.
- [ ] Confirm the destination has the needed content types, taxonomies, and plugins.
- [ ] Confirm media upload settings and file handling are suitable for the imported content.
- [ ] Confirm the expected users exist or decide how imported authors should be mapped.
- [ ] Confirm whether attachments should be downloaded during import.
- [ ] Confirm staging is preferred when the destination is already public.
- [ ] Confirm caches, sitemaps, and feeds will be reviewed after import.
If the destination is a live public site, run the first import in staging when the content set is large, old, media-heavy, or tied to custom post types. A direct live import is harder to undo cleanly.
Step 6: Import With A Written Mapping Plan
During import, the operator may need to assign imported content to existing users or create users. This is a content ownership decision, not just a technical prompt.
Use this mapping plan:
| Import decision | Safer operator default |
|---|---|
| Existing author has an account | Map imported posts to that account |
| Former author should not log in | Map content to an editorial owner and record the display-name decision |
| Guest or legacy content | Use a controlled author profile, not a personal account created casually |
| Media download option | Use it only when the destination can reach the source files and the result will be verified |
| Duplicate title or slug | Stop and decide whether to merge, skip, redirect, or rename |
Do not assume the import is complete just because the success screen appears. Treat the screen as the end of transfer, then run the review checklist.
Step 7: Verify Representative Content
After import, review examples from every meaningful content group. A small sample catches many problems before the operator changes menus, sitemaps, or redirects.
Minimum review checklist:
- [ ] One recently published post renders with title, body, date, author, categories, tags, featured image, and internal links.
- [ ] One old post renders without broken shortcodes, missing embeds, or unexpected formatting.
- [ ] One page renders with the expected hierarchy, slug, template, and navigation placement.
- [ ] One media-heavy article has images, captions, alt text, attachment pages, and galleries checked.
- [ ] One comment-enabled article has expected comments and moderation status.
- [ ] One custom post type item has the correct archive, template, and fields.
- [ ] One draft or scheduled post keeps the expected editorial status.
- [ ] One source URL and destination URL pair has redirect or canonical handling documented.
If a sample fails, pause before importing more files. A failed sample usually means the destination lacks a dependency, the source file was too broad, media could not be fetched, or URL mapping needs a redirect plan.
Step 8: Separate Content Transfer From Site Migration
Google site-move guidance treats URL changes, redirects, sitemap updates, and monitoring as migration work. WordPress export/import can be part of a migration, but it does not finish the migration by itself.
Use this separation:
| Workstream | Belongs in export/import? | Belongs in migration follow-up? |
|---|---|---|
| Moving post bodies | Yes | Verify rendered pages |
| Moving media references | Sometimes | Verify files and public URLs |
| Changing domain or permalink structure | No | Redirect, canonical, sitemap, and Search Console checks |
| Changing theme or templates | No | Visual review and template audit |
| Changing plugins | No | Plugin compatibility and settings review |
| Changing HTTPS or host variants | No | HTTPS migration and canonical host review |
If URLs change, connect this checklist to the redirect, HTTPS migration, sitemap, and Search Console workflows. If URLs do not change, still review canonical URLs and internal links because imported content can preserve old absolute links.
Step 9: Clean Up Duplicates And Orphans
Imports can create duplicate posts, unused categories, duplicated media, or old author records. Cleanup should happen after the operator understands what was imported, not during the import itself.
Post-import cleanup:
- [ ] Compare expected and actual counts for imported content types.
- [ ] Check duplicate titles and duplicate slugs.
- [ ] Review uncategorized posts and unexpected tags.
- [ ] Check media items without attached posts.
- [ ] Review broken internal links and old-host links.
- [ ] Confirm menus do not point to old or duplicate pages.
- [ ] Recheck feeds and sitemaps after the content settles.
- [ ] Record what was deleted, redirected, merged, or left alone.
Avoid deleting imported content blindly. If the source and destination both contain similar posts, decide which URL is canonical and whether the old version needs a redirect, noindex decision, or archive note.
What Should A WordPress Export Import Checklist Include?
It should include export purpose, source and destination backups, export scope, user mapping, taxonomy inventory, custom post type dependencies, media assumptions, upload limits, staging preference, representative content review, duplicate cleanup, URL migration notes, sitemap review, cache review, owner, date, and rollback path. The key rule is that a WXR export moves content records; it does not replace a full backup, theme migration, plugin configuration, or redirect plan.
When Is WordPress Export Import Better Than A Full Migration?
Export/import is better when the operator needs to move selected posts, pages, comments, categories, tags, or custom post types into another WordPress install. A full migration is better when the goal is to clone the whole site, preserve plugin settings, move uploads reliably, keep theme files, restore after a failure, or change hosting with minimal reconstruction.
Does WordPress Export Include Media Files?
Treat media as a separate verification item. WordPress export can include media records and the import flow may attempt to bring attachments across, but the operator still needs to verify that files are reachable, image URLs render, featured images are assigned, captions and alt text survived, and old-host links are not left in the article body.
Should Operators Import Directly Into Production?
Use staging first when the import is large, media-heavy, tied to custom post types, connected to URL changes, or entering a site that already has public content. A small, clearly scoped import can be reasonable in production only after backups, user mapping, expected counts, and rollback ownership are recorded.
What Should Stay Out Of This Workflow?
Do not include database credentials, backup archive paths, private upload URLs, user emails, unpublished customer data, personal data export requests, host control-panel screenshots, paid migration reports, private staging credentials, AdSense account settings, Search Console ownership changes, Bing verification data, or claims that a live migration was tested without evidence.
Source Notes
- https://wordpress.org/documentation/article/tools-export-screen/ checked 2026-06-11; used for source-derived analysis of WordPress WXR exports, export scope, and content types included in export files.
- https://wordpress.org/documentation/article/tools-import-screen/ checked 2026-06-11; used for source-derived analysis of WordPress import choices and importer workflow boundaries.
- https://developer.wordpress.org/advanced-administration/security/backup/ checked 2026-06-11; used for source-derived analysis of why export/import does not replace a full database and file backup.
- https://wordpress.org/documentation/article/media-settings-screen/ checked 2026-06-11; used for source-derived analysis of media upload assumptions and why attachment handling should be verified after import.
- https://wordpress.org/documentation/article/site-health-screen/ checked 2026-06-11; used for source-derived analysis of destination environment details, upload constraints, directories, plugins, themes, server, database, and filesystem facts operators may review.
- https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes checked 2026-06-11; used for source-derived analysis of why URL changes, redirects, sitemap updates, and monitoring belong to migration follow-up rather than the XML import alone.
No private WordPress dashboard, source site, destination site, staging environment, export file, importer run, backup archive, media library, host panel, Search Console property, Bing Webmaster Tools account, AdSense account, server log, or production URL test is claimed here. If a future operator adds screenshots, sanitized import logs, sampled URL checks, WXR file metadata, media-diff evidence, redirect traces, or Site Health exports, attach those artifacts internally and narrow public claims to match the verified environment.
Internal Link Notes
Link to wordpress-backup-restore-checklist before any import into a site that matters. Link to wordpress-staging-site-checklist when the destination should be checked before production. Link to wordpress-media-library-cleanup-checklist when attachments, alt text, or duplicate media need cleanup. Link to wordpress-redirect-checklist-for-slug-changes and wordpress-https-migration-checklist when old URLs, host changes, or permalink changes are involved. Link to wordpress-site-health-review-checklist when upload limits, filesystem permissions, server details, or plugin dependencies may affect the import.
Update Note
Review this checklist every 90 days. Recheck official WordPress Tools Export, Tools Import, backup, media settings, and Site Health documentation, plus Google site-move guidance. Refresh earlier after a WordPress importer change, media handling change, hosting migration, permalink change, custom post type change, plugin-stack change, failed import, duplicate-content cleanup, or production URL migration.