The usual story goes like this. A company spends months on a handsome new website, launches it on a Friday, and by the following week the enquiries have dried up. The design is fine. The old pages that Google knew, and that other sites linked to, no longer exist, and nobody told Google where they went.
A redesign does not have to cost you traffic. Most of the damage comes from a handful of avoidable mistakes, and most of them happen before launch day.
Start with a list of every address you have
Before anyone opens a design tool, write down every URL the current site serves. The sitemap is the obvious source, but it is rarely complete. Google's own guidance suggests combining the sitemap with your server logs, your analytics, the Links report in Search Console and an export from the CMS, and remembering that images, videos, scripts and PDFs have addresses too.
Next to each URL, note whether it earns anything: traffic, enquiries or links from other sites. That column tells you which pages the redesign must treat carefully and which can quietly disappear.
Keep the address where you can
The safest URL change is none. If a page lives at /services/seo today and the new design still has a page about SEO, leave it at /services/seo, even if the new information architecture would prefer /what-we-do/search. A neater structure is not worth a ranking dip.
Where the address really has to change, redirect it. Use a permanent server-side redirect, a 301 or a 308, from each old URL to its direct equivalent on the new site. Google states that these redirects do not reduce PageRank, which is why they are the right tool. A JavaScript redirect or a meta refresh is not a substitute.
Map one to one, and do not send everything home
A redirect map is a spreadsheet with two columns: the old address and the new one. Each old page should land on the page that replaces it. Two pages that were merged into one can both point to it, and that is fine.
What Google advises against is redirecting a large number of old pages to an unrelated destination such as the home page. The visitor does not find what they came for, and the search engine treats the redirect as a soft error. If a page has no replacement, it is better to let it return a proper 404 or 410 than to send people somewhere irrelevant.
Point each old URL directly at the final destination. Redirect chains, where A goes to B goes to C, slow things down and lose signals, and Google suggests keeping them to a minimum, ideally no more than three hops.
Keep the words that were working
Pages rank because of what is written on them. A designer who shortens every headline and trims the copy to a single sentence may be removing the very phrases that bring people in. Before you cut text, look at which queries each page currently receives in Search Console, and make sure the new version still answers them.
Titles and descriptions, headings, internal links and structured data all need to travel with the page. Each new page should carry its own canonical address, and if the site has several languages, the language annotations need updating too.
Test on a copy, then switch off the lock
Build and review the new site on a staging address that search engines are told to stay out of. It is the right thing to do, and it creates the most common launch-day disaster: the "noindex" setting or the password protection that goes live with the site. On launch day, check the robots file and the page source before you do anything else.
Also check that the redirects work by running the whole old list through a crawler or a simple script, and that the new sitemap lists the new addresses.
After launch
Submit the new sitemap in Search Console and watch the indexing and the crawl reports. Warnings that old URLs redirect are expected. Google says rankings can fluctuate for a few weeks or more while it recrawls a medium-sized site, so do not judge the result on day three.
Keep the redirects in place for at least a year. Longer is better, because old links keep arriving long after you have forgotten about them.
Finally, change as little else as you can at the same time. If you move domains, rebuild the navigation, rewrite the copy and switch the CMS in the same week, you will not know which change caused the dip. Where there is a choice, do the design first and the other big changes later.