SEO migration checklist
The steps that actually protect rankings during a replatform or redesign, in the order they have to happen, and the ones teams routinely skip.
Most traffic lost during a migration is lost for preventable reasons, and the losses are rarely visible on launch day. They surface two to four weeks later as a decline nobody can attribute, by which point the team has moved on and the cause is buried.
This checklist is ordered by when each step has to happen. Several of them cannot be done late, which is the main reason migrations go wrong.
Before design starts
These two are cheap now and expensive later, because everything downstream depends on them.
Crawl the existing site properly
A full crawl, not the sitemap. Sitemaps routinely omit URLs that still carry inbound links: discontinued products, old campaign pages, paginated category URLs. Every one of those is a future 404 if it is not in your map.
Export a ranking and traffic baseline
Current rankings, landing page traffic, and Core Web Vitals field data. Without a baseline captured beforehand you cannot tell afterwards whether a decline is real or seasonal, and you will spend weeks arguing about it.
While the new site is being built
The redirect map is the single most important artefact of a migration, and it should be built alongside the new URL structure rather than after it.
Map every old URL to exactly one new URL
One hop, no chains. Chains of two or three redirects are common on sites that have migrated before, and each hop dilutes the signal and slows crawling.
Decide what does not get a destination
Some pages genuinely should return 410 rather than redirect to a vaguely related page. Redirecting everything to the homepage is treated as a soft 404 and helps nobody.
Keep structured data at parity
Product, Offer, Article and Breadcrumb markup all get rebuilt with the templates. Rich result eligibility is easy to lose silently, because nothing errors.
Check what renders without JavaScript
If the new stack moves content to client-side rendering that was previously server-rendered, crawlers that do not execute JavaScript will see less than they did before.
Staging, and the mistake everyone makes
Put staging behind authentication. A staging site that gets indexed competes with your live site for your own terms, and it happens far more often than anyone admits, usually because a robots.txt disallow was treated as access control rather than a request.
A robots.txt disallow does not prevent indexing of a URL that is linked from elsewhere. HTTP authentication does.
Launch day, in order
The sequence matters more than the speed.
| Step | Detail |
|---|---|
| 1. Deploy redirects first | Before DNS moves, so nothing is briefly unhandled |
| 2. Verify a sample by hand | Old URL to new, one hop, correct status code |
| 3. Remove staging authentication | Only after robots.txt and meta robots are confirmed correct |
| 4. Confirm robots.txt on the live host | A staging robots.txt shipping to production is the classic disaster |
| 5. Submit the new sitemap | Search Console and Bing Webmaster Tools |
| 6. Push URLs to IndexNow | Bing discovers in minutes rather than weeks |
| 7. Watch for 404s and crawl errors | Daily for the first fortnight |
The two weeks after
Expect a dip. Rankings commonly wobble for one to two weeks while the new URLs are crawled and consolidated, and reacting to day-three data leads to changes that make things worse.
What to actually watch: 404s in Search Console, redirect chains appearing where you mapped single hops, pages dropping out of the index, and Core Web Vitals against your baseline. A sustained decline beyond about three weeks is a real problem rather than settling, and it usually traces back to something in the list above being skipped.
One change at a time
The most useful discipline in a migration is not doing two things at once. Migrating platform and redesigning content and changing URL structure simultaneously means that if traffic moves, you cannot attribute it.
Move with URL parity and a clean redirect map first. Confirm rankings hold. Then make structural changes deliberately, one at a time, with a baseline for each.
Common questions
How long does it take to recover rankings after a migration?
A well-executed migration typically sees rankings wobble for one to two weeks and settle back to roughly their previous positions within three to four. That assumes URL parity, a single-hop redirect map built from a full crawl, and structured data preserved. If you are still meaningfully down after about six weeks, it is not settling and something is wrong: the most common causes are redirect chains, pages that never got a destination, content that moved to client-side rendering, or a staging robots.txt that shipped to production. Recovery from those is fast once identified, because the fix restores the signals rather than rebuilding them. What genuinely takes months to recover is a migration that also changed content and URL structure at the same time, because you no longer know which change caused the loss.
Do we need to redirect every single old URL?
Every URL that has either inbound links or organic traffic, which is a smaller set than every URL that exists. Pages with neither can return 410 Gone, and that is a cleaner signal than redirecting them somewhere loosely related. What you should not do is redirect unmatched URLs to the homepage in bulk: Google treats an irrelevant redirect as a soft 404, so you gain nothing and lose the clarity of a proper status code. The practical approach is to rank old URLs by inbound links and organic sessions, map the meaningful ones individually to their closest equivalent, and let the long tail 410. For a large catalogue that usually means individually mapping a few hundred URLs rather than tens of thousands, which is a manageable afternoon rather than a project.
Should we change URL structure during a migration?
Only if the existing structure is actively causing a problem, and even then, consider doing it as a separate change afterwards. A migration already carries risk; changing URL structure at the same time compounds it and destroys your ability to attribute any traffic change. If the current structure is genuinely harmful, such as deeply nested category paths or URLs carrying session parameters, then fixing it during the rebuild is efficient because the templates are being written anyway. Just accept that you are choosing a longer settling period and a murkier read on the results. The sequence we prefer is to migrate with URL parity, confirm rankings hold for a few weeks, then restructure deliberately with a fresh baseline. It is slower on paper and usually faster in practice.
Services related to this guide
Tell us what you sell
A written audit covering AI crawler access, whether your key pages are structurally citable, how your brand currently surfaces across ChatGPT, Perplexity and Google AI Overviews, and the specific changes that would move it.