Redesigning your website without losing your rankings

The worst version of this I've seen came in about eighteen months ago. A business rang us six weeks after launching a new site, which looked good, genuinely, better than what they'd had. Their enquiries had gone quiet and they assumed the new design was putting people off.

It wasn't. Their old site had around ninety pages. The new one had twelve. The other seventy-eight addresses were returning a "page not found", including four service pages that between them had been most of the reason anyone ever arrived.

Nobody had done anything stupid. The new site was built by competent people, the content had been consolidated on purpose, and the plan to fold six thin pages into one good one was the right call. What nobody did was tell Google where the six had gone.

That's the whole risk of a redesign, and it's worth being blunt about it because the alternative story is more comforting and completely wrong. Rebuilds don't cost you rankings because the design changed. They cost you rankings because the addresses changed and the old ones were left to rot.

The redirect map is the job

If you take one thing from this: before the new site goes live, somebody has to sit down with a list of every URL on the old site and write next to each one where it now lives.

Not "the homepage". That's the lazy version, and it's worse than useless, because Google reads a hundred old pages all pointing at the homepage as a hundred pages that no longer exist. Each old address should point at the closest thing to what it used to be. The bathroom waterproofing page goes to the new bathroom waterproofing page. The six thin suburb pages go to the one good coverage page that replaced them. If an old page has no successor at all, that's a decision you make deliberately, not one that happens to you at 11pm on launch night.

Google's guide to a site move with URL changes is the reference here and it's more readable than most of their documentation. The mechanism is a 301, which tells a browser and a crawler that a page has moved permanently and that whatever the old address had earned should follow it.

Ask who owns the map before you sign anything. On the projects that go badly, the answer turns out to have been nobody, and everyone assumed it was the other party's job. We build the map ourselves as part of the rebuild work, which is less a service than a refusal to repeat that phone call.

Getting the old list is easier than people think

You can't map what you haven't listed, and the old list is usually sitting in three places.

Your existing sitemap.xml, if it has one, which gives you what the old site thought it had. Search Console, which gives you what Google actually indexed and, more usefully, which of those pages were bringing anyone in. And a crawl of the live site before it goes off, which catches the pages nothing links to and the ones no sitemap knew about.

Do the Search Console export before launch. Twelve months of page-level data, saved as a file, sitting on someone's desktop. It costs ten minutes and it's the only way you'll ever know afterwards whether the rebuild helped, hurt, or did nothing. Almost nobody does this, and then the argument about whether traffic dropped becomes a memory contest.

What happened to search traffic on the sites we rebuilt?

On the rebuilds below, Search Console clicks and impressions rose after launch, which is the outcome a correct redirect map is meant to protect. The figures are Search Console counts only, over the windows shown, and they say nothing about enquiries or revenue.

Avalanche and HTG start from small bases, so read those two rows as direction. These sites also gained new pages, so the rise is not only the redirects. Two further lessons come from our other sites.

Rankings survived a week-long domain outage. One of our own sites had its domain on hold from 11 to 17 August 2026 after it expired. Its daily impressions through that week were 231, 198, 181, 137, 127, 183 and 183, flat against the weeks either side. That is one site and one week, and visitors were lost for those days, but it shows the risk to rankings from a short outage is smaller than the risk from addresses left returning "page not found".

Plain http that does not redirect to https can split a page. In August 2026 five of ten house sites served plain http with a 200 status. On one carpenter's site a blog post was indexed twice, as http with 77 impressions at position 27 and as https with 119 at position 28. The fix is a redirect from http to https, which was in place by 1 September.

What should a redirect map checklist cover?

Google's guide to a site move with URL changes sets out the steps, and says to keep the redirects "for as long as possible, generally at least 1 year". Our version for a small business site:

1. Compile the old URLs from your sitemap, Search Console, analytics and a crawl of the live site before it goes off.
2. Export twelve months of page-level Search Console data and save the file.
3. Map every old URL to its closest new equivalent, not to the homepage. Google advises against sending many pages to an unrelated page.
4. Use server-side permanent redirects (301 or 308) straight to the final destination, with no chains, and test them before launch.
5. Update canonical tags, internal links and the sitemap on the new site, and submit the new sitemap.
6. Check that verification works in Search Console for both old and new sites, and that the new site is allowed in the index.
7. After launch, type your top twenty old addresses into a browser one at a time, and run through our website launch checklist.

The dip that's normal and the one that isn't

Even a clean migration usually wobbles. Google has to recrawl everything, follow all the redirects, and work out that the new page is the old page. A couple of weeks of noise is ordinary and I'd tell you not to panic in week two.

What isn't ordinary is a drop that starts on launch day and doesn't recover, or a drop concentrated in a handful of pages that used to do all the work. That's a mapping problem and it's fixable, usually in an afternoon, as long as somebody looks. The pages worth checking first are the ones from that export: your top twenty by clicks, typed into a browser at their old addresses, one at a time. It's tedious and it takes about fifteen minutes and I've found the fault that way more often than with any tool.

