An SEO Migration Checklist for the Weeks Before, the Day Of and the Weeks After a Site Move

An SEO migration checklist is an ordered list of checks that keeps pages findable in search when their addresses, domain or platform change. You need one whenever a URL that has traffic or links will stop answering at its old address: a move from HTTP to HTTPS, a new domain, a new URL structure, or a platform change that rewrites paths.

Not every project qualifies. A redesign that keeps every URL identical carries far less risk, and moving hosts without changing addresses needs a lighter version of this list. Google treats those as different cases from a move that changes URLs, and so should you. If you can avoid changing addresses, avoid it. Every URL that moves is a URL Google has to relearn.

The rest of this checklist follows Google's guidance for moves with URL changes, in three phases. Read it once end to end before you assign owners, because several launch-day tasks depend on decisions made weeks earlier.

Before launch, take an inventory of what exists, decide what each old page will become, and prepare the new site so it can be indexed the moment you flip the switch. Most migration damage is decided here, because the launch itself is only the execution of a plan.

Google advises changing one thing at a time and timing the move for a quiet traffic period. If the project also includes a new design and new copy, ship those separately from the address change, so a ranking dip has one suspect instead of three.

Record a baseline before anything moves. Save the last ninety days of clicks, impressions and conversions for the pages on your priority list, the count of indexed pages, and a screenshot of the Core Web Vitals report. Without a baseline, "traffic is down" is an impression, and you cannot say whether the drop is a migration effect, a seasonal pattern or a measurement break. Also agree in advance who has authority to approve the launch and who can roll back a redirect rule, because launch-day questions are slow to answer when nobody owns them.

A redirect map is a spreadsheet that pairs every old URL that matters with the single closest new URL, and records the redirect type. Build it from the crawl and the Search Console export, not from memory, and have someone who knows the content check the pairings, because a script can match slugs but not meaning.

Three rules cover most of the mistakes. Use permanent server-side redirects, such as 301 or 308, because Google uses those as a signal that the target should be canonical. Point each old URL straight at its final destination, since Googlebot follows long chains but Google advises keeping them to a handful of hops at most and ideally redirecting directly. And do not send hundreds of old pages to the home page: Google warns that this can be treated as a soft 404. Where several old pages were merged into one, redirecting them all to the merged page is fine.

Illustrative example: an old service page at /services/seo-audit.php maps to /services/seo-audit. A retired 2019 landing page with no replacement is listed as 410. Two near-duplicate pages about the same service are merged, and both old URLs point to the surviving page. Images and PDFs that earn traffic or links go in the same sheet, because they have addresses too.

On launch day you switch on the redirects, remove every block that kept the new site out of search, and confirm that Google can reach the new pages. The sequence matters less than the completeness: a single forgotten noindex tag can keep a whole section out of the index.

Test redirects on a sample before and after, with the URL Inspection tool for individual pages and a crawler or script for the full map. Google lists redirects to non-existent new URLs among the most frequent mistakes, so sample across every page type, not only the top ten. If you are changing domain or subdomain, submit a Change of Address for each verified variant of the old domain. You do not need it for HTTP to HTTPS, www to non-www, or path changes within a domain.

After launch, compare the two sitemaps in Search Console: indexed pages on the old URLs should fall while indexed pages on the new URLs rise. Google says a small or medium site can take a few weeks for most pages to move and a larger one longer, and that rankings may fluctuate temporarily while it recrawls.

Patience has limits. A dip that follows the expected pattern is no reason to touch anything, but unexpected not-found errors, new pages that are missing from the index, or redirects pointing to wrong targets should be fixed immediately. Keep the redirects for at least a year, which is the period Google generally recommends so that signals can transfer fully, and update your own links and the highest-volume external links to the new addresses so visitors skip the extra hop. Also update ad destinations and profile links.

The recurring failures are mundane. Google's troubleshooting section names leftover noindex or robots.txt blocks, redirects to wrong or non-existent URLs, other crawl errors, too little server capacity for the post-move crawl surge, and sitemaps that still list old URLs. Add to that the self-inflicted one: bundling the move with a redesign and a rewrite.

This checklist is not a substitute for judgement on a large or complex site. If you have millions of URLs, several languages or a regulated content estate where wording must not change without review, move it in sections, as Google suggests for large sites, and treat each section as its own small migration.