WordPress SEO Migration Checklist: How to Move Without Losing Rankings

Every WordPress migration carries some level of SEO risk. A host-to-host move with the same domain is low risk. A full domain change with URL restructuring is high risk. The difference between losing rankings and preserving them comes down to preparation, execution, and monitoring.

This guide covers the SEO implications of every type of WordPress migration, gives you a checklist for each scenario, and walks you through the exact steps to protect your search visibility before, during, and after the move.

The Six Types of WordPress Migration (Ranked by SEO Risk)

Not all migrations are equal. Here is every common migration scenario, ranked from lowest to highest SEO risk:

The rest of this guide is organized around these scenarios. Start with the pre-migration audit (required for all scenarios), then follow the checklist for your specific migration type.

Pre-Migration SEO Audit

Regardless of which migration type you are performing, complete this audit before changing anything. This gives you a baseline to compare against after the migration.

Record Your Current Rankings

Document your current search performance so you can detect problems after migration:

1. Google Search Console: Export your Performance report for the last 3 months. Save the data by query (keywords), page, country, and device. This is your ranking baseline.

2. Google Analytics: Export organic traffic data for the last 3 months. Note your top landing pages, bounce rates, and conversion rates from organic search.

3. Crawl your site: Use Screaming Frog, Sitebulb, or a similar crawler to create a complete inventory of every URL on your site. Export the full URL list, status codes, meta titles, meta descriptions, canonical tags, and internal links. This becomes your redirect map if URLs are changing.

4. Core Web Vitals: Record your current CWV scores from Google PageSpeed Insights or the CWV report in Search Console. Migration to a new host can improve or degrade these metrics, and CWV directly affects rankings.

5. Backlink profile: Export your backlink data from Google Search Console (Links report) or a tool like Ahrefs or Semrush. Know which external sites link to you and which pages receive the most backlinks. These pages need priority attention during migration.

Inventory Your SEO Configuration

Document everything that affects your search presence:

• SEO plugin settings: If you use Yoast, Rank Math, or AIOSEO, export your plugin settings. Most SEO plugins have an export/import feature. Custom meta titles, descriptions, and robots directives are stored in the database and will transfer with a full migration, but plugin-level settings (sitemap configuration, social defaults, schema templates) are worth documenting separately.

• Robots.txt: Save a copy of your current robots.txt file. After migration, verify it matches. A common mistake is carrying over a staging site’s Disallow: / rule that blocks all search engines.

• XML sitemap: Download your current sitemap. After migration, you will resubmit a new one, but having the old version lets you verify that all URLs are accounted for.

• Structured data / schema markup: Test your key pages with Google’s Rich Results Test. Note which pages have structured data and what types (Article, Product, FAQ, HowTo, etc.). After migration, verify that schema markup is intact and valid.

• Canonical tags: Check that your key pages have correct canonical tags. Record any pages with cross-domain canonicals or non-self-referencing canonicals, as these need special attention during migration.

• .htaccess rules: Save your current .htaccess file. It may contain redirects, security rules, or custom rewrite rules that affect SEO.

• Hreflang tags: If your site serves multiple languages or regions, document all hreflang annotations. These are frequently broken during migration.

Create a URL Map

If your migration involves any URL changes (domain change, permalink changes, HTTP to HTTPS, subdomain move), create a spreadsheet mapping every old URL to its new URL:

Prioritize pages that receive the most organic traffic and backlinks. These are the pages where a broken redirect will cost you the most.

For large sites, automate this with your crawl data. Export all URLs from Screaming Frog, apply the URL pattern changes, and generate the redirect list programmatically.

Pre-Migration Technical Preparation

Lower DNS TTL

If your migration involves a DNS change (new host, new domain), lower your DNS Time-to-Live to 300 seconds (5 minutes) at least 48 hours before the migration. This ensures that when you update DNS, the change propagates quickly and minimizes the window where some visitors hit the old server and others hit the new one.

