Site Migration Checklist Move Without Traffic Loss

Site migration checklist to move your website safely, protect visitors, and avoid the costly mistakes that derail launches.

A site migration checklist is a structured plan for moving a website to a new domain, CMS, hosting environment, URL structure, or architecture without losing important pages, links, tracking, or functionality. The safest migrations inventory the old site first, map every important URL, test the new site privately, configure permanent redirects, and closely monitor the move after launch.

A migration is not finished when the new site goes live; it is finished when the important old URLs, users, systems, and data have successfully found their new homes.

Why Site Migrations Go Wrong

A website migration looks deceptively simple from the outside: build the new site, point the domain at it, and launch.

The trouble is that a mature website is more than its visible pages. It has URLs, backlinks, internal links, redirects, analytics, forms, media files, canonical signals, localized versions, integrations, and years of accumulated history.

Change too many of those at once and small errors can become difficult to diagnose. Google specifically recommends changing one major thing at a time where practical and notes that significant moves can produce temporary ranking fluctuations while pages are recrawled and reindexed.

That makes the migration checklist less of a bureaucratic document and more of a chain of custody for your website.

What counts as a site migration?

A migration can involve much more than changing domains.

Common examples include:

Moving from one CMS to another
Changing domains
Moving from HTTP to HTTPS
Rebuilding URL structures
Moving hosting providers
Changing CDN or infrastructure
Combining multiple websites
Splitting one website into multiple properties
Replatforming an ecommerce store
Major information-architecture changes

Not every migration carries the same risk. A hosting change that keeps URLs identical is fundamentally different from moving thousands of URLs to a new domain. Google treats infrastructure-only moves separately from moves where visible URLs change.

Before Migration: Build Your Baseline

The best time to discover what your website contains is before you change it.

Start by crawling the existing site and exporting its important URLs, status codes, titles, internal links, canonical URLs, indexability information, and other page-level data. Then supplement that crawl with analytics, your CMS, XML sitemaps, backlink data, and server logs.

Google’s own migration guidance recommends using sitemaps, analytics, server logs, Search Console link data, and your CMS to identify URLs that need consideration. It also specifically warns not to overlook images, videos, JavaScript, CSS, and downloadable files.

Record the numbers that matter

Before launch, save a baseline for:

Organic and referral traffic
Top landing pages
Leads, sales, or other conversions
Indexed pages
Important page templates
Highest-value URLs
Backlinks to important pages
Crawl errors
Page-speed measurements
Core Web Vitals where available

This gives you something much more useful than a vague feeling that “traffic looks lower.”

For example, if overall traffic falls 12% after launch, you can determine whether that decline came from one broken product directory, missing redirects, a tracking problem, seasonality, or a genuine change in demand.

Build the URL Migration Map

If URLs are changing, the URL map is arguably the most important document in the entire project.

Create a simple table containing at least:

Old URL	New URL	Action	Priority	Notes
/old-product	/products/widget	Redirect	High	Same product
/guide-2019	/guides/current	Redirect	Medium	Content consolidated
/obsolete-page	,	404/410	Low	No replacement
/category-a	/collections/a	Redirect	High	New structure

The key is relevance, not simply making every old URL land somewhere.

If three related articles have genuinely been consolidated into one stronger resource, redirecting those three URLs to the consolidated page can make sense. Sending hundreds of unrelated URLs to the homepage does not create a meaningful replacement.

Google recommends mapping old URLs to corresponding new URLs and using server-side permanent redirects where possible. It also recommends avoiding redirect chains and sending visitors directly to the final destination.

Every important old URL should have a deliberate destination, or a deliberate reason not to have one.

Prioritize URLs instead of treating them equally

A 10,000-page website rarely needs identical attention on every URL.

Give extra scrutiny to pages that:

Generate significant traffic
Produce revenue or leads
Have strong external links
Rank for important topics
Receive substantial internal links
Are frequently visited by users
Are referenced in marketing campaigns

This creates a practical risk hierarchy. A broken redirect on your least-visited archive page is inconvenient; a broken redirect on your highest-revenue landing page is a launch blocker.

Prepare the New Site Before Launch

The new site should be treated as a controlled test environment, not a surprise reveal.

Keep staging private while development is underway. Check the site’s templates, navigation, forms, media, structured data, internal links, canonical URLs, localized versions, and analytics implementation before production.

