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.

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.

If the domain is changing too

Changing the domain at the same time as the design roughly doubles the work and about triples the number of places something can go wrong. Sometimes there's a good reason, like a business name change, and sometimes it's someone's preference. Know which one you've got.

If you're moving to or between .au addresses, check the eligibility side before the design conversation gets far, because auDA's licensing rules decide what you're allowed to hold and it's a poor time to find out. And keep the old domain, renewed, redirecting, for years. Letting it lapse hands away every link anyone ever gave you.

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.