How to Migrate WordPress to Another WordPress Site

Moving a WordPress site to another WordPress install is one of the most common jobs on the platform, and one of the easiest to get wrong. You switch hosts, change domains, promote a staging build, or merge two sites, and somewhere along the way the custom fields don’t arrive, the images 404, or the rankings slip because URLs changed with no redirects.

It doesn’t have to be that way. A WordPress → WordPress migration can be boring: everything arrives, nothing breaks. This guide walks the order of operations that protects your content, custom post types, media, and SEO, and shows you when to clone the whole site versus move just the content.

When you actually need a WP-to-WP migration

“Migrating WordPress” covers a few very different jobs, and the right method depends on which one you’re doing:

• New host, same site: you’re changing hosting but keeping the exact site, theme, plugins, and database.
• New domain: the content stays but the URLs change, so redirects become the whole game.
• Clean rebuild: you want the content on a fresh install with a new theme or builder, and you deliberately want to leave the old plugin baggage behind.
• Merging or splitting sites: pulling posts and custom post types out of one site and into another.

The first is a clone job. The rest are content-migration jobs, and that’s where WordPress’s own tools start to let you down.

Three ways to move, and their trade-offs

1. Full-site clone (whole database + files)

Tools like Duplicator or All-in-One WP Migration package your entire database and wp-content into an archive you restore on the new host. This is the right choice for “same site, new host”, it brings everything, including theme, plugins, users, and settings. The downsides: it also brings every bit of accumulated bloat, it’s all-or-nothing (no picking which content moves), and big sites hit upload or memory limits mid-restore.

2. WXR content export/import (WordPress’s native format)

WordPress’s built-in exporter produces a WXR file, an XML document the destination’s importer reads. This is the right tool for moving content into a different or clean install: posts, pages, custom post types, and taxonomies come across without dragging the old theme and plugin stack with them. It’s selective and portable, but, as we’ll see, stock WXR drops several things you probably care about.

3. Manual copy or raw SQL

Copy-pasting posts or hand-editing the database directly is how migrations go wrong. You lose relationships between posts, authors, and taxonomies; you miss custom fields entirely; and one bad UPDATE can take the site down. Unless you’re moving three pages, don’t.

What WXR carries, and what it drops

WXR (WordPress eXtended RSS) is the format behind Tools → Export. The native importer reads it and recreates posts, pages, custom post types, taxonomies, comments, and authors. That sounds complete, but a stock WXR export has real gaps:

• Builder content comes out raw. If your pages are built with Elementor, WPBakery, Divi, Bricks, or Oxygen, the exported content:encoded is a block of shortcodes and builder markup, not the rendered page. Import it into an install without that exact builder and you get an empty page.
• Media is referenced, not included. WXR stores image URLs. The importer can try to download them, but for large or externally-hosted libraries that step routinely fails or times out.
• Custom fields are hit-or-miss. ACF / JetEngine / Pods values live in postmeta, and only travel if the export includes them.
• SEO meta may not survive. Yoast and Rank Math store their data as postmeta too, same story.

Here’s the shape of a single WXR item, so you can see where the important data actually lives:

<item>
  <title>Corneal Cross-Linking</title>
  <link>https://old-site.com/services/corneal-cross-linking/</link>
  <wp:post_type>services</wp:post_type>
  <content:encoded><![CDATA[ rendered HTML here, not shortcodes ]]></content:encoded>
  <wp:postmeta>
    <wp:meta_key>_yoast_wpseo_metadesc</wp:meta_key>
    <wp:meta_value><![CDATA[ A minimally invasive treatment… ]]></wp:meta_value>
  </wp:postmeta>
</item>

The lesson: whether a WP-to-WP move keeps your custom fields, SEO, and builder content comes down entirely to how the WXR was generated. A file that rendered each page first and included the postmeta imports cleanly; a raw dump doesn’t.

Prepare the destination first

A clean destination checklist:

• Match the permalink structure under Settings → Permalinks, so URLs line up (critical for SEO, more below).
• Install the page builder if you’re keeping builder-made layouts, or plan to import rendered content if you’re not.
• Recreate custom post types & taxonomies with identical slugs.
• Install your SEO plugin (Yoast / Rank Math) so the imported meta has somewhere to land.

Run the import cleanly

With the destination ready, the import itself is straightforward:

1. On the destination, go to Tools → Import → WordPress and install the importer if prompted.
2. Upload your WXR file.
3. Map authors: assign old authors to existing users or create new ones.
4. Tick “Download and import file attachments” if you’re relying on the importer for media (see the next section for why you might not).
5. If your export is large, split it into smaller WXR files, the importer chokes on very big uploads.

Bring the media across

The importer’s “download attachments” step is the flakiest part of a WP-to-WP move. It re-fetches every image from the old site one by one, and on large libraries or slow hosts it stalls, times out, or silently misses files, leaving you with broken images you discover weeks later. The reliable alternative is a media bundle: package every referenced file with the export and rewrite the URLs to the bundled copies, so nothing depends on the old server still being alive. That’s exactly what Migratik Pro’s one-click bundle does, splitting large libraries into parts automatically.

Preserve your URLs and SEO

SEO survives a migration when two things hold: the URLs stay the same, and the metadata comes with them.

• Keep the permalink structure identical. If a URL must change (a new domain, a restructured path) add a 301 redirect from old to new. On a domain move, redirect at the server or DNS level for the whole site, then fine-tune per-URL.
• Carry over titles and meta descriptions. These are what Google shows in results; losing them resets the snippet Google already trusts. Make sure your SEO postmeta is in the export.
• Re-submit your sitemap in Google Search Console after the move, and spot-check a few key URLs with the URL Inspection tool.

Moving off WordPress entirely instead of to another WordPress? The redirect-and-metadata playbook is the same, see our WordPress → Next.js and headless CMS guides.

Verify nothing was lost

Before you point DNS at the new site or delete the old one, confirm the move actually landed:

• Compare counts per content type, posts, pages, and each custom post type should match the source.
• Spot-check custom post types and fields: open a few items and confirm ACF/JetEngine values are present, not blank.
• Check images resolve: load a media-heavy page and watch for 404s in the network tab.
• Crawl for broken links with a tool like Screaming Frog to catch anything the import mangled.
• Confirm redirects if the domain changed, test a handful of old URLs and make sure they 301 to the right place.

Every one of these failure modes traces back to the export, not the import. Start from a complete, rendered WXR with custom fields, SEO meta, and bundled media, and the destination side is the easy part.

Frequently asked questions

What’s the best way to migrate WordPress to a new host?

For a same-site host move, a full-site clone with a tool like Duplicator or All-in-One WP Migration is simplest, it copies the database and files as-is. For moving content into a new or differently built install, use a WXR export and import so you bring only content and leave old plugin and theme bloat behind.

Does WordPress’s WXR export include images and custom fields?

WXR references image URLs and can tell the importer to side-load them, but large or externally hosted libraries often fail. Custom fields from ACF, JetEngine, or Pods live in postmeta and only come across if the exporter includes them, many don’t. Check before you rely on it.

Will migrating WordPress hurt my SEO?

Not if you keep your permalink structure and 301-redirect anything that changes (especially on a domain change), and carry over your SEO metadata. Rankings drop when URLs change without redirects or when titles and meta descriptions are lost in the move.

How do I move custom post types between WordPress sites?

Register the same custom post types and taxonomies on the destination first (via the same plugin, CPT UI, ACF, JetEngine), then import a WXR that includes them. If the types don’t exist on the destination, the importer discards those items.