SEO Migration Checklist for Old Domains and Websites

The short version #

Failed migrations rarely look like bad design. They look like traffic that vanishes overnight. The cause is almost always one of the same handful of mistakes: old URLs never inventoried, 301s pointed at the homepage, canonicals stuck on the staging domain, sitemaps full of dead URLs, robots.txt left on Disallow: /. This is the checklist we run on every overseas B2B migration. Inventory, decide, map, ship, monitor. Plus the ten failure modes we've personally hit and learned to spot in the first ten minutes of an audit. The goal is the boring one. Organic traffic back to 90%+ of pre-launch within two weeks.

The most painful one we ever inherited was a Chinese exporter moving from .com.cn to .com. The agency moved 80 product pages cleanly. They also forgot about 200+ blog posts in the old CMS, written by an intern five years earlier. By day three, brand-plus-SKU searches still landed on the new site. Long-tail industry queries lost 80% of their clicks. The new site wasn't bad. The old URLs Google had indexed for years were just hitting 404.

All of it was avoidable. The checklist below is what we wish that team had run.

1. Inventory #

The biggest trap before mapping anything is assuming you know what's on the old site. You don't. CMS dashboards lie. The site you remember has 50 pages; Google's index has 800.

Pull a complete URL list from at least four sources, then dedupe:

• Old CMS export: every published page, including blog, news, retired products, draft pages mistakenly marked public.
• Google Search Console: export both "Indexed" and "Not indexed" tabs from the Pages report. The "Crawled - currently not indexed" bucket is the hidden one. Mishandled, those URLs disappear silently after migration.
• Server logs or GA4: every URL with at least one organic visit in the last 12 months. This is your real traffic surface.
• Ahrefs / SEMrush: every URL with external backlinks. Backlinks are the most expensive asset in any migration. Lose one, you have to earn another.

Merge into one master spreadsheet. Required columns: old URL, current status code, 12-month clicks, backlink count, content type (product / service / case / blog / landing). Every later decision keys off this sheet.

2. Keep, merge, kill #

Not every page deserves to migrate. Each URL gets exactly one of three labels:

• Keep and 1:1 migrate: meaningful traffic, backlinks, or commercial intent. The new site needs a corresponding URL with a clean 301.
• Merge into a new page: thin or overlapping pages that compete with each other. Combine into one stronger page; 301 every old URL to it.
• Kill with 410: low-quality, no traffic, no backlinks (placeholder posts, expired event pages, duplicate PDFs). Use 410 Gone, not 404. Google drops 410s from the index faster.

This is the step that exposes weak judgment. We see two failure patterns. One: 301 every old URL to the homepage. Google reads that as soft 404 and effectively deletes them all. Two: nuke half the site to "modernize" and lose three years of long-tail rankings along with it. Both are wrong. The decision criterion: when did this URL last drive a real inquiry, and how likely is it to drive one again?

Related: How to Preserve SEO During a Website Rebuild has a more detailed keep/merge/kill decision tree.

3. URL mapping #

For every "keep" or "merge" entry in the master sheet, name the new URL. Output is a CSV that an engineer can paste straight into Nginx, Cloudflare Workers, or a WordPress redirect plugin:

Common landmines:

• No redirect chains (A → B → C). Each hop bleeds equity, and Google reduces crawl after two hops. Always rewrite to A → C.
• No "everything to homepage". Google flags those as soft 404 in bulk. The old URL effectively dies.
• Normalize case, trailing slashes, www / non-www, http / https. Inconsistency means one logical page indexes as four URLs and the migration scrambles them.
• Strip tracking parameters in canonical. ?utm_source=... should never split a page into multiple indexable variants.

Field-level checklist: Website Content Migration Checklist.

4. Canonicals, sitemap, robots #

Three things must be right on launch day, not the week after:

• Canonical: every new page declares <link rel="canonical"> pointing at itself. Multilingual versions cross-reference via hreflang, but each canonical points to its own language. The textbook disaster: every page canonicalized to the homepage. The site indexes nothing.
• Sitemap.xml: only new URLs. No old URLs. No noindex pages. lastmod must reflect the actual change date; bulk-stamping today's date gets the file ignored. Over 50,000 URLs? Use a sitemap index.
• Robots.txt: staging probably had Disallow: /. On launch day, that line has to go. The most expensive bug we've seen on a migration was a Disallow: / left in for 31 days. The site was effectively invisible the entire month.

Authoritative references: Google Search Central — Site moves with URL changes and the SEO Starter Guide.

5. Search Console #

If the domain is changing, you have to run the Change of Address flow in Google Search Console, not just add the new property:

