The SEO Migration Checklist for Site Changes

Migrations are where well-ranked sites lose the most visibility in the shortest time. A redesign, a platform change, a domain move, or even a URL restructure can detach years of accumulated signals if the transition is handled casually. The checklist below treats a migration as a controlled project with a before, a launch window, and a monitored aftermath — because that is the only version of a migration that preserves search equity.

Before any code changes, build a complete URL inventory. Export every URL that currently receives organic traffic, every URL that earns links, and every URL in the XML sitemap. Combine those into one sheet with traffic, impressions, and backlink counts where available. This inventory becomes the source of truth for redirect mapping, and it is the only way to know after launch whether anything was overlooked.

Next, map every old URL to its new destination. Most URLs should map one-to-one to the closest equivalent page. Pages that genuinely no longer exist should return a 404 rather than redirect to the homepage, because a homepage redirect tells search engines nothing about the lost content. Group redirects by template where possible — thousands of product URLs can often be handled with a pattern rule — but verify that pattern rules produce the intended destination before trusting them.

Keep redirects to a single hop and use permanent status codes for permanent moves. Chains and loops waste crawl attention and dilute the signal transfer. If the migration also changes the domain, redirect every URL on the old domain, including images and other assets that receive requests. Do not redirect unrelated domains to the new site, and do not use temporary redirects for a permanent change. Test a sample of redirects with a command-line request or a browser before launch rather than after, and archive the output so the expected behavior is documented when someone questions it later.

Decide what does not need to change. URLs that can stay identical should stay identical, even if the page design is rebuilt around them. Every preserved URL is a page that does not need to be re-evaluated from scratch. This principle applies to parameter structures, trailing-slash conventions, and case sensitivity as well: pick one canonical form and enforce it with server rules rather than relying on search engines to guess.

Prepare the staging environment carefully. Staging sites should use authentication rather than noindex to keep crawlers out, because a forgotten noindex directive is the classic launch-day catastrophe. If stashing the site behind HTTP authentication is not possible, verify that robots.txt blocks crawling and that noindex tags are removed as part of the deployment checklist. Test that production robots.txt and sitemap files exist and return 200 status codes before the switch.

On launch day, remove every staging restriction, deploy the production robots.txt, submit the new XML sitemap, and verify that the canonical tags point to the new URLs — not to the old domain. Update the sitemap reference in robots.txt, confirm that Search Console has both the old and new properties verified, and use the Change of Address tool if the domain changed. If only URLs changed, update the internal links rather than relying solely on redirects.

Quality assurance after the switch should cover more than the homepage. Crawl the new site and check status codes, redirect targets, page titles, canonicals, and hreflang if the site is multilingual. Spot-check high-value pages in a browser with JavaScript disabled, test forms and checkout flows, and confirm that analytics and conversion tracking still fire. A migration that preserves rankings but breaks checkout is not a successful migration from the business's perspective.

The first two weeks after launch are for monitoring, not celebrating. Watch the Crawl Stats report for spikes in errors and the Page Indexing report for new exclusions. Compare impressions on the old and new URLs, and expect temporary turbulence as signals transfer. Keep the old domain active and renew it for years if the migration involved a domain change; letting it expire invites another business to inherit residual traffic.

Weeks three through eight are where the outcome becomes visible. Track the migration cohort — the specific URLs that carried the most traffic before — against their new equivalents. If a pattern of pages is underperforming, inspect their redirects, canonicals, and internal links. Content improvements made during a redesign can mask problems: if a page changed both its URL and its content, separate the two when diagnosing a drop.

Finally, document the migration and keep the redirect map in version control. Future platform changes will need it, and so will the person who inherits the site. A migration is successful when organic visibility recovers to its previous trajectory and the team knows exactly which URLs moved where — not when the new design goes live. Schedule a formal review at week twelve to decide whether any redirect or consolidated page needs adjustment.