Website redesign without losing SEO: the procedure, not the reminder

Every guide on this topic ends at the same sentence: remember to set up your redirects.

That sentence is where the work starts, not where it finishes. The redesigns that lose traffic almost never forgot redirects entirely. They redirected the pages someone remembered, missed the long tail, pointed twelve URLs at the homepage, and had no idea anything was wrong for six weeks.

Here is the actual procedure.

Build the URL inventory from three sources, not one#

A sitemap is not an inventory. It lists what you meant to publish.

Pull from all three and deduplicate:

1. A full crawl of the current site. Everything reachable, including the pages nobody links to any more.
2. Search Console, every URL that received an impression in the last 12 months. This is where you find the pages that rank and that nobody internally remembers.
3. Analytics, every URL with a session in the last 12 months, plus your top referring links.

The union is usually two to four times larger than anyone expects. That gap is the traffic that disappears in a careless migration.

Decide the fate of every URL, in writing#

Three outcomes, and every URL gets exactly one:

• Maps to a new URL. Most of them. One to one, to the closest equivalent page.
• Is being retired. Redirect to the nearest relevant parent, not the homepage. A redirect to the homepage is treated as a soft 404 and passes nothing.
• Stays as it is. The best outcome. Every URL you do not change is a URL that cannot break.

The last one deserves more weight than it gets. A redesign is not a reason to change URL structure. If the current structure is sane, keep it, and the whole risk profile of the project changes.

The cases that break migrations#

This is the part the two column example in most posts skips entirely.

Query strings. Filtered and sorted URLs (?colour=blue, ?sort=price) often have links and sometimes rank. Decide whether the new site preserves the parameter, ignores it, or canonicalises it, and make the redirect rules preserve or strip parameters deliberately rather than by accident.

Pagination. /blog/page/2 through /blog/page/14 exist, are indexed, and get forgotten. If the new site paginates differently, every one of them needs a destination.

Trailing slashes and case. Pick one convention, enforce it at the edge, and make sure the redirect from the other form is a single hop.

Uppercase and encoded characters. Old CMS platforms produce URLs with spaces, accents and capitals. They still get hit.

Redirect chains. The quiet killer. You redirect A to B during this migration, but B was already redirecting to C from the last one. Every chain you leave costs crawl budget and a little signal. Crawl your own redirect map before launch and flatten every chain to one hop.

Ship the map as 301s, not as a plugin table#

Use permanent redirects, implemented at the server or edge rather than in application code where you can. Test the map before launch by running the full old URL list against the staging environment and asserting two things: status 301 and the exact expected destination. Not "it redirects somewhere". Somewhere is how twelve URLs end up on the homepage.

If you want the detail on building and auditing that map, including the chain audit, it has its own post.

Launch day, in order#

1. Deploy, with the redirect map live from the first second. There is no acceptable window where old URLs 404.
2. Submit the new sitemap in Search Console and confirm the old sitemap still resolves for a while so the crawler can walk the redirects.
3. Verify a sample of 30 to 50 URLs across every template by hand.
4. Check robots.txt. The single most expensive migration mistake is shipping the staging Disallow: /.
5. Confirm canonical tags point at the new URLs and not at staging hostnames.

The four weeks after, which is the part nobody plans#

Rankings dip after a migration. Even a correct one. Google has to recrawl, follow the redirects and reassess. One to three weeks of wobble is normal and is not a reason to start changing things.

What to watch, weekly:

• Coverage report for a spike in 404s. Every one of them is a URL your inventory missed. Add the redirect, do not argue with it.
• Impressions by page, comparing the new URL against its predecessor's baseline rather than against the site total.
• Average position for your top 20 queries. Falling and recovering is normal. Falling and staying down after three weeks means a specific page lost something, usually content that was trimmed in the redesign.
• Core Web Vitals, because a redesign that is slower than what it replaced loses ground for a reason unrelated to URLs. The mechanism that prevents that is a performance budget enforced in the build, not a launch day Lighthouse screenshot.

The thing most likely to actually cost you rankings#

It is not the redirects. It is deleting content.

Redesigns cut copy for aesthetic reasons. The page that ranked had 1,400 words answering a question, and the redesigned version has a headline, three icons and a form. The URL resolved perfectly and the ranking still went.

Before launch, compare word count and heading structure on your top 20 pages against the old version. If the new page says less, it will rank for less.

Frequently asked questions#

How long do rankings take to recover after a site migration?#

One to three weeks of instability is normal, with most sites back to baseline inside four. If a page is still down after four weeks the cause is usually specific to that page, most often thinner content, rather than the migration as a whole.

Should I redirect old pages to the homepage?#

No. A redirect to the homepage from an unrelated page is treated as a soft 404 and passes essentially nothing. Redirect to the closest relevant page, or to the section parent if no equivalent exists.

Can I change my URL structure during a redesign?#

You can, but ask why. Every URL you keep is risk you avoid entirely. Change the structure only when the current one is genuinely harming you, not because the new CMS prefers a different pattern.

Do I need to keep the old sitemap after launch?#

Keep it resolving for a few weeks. It gives the crawler a list of old URLs to walk, which speeds up discovery of your redirects.