Also worth ruling out early: whether the new site is even allowed in the index. Staging flags get carried across more often than anyone admits, and we went through that whole category of problem separately. Check it before you go hunting for anything subtle.

The bits that get missed

Images move too, and if your product or job photos were earning anything in image search, their addresses matter the same way.

Old blog posts are the other one. They're the least glamorous content on the site and they're frequently the pages with the most links pointing at them from elsewhere, which is exactly what you don't want to throw away. Consolidating them is fine. Deleting them without a forwarding address is not.

Then there's the internal links inside your own new content, which have a habit of still pointing at old addresses. They'll work, because your redirects catch them, but you're making every visitor and every crawler take the long way around for no reason. Fix them to point straight at the new URL.

And the sitemap. Submit the new one on launch day, and leave the old redirects in place permanently rather than for a tidy three months. There's no upside to removing them and there's always one straggler.

How do you change your domain name without losing rankings or email?

Redirect every old address to its closest page on the new domain, tell Google with Search Console's Change of Address tool, and move email before anything else. Changing the domain at the same time as the design roughly doubles the work and about triples the places something can go wrong, so be sure which reason you have.

Is the change worth making? The reasons that hold up are structural: the business name has changed, two businesses merged and run competing sites, or the current domain is a spelling problem you lose people over on the phone. Moving from a .com.au to a .com because it feels more serious is a poor reason for a business selling to Australians. A .com.au shows where you are before anyone reads a word, and the eligibility rules behind it mean it is not handed to anybody. If you are moving to or between .au addresses, check auDA's licensing rules before the design conversation gets far, because they decide what you are allowed to hold. Buying the .com and pointing it at your existing site is a different decision and a fine one.

The search side. Every old address gets a permanent redirect to its closest equivalent on the new domain, page by page, and not everything piled onto the new home page. When only the domain changes and the pages do not, this is close to mechanical. Two steps are specific to a domain change:

1. Verify both the old and new properties in Search Console and use the Change of Address tool, which tells Google what you have done rather than leaving it to infer it from redirect patterns.
2. Keep renewing the old domain indefinitely. It costs little, and letting it lapse hands away every link anyone has given you and, eventually, your old email addresses to whoever registers it next.

Expect a couple of weeks of noise while Google recrawls. If something is still wrong a month later it is usually a redirect that was never written. Type your top twenty old addresses into a browser one at a time to find it, which takes about fifteen minutes. If traffic has not returned after a month, check whether the new site is allowed in the index, because staging flags come across in a domain move more often than anyone admits. Why your website isn't showing up on Google covers that category.

Email is where it goes wrong. A business we know changed its name and moved to the matching domain. The redirects were clean, rankings held and the search side was over in about three weeks, yet it still lost about a month of enquiries. The contact form on the new site sent to a mailbox on the old domain that nobody had migrated. The emails were delivered into an inbox no one opened, and the owner found out when a customer rang to complain.

• Mail for a domain is routed by its MX records. After a change you have two domains, and the failure is silent delivery to a place nobody looks, not a bounce. Keep the old domain receiving and forward it to the new mailboxes for years, because suppliers and old customers will use the old address long after you think they have stopped.
• The website's own sending, meaning contact forms, booking confirmations and invoices, needs SPF and DKIM set up on the new domain, or those messages start landing in spam while the form still says "thanks, we'll be in touch". See why contact form emails land in spam. On launch day, send yourself a test enquiry from an outside address and check the junk folder.
• Update every staff email signature, invoice template and automatic reply.

Everywhere else your address is written down. The most important for search is your Google Business Profile, where the website URL should change to the new domain instead of relying on the redirect. Then industry directories, accounting software, quote templates, social profiles, review links you send customers and printed material such as vehicle signage, flyers and the shopfront. Printed items do not need fixing immediately, which is why you keep the old domain alive. Make the list on paper before launch.

Allow a few weeks for search to settle, a couple of months before you stop noticing, and about a year before an old email address stops arriving. Before you start, send a test enquiry through your current contact form and confirm a person receives it. If that is already broken on the old domain, the domain change was never the problem.

What a rebuild won't do

Worth saying plainly, because we've had to say it in meetings. A rebuild raises the ceiling. It doesn't lift you off the floor.

If your old site had five thin pages and ranked for nothing, the new one will have five thin pages that load faster. That's a real improvement for the people who visit, and it changes nothing about search until someone writes the pages. We made the same point at the end of the piece on where builder platforms stop helping, and it's the honest half of the sales conversation.

This week

If a redesign is anywhere on your horizon, even a vague one, go into Search Console and export your top pages by clicks for the last twelve months. Save the file somewhere you'll find it.

That single file turns the whole thing from a matter of opinion into a matter of fact. It tells whoever builds the new site which pages absolutely must survive, and it tells you afterwards whether the work paid off.

If you'd rather have someone go through the current site before you commit to replacing it, an audit covers what's actually earning and what isn't, and we'll do one for free. Occasionally the answer is that you don't need a new site yet, which is a strange thing for a web agency to write down and true often enough to be worth writing.