Website Migration SEO Checklist: Move Without Losing Rankings

Website migration SEO comes down to one job. You help Google connect every old URL to its new home, so rankings, links and traffic carry over. Do that with a complete URL map, permanent 301 redirects, clean canonicals and fresh sitemaps. Then most migrations settle within weeks, not months.

When migrations go wrong, the cause is rarely bad luck. It’s usually something skipped. A forgotten section of URLs. Redirects that all point to the homepage. Or a staging noindex tag that went live with the new site. This checklist walks through each phase so none of that happens to you.

What Counts as a Website Migration?

Any change that alters how search engines find, crawl or understand your URLs is a migration. The common types are:

• Domain change: moving from old-example.com to new-example.com, including rebrands and ccTLD (country domain) consolidations.
• HTTP to HTTPS: every URL changes protocol, even if nothing else does.
• Platform or CMS change: for example, moving from a custom build to WordPress or Shopify. URL patterns often change as a side effect.
• URL restructure: new folder paths, removed file extensions, merged categories, or a switch between www and non-www.
• Redesign: new templates, navigation and content, sometimes on the same URLs. Even with no URL changes, losing internal links, headings or body text can shift rankings.

Google treats moves with URL changes differently from moves without them. Switching hosting providers while keeping every URL the same is the lowest-risk move. Anything that changes URLs needs the full process below.

Change One Thing at a Time Where You Can

It’s tempting to combine a domain change, a new CMS and a content rewrite in one launch. But it makes problems hard to diagnose. If traffic drops, you won’t know if redirects, content or templates caused it. If the budget allows, I always separate the technical move from the redesign.

Pre-Migration: Inventory and Benchmarks

You can’t protect what you haven’t recorded. Before anyone touches the new site, build a full picture of the old one.

Build Your URL Inventory

Google’s own site move documentation suggests pulling old URLs from several places, because no single source is complete:

• A full crawl of the current site with a desktop crawler.
• Your XML sitemaps.
• Server logs, which show URLs that bots and users visit but your navigation no longer links to.
• Landing pages in your analytics.
• Top linked pages from the Links report in Search Console.
• An export from your CMS, including PDFs, images and other downloadable files.

Merge these lists and remove duplicates. The URLs that only appear in logs or the Links report are often the ones that get missed. They often carry old backlinks too. In my experience, these are the URLs that cause the most quiet damage after launch.

Record Your Benchmarks

Save a snapshot of performance before launch, so you can compare like with like afterwards:

• Clicks, impressions and average position by page and by query from the Search Console Performance report. Export it, because you lose easy access to old-property data once traffic moves.
• The number of indexed pages from the Page indexing report.
• Organic sessions, conversions and revenue by landing page from analytics.
• Title tags, meta descriptions, H1s, canonicals and word counts from your crawl.
• Your top 50 to 100 pages by organic traffic and by backlinks. These get the most attention during testing.

Weekly totals help here. Search Console’s weekly and monthly chart views smooth out day-of-week ups and downs. That makes before-and-after comparisons much easier to read.

Pick a Sensible Launch Window

Google recommends moving during a quieter period for your business where possible. A retailer should not migrate just before a sales peak. I’d also avoid launching on a Friday, unless developers will be around over the weekend.

URL Mapping: The Core of Website Migration SEO

The URL map is a spreadsheet. It has every old URL in one column and its new destination in the next. Every redirect you write later comes from this file. So accuracy here matters more than anywhere else.

Follow three rules when choosing destinations:

1. Map like for like. Each old page should point to the closest matching new page, not a broad category or the homepage.
2. Merge on purpose. Merging several thin old pages into one stronger new page is fine, as long as the new page truly covers what the old ones did.
3. Let dead content go properly. If a page has no match and no value, return a 404 or 410 instead of forcing a redirect.

A simple mapping sheet might look like this:

For a pure domain change where every path stays the same, one pattern-based rule can handle everything. For a CMS change or restructure, you usually need a mix. That means pattern rules plus one-to-one mappings for the exceptions.

