SEO Website Migration Checklist: Before, During & After Launch

A successful SEO migration is a URL and signal-preservation project, not just a development launch. Before the switch, you need a complete baseline and redirect map. During launch, the new site must return the right status codes, canonicals and crawl controls. After launch, you monitor crawling, indexing, traffic and conversions until the new URLs stabilize.

This checklist applies to domain changes, CMS migrations, redesigns with URL changes, HTTP-to-HTTPS moves and major architecture changes. For hands-on planning and QA, see our SEO migration services.

Before migration: define exactly what is changing

Start by classifying the move:

• domain change;
• CMS/platform change;
• URL structure change;
• HTTP to HTTPS;
• subdomain ↔ subfolder;
• merger/consolidation of multiple sites;
• hosting/CDN change without visible URL changes;
• redesign where URLs stay the same.

The risk profile is different for each. A hosting move with identical URLs does not require the same redirect program as a domain and architecture change.

1. Export the existing URL universe

Do not create a redirect map from one crawl alone. Combine:

• full site crawl;
• XML sitemap URLs;
• Google Search Console landing pages;
• analytics landing pages;
• server log URLs where available;
• backlinked pages from Search Console and backlink tools;
• paid campaign landing pages;
• known legacy redirects.

This becomes the migration inventory.

2. Record a pre-migration benchmark

Before release, save page-level data for:

• organic clicks and impressions;
• top queries;
• conversions/revenue;
• index coverage;
• crawl stats;
• top linked pages;
• rankings for priority topics;
• Core Web Vitals and performance;
• current canonicals and status codes.

Without a benchmark, a post-launch decline is much harder to diagnose.

3. Build a one-to-one redirect map

Every valuable old URL should map to the most relevant new URL. Avoid sending large groups of unrelated URLs to the home page. Google explicitly warns that irrelevant mass redirects can confuse users and may be treated as soft 404s.

When multiple old pages are genuinely consolidated into one stronger replacement, redirecting them to that consolidated page is appropriate.

4. Preserve content intent where possible

A technically correct redirect cannot compensate for a completely different destination. If the old page earned visibility for “technical SEO audit checklist,” the new destination should satisfy substantially the same intent.

This is especially important when consolidating legacy content. Merge overlap, but do not collapse unrelated subjects simply to reduce URL count.

5. Prepare canonical, robots and sitemap rules before launch

The production configuration should be ready before DNS or routing changes go live:

• new pages self-canonicalize to the correct production URL;
• staging noindex rules are removed from production;
• robots.txt does not block important sections;
• the XML sitemap contains the new canonical URLs;
• internal links point directly to new destinations;
• alternate language/hreflang annotations use the new URLs where relevant.

6. Test redirects before users and crawlers depend on them

For permanent moves, Google recommends server-side permanent redirects such as 301 or 308.

Validate:

• old URL → correct new URL;
• one hop wherever possible;
• no redirect loops;
• no redirect chains inherited from previous migrations;
• query parameters handled intentionally;
• HTTP and www/non-www variants resolve to the final canonical origin.

7. Crawl the staging/new site before launch

Run a full crawl and compare it with the migration plan. Check status codes, canonicals, headings, metadata, internal links, image references and structured data.

For JavaScript-heavy builds, inspect rendered HTML. Google can render JavaScript, but a migration is the wrong time to discover that key navigation or body content disappears before rendering.

Launch day checklist

8. Turn on redirects and canonical production rules together

Do not create a state where the old site is gone but redirects are not yet active. The launch sequence should make the new destination and redirect rules available at the same time.

9. Update internal links

Internal links should point directly to final new URLs rather than relying on redirects. This reduces latency and keeps the site’s own canonical signals consistent.

10. Publish the new sitemap

Submit the new sitemap in Search Console after launch. Keep it limited to canonical, indexable production URLs.

11. Verify representative URLs immediately

Test priority templates and top organic landing pages:

• old URL response;
• final destination;
• HTTP status;
• canonical;
• robots directives;
• rendered content;
• structured data;
• analytics and conversion tracking.

After launch: monitoring and recovery

12. Watch server errors and redirect misses

In the first days, monitor 404s, 5xx errors and unexpected redirect targets. Old URLs that still receive bot or user traffic but have no mapping should be reviewed quickly.

13. Compare Search Console page by page

Track the replacement URLs against the pre-migration benchmark. Aggregate site traffic can hide serious page-level losses.

Watch for:

• old URLs remaining indexed longer than expected;
• new URLs discovered but not indexed;
• canonical mismatches;
• important queries moving to the wrong landing page;
• sharp losses isolated to one template or directory.

14. Keep permanent redirects in place

Google recommends keeping redirects for as long as possible and generally for at least one year so signals can transfer and users/crawlers continue to reach the correct destination. In many cases it is sensible to keep high-value legacy redirects indefinitely.

15. Update important external links where practical

You cannot update every backlink, but you can contact owners of important links, update profiles and change advertising/campaign URLs. Direct links reduce reliance on the redirect layer.

16. Re-crawl the site and compare inventories

Repeat the crawl after launch and compare:

• old vs new URL counts;
• redirect coverage;
• orphan pages;
• canonicals;
• internal links;
• sitemap coverage;
• indexability;
• structured data.

How long does an SEO migration take to settle?

There is no fixed timeline. Google notes that small and medium sites can take a few weeks for most URLs to move, while larger sites may take longer. Server speed, site size, crawl demand and the quality of the mapping all affect processing time.

Temporary visibility fluctuations are normal. Persistent losses should be investigated against the redirect map, page equivalence, crawl/indexability and internal-link changes.

Migration mistakes that cause avoidable losses

• launching without a complete URL inventory;
• redirecting everything to the home page;
• creating chains through multiple historical migrations;
• forgetting staging noindex rules;
• shipping new canonical tags that still reference staging or old URLs;
• changing domain, CMS, navigation and content strategy simultaneously without a baseline;
• removing pages that still have strong backlinks or search demand without an equivalent replacement;
• leaving internal links pointed at redirected URLs;
• measuring only total traffic instead of page/query-level movement.

Migration checklist for project teams

If the move also changes your CMS or application architecture, pair this checklist with our custom CMS SEO requirements and technical SEO framework.

Sources and further reading

• Google: site moves with URL changes
• Google: changing hosting without URL changes
• Google: redirects and Search
• Google: canonicalization