WordPress Migration SEO Checklist: Move Your Site Without Losing Rankings

The way to migrate a WordPress site without losing search traffic is simple to state: keep every URL working, keep every page’s content and metadata the same, and tell Google clearly what moved. The work is in the details. This checklist covers what we do before, during and after a migration so rankings survive the move.

It applies to the common kinds of moves: a new host, a new domain, a switch from HTTP to HTTPS, a new theme or page builder, or a change in URL structure. Some steps only matter for some moves, and we point those out.

Why migrations lose traffic

Search engines rank URLs, not “your website” as a whole. When a URL changes or disappears, the signals attached to it (links from other sites, history, relevance) have to be passed to a new URL. If that handoff fails, the new page starts from scratch.

Most traffic losses after a migration come from a short list of mistakes:

• Old URLs return a 404 (page not found) error instead of redirecting.
• Redirects point everything to the homepage instead of the matching page.
• The staging site’s “discourage search engines” setting gets copied to production.
• Page titles, meta descriptions or structured data get lost when a theme or SEO plugin changes.
• Content is trimmed, merged or rewritten during the move, so the new page no longer matches what ranked.
• The new server is slower, so pages load worse than before.

Every item in the checklist below exists to prevent one of these.

Before the migration

1. Crawl the current site and save the results

Use a crawler to collect every URL on the live site, with its status code, title, meta description, canonical tag and main heading (H1). Save this as your baseline. Add URLs from your XML sitemap, from Google Search Console’s page indexing report, and from your analytics tool’s landing pages report. A crawler only finds pages that are linked, and older posts or campaign pages often are not.

2. Export performance data

From Google Search Console, export the top pages and queries for the last 3 to 12 months. From analytics, export landing pages by organic sessions. This tells you which URLs matter most and gives you numbers to compare against after launch.

3. Benchmark speed

Record Core Web Vitals and page load times for your main page types (home, a post, a product, a category). If the new setup is slower, you want to know before launch, not after. Our guide to Core Web Vitals on WordPress explains what to measure.

4. Build a URL map

If any URLs will change, create a spreadsheet with two columns: old URL and new URL. Every old URL needs one row. Map each page to its closest equivalent, not to the homepage. Google may treat a redirect to an unrelated page, such as the homepage, as if the page were simply gone.

If your URLs are not changing (for example, a pure host move), you can skip the map. You still need the crawl, so you can confirm nothing broke.

5. Clean up before you move

A migration is a good time to remove dead plugins, unused themes and junk data. Moving less means fewer things can break. Our article on how to clean up a bloated WordPress database covers the database side. Do not remove or merge content that gets search traffic as part of the same project, though. Change one thing at a time so you can tell what caused any shift in rankings.

6. Lower the DNS TTL

DNS records have a TTL setting that tells the internet how long to cache them. Google recommends lowering it at least a week before the move so the switch spreads faster. We cover this in detail in how to change WordPress hosts with zero downtime.

On the new site, before launch

7. Block crawling of staging, the right way

Your staging copy should not be indexed. Protect it with a password (HTTP authentication) rather than relying only on robots.txt or the “Discourage search engines” setting. Password protection keeps Google out completely, and it does not get copied to production by mistake.

8. Replace old URLs in the database

If the domain or path changes, every internal link, image path and setting that stores the old address must be updated. WordPress stores some of this as serialized PHP data, which breaks if you run a plain text find-and-replace in SQL. Use WP-CLI, which handles serialized data correctly. Run it with --dry-run first to see what would change:

wp search-replace 'https://old-example.com' 'https://new-example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old-example.com' 'https://new-example.com' --skip-columns=guid

We skip the guid column on purpose. The WordPress documentation on moving sites says GUIDs should never be changed, because feed readers use them to tell which posts are new. The full option list is in the WP-CLI search-replace reference.

9. Compare the new site against your baseline

Crawl the staging site and compare it to the crawl from step 1. For each important page, check:

• The title and meta description match.
• The H1 and main content match.
• The canonical tag points to the page’s own new URL.
• Structured data (schema) is still present and valid.
• Images load and keep their alt text.
• Internal links point to new URLs directly, not through redirects.
• Hreflang tags are updated if you run a multilingual site.

10. Check speed and accessibility

Run the same speed tests as in step 3. A migration should not make the site slower. If you changed themes, also spot-check accessibility. A new theme can introduce problems with headings, contrast or keyboard navigation that were not there before.

Launch day

11. Put 301 redirects in place

A 301 is a permanent redirect. It tells browsers and search engines that a page has moved for good. Google prefers server-side permanent redirects (301 or 308) for site moves.

For a domain change, redirect every old URL to its matching new URL, keeping the path. On Apache, a rule in the old domain’s .htaccess file might look like this:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-example\.com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

For individual URL changes from your map, add one rule per row, or use a redirect plugin if you prefer managing them in the dashboard. Avoid redirect chains, where URL A redirects to B and B redirects to C. Google can follow several hops, but its site move guide recommends sending users straight to the final URL.

12. Remove crawl blocks on production

Check right away that:

• Settings > Reading > “Discourage search engines from indexing this site” is unchecked.
• robots.txt does not contain Disallow: / for all user agents.
• No pages carry a stray noindex tag.

These settings are easy to miss, and any one of them can keep your new site out of search results.

13. Verify Search Console and submit sitemaps

Make sure the new site is verified in Google Search Console. If you verify with an HTML file, copy that file to the new server. Submit the new XML sitemap so Google can find your new URLs quickly. At first the sitemap may show few indexed pages. That number should climb as Google processes the redirects.

14. Use the Change of Address tool (domain moves only)

If you moved to a new domain or subdomain, use the Change of Address tool in Search Console. You must be a verified owner of both properties, and the old homepage must 301 redirect to the new one. According to Google’s Change of Address documentation, the move notice and signal forwarding last 180 days.

Do not use this tool for an HTTP to HTTPS switch, a www to non-www change, a path change on the same domain, or a host change where the URLs stay the same. Google handles those through redirects alone.

After launch

15. Test every redirect

Take the old URL list from your crawl and request each one. Every URL should return a single 301 to the correct new page, which then returns a 200 (OK). A short script or a crawler in “list mode” can check thousands of URLs in minutes.

16. Watch Search Console daily for two weeks

Look at the page indexing report for spikes in “Not found (404)”, “Redirect error” or “Blocked by robots.txt”. Check the crawl stats report too. Google notes that crawl rate often drops briefly after a move and then recovers over the following days.

17. Compare rankings and traffic with your baseline

Some movement is normal. Google says that for medium-sized sites it can take a few weeks or more for new URLs to replace old ones in results. Compare against the exports from step 2, page by page. If a specific page lost traffic, check its redirect, content and metadata first. Those three explain most cases.

18. Keep the old domain and redirects

Google’s guidance is to keep redirects “for as long as possible, generally at least 1 year.” We recommend keeping them, and renewing the old domain, permanently. Other websites will link to your old URLs for years, and letting the domain expire means losing those visitors and links.

Quick reference checklist

Special cases

Some migrations need extra planning. Moving a WordPress multisite network, or splitting one site out of a network, involves shared tables and per-site domains. We cover that in our guide to WordPress multisite migration. If the migration also involves a PHP upgrade, do it as a separate step. Our guide on how to upgrade the PHP version on WordPress explains why.

Get help with your migration

We have moved sites of every size, including large multisite networks and sites with years of custom code. We test migrations in automated environments before launch, so we catch broken pages and missing redirects before Google does. If you are planning a move, see our WordPress migration service or contact us to talk through your project.