Website Migration SEO Checklist: Rebuild Without Losing Traffic

This tutorial is part of the SEO series for web developers.

Rebuilding a website is the easiest way to lose search traffic you spent years earning. The new site can look better, load faster and have cleaner code, and still drop out of Google, because the things search engines rely on (URLs, links, titles, internal structure) quietly changed underneath it. This checklist is what we used when this site, REM Web Development, was rebuilt from a 2009–2023 custom CMS into a static Astro site.

Before you change anything

Make a complete list of the old URLs. Don't rely on your navigation. Combine the old sitemap, a crawl of the live site, your analytics landing pages and, if the site is already gone, the Internet Archive's CDX index (web.archive.org/cdx/search/cdx?url=example.com/*). This list is your contract: every URL on it must either keep working or redirect.
Find the URLs that matter most. Export the pages that have backlinks from a tool like Ahrefs or Search Console's Links report. On this site, a handful of 2009 Android and Flex articles carried far more links than the home page. Those URLs should keep their exact address.
Record the on-page basics for your top pages: title, meta description, H1, canonical, structured data. You want to compare them after launch.
Benchmark. Note your current indexed page count, top queries and Core Web Vitals so you can tell a real drop from normal noise.

While you build

Keep URLs wherever you can. Static site generators can produce any path, including old-style .html files. This site still serves /dev/a33/Passing-Bundles-Around-Activities.html from 2009 because other sites link to it.
Build the redirect map as data, not by hand. One list of old → new pairs, generated into your server config. Duplicates, renamed folders and mistyped inbound links (yes, people link to typos) all go in the same list.
Never blanket-redirect to the home page. Each old URL goes to the closest page on the same topic. If there is no equivalent, return 410 Gone.
Carry over titles and descriptions, and improve the weak ones instead of starting from scratch.
Add a self-referencing canonical to every page (see Canonical URLs Explained).
Generate an XML sitemap that lists only the canonical, indexable URLs, and reference it in robots.txt.
Don't let staging get indexed. Password-protect it or send noindex, and make sure that setting does not ship to production.

The day before launch

Point a test machine at the new server (for example with curl --resolve or a hosts-file entry) and run every old URL through it. Each one should return 200 or a single 301 to a page that returns 200. No chains. The method is in 301 Redirects with .htaccess.
Run a link checker over the new site. Zero internal 404s.
Check that robots.txt does not block anything you want indexed.
Make sure the SSL certificate covers both the bare domain and www. Because your redirects force https, a missing certificate means a browser warning on every page.
Run Lighthouse on your main page templates and compare the scores with your benchmark.

After launch

Submit the sitemap in Google Search Console and request indexing for your most important URLs.
Re-run the redirect test against the live site. Hosting control panels sometimes add their own rules.
Watch Search Console's "Pages" report for a few weeks. A spike in "Not found (404)" means a URL you missed. Add it to the redirect map.
Keep the redirects forever. Links on other sites don't get updated, and some of the links to this site are more than fifteen years old.

The short version

Every URL that ever had value must still answer, in one step, on the final https address. Everything else about a rebuild is a design decision. That part is the one that protects your traffic.

If you are planning a redesign and want someone else to manage the SEO side of it, Southern Whale offers website redesigns that keep your Google rankings.