For a full walkthrough of DNS preparation and the migration process itself, see our complete guide to migrating WordPress to a new host.

Set Up the New Environment Without Indexing

When you set up WordPress on the new server for testing, make sure search engines cannot index it:

• Use a temporary URL or subdomain for testing (not the final domain)
• Or add noindex directives, but remove them before going live (forgetting this is one of the most common SEO migration disasters)
• Or use the hosts file trick to test the new server on the final domain without changing public DNS (the safest approach, covered in our migration guide)

Back Up Everything

Create a full backup of your current site: database, files, and your .htaccess / Nginx configuration. If the migration goes wrong, you need to be able to restore the original site quickly.

All-in-One WP Migration creates a single .wpress archive containing your complete site that you can restore at any time.

Scenario-Specific Checklists

1. Host-to-Host Migration (Same Domain)

This is the lowest-risk migration. Your domain, URLs, and content stay the same. You are just moving to a new server.

SEO-specific steps:

• Verify PHP version on new host matches or exceeds old host (performance affects CWV)
• Migrate using All-in-One WP Migration or another full-site migration method
• Test the site on the new server before switching DNS (hosts file trick)
• Verify SSL certificate is installed and working on the new host
• Switch DNS and monitor for crawl errors in GSC
• Purge any CDN caches after DNS propagation completes
• Run a post-migration crawl and compare URLs against your pre-migration crawl
• Monitor GSC Performance report for 2 weeks

What can go wrong: Temporary crawl errors during DNS propagation. Google may encounter timeouts or 5xx errors if it crawls during the transition. These typically resolve within days once DNS fully propagates.

2. HTTP to HTTPS Migration

Google has used HTTPS as a ranking signal since 2014. If you have not migrated yet, you should, as over 98% of Google search results are now HTTPS.

SEO-specific steps:

• Install SSL certificate on your server
• Update WordPress Address and Site Address to HTTPS (Settings > General)
• Run database search-replace to update all internal URLs from http:// to https://
• Add a 301 redirect from HTTP to HTTPS in .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

• Fix mixed content (HTTP resources loaded on HTTPS pages). Check browser console for warnings.
• Update canonical tags to use https://
• Update your XML sitemap URLs to https://
• Add the HTTPS version as a new property in Google Search Console
• Resubmit your sitemap in the new HTTPS property
• If you have a disavow file, resubmit it to the HTTPS property (disavow files are property-specific)
• Update external profiles (social media, business directories) to use HTTPS URLs
• Monitor both HTTP and HTTPS properties in GSC for 4 weeks

For a detailed HTTPS migration walkthrough, see our guide on moving WordPress from HTTP to HTTPS.

What can go wrong: Mixed content warnings reduce trust signals. Forgetting to redirect HTTP to HTTPS creates duplicate content. Not updating the canonical tags means Google may still prefer the HTTP version.

3. Subdomain to Subfolder (or Reverse)

Moving from blog.example.com to example.com/blog/ (or the reverse) is more significant than it sounds. Google treats subdomains as partially separate entities from the root domain, so this migration affects how domain authority is distributed.

SEO-specific steps:

• Set up the new URL structure on the destination (subfolder or subdomain)
• Migrate the content using All-in-One WP Migration
• Create 301 redirects from every old subdomain URL to its new subfolder equivalent
• Run database search-replace to update all internal URLs
• Add the new URL structure as a property in Google Search Console
• Resubmit the sitemap
• Update canonical tags across all pages
• Monitor organic traffic for 3 months (this migration type has a longer recovery window)

What can go wrong: Redirect map errors. If your subdomain had different URL patterns than the main site, you need individual redirects, not just a blanket subdomain-to-subfolder rewrite. Internal links pointing to the old subdomain URLs create redirect chains if not updated in the database.

Long-term outlook: Despite Google’s official position that subdomains and subfolders are treated equally, real-world data consistently shows that consolidating content under a single domain (subfolder) tends to improve overall domain authority. Expect a short-term dip followed by long-term gains.