301 Redirects: How to Set Them Up

Use server-side permanent redirects, either 301 or 308. They tell Google the move is permanent and that the new URL should be treated as canonical (the main version). JavaScript or meta refresh redirects are a last resort. They rely on the page being rendered and are weaker signals.

Example: Apache (.htaccess)

A whole-domain move that keeps paths the same:

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

Single page mappings from your spreadsheet:

Redirect 301 /services/seo-audit.html https://www.example.com/seo/audit/
Redirect 301 /contact-us.php https://www.example.com/contact/
Redirect gone /promo/summer-2021/

Example: Nginx

A whole-domain move, covering both HTTP and HTTPS on the old host:

server {
    listen 80;
    listen 443 ssl;
    server_name old-example.com www.old-example.com;
    # ssl_certificate lines for the old domain go here
    return 301 https://www.new-example.com$request_uri;
}

One-to-one mappings using a map block:

map $request_uri $new_uri {
    default                    "";
    /services/seo-audit.html   /seo/audit/;
    /contact-us.php            /contact/;
}

server {
    # ...
    if ($new_uri) {
        return 301 $new_uri;
    }
}

Keep the old domain’s SSL certificate valid. If the certificate on the old HTTPS URLs runs out, browsers show an error before the redirect can work.

Avoid Chains, Loops and Homepage Dumps

• Chains: if you migrated before, old URLs may already redirect. Update those rules to point straight to the final destination, instead of hopping through the previous site. Google can follow several hops, but each one slows users and adds risk.
• Loops: a rule that sends A to B while another sends B to A breaks both pages. Test before launch.
• Homepage dumps: sending lots of unrelated URLs to the homepage can be treated as soft 404s (pages Google sees as empty or missing). Then the old pages’ value is not passed on.

Homepage dumps are the shortcut I push back on hardest. They save a day of mapping and can cost months of traffic.

Test Redirects in Bulk

Check single URLs from the command line with curl:

curl -sI https://old-example.com/services/seo-audit.html
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/seo/audit/

For the full list, upload your old URLs into a crawler in list mode. Confirm each one returns a single 301 to the expected destination, and that the destination returns a 200.

How Long to Keep Redirects

Google advises keeping redirects in place for at least one year. From a user’s point of view, keep them forever. Old bookmarks, printed materials and backlinks keep sending people to old URLs for years. Keep renewing the old domain too.

Canonicals, Internal Links and Hreflang

Redirects are only one signal. If other signals on the new site still point to old URLs, you’re sending Google mixed messages.

• Canonicals: every indexable page on the new site should have a rel="canonical" pointing to itself, using the new, final URL. A common bug is canonicals still pointing at the old domain or at the staging host.
• Internal links: update navigation, footers and in-content links to the new URLs directly. Relying on redirects for internal links wastes crawl effort and slows pages down.
• hreflang: if you run versions for different countries or languages, update every hreflang tag so the alternates use new URLs.
• Structured data and assets: check that schema markup, image URLs, Open Graph tags and CSS or JavaScript files use the new locations.

A redesign is also a good time to check page weight. Heavy new templates with large inline scripts can push HTML towards Googlebot’s 2MB fetch limit. That means content near the bottom of the page may not be indexed.

Staging Environments and the Noindex Trap

Developers usually block the staging (test) site from search engines, which is correct. The problem is that those blocks sometimes travel to the live site on launch day. This is the first thing I check when traffic drops right after a launch.

Watch for three things:

1. A noindex robots meta tag or X-Robots-Tag header left in the template. This removes pages from Google’s index as it recrawls them. My guide to robots meta tags and X-Robots-Tag explains how to spot both.
2. A Disallow: / rule in robots.txt. This stops Google crawling the new site, so it can’t see your content or your canonicals.
3. The “discourage search engines” setting in some CMSs, which adds a site-wide noindex behind the scenes.

The safest way to protect staging is a password or HTTP authentication, not noindex alone. Nothing needs removing at launch. And the protection can’t go live by accident, because the live server doesn’t use it.

