A website migration can preserve organic visibility, but only when URLs, redirects, canonicals, internal links, sitemaps, and measurement are managed as one system. This SEO site migration checklist gives you a phase-by-phase workflow for planning the move, validating the launch, diagnosing problems, and monitoring performance after release.
Overview
A migration includes more than changing a domain. It can involve a redesign, CMS change, hosting move, HTTPS implementation, URL restructuring, or several of these changes at once. Each variation creates different risks, but the central SEO objective is the same: help users and search engines find the correct replacement for every important old URL.
The safest approach is to treat migration as a controlled technical project rather than a single launch-day task. Build a complete URL inventory, preserve valuable content where possible, map old URLs to the most relevant new destinations, test the staging environment, and compare post-launch data with a documented baseline.
Do not assume that every old URL should redirect to the home page. A redirect should normally lead to the closest useful replacement. If no comparable page exists, review whether the old URL should return an appropriate status or be retired. Irrelevant mass redirects make troubleshooting harder and may create a poor user experience.
Before starting, record baseline data for organic clicks, impressions, indexed pages, top landing pages, conversions, crawl errors, important rankings, and backlinks. A monthly dashboard such as the SEO reporting template can help organize the comparison.
What to track
1. Build a complete URL inventory
Export URLs from several sources instead of relying on one crawl. Combine your XML sitemap, analytics landing pages, Search Console performance data, server logs if available, CMS records, and a backlink audit. Include image, PDF, feed, pagination, and other indexable asset URLs when they matter to the site.
For each URL, record its current status code, indexability, canonical URL, title, organic clicks, impressions, conversions, backlinks, and proposed destination. Mark URLs that have no replacement so they receive an explicit decision rather than disappearing accidentally.
2. Use a redirect-mapping template
Maintain the mapping in a shared spreadsheet or migration system. A practical format is:
| Old URL | New URL | Action | Status | Owner | Validation note |
|---|---|---|---|---|---|
| /old-guide | /new-guide | 301 redirect | Pending | SEO | Check destination relevance |
| /old-category | /resources | Review | Pending | Content | Confirm equivalent content |
| /outdated-page | None | Retire | Pending | Product | Check backlinks and traffic |
Use permanent redirects for a permanent URL change, and avoid redirect chains. The ideal path is one request from the old URL to the final destination. Update internal links to point directly to new URLs instead of relying on redirects indefinitely.
3. Validate technical signals
On the new site, check that important pages have a self-consistent canonical, are not blocked by robots directives, return the intended status code, and appear in the correct XML sitemap. Confirm that staging protections will not remain active after launch. Review hreflang, pagination, image paths, structured data, and mobile rendering where those features are part of the site.
Structured data should be tested against the page content and maintained after templates change. The schema markup guide provides a useful maintenance workflow.
4. Test the user and crawler paths
Before launch, crawl the staging site or a representative authenticated copy. Test navigation, search, forms, JavaScript-dependent content, downloads, login boundaries, and key conversion journeys. Sample high-value URLs manually and with a crawler. Verify that links do not point to staging, old domains, temporary paths, or mixed HTTP and HTTPS versions.
Cadence and checkpoints
Pre-launch checkpoint
- Freeze or document the final URL structure.
- Complete the old-to-new redirect map.
- Save baseline analytics, Search Console, crawl, and backlink data.
- Test representative templates and high-value URLs.
- Prepare the new XML sitemap and review robots directives.
- Confirm canonical, hreflang, structured data, and internal-link behavior.
- Assign launch-day owners for engineering, SEO, analytics, and communications.
Launch-day checkpoint
Test a sample of old URLs immediately after deployment. Confirm that redirects resolve to the intended HTTPS or canonical host, that new pages return successful responses, and that no broad noindex or disallow rule has been introduced. Submit or resubmit the new sitemap through the site’s normal search-engine tools when appropriate, and monitor server errors, redirect errors, and crawl activity.
First 48 hours
Check critical pages several times during the first day and again on the second day. Review real-time analytics for broken journeys, server logs or monitoring alerts for spikes in errors, and Search Console for indexing or coverage changes as data becomes available. Test the old domain, new domain, primary subdomains, redirects, canonical host, and important parameter variations.
First two weeks
Run a fresh crawl and compare it with the pre-launch crawl. Look for redirect chains, redirect loops, orphan pages, broken internal links, unexpected canonical targets, blocked resources, duplicate URL variants, and large changes in indexed page counts. Segment organic traffic by landing page, directory, device, country, and search type rather than judging the entire site from one total.
Monthly or quarterly review
Keep a migration log with the date, symptom, affected URLs, likely cause, action taken, and result. Recheck redirect coverage, important landing pages, crawl errors, sitemap status, indexation, branded and non-branded traffic, conversions, and backlinks. For larger publishers, pair this review with a recurring crawl budget audit.
How to interpret changes
Not every traffic change proves that the migration failed. Compare like with like: the same days of the week, the same country and device segments, and the same page groups. Separate the effects of the migration from seasonality, content changes, tracking changes, promotions, outages, and broader search volatility.
A sharp decline isolated to URLs with missing redirects points toward redirect coverage or destination problems. A decline across many pages with a rise in excluded or blocked URLs suggests a robots, noindex, canonical, or rendering issue. Traffic may remain stable while conversions fall because forms, analytics events, checkout steps, or page speed changed during the redesign.
When impressions fall but rankings appear stable, inspect indexation, query demand, snippets, tracking configuration, and landing-page eligibility. When clicks fall while impressions remain similar, review titles, descriptions, rich-result eligibility, search intent alignment, and changes in the search results. Use Search Console insights alongside analytics rather than treating either platform as a complete explanation.
For a more disciplined diagnosis, create a URL validation table:
| Check | Expected result | If it fails |
|---|---|---|
| Old URL | Resolves once to the intended new URL | Fix missing redirect, chain, or loop |
| New URL | Returns the intended status and content | Review deployment, routing, or server rules |
| Canonical | Points to the preferred indexable URL | Correct template or canonical logic |
| Robots directives | Important pages are crawlable and indexable | Remove accidental blocks or noindex rules |
| Sitemap | Contains valid preferred URLs | Regenerate and remove obsolete entries |
| Internal links | Point directly to current URLs | Update navigation, content, and templates |
If the issue is broad or unclear, avoid making multiple unrelated changes at once. Prioritize errors affecting the largest number of important URLs, fix one class of problem, and measure the result. The Search Console traffic-drop workflow can help structure that investigation.
When to revisit
Revisit this checklist before every domain change, redesign, HTTPS move, CMS migration, hosting change, or URL restructure. After launch, schedule reviews at 24 hours, 48 hours, two weeks, one month, and then monthly or quarterly until the migration is stable and the issue log is closed.
Update the checklist when your CMS, routing rules, analytics implementation, sitemap process, or search-console workflow changes. It is also sensible to review it after major crawling or indexing changes documented by search engines, but avoid changing a stable migration process based only on informal speculation.
For the next review, duplicate the redirect and validation tables, attach a fresh crawl, and record the baseline comparison. Start with these five actions:
- Export current organic landing pages and important indexed URLs.
- Check the redirect map against live responses.
- Compare sitemap, canonical, robots, and indexation signals.
- Segment traffic and conversions by affected URL groups.
- Assign an owner and deadline for every unresolved issue.
A migration is complete when important users and crawlers can reliably reach the right destinations, measurement is trustworthy, and the remaining differences are understood. Keeping the checklist and evidence makes the next migration faster without treating any platform or URL structure as permanently risk-free.