4. URL Structure / Permalink Changes

Changing your WordPress permalink structure (for example, from /?p=123 to /post-name/, or from /2024/01/post-name/ to /post-name/) means every post and page URL changes.

SEO-specific steps:

• Create a complete URL map (old URL to new URL) using your pre-migration crawl data
• Implement 301 redirects for every changed URL. For pattern-based changes, use regex redirects in .htaccess:

# Example: Remove date from URLs
# /2024/01/15/post-name/ -> /post-name/
RedirectMatch 301 ^/[0-9]{4}/[0-9]{2}/[0-9]{2}/(.*)$ /$1

• Update internal links in the database. Do not rely solely on redirects. Use WP-CLI:

wp search-replace '/2024/01/15/' '/' --precise --recurse-objects

• Change the permalink structure in Settings > Permalinks
• Resubmit your XML sitemap with the new URLs
• Test every redirect, especially for your highest-traffic pages
• Monitor for 404 errors in GSC for 8 weeks
• Do NOT change permalinks and domain at the same time. If you need to do both, change the domain first, wait at least 3-6 months for rankings to stabilize, then change the permalink structure

What can go wrong: Regex redirect errors can create redirect loops or send pages to the wrong destination. Forgetting to update internal links means visitors and crawlers follow redirect chains on every navigation. Category and tag archive URLs also change with permalink updates and are often missed.

5. Domain Name Change

This is a high-risk migration. Google treats your new domain as an entirely new website. All backlink equity, domain authority, and ranking history must be transferred through redirects and the Change of Address tool.

SEO-specific steps:

• Set up the new domain with a complete copy of your site (use All-in-One WP Migration)
• Run database search-replace to update all references from old domain to new domain
• Implement 301 redirects from every old URL to its new URL equivalent on the old domain. In .htaccess:

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

• Keep the old domain active and renewed. Do not let it expire. Keep the SSL certificate valid on the old domain so redirects work over HTTPS. If you do not want to maintain hosting for the old domain, use Cloudflare (free plan) to serve redirects without active hosting.
• Use Google Search Console’s Change of Address tool:
  1. Verify both old and new domains in GSC
  2. Go to the old domain’s property in GSC
  3. Click Settings > Change of Address
  4. Select the new domain and submit
  5. This process can take up to 180 days to fully complete
• Submit a new sitemap on the new domain property
• Update Google Business Profile, social media accounts, business directories, and anywhere else the old domain appears
• Contact owners of your most valuable backlinks and ask them to update their links to the new domain. Redirects pass most link equity, but direct links are always better.
• Monitor both domains in GSC for 6 months. Expect a temporary ranking dip in the first 2-4 weeks.

What can go wrong: Letting the old domain expire is the single biggest mistake. Your old domain’s backlinks become worthless, and someone else can register it. Not maintaining SSL on the old domain means HTTPS backlinks get certificate errors instead of clean redirects. Changing both domain and URL structure simultaneously doubles the risk and makes it impossible to diagnose problems.

6. Full Redesign / Rebuild

This is the highest-risk scenario because multiple things change at once: design, content, URL structure, and sometimes even the CMS. The SEO risk comes from the sheer number of variables.

SEO-specific steps:

• Content audit first. Before touching any code, categorize every page:

  • Keep as-is: Pages with strong rankings and backlinks. Do not change the URL or content.
  • Improve: Pages with ranking potential. Update the content but keep the URL.
  • Redirect: Pages being removed but that have backlinks or rankings. 301 redirect to the most relevant replacement page.
  • Remove: Pages with no traffic, no backlinks, and no value. Return a 410 (Gone) status.

• Preserve URL structure wherever possible. Every URL you change requires a redirect and carries ranking risk.

• Verify that all SEO metadata (titles, descriptions, robots directives) transfers to the new design

• Check that the new theme/design includes proper heading hierarchy (single H1 per page, logical H2-H6 structure)