Also check the old site’s robots.txt. If it blocks Googlebot from the old URLs, Google can’t crawl them to find your redirects.

Sitemaps and Search Console Setup

Before launch, verify the new site in Search Console, including every version you use. A Domain property covers all protocols and subdomains in one place. Make sure the old properties stay verified too. You need their data, and the Change of Address tool runs from the old site.

After launch:

• Submit a new XML sitemap with only the new, final, indexable URLs.
• Keep the old sitemap for a while. Google’s documentation suggests leaving it in place while you monitor. Its indexed count should fall towards zero while the new one climbs. Redirect warnings on the old sitemap are expected.
• Carry settings across, such as any disavow file you rely on.
• Check a newly bought domain for leftover manual actions or history before you move to it.

The Search Console Change of Address Tool

The Change of Address tool tells Google you have moved from one domain or subdomain to another. It’s only for domain-level moves, such as example.com to example.org.

Don’t use it for:

• HTTP to HTTPS moves, which Google detects by itself.
• Switching between www and non-www on the same domain.
• Path changes within one domain, such as a URL restructure.

To submit a request, you must be a verified owner of both the old and new properties under the same Google account. Your 301 redirects need to be live first, at least from the old homepage. The tool runs checks before the move and blocks the request if critical ones fail.

Once accepted, Google says the move signals continue for 180 days. During that time, it prefers the new site as canonical. Keep your redirects running for at least that long. Google also recommends keeping the old domain registered for at least a year.

Launch-Day Checklist

I work through this list in order as soon as the new site goes live:

1. Confirm robots.txt on the new site allows crawling and has no leftover Disallow: /.
2. Spot-check key templates for noindex in the HTML and in HTTP headers.
3. Run your old URL list through a crawler and confirm single-hop 301s to 200 pages.
4. Test HTTP, HTTPS, www and non-www versions of the old homepage.
5. Check that canonicals on the new top pages point to themselves on the new domain.
6. Inspect a few important new URLs with the URL Inspection tool, and request indexing for the most important ones.
7. Submit the new sitemap and, for domain moves, the Change of Address request.
8. Confirm analytics and conversion tracking work on the new site.
9. Update your Google Business Profile website link, social profiles and paid ad destination URLs.

Post-Launch Monitoring

For the first few weeks, check these daily, then weekly:

• Page indexing report: look for jumps in “Excluded by noindex”, “Not found (404)” or “Redirect error”.
• Performance report: compare clicks for your top pages against your benchmarks. Traffic should fall on the old property as it rises on the new one.
• Crawl stats and server logs: Google crawls more after a move. Make sure your server copes and isn’t returning 5xx errors.
• 404 log: any old URL returning a 404 that has traffic or links needs a redirect added.

Then contact the owners of your most valuable backlinks. Ask them to update their links to your new URLs. Redirects pass signals, but direct links are cleaner and faster for users.

Keep an eye on the wider search calendar too. Google updates rolling out at the same time can blur the picture. For example, the February 2026 Discover core update was rolling out in the same weeks. So a Discover traffic change during that period may not be caused by the migration. I check the Search Status Dashboard for those dates.

How Long Do Ranking Fluctuations Last?

Some movement is normal. Google says visibility may go up and down for a while as it recrawls and reindexes. For a medium-sized site, it can take a few weeks or more before Google slowly starts showing the new URLs. Larger sites can take longer.

Speed depends on how many URLs you have and how fast your server responds. If traffic is still well below benchmark after a couple of months, I treat it as a problem to investigate, not a waiting game. The usual causes are missing redirects, blocked pages, lost content or weaker internal linking.

Final Thoughts

Good website migration SEO is mostly preparation. You need a complete URL inventory, a careful map, permanent redirects, and clean signals on the new site. Then launch day becomes a checklist, not a gamble.

My advice: start the inventory now, even if the launch is months away. Begin with the Search Console export and your crawl. Those benchmarks are the only way to prove afterwards that your website migration SEO worked.