The Website Migration Checklist: Every Step Before, During, and After the Move

1. First, name what kind of migration this is

Not every move carries the same risk, and the checklist changes with the type. A hosting move with identical URLs is the lowest-risk migration: the danger is downtime and email, not rankings. A domain change is the highest-risk common move, because every signal attached to the old domain has to be re-earned at the new address. A platform change, from one CMS or shop system to another, sits in the middle: URLs, templates, and metadata all shift at once. A redesign that keeps URLs is still a migration in search engines' eyes if templates, navigation, internal links, or page content change materially.

The rule that saves the most trouble: do one big change at a time. If you are changing domain, redesigning, and switching platforms in a single launch, and traffic falls, you cannot tell which change caused it, and you cannot roll back one piece without unpicking the rest. Where the business allows it, move first and redesign second, or the reverse. When everything must ship together anyway, the rest of this checklist matters twice as much.

2. Before you touch anything: baseline and backup

Crawl the live site completely. Use a crawler such as Screaming Frog or a comparable tool and export every URL, title, meta description, heading, status code, and internal link. This crawl is your source of truth for the redirect map, and it is also how you discover pages you had forgotten: old campaign pages, PDFs that rank, archives. Anything the crawl misses cannot be redirected, and unredirected pages are how traffic quietly evaporates.

Record the numbers that matter. Export Search Console data for at least the last 12 months: top pages by clicks and impressions, top queries, and the pages that carry the most earned links. Note organic traffic by landing page, conversion counts, and Core Web Vitals scores. These baselines are the only way to judge, two weeks after launch, whether a dip is a real problem or normal fluctuation.

Take a full backup, then prove it restores. Files, database, configuration, and media stored outside the main install. A backup nobody has restored is a hope, not a safety net: restore it to a test location and confirm the site actually runs there. Keep the old hosting account and the old site live until the new one has proven itself; the cheapest rollback plan is an old site you have not yet switched off. Gather every credential you will need, registrar, DNS, both hosting panels, analytics, Search Console, and email, before launch day, not during it.

3. The redirect map: the single most valuable document in the project

Every old URL gets mapped to its closest new equivalent, one to one, with a single-hop 301 permanent redirect. Not to the homepage, not to a category page two clicks away: to the page that answers the same query the old page answered. Pages with genuinely no equivalent go to the most relevant surviving page, and retired content gets a 410 gone status rather than a soft 404. Redirect chains, where an old URL points to a URL that itself redirects, leak authority and slow crawlers down; every redirect should land directly on its final destination.

Build the map from the crawl and the Search Console export, not from memory. Sort it by value: pages with traffic, pages with links, and pages that convert go first, because those are the ones a partial map hurts. Preserve meaningful query strings where they carry real content, and drop tracking parameters entirely. Implement the redirects at server level, not through a plugin that loads after the page does, and test them on staging before launch: old URL in, final URL out, one hop, correct status code, every row.

Two details people get wrong. First, internal links must be updated to point at the new URLs, not left pointing at the old ones and relying on redirects to catch them; redirects are a safety net for external links and bookmarks, not a substitute for a clean internal structure. Second, keep the old domain registered and its redirects live for at least a year. Old links and bookmarks keep sending visitors for years, and killing the redirects kills that traffic with them.

4. Carry the content, metadata, and structured data across

Redesigns routinely cut copy for aesthetic reasons, and that is where rankings go to die. If a page ranks, its content is doing work: the headings, the body text, the internal links, and the phrases real people searched for. Carry that content across to the new page, and if the new design genuinely needs shorter copy, keep the ranking page's substance. The same applies to titles and meta descriptions: carry them across rather than letting a new CMS regenerate defaults, because a regenerated title is a changed signal on every page at once.

Structured data travels with the content. If the old site had FAQ, product, article, or local business schema, the new site needs the equivalent markup, tested, on the equivalent pages. Losing schema can cost the rich result that was winning the click, which looks exactly like a ranking loss in the traffic report. The same applies to canonical tags, hreflang where multiple languages exist, and the XML sitemap, which should be rebuilt for the new URLs and submitted fresh.

5. Prove the new site on staging before anyone sees it

Build the new site on a staging copy and test it as if it were already live, because after launch there is no second rehearsal. Run the full redirect map against staging and check every row. Crawl staging and compare it against the old crawl: same page count, same titles, no missing content, no new 404s, no redirect loops. Test the forms, the checkout, and the payment flow with real test transactions, and confirm email still sends and lands.

Keep staging hidden from search engines while you work: password protection is the reliable option, and a noindex tag is the backup, not the plan. The single most common self-inflicted migration wound is a staging site that got indexed, leaving duplicate content live alongside the real site. Before launch, verify the staging protections are removed from the live site itself, because the mirror image of that wound is a live site that inherited staging's noindex tag and quietly vanished from search results. Both are caught by a pre-launch crawl of the actual launch build.