• Verify structured data / schema markup works in the new templates. Test with Google’s Rich Results Test before going live.

• Benchmark Core Web Vitals before and after. A redesign can dramatically change CWV scores, which directly affect rankings.

• Test the complete site on staging before going live. Crawl the staging site and compare the URL list against the production crawl.

• Deploy and immediately resubmit the sitemap

• Monitor GSC for crawl errors, indexing drops, and ranking changes daily for the first week, then weekly for 3 months

What can go wrong: Everything. Content removal without redirects. Changed heading structure. Missing schema markup. CWV regression from heavier design. New templates that accidentally include noindex tags. Changed internal linking structure. This scenario requires the most thorough pre-migration planning and post-migration monitoring.

301 Redirects: The Foundation of SEO Migration

Every migration that changes URLs depends on 301 redirects to transfer ranking signals from old URLs to new ones. Here is what you need to know:

How 301 Redirects Work for SEO

A 301 redirect tells search engines that a page has permanently moved to a new URL. Google transfers most of the original page’s ranking signals (backlinks, authority, relevance) to the new URL. The transfer is not 100% - Google has confirmed that some signal is lost through redirects - but it is the best mechanism available.

Redirect Best Practices

Map one-to-one wherever possible. Each old URL should redirect to the single most relevant new URL. Redirecting everything to the homepage wastes the ranking authority of individual pages.

Avoid redirect chains. If URL A redirects to URL B, and URL B redirects to URL C, that is a chain. Google follows up to 5 redirects but loses signal at each hop. Fix chains so A redirects directly to C.

Avoid redirect loops. If A redirects to B and B redirects to A, both pages become inaccessible. Test every redirect before going live.

Keep redirects in place permanently. Google’s John Mueller has recommended keeping redirects active for at least one year. For domain changes, keep them active as long as you own the old domain.

Use server-level redirects, not JavaScript or meta refreshes. .htaccess (Apache) or Nginx config redirects are the fastest and pass the most SEO value. JavaScript redirects are not reliably followed by search engines.

Testing Redirects

After implementing redirects, test them with:

# Test a single redirect
curl -I https://old-domain.com/some-page/

# Test all redirects from a file
while IFS= read -r url; do
    echo -n "$url -> "
    curl -s -o /dev/null -w "%{redirect_url} (%{http_code})\n" -I "$url"
done < old-urls.txt

Verify that each redirect returns a 301 status code and points to the correct destination.

Google Search Console Setup

For Host-to-Host Migration (Same Domain)

No special GSC action needed. Monitor the existing property for crawl errors and ranking changes.

For Domain Changes

1. Verify the new domain as a property in GSC
2. In the old domain’s property, go to Settings > Change of Address
3. Select the new domain and submit
4. Resubmit the sitemap on the new domain property

The Change of Address tool signals to Google that this is an intentional migration, not a hijack. It can take up to 180 days to fully process.

For HTTP to HTTPS

1. Add https://yourdomain.com as a new property (HTTPS is treated as a separate property)
2. Resubmit your sitemap on the HTTPS property
3. If you have a disavow file on the HTTP property, download it and resubmit it to the HTTPS property
4. Monitor both properties for 4 weeks

For All Migrations

After the migration is live:

1. Resubmit your sitemap. Go to Sitemaps in GSC and submit the URL of your new sitemap.
2. Check Coverage/Indexing report. Look for new errors, especially 404s, soft 404s, and “Crawled - currently not indexed” pages.
3. Check the Crawl Stats report (under Settings > Crawl Stats). Verify that Googlebot is crawling the new site at a healthy rate and not getting blocked or receiving errors.

Post-Migration Monitoring

The first 48 hours, the first 2 weeks, and the first 3 months after migration each require different monitoring.

First 48 Hours