1. Add the new domain as a property and verify ownership.
2. Submit the new sitemap on the new property.
3. Open the old property's Settings, run "Change of Address". Google auto-checks that 301s and the homepage are reachable.
4. Keep the old property for at least six months. Its historical data is the only thing you can compare against later.

If only the CMS is changing and the domain stays, skip Change of Address but still re-submit the sitemap so Google re-crawls fast. Bing Webmaster Tools follows the same pattern; don't forget it for European and US B2B searches.

6. Pre-launch QA #

In the 24 hours before launch, one person walks this list end to end:

• Run Screaming Frog (or httpx) over the old URL master sheet. Every "keep" row must return 301 → 200. No 302. No chains. No 404.
• Spot-check canonicals on the live URLs. None should still point at the staging domain. This is the single most common low-grade fail.
• Disallow: / is removed from robots.txt. sitemap.xml is reachable.
• Internal links across the new site point to new URLs directly. Don't rely on the 301s for in-site navigation; that's just wasting redirects.
• GA4, Search Console, and Bing Webmaster verification tags are in place.
• DNS TTL was reduced to 300 seconds 24 hours earlier so rollback is fast.

Two people, independent passes, compare results. Every smooth migration we've shipped did this; every messy one skipped it.

7. The first 30 days #

The migration doesn't end at launch. The next four weeks are where you catch the silent failures:

• Days 1–3: Search Console crawl stats. New URLs should start showing up as "crawled". If after three days Google is still hammering old URLs more than new ones, the sitemap or internal linking is wrong.
• Week 1: focus on the "Not indexed" report. Old URLs should be moving into "Page with redirect", which is the healthy signal. A spike in "Soft 404" means a chunk of 301s landed wrong; fix immediately.
• Week 2: organic traffic is usually down 10–30%, which is normal. If a single page type (e.g., every product page) drops below 30% of baseline, that group's mapping is broken.
• Weeks 3–4: traffic should be back to 90%+ of pre-launch. Run an internal review: which URLs didn't recover, why, and which ones are worth a manual rescue.

For the monitoring playbook, see How to Measure SEO with Search Console and Analytics.

Top 10 failures #

Ranked by frequency in our own debugging, not alphabetically:

1. Old blog never inventoried, 200 posts hit 404 on day one.
2. Every old URL 301'd to the homepage. Soft 404 everywhere.
3. Canonicals still pointing at the staging subdomain. Nothing indexes.
4. Disallow: / left in production robots.txt for weeks.
5. Redirect chains (old → interim → new) bleeding equity at every hop.
6. Sitemap full of noindex or 410 URLs, wasting crawl budget.
7. Internal links not rewritten, every click costs a redirect hop.
8. Hreflang missing, language variants competing for the same query.
9. No Change of Address in Search Console. Old property data freezes.
10. GA4 cutover with no annotation, so post-launch comparison is unreadable.

Each of these maps to one concrete check. Pin those ten at the top of the migration doc and you'll catch most of what would otherwise leak.

Migration table #

FAQ #

Traffic dropped 30% — is that normal? #

Weeks 1–2: 10–30% drop is expected. Weeks 3–4: should be back above 90%. If you're still under 70% by week four, the "Not indexed" report in Search Console will usually tell you why. Typically a 301 chain, a canonical pointing the wrong way, or a content type that got over-pruned.

Do we have to change the domain? #

Not always. If the old domain has clean history (no PBN, no manual penalty), keep it and just swap the CMS. A domain change costs three to six months of authority rebuilding at minimum. If .com.cn is genuinely hurting trust with overseas buyers, the change is worth it. If you "just want a fresh look", run an audit first using the Complete Website Renovation Audit Checklist before committing.

How long do the 301s need to stay? #

At minimum 12 months. Permanently is better. Google usually transfers equity within 6–12 months, but external backlinks can keep pointing at old URLs for years. Bake the redirect rules into the Nginx or Cloudflare config and treat them as a long-term asset.

What about Bing and Yandex? #

For Russia, Eastern Europe, and parts of the Middle East, run Yandex separately. Submit the sitemap to Yandex Webmaster. Bing still drives 8–10% of overseas B2B search traffic in North America and Europe; run the same Change of Address flow inside Bing Webmaster Tools. Baseline technical SEO settings are covered in Technical SEO Baseline for a New or Rebuilt Website.

Book a review #

If you're planning a migration, or you just shipped one and the numbers look wrong, send us the old site, the new site, and the cutover timeline. We'll run this checklist against your project as a free initial review under our overseas website build and SEO/GEO support service, and tell you which items are P0 fixes versus what can wait until next quarter.