6. Launch day: the website migration checklist cutover sequence

Pick a low-traffic window and warn everyone who touches the site not to publish during the move, because content added mid-migration exists in one copy and not the other. Lower DNS time-to-live values at least 48 hours ahead so the switch propagates quickly, and keep the SSL certificate ready on the new host before cutover, not after: a site that flips to HTTPS with a certificate error just told every visitor to leave.

On the day, the order is: deploy the final build, apply the redirect map, verify the homepage and the ten highest-traffic pages by hand, confirm analytics and Search Console tracking fire on the new pages, and then switch DNS. Test again from a device outside your own network, because your own machine may still be resolving the old server. Keep the old site running and untouched for now. If something critical breaks, the rollback is to point DNS back, and that only works if the old site is still there, still complete, and still paid for.

For a domain change specifically, verify both properties in Search Console, submit the new sitemap, and use the change-of-address tool. Update the listings, social profiles, and partner links you control over the following days. You cannot update every backlink, which is exactly why the redirects must stay live so long.

7. The first 30 days on the website migration checklist: what to watch

Check Search Console daily for the first two weeks: crawl errors, pages excluded from indexing, and any spike in 404s. A handful of 404s from URLs nobody linked to is housekeeping; a spike on pages that used to rank is a redirect-map gap, and it should be fixed the day it appears. Compare organic traffic weekly against the baseline, page by page, not just in total: total traffic can look stable while your best page quietly halves.

Expect some fluctuation. Search engines reprocess signals after a move, and a domain change in particular can wobble for weeks before settling. What should not happen is a sustained, across-the-board drop with no recovery trend after two weeks, or a single important page that never reappears in the index. Those are the signals that send you back to the crawl comparison: is the page live, is it indexed, does its redirect land correctly, is its content intact, is anything blocking it. Audit again at 30 days and at 90 days, and only then start decommissioning the old environment.

Do not forget the parts of the site that are not search traffic. Confirm email still flows both ways after any DNS change, because mail records are easy to lose in a hosting move and the symptom, missing enquiries, looks like a quiet month rather than a technical fault. Confirm analytics, conversion tracking, and integrations still fire. A migration is only finished when the business functions that depended on the old site all demonstrably work on the new one.

8. The website migration checklist mistakes that cost rankings

• No baseline. Without pre-move numbers, nobody can tell a real loss from noise, and real losses go unfixed.
• A partial redirect map. Redirecting the homepage and the main pages while leaving long-tail pages to 404 is how a site loses a third of its traffic while looking fine.
• Redirecting everything to the homepage. Search engines treat mass homepage redirects as soft 404s, and visitors bounce anyway.
• Staging leftovers. A noindex tag or password carried to the live site, or a staging copy left open to crawlers.
• Content cut in the redesign. Ranking copy removed for a cleaner layout, with nothing equivalent left behind.
• Changing everything at once. Domain, platform, and design in one launch, so no single cause can be isolated when traffic moves.
• Switching the old site off too soon. The rollback plan and the redirect host both disappear the week they are most needed.

Common questions

Will my rankings drop after a migration?

Some fluctuation is normal, especially after a domain change, while search engines reprocess the moved signals. A well-executed migration with a complete redirect map and carried-over content usually settles close to its baseline. A sustained drop is not normal fluctuation; check the redirect map, indexation, and content against the pre-move crawl.

How long should 301 redirects stay in place?

At least a year, and longer where possible. Search engines advise keeping redirects live for as long as you can, because old links and bookmarks keep sending visitors well beyond the first year. Keep the old domain registered for the same period.

Can I redesign and migrate at the same time?

You can, but it costs you the ability to isolate causes if anything goes wrong, and it multiplies the things that can go wrong in one launch. If the schedule allows, split the work: move first, then redesign, or the reverse. When both must ship together, the baseline and the redirect map become non-negotiable.

What do I do if traffic falls after launch?

Work the list in order: check Search Console for crawl errors and indexation, compare the new crawl against the old one, test the redirects on your highest-traffic pages, confirm no noindex tag survived from staging, and verify the ranking pages still carry their content.

Does a hosting-only move affect SEO?

Barely, provided the URLs, content, and metadata do not change and downtime stays minimal. The risks in a hosting move are practical rather than search-related: downtime during cutover, broken email, slower performance on the new host, or a certificate gap. Test the new host's speed before you commit, because a slower host is a ranking factor you just bought.

Related: Website migration service · Product catalog migration checklist · WordPress care plans: what should be included