• Check GSC for new crawl errors every few hours
• Verify that your sitemap is being processed (check the sitemap status in GSC)
• Check that Googlebot is crawling the new server (Crawl Stats report)
• Test key pages in Google’s URL Inspection tool to verify they are indexable
• Monitor your site for mixed content warnings, broken images, and 404 errors
• Check that robots.txt is correct and not blocking search engines

First 2 Weeks

• Compare organic traffic against your pre-migration baseline daily
• Monitor GSC Performance report for ranking changes on your top keywords
• Run a full site crawl and compare against your pre-migration crawl. Look for:
  • New 404 errors (pages that did not get redirected)
  • Redirect chains or loops
  • Missing meta titles or descriptions
  • Changed canonical tags
  • Missing structured data
• Check Core Web Vitals report for changes in performance scores
• Verify that Google is indexing the new URLs (not still showing old URLs in search results)

First 3 Months

• Weekly comparison of organic traffic and rankings against baseline
• Monthly GSC Performance report exports
• Watch for “Crawled - currently not indexed” pages increasing (may indicate quality or technical issues)
• For domain changes: monitor both old and new properties in GSC
• After 3 months of stable performance, you can be confident the migration was successful

When to Worry

A temporary ranking dip of 10-20% in the first 1-2 weeks is normal for most migration types. This is Google re-evaluating your site in its new configuration. If you see:

• Rankings drop more than 30% and do not begin recovering after 2 weeks
• Organic traffic drops and stays flat for 4+ weeks
• Key pages disappear from the index entirely
• Google Search Console shows a spike in “Not indexed” pages

Then something went wrong. Check for:

1. Redirect errors: Are all 301s working? Any chains, loops, or redirects to wrong pages?
2. Noindex tags: Did a staging noindex directive get carried over to production?
3. Robots.txt blocking: Is your robots.txt accidentally blocking Googlebot?
4. Canonical tag errors: Are canonical tags pointing to old URLs, wrong URLs, or non-existent pages?
5. Missing content: Did pages get lost during migration?

SEO Plugin Data Migration

If you are switching between SEO plugins as part of your migration (for example, from Yoast to Rank Math, or vice versa), handle this as a separate step:

1. Before migration: Export your SEO plugin settings and verify all custom meta titles, descriptions, and robots directives are saved in the database.

2. During migration: A full-site migration with All-in-One WP Migration transfers the complete database, including all SEO plugin data stored in post meta fields.

3. After migration (if switching plugins): Most SEO plugins can import data from other SEO plugins. Rank Math, Yoast, and AIOSEO all have built-in importers. Run the importer after installing the new plugin, then verify a sample of pages to confirm that titles, descriptions, and redirects transferred correctly.

Do not switch SEO plugins and migrate at the same time. Migrate first, verify everything is stable, then switch plugins. Changing too many variables at once makes it impossible to diagnose problems.

Structured Data / Schema Verification

Structured data affects how your pages appear in search results (rich snippets, FAQ dropdowns, product ratings, etc.). Migration can break schema markup in several ways:

• Theme-generated schema may not transfer if you change themes during migration
• Plugin-generated schema should transfer with the database, but verify it is still valid
• Hardcoded schema in template files needs manual verification
• URL references within schema markup need to match the new URLs

Verification process:

1. Before migration, test 5-10 key pages with Google’s Rich Results Test
2. After migration, test the same pages again
3. Compare the results. Any missing or invalid schema needs immediate attention.
4. Check GSC’s Enhancements reports (FAQ, Product, Article, etc.) for new errors after migration

Common Mistakes That Destroy Rankings

These are the errors we see most frequently across the 60 million+ sites that have used our migration tools:

1. Leaving noindex on from staging. If you tested on a staging site with noindex directives and forgot to remove them before going live, Google will de-index your entire site. Check <meta name="robots"> tags and your SEO plugin settings immediately after going live.

2. Letting the old domain expire. All backlinks to the old domain become worthless. Someone else can register it and get your link equity. Renew it indefinitely, even if it only costs $10/year.

3. Redirecting everything to the homepage. This wastes the ranking authority of individual pages. Each page should redirect to its specific equivalent on the new site.