One particularly nasty migration mistake is allowing staging restrictions to survive the launch. Development sites commonly use crawling restrictions or noindex directives; those controls need to be deliberately removed or changed when production begins. Google explicitly calls this out in its site-move documentation.

Run a content-parity check

Don’t assume that “the content was migrated” means the content actually arrived intact.

Compare representative pages from the old and new systems for:

Main copy
Product information
Images
PDFs and downloads
Titles and descriptions
Headings
Internal links
Structured data
Canonical tags
Language annotations
Embedded media

A CMS migration can fail quietly. A rich-text field may lose formatting, product descriptions may truncate, image paths may break, or an entire content type may simply fail to import.

A page can look perfectly polished while containing 40% less useful information than its predecessor.

Test Redirects, Canonicals, and Internal Links

These three systems should agree about where each page now lives.

Suppose an old article is:

example.com/blog/old-guide

and its replacement is:

example.com/resources/new-guide

The ideal setup is straightforward:

Old URL → 301 redirect → New URL

The new page should then link to itself as the preferred canonical URL, while the site’s internal links should point directly to the new address.

Google describes permanent server-side redirects such as HTTP 301 and 308 as the preferred mechanism when a page has permanently moved. Google also says permanent redirects are strong canonicalization signals.

Don’t make redirects do unnecessary work

Avoid this:

Old URL → Redirect A → Redirect B → Final URL

Prefer:

Old URL → Final URL

Google says its systems can follow multiple redirect hops, but recommends keeping chains low because they add latency and can create compatibility problems.

Also update internal links. Visitors should not click a new site’s navigation only to be sent through old URLs before arriving at the actual destination.

Validate Sitemaps, Robots Rules, and Canonicals

Your discovery and indexing signals need to tell one consistent story.

The production sitemap should contain the new URLs you actually want indexed, not the old URLs, staging URLs, redirects, or accidental parameter variations.

Google’s current sitemap guidance says sitemaps should use fully qualified URLs and generally contain the canonical URLs you want shown in search results. A single sitemap file is limited to 50 MB uncompressed or 50,000 URLs, after which multiple files or a sitemap index may be needed.

Canonicals deserve a separate check. Google considers redirects a strong canonical signal, rel=”canonical” a strong signal, and sitemap inclusion a weaker signal; these signals work best when they agree.

Be careful with robots.txt

robots.txt controls crawling; it is not a substitute for deciding which URL should be canonical.

Google explicitly advises against using robots.txt for canonicalization because a blocked URL can still potentially appear in search results without its content being crawled.

That distinction matters during migrations. Blocking an old URL does not magically transfer its history to the new one.

Check Performance and User Experience

A migration should preserve more than URLs.

If the new platform introduces slower templates, oversized images, heavy JavaScript, layout shifts, or sluggish interactions, users will notice even if every redirect works perfectly.

For Core Web Vitals, Google’s current guidance identifies three key metrics:

LCP: aim for 2.5 seconds or less
INP: aim for less than 200 milliseconds
CLS: aim for 0.1 or less

Don’t obsess over one synthetic test score, though. Compare important templates and real-world performance where data is available.

A migration that preserves traffic but makes checkout, navigation, or forms painfully slow is not a successful migration.

Launch Day: Use a Runbook, Not Memory

Launch day is where preparation earns its keep.

Create a time-ordered runbook with an owner for each critical action. Ideally, someone should be responsible for making the change while another person independently validates the result.

Launch-day checklist

Confirm backups are available
Confirm the final redirect rules are enabled
Remove staging-only crawl restrictions
Confirm production robots rules
Confirm canonical URLs
Publish the production sitemap
Confirm DNS changes
Confirm HTTPS certificates
Test priority old URLs
Test priority new URLs
Test forms and checkout
Verify analytics events
Check important third-party integrations
Check server capacity
Review error logs
Confirm Search Console access

For infrastructure moves, Google notes that the new environment may receive increased crawling after launch, so adequate server capacity matters.

What to Do After the Migration

The first few hours are for finding obvious breakage. The following weeks are for determining whether the migration has actually settled.

Crawl the old URL list again and verify that each important address reaches the intended destination.

Then monitor:

404 and 5xx errors
Redirect errors
Traffic by landing page
Conversions
Indexed-page trends
Sitemap processing
Crawl activity
Canonical selection
Server response times
High-value pages
Brand and non-brand traffic
Important external links

