Website migration SEO checklist: redesign or replatform without losing traffic

A website migration is any change that alters the URLs, content, structure or technology search engines have already learned: a redesign, a move to a new CMS or ecommerce platform, a domain change, a restructure of URLs, or merging several sites into one.

Migrations are where search visibility is most exposed, because everything a search engine has learned about your pages is tied to their URLs. This checklist follows the order the work should happen in. It is based on Google's guidance on site moves with URL changes and on the mistakes that most often turn a routine launch into months of recovery.

First, know what kind of migration you are running

Risk depends on how much changes at once:

Change	Risk	Why
Design only, same URLs and content	Low	Signals stay attached to the same URLs, but templates can still drop content or links
New CMS or platform, same URLs	Medium	Rendering, internal links, metadata and structured data often change silently
URL structure changes	High	Every changed URL needs a redirect and time to transfer signals
Domain change	High	All URLs change; Search Console's Change of Address tool is needed
Several of the above at once	Highest	When everything changes, nobody can tell what caused a drop

If the project allows it, stage the changes: move platforms first with the same URLs, then restructure later.

Before launch: benchmark and inventory

• Crawl the current site and save the export: every URL, status code, title, H1, canonical, meta robots and internal link count.
• Export Search Console performance for the last 16 months by page and by query, so seasonal patterns are visible later.
• Export analytics for organic landing pages: sessions, conversions and revenue.
• List pages with external links using the Links report in Search Console and any backlink tool you have.
• Collect every URL that matters. Combine the crawl, sitemaps, analytics landing pages, server logs and linked pages. Old URLs that only exist in logs or backlinks still need redirects.
• Record rankings for priority searches, so you have a before picture for the queries that bring business.

Before launch: map every URL

• Map each old URL to its closest equivalent on the new site. One-to-one where possible.
• Use permanent server-side redirects (301 or 308). Google recommends HTTP permanent redirects where possible.
• Don't redirect everything to the homepage. Google warns that sending many old URLs to one irrelevant destination, such as the homepage, may be treated as a soft 404, so the old pages' signals are lost.
• Decide deliberately about removed pages. If a page truly has no replacement and no value, let it return 404 or 410. If it has links or traffic, redirect it to the most relevant alternative.
• Flatten old redirect chains. Previous migrations often leave redirects that point to redirects. Update them to point straight at the final URL.
• Include files. Images, PDFs and other documents with links or traffic need redirects too.

Before launch: test the new site on staging

• Protect staging properly, ideally with a password. A staging site that gets indexed competes with the live one.
• Crawl staging with the same settings as the benchmark crawl and compare: missing pages, changed titles and headings, lost internal links, new duplicate URLs.
• Check content parity on pages that bring traffic. If a template drops a section, the page may lose rankings for everything that section covered.
• Check canonicals are self-referencing and point to production URLs, not staging hostnames.
• Check rendering. Compare raw and rendered HTML on key templates; navigation and content should not depend on scripts crawlers might not run.
• Check structured data, hreflang and pagination on the new templates.
• Test the redirect map on staging or with a script: every mapped URL should return a single permanent redirect to a page that returns 200.
• Check Core Web Vitals on new templates. A heavier design can make key pages noticeably slower.
• Prepare the production robots.txt and XML sitemaps in advance.

Launch day

• Remove staging protections: noindex directives, robots.txt disallow rules and password protection. This single step is where many migrations fail.
• Deploy and test redirects live, starting with the top pages by traffic and links.
• Verify the new site in Search Console, including the new domain if it changed.
• Submit the new sitemap, and keep the old one available. Google suggests submitting both; over time the old URLs drop out of the index as the new ones replace them.
• Use the Change of Address tool in Search Console if you moved to a new domain or subdomain. It isn't needed for HTTP to HTTPS or www changes.
• Check analytics and conversion tracking are firing on the new site.
• Update internal links so they point directly to new URLs, not through redirects.
• Update what you control off-site: Business Profile, social profiles, directory listings and your most important backlinks.

After launch: monitor and fix fast

• Days 1–7: check daily. Search Console's Page indexing report, 404 errors, server errors, redirect behavior and a sample of rankings.
• Weeks 2–8: compare weekly with the benchmark, by page group rather than sitewide totals, so problems in one section stand out.
• Fix issues while they're small. A missing redirect pattern found in week one costs far less than one found in month three.
• Keep redirects for at least a year. Google recommends keeping them as long as possible, generally at least one year.
• Write a closing report once traffic and indexing are back in line with the benchmark, including what went wrong and what to repeat.

How long recovery takes

Some fluctuation after a migration is normal while search engines recrawl and process the changes. Google says that for medium-sized websites it can take a few weeks or more for the new URLs to replace the old ones in results, and longer for large sites.

A migration that is still down after several weeks usually has a specific cause: missing redirects, content that didn't make it across, a template change that removed important text or links, or leftover blocking directives. Compare the benchmark crawl with the live site page group by page group, and the cause usually shows itself.

When to bring in help

If the site earns a meaningful share of its business from organic search, involve an SEO specialist at the planning stage, before designs and URL structures are signed off. Requirements written early cost almost nothing; the same requirements discovered after launch become expensive change requests.