Table of Contents

SEO Website Migration: A Practical Checklist for Changing URLs or Domains

Originally published: December 26, 2021 · Last updated: August 16, 2026

A website migration can be as small as moving to a new host or as disruptive as changing the domain, URL structure, CMS and design at the same time. From an SEO perspective, the risk depends on what changes for users and search engines.

The safest migration is the one you can explain URL by URL before launch.

First identify the type of migration

A hosting move with the same public URLs is mostly an infrastructure change. A domain change or URL restructure is a site move with visible URL changes. Google provides separate guidance for these scenarios because the search implications are different.

If you can avoid combining a domain move, redesign, CMS replacement and content rewrite into one release, do so. Changing several major variables together makes problems harder to isolate.

Create a complete URL inventory

Before touching the new site, collect the important URLs from several sources:

  • current XML sitemaps;
  • Google Search Console landing pages;
  • analytics;
  • internal crawl data;
  • important backlinks;
  • high-value commercial pages;
  • URLs still receiving traffic even if they are not in navigation.

This inventory becomes the basis for the migration map.

Map every old URL to its future state

Each important URL should have one deliberate outcome:

  • same URL: content remains at the existing address;
  • new equivalent URL: redirect old to new;
  • merged content: redirect to the genuine consolidated replacement;
  • removed with no replacement: return a real 404 or 410;
  • temporarily unavailable: handle as a temporary condition rather than inventing a permanent destination.

Do not redirect hundreds of unrelated old pages to the homepage just to avoid 404s. A redirect should represent a meaningful replacement.

Use permanent redirects for permanent URL changes

When a page has permanently moved, use a permanent server-side redirect such as 301 or 308. Google treats permanent redirects as a strong signal that the destination should become canonical.

Keep redirects direct. Old URL → new URL is better than old URL → intermediate URL → final URL.

Update internal links to the new destinations

Redirects are for visitors and external links that still use the old addresses. Your own navigation and contextual links should point directly to the new URLs after launch.

Update canonical tags, hreflang annotations, structured data references, image references and other internal URL signals where the migration affects them.

Prepare the new XML sitemap

The new sitemap should contain the URLs you want indexed after the move, not the old redirecting URLs. Submit it in Search Console and keep the old sitemap available temporarily if it helps Google discover the redirects and historical mapping.

A sitemap supports discovery; it does not replace redirects.

Check robots and noindex before launch

Staging environments are often protected with robots rules, authentication or noindex. Those protections must not accidentally reach production.

Before launch, verify that important public URLs are crawlable and indexable and that the production robots.txt does not contain a staging-wide block.

Keep Search Console verification working

Verify the relevant old and new properties before a domain move. If verification depends on an HTML file, meta tag or analytics configuration, make sure the method survives the migration.

For eligible domain changes, Google’s Change of Address tool can help communicate the move. Google updated its site-move guidance in June 2026 to clarify handling of domain variants, including www and non-www variants.

Test before opening the floodgates

Crawl the staging or pre-production version and check:

  • status codes;
  • canonical URLs;
  • internal links;
  • robots directives;
  • structured data;
  • forms and checkout;
  • mobile templates;
  • page titles and metadata;
  • sitemaps;
  • critical images and scripts.

A migration is easier to fix before DNS or redirects send every visitor to the new system.

Launch the redirects and new site together

When URLs change, the new content and the redirect map should be ready at launch. Avoid a period where old URLs disappear before their replacements are available.

If only hosting changes and URLs remain identical, update DNS after the new infrastructure is tested and monitor both old and new servers while traffic shifts.

Expect some temporary movement

Search performance can fluctuate while Google crawls redirects, processes new URLs and updates its signals. A short-term movement does not automatically mean the migration failed.

The useful question is whether crawling, indexing and traffic are converging toward the new site without systematic errors.

Monitor after launch

During the first days and weeks, watch:

  • Search Console indexing and crawl issues;
  • server logs for old and new URLs;
  • 404s and redirect chains;
  • organic landing-page traffic;
  • important query trends;
  • canonical selections;
  • conversion paths;
  • site performance.

Fix patterns rather than individual harmless errors. Ten thousand requests for one obsolete crawler URL may matter less than a single broken redirect on your main commercial page.

Keep redirects for the long term

Google recommends keeping site-move redirects in place for at least a year. In practice, if old URLs still receive external links or users may continue to use them, keeping stable redirects longer is often useful.

Do not remove redirect rules simply because the migration dashboard looks quiet after a few weeks.

Do not change every piece of content during the move

If the primary objective is to move URLs or infrastructure safely, preserve the core content and information architecture where practical. Large editorial changes can be made after the migration stabilizes.

This makes it much easier to distinguish a technical migration problem from a change in content relevance or search intent.

A practical migration checklist

  1. Define exactly what is changing.
  2. Inventory current URLs and important signals.
  3. Map every old URL to keep, redirect, merge or remove.
  4. Build and test the new site.
  5. Prepare permanent redirects.
  6. Update internal links, canonicals and structured references.
  7. Prepare the new sitemap.
  8. Verify robots and indexability.
  9. Confirm Search Console ownership.
  10. Launch the new site and redirects together.
  11. Monitor crawling, indexing, traffic and conversions.
  12. Keep redirects in place long enough for users and search systems.

The practical rule

A successful migration is a mapping exercise before it is a deployment exercise. Know where every important URL is going, preserve the signals that still matter and make the old-to-new relationship obvious. The more predictable the transition is, the easier it becomes to diagnose the inevitable post-launch noise.

Official references: Google site moves with URL changes and Google hosting migration guidance.