Google says temporary ranking fluctuations are normal during significant site moves and notes that, for medium-sized sites, it can take a few weeks or more for new URLs to gradually replace old ones. Larger sites can take longer.

So don’t declare the migration a failure, or a success, based solely on the first 24 hours.

Should you keep the old site?

Usually, keep the old URLs accessible through redirects rather than immediately shutting everything down.

For a domain migration, Google recommends keeping redirects in place and using its Change of Address tool when appropriate. The tool is specifically designed for moving from one domain or subdomain to another; it should not be used for ordinary HTTP-to-HTTPS changes or moving pages within the same site.

Google’s guidance was updated in June 2026 to clarify that domain migrations should account for all relevant domain variants, including www and non-www versions.

Site Migration Approaches Compared

Migration type	Main risk	Most important checks
Hosting change	Downtime, access problems	DNS, TLS, server capacity, crawl access
CMS migration	Missing or altered content	Content parity, templates, links, metadata
URL restructure	Lost destinations	URL map, redirects, internal links
Domain change	Loss of URL continuity	Redirects, domain variants, Change of Address
HTTPS migration	Mixed protocols	TLS, redirects, canonicals, internal links
Full redesign	Too many simultaneous changes	Content, URLs, templates, performance

The safest approach depends on what is changing. A hosting move with identical URLs does not require the same redirect strategy as a domain migration. Google explicitly separates hosting moves without URL changes from site moves where URLs change.

The Most Common Migration Mistakes

Redirecting everything to the homepage

This is fast but usually poor. Users looking for a specific product, article, or service deserve the closest relevant replacement.

Launching before the redirect map is finished

The redirect map should be treated as a launch dependency, not something to complete afterward.

Forgetting non-HTML assets

PDFs, images, videos, JavaScript, and CSS can have their own URLs, traffic, and external links. Google specifically includes these assets in its migration planning guidance.

Keeping staging restrictions in production

A forgotten noindex or overly restrictive robots rule can make a beautifully built website effectively invisible.

Changing everything simultaneously

A new domain, new CMS, new information architecture, new content, and new design launched together may be exciting, but diagnosing the resulting performance change becomes much harder.

Measuring only traffic

Traffic alone doesn’t tell you whether the migration worked. Revenue, leads, landing-page performance, crawl errors, conversions, and page-level behavior can reveal problems hidden by aggregate numbers.

FAQ

What is a site migration checklist?

A site migration checklist is a structured set of tasks for planning, testing, launching, and monitoring a website move. It typically covers URLs, redirects, content, infrastructure, analytics, technical settings, quality assurance, and post-launch monitoring.

How long should a site migration take?

There is no universal timeline. Small migrations can be completed quickly, while large or complex migrations may require weeks of preparation and monitoring. Google notes that medium-sized site moves can take a few weeks or more for new URLs to gradually replace old ones.

Do I need 301 redirects when changing URLs?

Yes, when an old URL has a relevant permanent replacement, a server-side permanent redirect such as a 301 is generally the preferred approach. Google recommends permanent redirects for URLs that have permanently moved.

Should old URLs redirect to the homepage?

Not by default. Redirect old URLs to their closest relevant replacement; if no meaningful replacement exists, allowing the old URL to return an appropriate 404 or 410 can be better than sending visitors somewhere unrelated.

When should you monitor a migration?

Monitor immediately after launch and continue for several weeks. Look at both technical signals and business outcomes rather than relying on a single traffic number.

Key Takeaways

A site migration checklist should begin before development ends, not on launch day.
Inventory the old site from multiple sources so valuable URLs don’t disappear from your migration plan.
Map important old URLs to relevant new destinations and use direct permanent redirects wherever appropriate.
Make redirects, canonicals, internal links, and sitemaps agree about each page’s preferred destination.
Test staging thoroughly, especially content, forms, analytics, crawl controls, performance, and integrations.
Expect some fluctuation after launch; Google says medium-sized migrations can take a few weeks or more to settle.
Keep monitoring after launch, because the most expensive migration problems are often discovered after the celebratory “we’re live” message.

Additional Resources

Site Moves and Migrations: A primary-source guide covering URL mapping, redirects, staging, timing, monitoring, and the practical mechanics of moving a website safely.