SEO Migrations

Website Migration SEO Checklist: Before, During & After

A successful website migration requires benchmarks, URL mapping, staging tests, permanent redirects, updated search signals, and post-launch monitoring so search engines and users can reach the correct pages throughout the move.

Website migration SEO checklist covering redirects, crawlability, indexing, and launch validation

Quick overview

Summary

Document the existing website first, including priority URLs, organic performance, internal links, indexability, canonicals, and tracking .
Launch with consistent migration signals, including relevant permanent redirects, updated internal links, crawl access, canonicals, and XML sitemaps .
Validate the new website after launch by crawling old and new URLs, monitoring Search Console and analytics, and correcting unexpected errors quickly .

By Murat SEO · Technical SEO Specialist

A website migration can appear successful because the homepage loads, the navigation works, and nobody has reported a broken contact form.

Search engines are slightly less impressed by appearances. They need to understand which URLs moved, which pages disappeared, which version is canonical, and whether the new website can still be crawled and indexed.

The safest approach is to treat SEO as part of the migration plan rather than as a post-launch repair task. Establish reliable baselines, inventory the existing URLs, map old pages to relevant new destinations, test the staging website, and prepare validation checks before launch. During the move, activate permanent redirects and remove temporary crawl or indexing blocks. After launch, crawl the website again and monitor indexing, traffic, rankings, and conversions against the original benchmarks.

What Counts as a Website Migration?

A migration often needs a technical SEO specialist to translate URL changes, redirects, canonicals, sitemaps, tracking, and post-launch checks into testable implementation requirements.

A website migration is a substantial change that can affect how users and search engines access, understand, or evaluate the website.

Common examples include:

Moving to a different domain
Changing URL structures
Moving to another CMS or ecommerce platform
Redesigning templates or navigation
Consolidating websites or sections
Switching hosting providers or CDNs
Moving from HTTP to HTTPS

The checklist depends on what is changing.

A domain or URL-structure migration requires old-to-new URL mapping and permanent redirects. A hosting migration with unchanged public URLs focuses more heavily on infrastructure testing, DNS changes, server availability, crawl access, and monitoring.

Define the migration scope before building the checklist. Otherwise, important responsibilities tend to appear for the first time during launch—which is an exciting moment to discover that nobody prepared the redirects.

What Should You Do Before a Website Migration?

1. Establish performance benchmarks

Record the website’s current performance before changing it.

At minimum, capture:

Organic sessions
Search impressions and clicks
Rankings for priority queries
Conversions and key events
Indexed-page patterns
Top landing pages
Backlinks to important URLs
Crawl errors and server responses

Benchmarks help separate migration effects from existing problems or normal seasonal changes.

2. Crawl and inventory the current website

Run a complete crawl and save the results. The inventory should include:

Indexable URLs
Status codes
Page titles and headings
Canonical URLs
Meta robots directives
Internal links
Redirects
XML sitemap inclusion
Structured data
Image and document URLs where relevant

A broader Technical SEO audit checklist can help identify existing problems that should not be quietly copied into the new website.

Mark the pages that generate traffic, conversions, rankings, or backlinks. These priority URLs should receive additional testing before and after launch.

3. Define what will change

Document whether the migration affects:

Domain or hostname
URL paths
Protocol
CMS or platform
Templates
Navigation
Content
Internal linking
Canonical tags
Structured data
Analytics or tag management

Changing a domain, platform, design, architecture, content, and tracking system simultaneously creates more variables to diagnose. When practical, separate major changes or test them in controlled stages.

4. Test the staging website

The staging environment should be protected from accidental indexing, but it must still be testable by the migration team.

Check:

Templates and page rendering
Mobile layouts
Navigation and internal links
Forms and conversion paths
Canonicals
Structured data
Robots directives
Analytics and tag-manager implementation
Page speed and server stability
Search Console verification methods

Create a launch task specifically for removing temporary noindex directives, password restrictions, or robots.txt rules. Do not rely on someone remembering this while the launch channel is producing messages every twelve seconds.

5. Create the old-to-new URL map

Map every important old URL to its most relevant new destination.

Use sources such as:

Existing XML sitemaps
Website crawls
Analytics landing-page reports
Search Console performance data
Backlink exports
Server logs
CMS exports

An old product page should redirect to its direct replacement or the closest relevant alternative—not automatically to the homepage.

URLs for content that has been removed without a replacement may need to return 404 or 410. Redirecting unrelated pages to one generic destination can confuse users and may be interpreted as a soft 404.

6. Prepare the launch and rollback plans

Assign responsibility for:

Redirect implementation
DNS changes
Robots.txt and noindex removal
Canonical and hreflang checks
XML sitemap publication
Analytics and conversion testing
Full-site crawling
Search Console monitoring
Server-log review
Rollback decisions

Define the conditions that would justify delaying or reversing the launch. A rollback plan is much more useful when written before anyone needs it.

PLANNING A WEBSITE MIGRATION?

Protect the URLs and search signals that matter.

Get a focused migration review covering redirect mapping, crawl access, canonicals, tracking, launch checks, and post-launch validation.

View Migration SEO

What Should You Check During Migration and Launch?

1. Activate permanent redirects

When URLs change permanently, use server-side 301 or 308 redirects wherever technically possible.

Each old URL should redirect directly to its final relevant destination. Avoid unnecessary chains such as:

Old URL → Temporary URL → Previous Redesign URL → New URL

Search engines do not need a historical tour of the website before reaching the current page.

Test the redirects in bulk as soon as they are active. Check for:

