Most rankings that disappear after a redesign were not lost to the redesign. They were lost to a redirect map written in the last week, when the site was already built and the launch date had already been promised. Migration is not the risky part. Leaving it until the end is.
What an SEO migration actually covers
People hear the word and picture a server move. In search terms, a migration is any change that moves URLs or changes what lives at them. A redesign, a platform change, a domain change, a move to HTTPS, merging two sites, splitting one into two, or adding a language folder to a site that never had one.
If a URL that used to answer a query no longer answers it, you have migrated, whether or not anyone called it that.
The five things that break
1. URLs change for reasons nobody wrote down
A new CMS has opinions. It adds a category to the path, or drops a date, or decides that uppercase is now lowercase. None of that is discussed, because none of it looks like a decision. It looks like a default.
The fix is boring and it works: export every indexed URL before anyone touches the build, and treat that list as a contract.
2. The redirect map is built from the sitemap
The sitemap is the URLs you know about. It is not the URLs Google knows about. On the site you are reading this on, the old sitemap listed eleven pages and the live site had twelve, and the twelfth was the one with a thousand words of indexable content on it.
Build the list from three sources at once: the sitemap, a crawl, and your analytics or Search Console export for the last twelve months. The URLs that appear only in the third source are usually the ones with links pointing at them.
3. Redirects chain, or land on the wrong side of a language
Old URL to intermediate URL to final URL is a chain, and chains lose value at every hop. Worse, on a bilingual site an old page in one language often has no counterpart in the other, and it quietly gets sent to a homepage that speaks a different language than the person who clicked.
Every redirect should be one hop, 301, and land on the closest real equivalent. A homepage is the fallback, not the plan.
4. The staging site ships its own settings
Staging is built with search engines discouraged, and that setting is stored in the database. If the database moves, the setting moves with it. A site can go live looking perfect and carrying a noindex tag on every page, and nothing on the screen will tell you.
The same applies in reverse: staging that was never blocked gets indexed, and then you are competing with yourself.
5. Canonical and hreflang are written for the old structure
These two are written once, early, and then forgotten. After a migration they often point at URLs that now redirect, which tells a search engine to prefer a page that no longer exists. The hreflang side of this is covered in the four ways hreflang breaks.
The redirect map is most of the job
The same map is what makes removing pages at scale safe, which is most of the work described in crawl budget. If you only do one thing properly, do this one. A redirect map is a spreadsheet with two columns, old URL and new URL, and one rule: every row has a destination that returns 200.
Three checks before launch, and they take an afternoon:
- No row points at a redirect. Follow every destination once and confirm it is final.
- No live page is in the left column. This is the one that bites. If a URL exists on both the old and the new site with different content, a redirect will delete the new page. Two URLs cannot both be kept.
- Every code is 301, not 302. A 302 says the move is temporary, and search engines treat it accordingly.
When I rebuilt this site in September 2026, the old one had 12 URLs and the new one 42. The redirect map ended up with 20 rules, and the only one that failed testing was the one that would have sent a live page somewhere else. That rule is the whole job.
Measure before you move, or you cannot tell what happened
Take a snapshot a week before launch: rankings for your top fifty terms, organic sessions by landing page for the last three months, total indexed pages, and a full crawl of the old site saved to a file.
Without that baseline, every conversation after launch is an argument about whether things got worse. With it, the conversation is about which twelve pages got worse and why.
The two weeks after
Traffic usually dips. A dip of ten to fifteen percent for two to four weeks while search engines reprocess is normal and recovers. A dip that is still there at week six is not settling, it is a symptom, and by then you want the baseline you took.
What to watch, in order: crawl errors in Search Console, the redirect log for 404s that are actually being requested, and index coverage. The 404 log is the most useful of the three, because it shows you the URLs real people and real crawlers still expect to exist. Those are the rows your map was missing.
Where this usually goes wrong in practice
The build and the search work sit with different people, and the handoff happens after the build is finished. By then the URL structure is set, the copy is written, and the redirect map is a cleanup task rather than a design input.
That is the argument for deciding structure, URLs and redirects at the same time as the layout, which is how I build sites, and for keeping the person who will be judged on the rankings in the room while the structure is being chosen.
Google’s own documentation on site moves with URL changes is short and worth reading before you plan one.
If you have one coming up
The cheapest moment to involve someone is before the URL structure is agreed. The second cheapest is before launch. After launch it is recovery work, and recovery costs more than prevention every time.
If you are planning a move and want the structure and the redirect map decided while there is still time to change them, tell me what you are moving.