How to Redesign a Website Without Losing Your SEO Rankings

The story is always the same. New site launches, everyone's pleased with it, and six weeks later enquiries are down by half. Somebody suggests Google is punishing the change, or that it takes time to settle, and the business waits it out.

It isn't settling and it isn't a penalty. In almost every case it's a small number of things that were decided before launch and can still be checked in an afternoon. Here they are, roughly in the order they cost people money.

Crawl the old site before you touch anything

This is the step that makes every other step possible, and it's the one that gets skipped because it feels like admin rather than work.

Before the new design goes anywhere near production, crawl what you have. Screaming Frog is free up to 500 URLs, which covers most business sites. Export the list with titles, H1s, word counts and status codes, and save it somewhere that isn't a laptop.

That export is the artefact everything else checks against. Without it you're relying on somebody remembering that there used to be a page about commercial roof repairs, and nobody remembers.

Pull the second list from Search Console: Performance, last 12 months, by page. That's your ranked inventory. Anything on it is a page whose URL you're not allowed to break by accident.

The URL map is the actual deliverable

Every URL on the old site needs one of two outcomes: a 301 to the closest equivalent page on the new one, or a deliberate decision to let it go.

Things that go wrong here, in the order we see them:

Redirecting everything to the homepage. This is the big one. If a hundred old URLs all point at /, Google treats those redirects as soft 404s, and the accumulated authority on those pages doesn't transfer anywhere. Redirect to the equivalent page or don't redirect at all.

302 instead of 301. A 302 says "this moved temporarily, keep the old one." Google works it out eventually, but "eventually" is the thing you were trying to avoid.

Chains. Old URL to interim URL to final URL, usually because there was a redesign before this one. Collapse them so every old URL points straight at its destination.

Case and trailing slashes. /Services/ and /services are two URLs. Pick one form, redirect the other, and be consistent about it in the new site's config rather than patching it later.

Write the map as a spreadsheet with old URL, new URL, and a reason. It's tedious and it's the single highest-value hour in the entire project.

Redesigns delete content, and content was doing the ranking

The new design is cleaner. Cleaner usually means shorter. A service page that carried 900 words is now a headline, three icons and a button, and it looks far better.

It also ranked on those 900 words. The page answering six specific questions was matching six specific searches, and the new one answers none of them.

You don't have to keep the old layout to keep the substance. Accordions, longer sections further down the page, and a proper FAQ block all hold real copy without cluttering the top of the page. But somebody has to make the call deliberately, and on most redesigns nobody does. The words just quietly don't make it across.

Same goes for pages. If the old site had eleven service pages and the new one has one page listing eleven services, you've merged eleven ranking pages into one, and the one now has to compete for all eleven queries with a paragraph each.

Internal links disappear with the old navigation

A page that used to be linked from every footer on the site is now linked from nowhere, because the new footer is tidier. It's still in the sitemap, it still returns a 200, and it has quietly lost most of the internal authority pointing at it.

Crawl the new site before launch and compare inbound internal link counts against the old export. Anything that went from twenty to zero needs a home somewhere.

The staging robots.txt

Check it on launch day, from the live domain, before you tell anyone the site is up. Load /robots.txt and read it. Then view source on the homepage and search for noindex. Then check the response headers, because a header-level noindex doesn't appear in the HTML at all and is the version that hides for weeks.

Don't change everything at once

Titles, URLs, content, design and platform can all change in one launch. When traffic moves after that, you have no way of knowing which one did it.

If the URLs have to change, keep the title tags. If you want to rewrite the titles, do it a month later as its own change. Sequencing costs a little patience and buys you the ability to attribute a drop to something specific, which is the difference between fixing it and guessing.

What matters less than people think

Not everything on a redesign checklist is load-bearing.

Changing the visual design doesn't hurt rankings. Neither does moving hosts, switching frameworks, or changing your colour palette. Google doesn't rank the design; it ranks pages, and pages are URLs, content and links.

A small dip in the first two or three weeks is normal even when the work is right. Google has to recrawl and reprocess a large number of URLs, and there's genuine noise in that window. The signal to watch is week four onwards, and the number to watch is clicks by page in Search Console, not sessions in analytics. Sessions include everything and will tell you nothing about which pages moved.

Launch day, in order

1. Deploy, with the site still not announced anywhere
2. Check robots.txt, meta robots, and response headers on the live domain
3. Spot-check twenty redirects by hand, including the five highest-traffic pages
4. Crawl the live site and look for 404s, chains and anything returning 500
5. Submit the new XML sitemap in Search Console
6. Keep the old sitemap live for a few weeks so the redirects get crawled rather than forgotten
7. Annotate the launch date in analytics, so the next person to look at the graph knows what the step is

Two weeks later

Pull Search Console again, page by page, and compare against the pre-launch export. Pages that lost clicks are usually one of four things: a redirect that went somewhere generic, content that didn't make the move, internal links that vanished, or a page you merged into another one.

All four are fixable after the fact. They're just cheaper to avoid, which is the whole argument for doing the crawl first.

Redesigns are most of what we're asked for, and the ranking half of the job is usually the part no one has scoped. It's covered inside web design and development, and the audit side of AI SEO and analysis is where the before-and-after crawls come from. If you're mid-project with someone else and want the URL map checked before you launch, that's a short piece of work and worth doing.