Website Migration SEO Checklist: Redirects, Canonicals, Sitemaps and Ranking Monitoring

Why website migrations need an SEO plan

A website migration can improve usability, performance, branding and conversion rates. It can also cause avoidable organic traffic losses when search engines cannot connect old URLs, new URLs and the content relationships between them.

A migration may involve a domain change, a redesign, a new content management system, a change in URL structure, a move from HTTP to HTTPS, a change in hosting, or several of these projects at once. Each change introduces different technical risks. A domain change requires careful redirects and domain verification. A URL restructure requires a complete mapping of old addresses to new destinations. A CMS rebuild can introduce accidental noindex directives, broken canonicals, changed headings or inaccessible content.

The safest approach is to treat SEO migration as a controlled release. Establish a baseline, create a URL migration plan, test the new site before launch, validate redirects on launch day and monitor crawling, indexation, traffic and rankings after the change.

This guide focuses on the technical and operational steps that help preserve existing search visibility. It does not replace a broader content, analytics or conversion review, but it gives your team a reliable framework for a website redesign SEO project or domain migration SEO project.

1. Define the migration scope

Start by documenting exactly what will change. Do not assume that a project described as a “redesign” is limited to visual changes. Confirm whether the migration includes any of the following:

• A new domain, subdomain or protocol.
• A new CMS, hosting platform or rendering architecture.
• Changes to URL paths, file extensions, trailing slashes or capitalization.
• Content removals, consolidations or category changes.
• Changes to navigation, internal links or breadcrumb structures.
• Changes to robots.txt, XML sitemaps, canonical tags or meta robots directives.
• Changes to analytics, Google Search Console or conversion tracking.

Assign an owner for SEO decisions, an owner for implementation and an owner for launch monitoring. A migration without clear ownership often leaves redirect rules, analytics validation or post-launch fixes unfinished.

2. Build a complete URL inventory

A URL migration plan is the central working document for the project. It should list important URLs on the old site, their proposed destinations and the implementation status for each mapping.

Use multiple sources to build the inventory. A crawl of the existing site can identify discoverable pages, while XML sitemaps, analytics data, search performance reports, server logs and backlink reports can reveal URLs that are not prominent in the current navigation. Include HTML pages, PDFs, images that receive search traffic, feeds and other indexable resources when they are relevant to the business.

Useful columns include:

• Old URL and new URL.
• HTTP status of the old URL.
• Primary topic or page type.
• Organic clicks, impressions or conversions where available.
• External links or referring domains.
• Redirect status and destination.
• Canonical target and indexability status on the new page.
• Review notes and implementation owner.

Map each valuable old URL to the most relevant equivalent new URL. Avoid sending many unrelated URLs to the homepage. If a page has no genuine replacement, return an appropriate status such as 404 or 410 rather than creating a misleading redirect. Whether a removed page should be redirected, replaced or retired depends on its content, links, traffic and role in the site structure.

3. Create and test the redirect plan

Permanent redirects are one of the most important parts of a website migration SEO checklist. They tell browsers and crawlers that a resource has moved and help users who follow old links reach the new location.

Use a server-level or platform-level redirect system where possible. Redirects should generally point directly from the old URL to the final new URL. Avoid chains such as old URL to an intermediate URL to a second intermediate URL to the final page. Chains add unnecessary requests and make troubleshooting more difficult.

Check every redirect for:

• The correct permanent redirect status, normally HTTP 301 or an equivalent platform implementation.
• A destination that is relevant to the original content.
• No redirect loops.
• No unnecessary redirect chains.
• Correct handling of uppercase and lowercase paths.
• Correct handling of query parameters and tracking parameters.
• Working HTTPS, hostname and trailing-slash rules.

Test redirects from a representative sample before launch, then crawl the complete redirect list after deployment. A redirect that works in a browser may still be wrong if it sends crawlers to a blocked, noindex, slow or irrelevant destination.

4. Preserve important page signals

Redirects alone do not preserve every SEO signal. Compare important old and new pages to confirm that the migration has not accidentally removed the information that made the original pages useful.

For priority URLs, review:

• Page purpose and primary search intent.
• Title element and meta description.
• Visible heading structure.
• Important copy, product details, service information or supporting content.
• Structured data that remains accurate and eligible for the page type.
• Internal links pointing to related pages.
• Image alt text and important media references.
• Canonical URL and indexability directives.

A redesign may shorten content, change templates or remove internal links without anyone intending to affect search. Compare a crawl of the old site with a crawl of the staging site so these changes can be reviewed before launch.

5. Validate canonical tags

Canonical tags help indicate which URL should be treated as the preferred version of substantially similar pages. During a migration, incorrect canonical tags can conflict with redirects, internal links or XML sitemaps.

On indexable pages, check that the canonical points to the intended final URL, uses the correct protocol and hostname, and does not point back to the old domain. Canonical URLs should normally be absolute and should resolve successfully. They should not point to a redirected URL, a blocked URL or a page with a different purpose.

Pay particular attention to templates that generate canonicals automatically. A single template error can place the same incorrect canonical on thousands of pages. Test product pages, category pages, articles, pagination patterns, filtered URLs and any localized or alternate versions separately.

Do not use canonical tags as a substitute for redirects when a URL has permanently moved. A redirect and a canonical serve different purposes: the redirect handles the old address, while the canonical expresses the preferred version among accessible page variants.

6. Review robots.txt and indexability controls

Staging environments are often protected from indexing, which is appropriate before launch. The risk is that the same restrictions remain when the production site goes live.

Before launch, identify every mechanism that can control crawling or indexation:

• Robots.txt rules.
• Meta robots directives.
• X-Robots-Tag HTTP headers.
• Password protection or IP restrictions.
• Login requirements.
• Canonical tags.
• HTTP status codes.