4. Changing domain and URL structure simultaneously. Google cannot distinguish between a domain migration and a content restructuring when both happen at once. Do one at a time with months between them.

5. Not updating internal links. Relying on redirects for internal navigation creates unnecessary redirect chains and wastes crawl budget. Update all internal links in the database to point directly to the new URLs.

6. Forgetting about images. Image URLs change during migration too. If your images ranked in Google Images or were referenced by external sites, those URLs need redirects as well.

7. Ignoring non-page URLs. PDFs, media files, RSS feeds, and API endpoints are all indexed by Google. Include them in your redirect plan.

8. Skipping the post-migration monitoring. Many SEO migration problems are not immediately visible. They surface over weeks as Google re-crawls your site. Without monitoring, you will not catch problems until the damage is done.

Frequently Asked Questions

Will I lose my SEO rankings if I change hosting providers?

If you keep the same domain and URL structure, a host-to-host migration is the lowest-risk scenario. Rankings should not be affected as long as the migration is executed correctly (no extended downtime, no broken URLs, no configuration errors). Use a migration plugin to transfer everything cleanly.

How long does it take for SEO to recover after migration?

It depends on the migration type. Host-to-host with the same domain: days to 2 weeks. HTTP to HTTPS: 1-4 weeks. Subdomain to subfolder: 1-3 months. Domain change: 2-6 months. Full redesign: 1-6 months. These are ranges. A well-executed migration with proper redirects recovers faster.

Should I submit a Change of Address in GSC?

Only for domain changes. The Change of Address tool is specifically for telling Google you have moved to a new domain. It is not needed for host changes, HTTPS migration, or URL structure changes on the same domain.

Do 301 redirects pass full link equity?

Not 100%. Google has confirmed that some ranking signal is lost through redirects, but the amount is small. A properly implemented 301 redirect transfers the vast majority of a page’s ranking authority. Direct links (where the source updates their link to point to your new URL) are always better, which is why reaching out to your top backlink sources is worth the effort.

Can I use a WordPress plugin for redirects instead of .htaccess?

Yes, but server-level redirects (.htaccess for Apache, configuration files for Nginx) are faster and more reliable. Plugin-based redirects require WordPress to load before the redirect executes, which adds latency. For a small number of redirects, plugins like Redirection or your SEO plugin’s redirect manager work fine. For hundreds or thousands of redirects (common in large migrations), use server-level redirects.

What about WooCommerce SEO during migration?

WooCommerce adds product URLs, category URLs, product schema markup, and customer-facing pages (cart, checkout, account) that all need to be preserved. Product pages often have rich results in Google (price, availability, reviews), and losing this structured data impacts click-through rates. See our WooCommerce migration guide for the complete process. For migration errors specific to WooCommerce, check our troubleshooting guide.

What about multisite SEO?

WordPress multisite migrations involve multiple sites, each potentially with their own search presence, sitemaps, and GSC properties. The SEO checklist in this guide applies to each subsite individually. See our WordPress multisite migration guide for the technical migration process.

What if my SEO tanks after migration and I cannot figure out why?

If you have a pre-migration backup, the safest option is to restore it and start over. A failed migration that stays live continues to lose rankings every day. Restore, diagnose the issue, fix it, and try again. Migration is always easier the second time. If you did not take a backup, work through the troubleshooting section above systematically: check redirects, check for noindex, check robots.txt, check canonical tags, and check for missing content.

Ready to migrate? Download All-in-One WP Migration to handle the technical migration while you focus on the SEO-critical details.

Need the full migration walkthrough? Read our complete guide to migrating WordPress to a new host. Running WooCommerce? See our WooCommerce migration guide. Managing a multisite network? See our WordPress multisite migration guide. Something broken after migration? Check our troubleshooting guide for step-by-step fixes.

Need help? Visit our support center for migration assistance from the team that has helped migrate over 60 million WordPress sites.