A migration loses traffic for one reason almost every time: the old addresses stop answering. Here is the redirect map, the order to do things in, and the two checks that catch the damage in the first week rather than the second month.

Most of the traffic lost in a migration is lost in one specific way. The pages are fine. The design is fine. The old addresses just stop answering, and every link anyone ever made — from a search result, a directory, another person's blog — now lands on a 404.

That is a solved problem. It is also the part people do last, in a hurry, on the evening the domain switches.

Before you move: write down every URL you have

Not the ones you remember. All of them.

Open yoursite.com/sitemap.xml and copy the list.
Add anything in Search Console that has impressions, including pages you forgot existed.
Add the URLs that show up in your analytics with real visits.

Put them in a spreadsheet, one per row. Next to each, write the address it will have on the new site. That second column is the whole job.

The two columns that make a migration survivable

Where the address can stay identical, keep it identical. Every URL you change is a redirect to maintain and a small tax on the link pointing at it. Changing /about-us/ to /about/ because it reads better is the kind of tidying that costs real traffic and buys nothing.

Keep the titles and the descriptions

An indexed page has a title Google has already matched to queries. Rewriting all of them on moving day means every result in the SERP changes text on the same afternoon, and you lose the ability to tell a ranking drop from a click-through drop.

Move first. Rewrite later, one page at a time, when you can see what each change did.

The order that keeps you online

Build the new site somewhere private. A staging URL, a subdomain, a local preview — anywhere the old site is not.
Check every row of your spreadsheet exists on the new site. This is where you find the three pages nobody mentioned.
Set up the redirects, before the switch. Old address → new address, 301, permanent.
Switch the domain. The old site stays up until you point away from it, so there is no window where nothing works.
Submit the new sitemap in Search Console and leave the old property alone — do not remove it.
Watch for two weeks.

Redirects: the three rules

301, not 302. A 302 says "back shortly", so the old address keeps its standing and the new one never inherits it. If the move is permanent, say permanent.

One hop. /old/ → /new/ directly. Chains of three and four redirects are slow, and each link is somewhere the chain can break next year.

Do not send everything to the homepage. It is the tempting shortcut and it is the worst outcome: a person looking for one specific page gets the front door and leaves. If a page genuinely has no successor, let it 404 honestly, or send it to the closest real equivalent.

The sitemap detail that actually matters

changefreq and priority are ignored. The field that does work is lastmod, and it is the signal that tells a crawler this URL is worth looking at again.

Give each URL the real date its content last changed. Do not stamp every page with today — a sitemap where all 200 URLs changed this morning is a sitemap that is not telling the truth, and it gets treated accordingly.

We learned that one the slow way on this site: a set of pages kept showing an old description in search for weeks, and a missing lastmod was why nothing was being recrawled.

The two checks that catch a broken move early

Check one: does a real URL answer? Not the homepage. Take five addresses from the middle of your spreadsheet — a blog post, a deep service page — and open them. Homepages almost always survive a migration. It is the pages three levels down that quietly vanish.

This is worth building into your process rather than doing by memory. A deploy that swaps a folder can replace a hundred working pages with a hundred 404s and still look completely successful from the front page.

Check two: is anything in your sitemap missing a file behind it? If a URL is listed as existing and nothing answers at it, you have found tomorrow's traffic drop today.

What the first fortnight looks like

Expect a wobble. Impressions move about for a week or two while the new addresses get crawled and the redirects are followed. That is normal and it settles.

What is not normal: a straight-line drop that does not recover, or Search Console filling up with 404s. Both mean redirects, and both are fixable in an afternoon if you spot them in week one rather than month two.

End this migration owning the files. Static HTML on hosting you control. The move after this one is a folder and a DNS change. Try DragGo free.

And the part that makes the next move easy

The reason migrations hurt is that the site was only ever a service. If what you have at the end of this one is a folder of HTML and CSS on hosting you control, the next move is a file copy and a DNS change.

That is most of the argument for builders that hand you clean HTML, and for knowing what comes out before you go in.

How to move a website without losing your rankings