Site migration checklist: domain moves, redesigns and platform changes

A site migration is any change that affects how search engines find and understand a whole site: a new domain, a move from HTTP to HTTPS, a new CMS or e-commerce platform, a new URL structure, a merge of two sites, or a redesign that changes templates and navigation. Migrations are where the largest avoidable traffic losses in SEO happen. Not because search engines punish change, but because a launch involves hundreds of small decisions, and a few of them quietly break the signals that rankings depend on.

This checklist is organised in the order the work happens. It assumes a medium-sized site; scale the effort up or down, but do not skip whole sections.

Before you start: decide what is changing

Write down, in one line each, which of these will change: domain, protocol, URL paths, CMS or platform, templates and design, content, internal navigation, hosting. Every item on that list is a separate risk. The more items change at once, the harder it is to diagnose problems afterwards. If you can, split the migration into phases, for example move the platform with URLs unchanged, then change URLs months later.

Then record a baseline you can compare against:

• Search Console performance for the last 16 months, exported by page and by query, so you can compare page by page afterwards.
• A full crawl of the current site: every URL, status code, title, canonical, meta robots, H1 and word count.
• Analytics landing page data for organic traffic over the last 12 months.
• A list of the URLs with the most external links, from any backlink tool.
• Current technical scores and response times. A check with the SEO checker on the main templates takes a minute and gives you something to compare against after launch.

The redirect map

The redirect map is the single most important document in a migration. It lists every old URL that has any value, and the new URL each one should go to.

1. Collect old URLs from every source: the crawl, XML sitemaps, Search Console pages with impressions, analytics landing pages, backlink targets and server logs. Crawls alone miss orphaned pages that still receive links.
2. Map one to one wherever possible: old product to new product, old article to new article. Redirecting many pages to the home page is treated by Google as a soft 404 and passes little value.
3. For pages with no equivalent, redirect to the closest relevant page (the parent category, a replacement product) or let them return 404 or 410 if nothing relevant exists. See HTTP status codes for when each is right.
4. Use 301 or 308 permanent redirects, served by the server, in a single hop. Avoid JavaScript or meta refresh redirects. The redirects guide covers codes and chains in detail.
5. Preserve query strings where they matter, and decide what happens to old parameter URLs.
6. Test the map before launch by running every old URL against the staging server and checking that each returns a single 301 to a 200 page.

Staging checks before launch

Build the new site on a staging server that search engines cannot index, protected with HTTP authentication rather than a noindex tag or robots.txt block. Password protection is safer because it cannot be accidentally carried over to production.

Check	What good looks like
Titles, meta descriptions, H1s	Carried over or deliberately improved for every important page; no template defaults
Content	Main body text preserved on pages that rank; no sections lost to the new design
Canonicals	Point to the new production URLs, not staging or old URLs
Internal links	Point directly to new URLs, not through redirects
Structured data	Same types and properties as before, valid
hreflang	Updated to new URLs with return links, if the site is multilingual
Robots directives	No accidental noindex or disallow rules prepared for production
Rendering	Main content and links present in the HTML or rendered without errors
Speed	Core Web Vitals at least as good as the old site on key templates
Analytics and tag manager	Installed and firing on every template

Launch day

1. Remove staging protection and confirm that no noindex and no Disallow: / made it to production. This single mistake is behind a large share of failed migrations.
2. Deploy the redirects and test a sample of the top 200 old URLs by traffic and by backlinks.
3. Upload new XML sitemaps with the new URLs. For a domain move, temporarily keeping a sitemap of old URLs on the old property can help Google discover the redirects faster.
4. For a domain change, verify the new domain in Search Console and submit the Change of Address from the old property.
5. Crawl the live site immediately. Look for 4xx, 5xx, redirect chains, missing canonicals and pages that still link to old URLs.
6. Check robots.txt on the new site, including rules for AI crawlers if you had any. The AI bot checker shows the effective rules for each bot.
7. Update external assets you control: social profiles, business listings, ad destinations, email templates.

The first two weeks

Expect some turbulence. Rankings often wobble for a few days as search engines process redirects. What you are looking for is evidence of systematic breakage rather than normal fluctuation.

• Daily: server errors and 404s in logs, URL Inspection on a few key pages to confirm the new URLs are being crawled and the old ones show as redirected.
• Every few days: Search Console's Page indexing report for the new property. Watch for rises in "Not found", "Blocked by robots.txt", "Excluded by noindex" and "Duplicate, Google chose different canonical".
• Weekly: compare organic clicks by page group against the same period before launch. Group by template or section, not by individual URL, to see patterns.

Months one to three

Most clean migrations settle within a few weeks to a couple of months. If traffic to a section is still significantly down after that, compare that section's old and new pages directly: content length, title, internal links pointing in, page speed, and whether the page still matches the queries it used to rank for. The traffic drop diagnosis guide has a structured approach.

Keep redirects in place for at least a year, and in practice indefinitely. Keep the old domain registered and pointed at the redirect server. Migrations that lose traffic a year later often do so because someone let the old domain expire or removed the "old" redirect rules during a server change.

Special cases

Merging two sites

When two sites become one, the redirect map has to decide which of two overlapping pages survives. Pick the page with stronger performance and links as the destination, merge the useful content of the other into it, and redirect the loser. Do not keep both and canonicalise one to the other; you will end up maintaining two pages that compete.

Platform changes with identical URLs

Moving from one CMS to another while keeping every URL is the lowest-risk migration, and it is still easy to break. New platforms change templates, heading structure, internal linking blocks, pagination, image URLs and structured data, often without anyone deciding to. Compare a sample of old and new pages side by side in their rendered HTML, not just in the browser.

HTTP to HTTPS

Search engines treat this as a site move too, but a simple one: redirect every HTTP URL to its HTTPS equivalent, update canonicals, internal links and sitemaps, and add the HTTPS property in Search Console. The Change of Address tool is not used for protocol changes.

Common mistakes, in order of how much they cost

1. Noindex or a robots.txt block carried over from staging.
2. No redirects, or everything redirected to the home page.
3. Content removed or thinned during the redesign, especially text on category pages.
4. Internal links and canonicals still pointing to old URLs.
5. Changing domain, URLs, content and design at once, making problems impossible to isolate.
6. Launching just before a peak season with no time to recover.

A scheduled check that compares each run with the previous one, such as DeskSEO's weekly monitoring, catches the first item within days rather than weeks, which is often the difference between a dip and a disaster.