SEO migration checklist for old domains

A website migration often looks simple from the outside. New design, new CMS, maybe a cleaner domain. Then a buyer searches the brand, a product certificate, or an old case study and lands on a dead URL. The new site may look better, but the old search paths are gone.

That is the part teams underestimate. An SEO migration is less about moving pages and more about preserving routes that already worked. Old URLs may have backlinks, rankings, sales history, bookmarks, and internal documents pointing to them. If those routes break, the business feels it before the dashboard explains it.

Google's own guidance on site moves with URL changes recommends building a list of old URLs and mapping them to new destinations for more complex moves. That is the backbone of this checklist.

Use this when you are changing domains, moving from an old CMS, rebuilding a corporate site, or cleaning up an international site before a market push. If you need hands-on help, our global website and SEO support starts with this kind of audit before design or development decisions get locked in.

Short answer #

An old domain migration should preserve working entry points before the new site takes over. At minimum, export old URLs, mark their value, map each important URL to a new destination, set permanent redirects, check canonicals, sitemaps, and robots.txt, then monitor Search Console for 2 to 4 weeks.

Main risk #

The risk has two sides: old signals and new crawlability.

Old signals include backlinks, branded search demand, indexed product pages, case studies, and links your sales team has already shared. New crawlability includes robots.txt, sitemaps, canonicals, redirects, status codes, internal links, and page content.

A migration fails when the old signals point nowhere useful, or when the new site sends mixed signals about what should be indexed.

Before the move #

Start with an old URL inventory. It does not have to be perfect on day one, but it should be good enough to stop valuable pages from disappearing by accident.

Pull URLs from these places:

• Google Search Console pages with impressions or clicks.
• Analytics pages with organic sessions in the last 6 to 12 months.
• Backlink exports from SEO tools or partner records.
• URLs used by sales teams in emails, PDFs, catalogs, and proposals.
• Indexed pages found through site:example.com checks.
• CMS pages that still exist but are no longer linked from navigation.
• Product, certificate, case study, download, and contact pages.

If the project is part of a broader rebuild, pair this with a wider SEO preservation plan. That process covers redesign risk. This article focuses on domain, URL, and index migration.

URL map #

The URL map is the most boring file in the project. It is also the file that saves the most traffic.

A useful map includes at least these columns:

Do not leave the action column vague. Write the decision: redirect, merge, rewrite, keep, delete, or review. If this decision is unclear before launch, it will be made in a hurry during launch.

Redirects #

When a page has permanently moved, use a server-side 301 or 308 where possible. Google's redirect documentation says permanent server-side redirects are the recommended way to direct Google Search and users to the correct page when a URL changes.

A few rules keep migrations sane:

• Do not redirect every old URL to the homepage.
• Do not build long redirect chains.
• Point old product pages to the closest matching product or category.
• Redirect merged articles to the new consolidated page.
• Update internal links to the new URLs after launch.
• Keep redirects for at least a year, and longer if old URLs still receive visits or backlinks.

Homepage dumping is one of the easiest mistakes to make. It feels efficient, but users do not get the answer they expected, and search engines may treat many of those redirects as soft 404s.

Content calls #

A migration is not a copy-and-paste job. Old content needs decisions.

Keep pages that bring traffic, links, leads, or proof. Product capability pages, certifications, technical downloads, case studies, and market landing pages usually belong here.

Merge thin pages when several old URLs answer the same question. Three short posts about one product application may become one stronger guide. Each old URL can redirect to the new guide.

Remove pages with no traffic, no links, stale information, and no business use. Old event notices, empty tag pages, and duplicate archives often fall into this bucket.

The hard part is not SEO theory. It is knowing which old pages sales, support, partners, or distributors still use. For messy content projects, work through a separate content migration checklist before writing redirect rules.

Technical checks #

These checks should happen before launch, not after traffic drops.

• Canonicals point to final new URLs.
• Robots.txt does not block important sections.
• XML sitemaps include only indexable new URLs.
• Important pages return 200.
• Old URLs return 301 or 308, not 302, JavaScript redirects, or meta refresh.
• The 404 page helps users find products, resources, or contact options.
• Hreflang points to equivalent pages on the new URL structure.
• Structured data uses the new domain, logo, Organization, Article, and Service URLs.

Google's robots.txt documentation notes that the sitemap field should use a fully qualified URL. It also explains how HTTP status codes affect how robots.txt is used. Small syntax or availability issues can create confusing crawl behavior, so include robots.txt in the launch checklist.

For a deeper baseline, connect this work to your technical SEO checklist. If terms like canonical, sitemap, hreflang, and UTM still cause meeting-room confusion, keep a simple website glossary nearby.

Search Console #

Search Console is not a tool you open after the move. Verify the old and new properties before launch.

If you are moving from one domain to another, such as old.com to new.com, use the Change of Address tool after redirects are in place. The tool is for domain-level moves. It is not for HTTP-to-HTTPS moves or for moving a few paths inside the same site.

After launch, check these areas:

• Page indexing issues such as 404s, blocked pages, duplicate pages, and redirect URLs.
• Performance changes for brand terms, product terms, and target countries.
• Sitemap discovery and processing.
• URL Inspection for priority pages, including selected canonical and last crawl date.
• Crawl stats for spikes in 5xx errors or unusual crawl patterns.

The Page indexing report is not instant. Google's documentation explains that server errors can be temporary, and a live test may pass even if Google previously saw a crawl failure. Watch the data for at least 2 to 4 weeks.

Common mistakes #

These are the issues I would check first when a migration loses traffic:

1. The old domain expired.
2. Most old URLs redirect to the homepage.
3. Redirect chains are too long.
4. The new site still has noindex from staging.
5. Canonicals point to the test domain.
6. The sitemap includes old URLs, test URLs, or 404s.
7. International pages do not match across languages.
8. PDFs, images, and case study links were skipped.
9. Thank-you pages are indexable.
10. Nobody checks Search Console after launch.

If time is tight, protect the URLs that already have traffic, backlinks, brand demand, or sales value. Archive pages can wait.

What can wait #

Not every site update needs a full migration project.

If you are only editing page copy and keeping URLs stable, you probably do not need a Change of Address request or a large redirect map. Check titles, internal links, and content quality instead.

If you are moving from HTTP to HTTPS, set up sitewide permanent redirects and update internal links and sitemaps. Do not use the Change of Address tool for that move.

If the site is new and has no old domain, old backlinks, or old indexed pages, there is no old SEO equity to migrate. Focus on structure, content, and crawlability.

The practical test is simple: if an old URL still matters to search, sales, customers, or partners, put it in the migration map.

Deliverables #

A clean migration should leave behind a few plain files:

• Old URL inventory.
• Old-to-new URL map.
• Redirect rules or CMS redirect settings.
• Pre-launch SEO checklist.
• Search Console verification notes.
• Post-launch monitoring sheet.
• Content merge and rewrite backlog.

These documents are not only for SEO. They help founders, sales teams, developers, and content owners agree on which pages matter and what to check if traffic drops.

Next step #

If you are preparing a domain change, CMS migration, or rebuild, bring the current site, target markets, and Search Console access into the first review. We will look at old URLs, indexed pages, backlinks, and high-value search queries before deciding what must move, what can merge, and what should be left behind.