Confirm that important production pages are accessible to search engine crawlers and that intentionally private, duplicate or utility URLs remain appropriately restricted. A robots.txt rule can prevent crawling, but it should not be treated as a universal method for removing already indexed URLs. Indexation management should be planned separately when pages must disappear from search results.

7. Generate clean XML sitemaps

The new XML sitemap should contain the final, preferred URLs that you want search engines to discover and consider for indexing. Exclude redirected URLs, error pages, blocked pages, duplicate variants and URLs with a conflicting canonical.

If the site is large, use multiple sitemaps and a sitemap index where appropriate. Keep sitemap files technically valid and ensure they are accessible over the final HTTPS hostname. Submit the production sitemap in the relevant search engine tools after launch, and retain the old sitemap temporarily only when it serves a clear migration purpose and does not create confusion about which URLs are current.

Compare sitemap URLs with the URL inventory. A mismatch may reveal missing pages, accidental exclusions or pages that are being treated as important internally but are not intended to be indexable.

8. Test the staging site before launch

Staging is the best opportunity to find migration defects before they affect users and crawlers. Crawl the staging site with the same settings you expect to use for the production audit, while respecting access controls and the project’s security requirements.

Check for broken internal links, redirect chains, missing titles, duplicate titles, missing canonicals, unexpected noindex directives, blocked assets, incorrect language or location annotations, and pages that return the wrong status code. Test forms, navigation, search, pagination, filters and downloadable resources as well as standard content pages.

Compare key technical and content signals against the old site. If the new site intentionally changes a signal, record the reason so the change can be evaluated after launch rather than mistaken for an implementation error.

9. Prepare the launch-day SEO checklist

Launch day should use a written checklist rather than memory. The following sequence is practical for most migrations:

1. Confirm that the production domain, protocol and preferred hostname resolve correctly.
2. Remove staging-only access restrictions from production.
3. Publish redirect rules and verify a sample from every major URL pattern.
4. Confirm that important pages return HTTP 200 responses.
5. Check robots.txt and production meta robots directives.
6. Verify canonical tags on representative templates.
7. Publish the final XML sitemap and confirm that it contains current URLs.
8. Check analytics, consent handling and conversion tracking.
9. Verify Google Search Console properties for the old and new versions where applicable.
10. Test internal links, navigation, forms, structured data and important assets.

Capture the exact launch time and the version of the redirect and sitemap files deployed. This creates a useful reference when comparing traffic and crawl data later.

10. Monitor the first days and weeks

Do not judge a migration from a single day of traffic. Compare performance with suitable previous periods while accounting for seasonality, campaigns, weekends and other business changes.

Monitor organic clicks, impressions, indexed pages, crawl errors, top landing pages, conversion events and rankings for important queries. Segment the analysis by directory, page type, device and country when the site has meaningful differences between those groups.

Pay special attention to:

• Important old URLs that still return errors instead of redirecting.
• New pages that are excluded because of noindex, canonical or robots rules.
• Unexpected increases in 404, soft 404 or server errors.
• Redirects that point to irrelevant pages.
• Sharp declines isolated to a template, directory or content type.
• Pages receiving impressions but not clicks because titles or snippets changed.
• Conversion tracking failures that make SEO performance appear worse than it is.

Use search performance tools, server logs and a crawler together. Search data shows how visibility is changing, logs show how crawlers interact with the site, and crawling tools help identify implementation patterns. No single report provides a complete diagnosis.

11. Keep redirects and monitoring in place

Do not remove migration redirects immediately after launch. Old URLs can remain in search indexes, bookmarks, referral links and external websites for a long time. Keep redirects for as long as they continue to serve users or protect valuable references, and review them periodically for errors and unnecessary chains.

After the initial stabilization period, run a second audit. Review whether important old URLs have been replaced correctly, whether new pages are indexed, whether internal links still reference old addresses and whether ranking changes are concentrated in specific sections. Fix technical problems before changing content or making broad strategic conclusions.

Common migration mistakes to avoid

• Launching without a complete old-to-new URL map.
• Redirecting every removed page to the homepage.
• Leaving staging noindex or disallow rules on production.
• Publishing an XML sitemap containing redirected or canonicalized URLs.
• Changing URLs, content, navigation and templates at the same time without documenting the changes.
• Forgetting image, PDF, feed or alternate-language URLs that receive traffic.
• Testing only the homepage instead of representative page types.
• Removing redirects before old links and search results have been evaluated.
• Relying on rankings alone without checking indexation, crawl errors and conversions.

Final website migration SEO checklist

• Migration scope and responsibilities are documented.
• Important old URLs have been collected from crawls, analytics, search data and other sources.
• Each valuable URL has a relevant destination or a documented retirement decision.
• Redirects are direct, permanent, tested and free from loops.
• Canonical tags point to the intended final URLs.
• Robots.txt and indexability directives have been reviewed for production.
• XML sitemaps contain current, indexable, canonical URLs.
• Staging and production have been crawled and compared.
• Analytics, conversion tracking and search properties have been verified.
• Launch-day checks and rollback contacts are documented.
• Post-launch monitoring covers traffic, rankings, indexation, crawl errors and conversions.

A well-managed migration is less about making one perfect configuration and more about maintaining a clear chain of evidence: which URLs existed, where they moved, how search engines can access them and what changed after launch. Document the decisions, test before release and investigate problems by pattern. That process gives you the best chance of preserving rankings while still achieving the goals of the new website.

Because website migrations often affect hosting, access controls, domains and business data, include the project in your broader operational risk review. The Small Business Cybersecurity: Complete Guide for 2026 provides a complementary checklist for protecting accounts, websites, devices and cloud services during major digital changes.