Missing redirects
Redirect loops
Chains
Incorrect destinations
Redirects to error pages
HTTP and HTTPS inconsistencies
Hostname inconsistencies

2. Remove unintended crawl and indexing blocks

Confirm that the production website:

Is not blocked by a staging robots.txt file
Does not contain temporary noindex directives
Returns successful responses for indexable pages
Allows Googlebot to load essential resources
Does not require staging authentication

Inspect representative templates rather than checking only the homepage.

3. Update internal links and canonical signals

Internal links should point directly to the new URLs instead of relying on redirects.

Update:

Navigation
Breadcrumbs
Contextual links
Footer links
Image and document links
Pagination
Hreflang annotations
Structured-data URLs

Each preferred page should normally use an appropriate self-referencing canonical. Review canonical-tag best practices when the migration creates multiple accessible URL versions or conflicting canonical signals.

4. Verify tracking and Search Console

Check that:

GA4 is collecting real-time visits
Key events and conversions still fire
Google Tag Manager loads correctly
Consent behavior still works
Search Console verification remains active
New domain properties have been verified where required
Paid campaigns point to the correct landing pages

A migration without working measurement may appear calm simply because the reporting system has stopped observing it.

5. Publish and submit the updated XML sitemap

The new sitemap should contain current, canonical, indexable URLs returning successful responses.

Submit it in Search Console and confirm that Google can fetch it. Remove obsolete sitemap references when appropriate, but retain your migration records for later comparison.

For qualifying domain or subdomain moves, use the Change of Address tool after the site has moved and the redirects are active. It is not required for ordinary internal path changes, hosting migrations without visible URL changes, or HTTP-to-HTTPS moves.

What Should You Monitor After Migration?

1. Crawl both old and new URLs

Crawl the old URL list to verify that each address produces the intended outcome.

Then crawl the new website to identify:

Broken internal links
Unexpected 404 or 5xx responses
Redirect chains
Orphan pages
Incorrect canonicals
noindex pages
Missing titles or headings
Sitemap inconsistencies

Compare the post-launch crawl with the pre-migration version rather than evaluating the new site in isolation.

2. Monitor Google Search Console

Review:

Page Indexing
Sitemaps
Performance
Crawl Stats
URL Inspection for priority pages

Expect indexed old URLs to decline as new URLs are crawled and processed. Investigate unexpected spikes in not-found pages, server errors, blocked URLs, incorrect canonicals, or important pages remaining unindexed.

The guide to diagnosing indexing issues in Google Search Console provides a fuller workflow when important migrated URLs are missing from Google.

3. Compare performance with the baseline

Monitor:

Organic traffic
Search impressions and clicks
Priority-query rankings
Conversions
Revenue or lead volume
Organic landing-page coverage

Review page groups rather than relying only on total site traffic. A stable overall number can hide a serious loss affecting one profitable section.

4. Keep redirects in place

Migration redirects should not be removed after a few weeks. Search engines, users, external links, bookmarks, and old campaigns may continue requesting the old URLs.

Keep permanent migration redirects active for at least one year when possible, and longer when the old URLs still receive traffic or backlinks. Updating internal links reduces unnecessary redirect use, but it does not make the old URLs immediately irrelevant.

Is a Post-Migration Traffic Drop Normal?

Some ranking and traffic fluctuation can occur while search engines recrawl old URLs, process redirects, evaluate the new pages, and update their indexes.

However, a sharp or persistent decline should not automatically be dismissed as normal.

Investigate when the drop is accompanied by:

Important pages returning errors
Incorrect or missing redirects
Robots.txt or noindex blocks
Canonicals pointing to old or unrelated URLs
Missing internal links
Sitemaps containing the wrong URLs
Lost content or changed search intent
Server instability
Broken analytics or conversion tracking

The practical distinction is evidence. Temporary fluctuation with clean validation signals may require monitoring. A decline accompanied by technical failures requires action.

Common questions

Frequently Asked Questions

Should every old URL be redirected to the new homepage?

No. Redirect each old URL to its closest relevant replacement. Redirecting many unrelated URLs to the homepage can provide a poor user experience and may be treated as a soft 404.

How long should website-migration redirects remain active?

Keep permanent migration redirects for at least one year when possible. Retaining them longer can continue helping users and external links that still request the old URLs.

Do I need the Change of Address tool for every migration?

No. The tool is intended for qualifying domain or subdomain moves. It is not normally used for internal path changes, HTTP-to-HTTPS moves, www-to-non-www changes, or hosting migrations where public URLs remain unchanged.

Is a temporary ranking decline normal after migration?

It can be. Search engines need time to recrawl and process moved URLs. Persistent or severe declines should be investigated for redirect, crawlability, indexability, canonical, content, server, or tracking problems.

Should the migration launch happen during a low-traffic period?

When practical, choose a lower-traffic period that still allows the full team to monitor and respond. Avoid launching immediately before weekends, holidays, major campaigns, or periods when key developers are unavailable.

Final Thoughts

A website migration without SEO preparation can turn a technically successful launch into an organic-search recovery project.

The safest sequence is straightforward: document the current website, define what is changing, map old URLs, test the staging environment, launch with consistent redirects and indexing signals, and validate the new website immediately.

Prioritize revenue-generating and high-visibility pages first. Monitor them in Search Console, analytics, crawl data, and server logs until their redirects, indexing, traffic, and conversions behave as expected.

For complex domain, platform, or architecture changes, Technical SEO audit and migration support can help translate the migration plan into testable requirements, implementation checks, and post-launch validation.