Use a scoped content transfer for editorial merging, with a protected trial, destination backup and complete reconciliation. Use a full migration workflow when the whole site must move.

Use WordPress’s export and import tools when you want to transfer editorial content into another WordPress installation. Treat the XML file as a content package, then verify authors, categories, publication status, links and media separately. It is not a complete backup or a promise that the new site will look and behave like the old one.
This guide uses official WordPress documentation and importer source code checked on 13 October 2026. It describes a cautious workflow rather than a migration we have performed on your installation. Themes, plugins, custom content types and host limits can change what needs additional work.
Choose content transfer or a complete site move
Start by deciding what should survive. Moving a collection of articles into an established publication is different from moving an entire functioning website to another host.
| Your goal | Appropriate starting point | What needs separate attention |
|---|---|---|
| Bring selected articles into an existing site | A deliberately filtered content export and a trial import | Authorship, taxonomy overlap, media and old links |
| Move the whole website without rebuilding it | A full migration and verified recovery plan | Files, database, configuration, domain routing and services |
| Keep an emergency recovery copy | A restorable backup set | Recovery access, retention and a restore check |
WordPress’s exporter reference explicitly distinguishes its content-transfer file from a complete site backup. The backup handbook explains why a typical full restore needs both database and files. An XML export does not carry your plugin code, theme files, server configuration or the actual bytes of every uploaded image.
For a complete move, follow our WordPress hosting-migration guide. Do not dismantle the old installation after seeing a successful content-import message.
Write down the transfer boundary
Make a short inventory before exporting: which articles, which dates or authors, whether comments belong in the transfer and whether unpublished work should be included. Record a few representative source URLs and the expected number of items in each selected group.
Suppose a fictional gardening publication is merging its composting section into an existing magazine. It needs those articles and their illustrations, not the source site’s contact page, abandoned drafts or unrelated contributor accounts. A boundary written in those terms is easier to verify than “copy everything and tidy it later.”
Keep the export private. It can contain unpublished text, author information, comments and custom-field values. A file prepared for import is not automatically safe to put in a public downloads folder or send to an unrelated service.
Back up the destination before changing it. If it already receives orders, submissions or edits, plan how recovery would preserve that newer activity. Restoring the entire database later could undo legitimate changes made after the backup.
Export with filters you can explain
On the source installation, open Tools → Export. The official Export screen guide describes All content and the filters available for posts and pages, including author, date and status. Select the scope that matches the inventory and download the export file.
All content is broader than the articles visible on the homepage. A filtered export is narrower, so check that it contains the intended records rather than assuming a category or date selection means “everything this article needs.” Preserve the original export unchanged and name the file so you can identify its source, date and scope.
If the package seems unexpectedly small or an expected article is absent, recheck its actual content type, status, author, category and publication date against the chosen filters. Do not run an import just to discover whether the selection was right.
For the fictional merger, list a recent composting article, an older one and one with several images. Those become deliberate acceptance examples; they are not a substitute for reconciling the complete inventory.
Prepare a destination that can represent the content
Use a protected test copy before importing into a public site. Confirm its site identity and database so a trial cannot accidentally modify another publication. Decide who is authorized to review private drafts and exported comments.
A custom recipe, portfolio or other content type needs its corresponding registered type and supporting functionality at the destination. The WordPress Importer listing describes the content it handles, but importing records does not install the plugin or theme that makes a specialist feature work.
Check the current importer requirements and compatibility information against the destination’s WordPress and PHP versions. Follow Tools → Import → WordPress to install or run the appropriate importer, as documented on the Import screen. Avoid adding several competing import tools while diagnosing the first attempt.
Keep a destination record with the existing article, media and term counts, the backup reference and the intended author mapping. It gives you a baseline if the process stops halfway through.
Map authors deliberately
The import handbook describes mapping exported authors to existing destination users or creating new users. Choose the author for each contributor instead of accepting an accidental catch-all assignment.
For the fictional magazine, an existing contributor account may be the right destination for that person’s older work. A shared editorial account might be appropriate only when the publication has a truthful attribution policy. Do not attribute someone else’s article to the importing administrator merely because that is convenient.
Content attribution and permission to sign in are separate decisions. Review any newly created account’s access through the destination’s normal user-management process; do not assume an imported byline transfers passwords or recreates the source site’s permissions.
After importing, open representative articles and their author archives. Check both the public byline and the account selected in the editor. A correct-looking title does not prove the author mapping was correct.
Handle media as a separate transfer and verification task
The attachment-download option asks the importer to retrieve files described by attachment records; the XML itself is not a self-contained folder of images. Keep the source files reachable through an authorized transfer route while the import runs. Authentication barriers, missing files or host limits can prevent retrieval.
Do not publish private uploads or remove access controls broadly to make an importer work. If the source is restricted, arrange a supported transfer method with the responsible administrator. Never put credentials into image URLs or a shared export.
Distinguish three questions: was the attachment record included, did the destination retrieve the file, and does the imported article now use the intended destination URL? WordPress can include attachment references in exports, but coverage and URL rewriting depend on the content and tool version. A successful post count does not settle those questions.
Inspect a featured image, an inline image, a gallery or background if used, and a linked document. Open their actual file addresses. A picture can appear because the new article still requests the old host; that is a remaining dependency, not proof that the media moved.
Maintain an exception list with the source article, old asset URL, intended destination and specific failure. Repair those references through a supported process. Avoid an unreviewed database-wide replacement that could alter unrelated links or structured data.
Check publication status before the public site sees it
The official importer code carries source status and date fields into post creation. Do not assume an import turns every item into a draft. Published source articles can become publicly visible on an unprotected destination.
Review draft, private, password-protected and scheduled examples where they are part of the agreed scope. Check the saved status and dates in the post settings sidebar, then check the public result without editor privileges where appropriate.
Keep unpublished material out of public archives, feeds and navigation. If the transfer needs a different publication plan, prepare it explicitly; do not improvise status changes across an unknown batch on the live site.
Review categories, links and presentation
Reconcile source terms with the destination’s existing structure. Two sections with similar labels may represent the same editorial topic or different ones. Review their slugs, hierarchy and actual assignments before merging anything. Our categories and tags guide explains that decision.
Test old internal links inside imported articles and links from menus or resource lists. An imported article can have a new address even when its text is intact. Check any custom blocks with their required functionality available, and compare a representative table, caption and downloadable resource.
If the destination is a network, confirm which individual site receives the content. The Multisite and separate-installations guide explains those boundaries. Shared administration is not permission to import into every site.
Recover from a partial import without blind retries
WordPress’s import handbook warns that an unsuccessful import may still create content and a retry may create duplicate data. Save the result messages, identify what exists and resolve the actual error before choosing the next attempt.
The importer has existing-post matching, but that is not a general guarantee that repeated imports merge all fields, repair every attachment or update an existing article. Do not use reimporting as an ordinary synchronization workflow.
For a failed trial, restoring the isolated destination baseline can be clearer than guessing which partial records to remove. For an active publication, recovery requires a narrower plan that preserves unrelated new activity. Do not bulk-delete content based only on a similar title.
- Reconcile the intended inventory against destination items and recorded exceptions.
- Confirm authors, terms, dates and visibility.
- Verify media is retrievable from its intended long-term location.
- Follow internal links and inspect representative public layouts.
- Keep the source and recovery materials until the transfer has been reviewed and accepted.
A reliable transfer is one you can account for: the right content arrived, its permissions and attribution remain appropriate, and its files and links survive independently of the old installation. The final import message is one piece of that evidence.
Sources and verification
Editorial review 2026-10-13. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- WordPress: exporter referenceChecked WXR content-transfer scope, explicit not-complete-backup warning and attachment-reference handling in current exporter source.
Limits: No export generated or exact attachment coverage guaranteed. Historical forum claims excluding all unattached media are not generalized to current core. - WordPress: backups handbookChecked Typical full-site recovery requires database and files; content XML is distinct from a complete recovery set.
Limits: No backup or restore performed, fixed cadence prescribed or shared-host database operation recommended. - WordPress: Tools Export screenChecked Native export workflow, All content and available post/page author, date and status filters.
Limits: Selected filters must be reconciled against actual records. No implication that a filter captures every external asset or configuration dependency. - WordPress: official importer listingChecked Supported record types, attachment-fetch controls, installation route and published compatibility information.
Limits: Community reviews are not evidence for guaranteed success. Current compatibility must be checked; importing records does not install supporting plugins or prove full-site reproduction. - WordPress: Tools Import screenChecked Tools Import WordPress content-file workflow distinct from importers for other systems.
Limits: No tool installed, unrelated importer selected or external content transfer performed. - WordPress: importing content handbookChecked WXR selection, author mapping, attachment-download option and explicit warning that a failed import may leave records and retries may duplicate data.
Limits: No universal import idempotency, automatic merge, complete media retrieval or instruction to edit XML blindly claimed. - WordPress: official importer sourceChecked Source status/date fields carried into insertion and existing-post matching that is narrower than guaranteed complete synchronization.
Limits: Moving repository branch is a checked-date implementation reference, not a guarantee for every installed version or extension. No code executed or repeated import performed. - WordPress: post settings sidebarChecked Status, visibility, publication-date and author-facing editorial review context.
Limits: Version/editor UI can vary. No claim that visibility protects every linked upload or that checking one example verifies the full batch.