How to Migrate a WordPress Site Without Losing SEO

Search engines don’t punish you for moving a website. They punish what often goes wrong during the move: pages that vanish, redirects that point nowhere, and a staging setting that tells Google to stay away. If you prevent those three things, a migration can pass with only minor, short-lived movement in your traffic.

Short answer: to migrate WordPress without losing SEO, record every existing URL first, rebuild on a private staging copy, redirect each old URL with a 301 to its closest new equivalent, confirm the new site is indexable, then watch Google Search Console closely for several weeks after launch.

What counts as a migration, and how risky is each type?

The same discipline applies everywhere, but the amount of risk depends on what changes.

The migration process

1. InventoryRecord what exists before touching anything.
2. StagingBuild and test privately.
3. URL mapGive every old URL a destination.
4. RedirectsImplement and test the 301s.
5. Launch & monitorCut over, verify, then watch.

Step 1: Inventory the old site before changing anything

This is the step most often skipped and the one that causes the most regret. You are building the reference you’ll compare against later.

• Crawl the site with a tool such as Screaming Frog or Sitebulb and export every URL, with status code, title, meta description, canonical and H1.
• Save a copy of the current XML sitemap.
• Export Google Search Console performance data so you know which pages earn clicks and impressions.
• Note existing redirects (in .htaccess, server config or a plugin). They must be carried over.
• Record top backlinked pages if you have access to a backlink tool. These are the URLs you can least afford to break.

Step 2: Build the new environment on staging

Set up the new site on a password-protected staging URL or a local environment, never on a live, crawlable domain. Most managed hosts offer one-click staging.

When you move the database, any hard-coded old URLs inside content, widgets and theme options need updating. Use WP-CLI’s search-replace or a tool that handles serialized data safely. A plain find-and-replace in the database can corrupt serialized settings.

Step 3: Map every old URL to a new one

Create a spreadsheet with the old URL in one column and its destination in the next. Use your crawl from Step 1 as the source list.

• Same page, new address: point it to the matching new URL.
• Merged or rewritten content: point it to the closest relevant page.
• Intentionally removed: let it return a 410 (or 404) rather than redirecting it to something unrelated.

If URLs aren’t changing, this list still matters: it becomes your checklist for post-launch testing.

Step 4: Set up 301 redirects correctly

A 301 redirect is a permanent redirect. It tells browsers and search engines that a page has moved for good and lets the new URL inherit the old one’s signals.

• Match intent, not just location. Redirecting thousands of unrelated pages to the homepage is treated as a soft 404 by search engines and wastes the value of the old pages.
• Avoid chains. Send A straight to C, not A to B to C.
• Use server-level redirects (Apache, Nginx, or your host’s redirect tool) or a well-maintained redirect plugin, not JavaScript redirects.
• Keep them in place. Google’s site-move guidance suggests keeping redirects for at least a year, and longer if the old URLs still receive links.
• Update internal links to point to final URLs so the site doesn’t depend on redirects internally.

For a domain change, also keep the old domain registered and use Search Console’s Change of Address tool once the redirects are live. It applies to domain-level moves, not to HTTPS or path changes.

Step 5: Carry over on-page SEO elements

Compare titles, meta descriptions, headings, canonical tags, image alt text, structured data, hreflang (if used) and internal links against your crawl. Theme or page-builder changes are the usual cause of silently dropped metadata, so check an SEO plugin’s settings were imported, not just the content.

Step 6: Confirm the new site can be indexed

A staging site is usually blocked from search engines, and that block often travels with the database or files. Before launch, check:

• Settings → Reading: “Discourage search engines from indexing this site” is unticked.
• robots.txt does not contain a blanket Disallow: /.
• No site-wide noindex meta tag or X-Robots-Tag header.
• Canonical tags point to the live URLs, not staging.
• A fresh XML sitemap lists only live, indexable URLs.

Step 7: Launch and verify straight away

Pick a lower-traffic window and keep the people who can fix problems available. Immediately after cutover:

• Re-crawl the live site and test your redirect list. Every old URL should return a single 301 to the right destination, ending in a 200.
• Confirm HTTPS works across the site with no mixed-content warnings.
• Submit the new sitemap in Google Search Console and Bing Webmaster Tools.
• Use URL Inspection on your most important pages.
• Check forms, checkout and tracking tags. Conversions can break without affecting rankings.

Step 8: Monitor for the next several weeks

Some movement in impressions and rankings is normal while search engines reprocess your URLs. If you want ongoing help interpreting the data, our SEO services cover technical monitoring. You’re looking for a sustained decline, not day-to-day noise.

• Review the Page indexing and Performance reports in Search Console weekly.
• Watch for new “Not found (404)” entries, which usually point to gaps in your URL map.
• Compare clicks and rankings for your top pages against the baseline you saved in Step 1.

If a drop persists, the usual causes are missing redirects, a noindexed template, a robots.txt block, or content that changed substantially during the move.

Common migration mistakes

• Starting without a full URL inventory.
• Redirecting everything to the homepage.
• Launching with staging’s “noindex” or robots.txt block still active.
• Leaving internal links pointing at old URLs.
• Changing design, content and URLs in the same release, so no one can tell what caused a drop.
• Never testing redirects before launch.