How to Redesign a Site Without Losing Your Google Rankings

A redesign is usually four changes happening at once. New addresses for the pages. A new structure. New words. New code. Each of those can affect search on its own, and doing all four on the same night is why the diagnosis afterwards is so difficult.

The most common cause is also the most preventable. The addresses changed and nobody mapped them. Every link anyone has ever made to you, every result sitting in Google, every bookmark, now points at a page that no longer exists. The site is fine. It is simply not where anybody is looking for it.

The second cause is content. Somebody looked at a long, unfashionable page full of detail and replaced it with something short and elegant. The long page was the one answering a question people were searching for, and the short one answers nothing, so it stops being shown.

The third is technical and almost invisible. A blocking instruction left on from the staging site. A robots file that was correct for testing and wrong for launch. A sitemap still describing the old site. Tags on every page pointing back at the old address. All of these are one line each and any of them can hide a whole site.

Do this before the project starts, not during it. Once the old site is gone, none of it can be recovered, and the arguments afterwards become unwinnable because nobody can agree on what the site was doing before.

Crawl the entire current site with any of the standard tools and save the output. Every address, every title, every description, every heading, and the status each one returns. Then export your search console data for the longest period available, your analytics data, and a list of the sites that link to you.

Then build the single most valuable file in the project: a list of every address with its traffic, its search impressions and rankings, and how many external links point at it. That file tells you, page by page, what you actually have to protect. Most redesigns are planned without anybody ever looking at it, which is how the page bringing in most of your enquiries gets deleted for being ugly.

Take screenshots of the key reports and save the raw exports somewhere outside the project folder. You need a before picture nobody can argue with, because the conversation that happens after a bad launch is always about whether it was already declining.

The deliverable that saves the project is a spreadsheet with three columns: the old address, the new address, and the decision. Nothing more complicated than that, and nothing else in a redesign plan protects you as reliably.

The default should be to keep the address. Changing addresses because the new ones look tidier is the most common self inflicted wound in this whole business. If a page is staying, its address stays, and you have removed the risk entirely for that page. Save the changes for pages that genuinely have to move.

For every old address, answer one question: does this exist in the new site, and where. If it does not, what is the closest thing that does. Work through the whole list, including the ones with no traffic, because a page with no traffic can still be carrying links from other sites.

And do not send everything to the homepage. A mass redirect of every retired page to the homepage is treated as a page that no longer exists, and the value is lost exactly as if you had done nothing. Send each page to the most similar page, and where nothing similar exists, return a proper gone response and let it drop cleanly rather than pretending.

Use permanent redirects, and make each one a single hop. Chains happen easily: an address moved during a previous redesign, then moves again, and now a visitor makes three requests before seeing anything. Chains are slower for the visitor, and a crawler gives up after a small number of hops, so the page at the end of a long chain may never be reached. Point old addresses directly at where they end up.

Test the whole list before launch, not after. Put the new site on a staging address, run a script that requests every old address from your file, and record where each one ends up and with what status. Anything that does not resolve to the intended page is a bug you have found for free. Doing this after launch means finding them from a traffic graph.

The ones people forget are always the same. Images and PDF files, which have their own links and their own search traffic. Old blog category and tag pages. Paginated listings. Addresses carrying parameters from old campaigns. The version with www and the version without. And the plain unsecured version of every address if the site was ever served that way.

Then keep the redirects. Permanently, in practice. Somebody always proposes clearing them out after a year because the file has grown long, and traffic drops again, and nobody connects the two events for a month. They cost almost nothing to keep.

This is the hardest conversation in a redesign, because the pages that bring in traffic are frequently the ones nobody is proud of. They are long, they are badly formatted, they were written years ago by somebody who has left, and they are doing more for the business than the homepage.

Here is what it looks like. A plumbing company has a page about one specific boiler fault, written in a hurry in the past, ugly and unstyled, that brings enquiries every week from people searching that fault late at night. The redesign replaces it with a clean services page and a nice photograph. The enquiries stop, and it takes months for anybody to work out why.

So make it a rule with a name on it. Any page with traffic, rankings or external links keeps its content, its headings and its depth. It can be restyled completely, and it should be. It cannot be shortened into a paragraph because the new design looks better with less text on the screen.

If you genuinely need to combine several pages into one, build the new page so it contains everything the old ones said, redirect the retired addresses to it, and then watch what happens rather than assuming. Consolidation works when the new page is more complete than either original. It fails when it is the average of them.

Every staging site is configured to stay out of search, and every launch checklist has to undo that. The blocking tag on the pages, the disallow in the robots file, the password on the whole site, the analytics that was switched off so test traffic did not pollute the data. Any one of these left in place is a site that quietly does not exist.

Then the things that have to be carried across rather than regenerated. Page titles and descriptions, which are frequently rewritten wholesale by a new content system and lose years of tuning in an afternoon. Heading structure. The alt text on images. Structured data. Language tags if you serve more than one country. The sitemap. And the canonical tags, which are worth checking on the live site by hand, because pointing them at the staging domain is a classic and it hides everything.

Internal links are the underrated one. A new navigation that is cleaner and shorter usually links to fewer pages, and the pages that quietly lost their links from the menu quietly lose their standing too. Check that every important page is still reachable from somewhere prominent, not just from the sitemap.

And get search console verified for the new setup before launch rather than after, including every version of the domain. It is the tool you will need most in the first week, and verifying it in the middle of a problem is an unnecessary extra hour.

Launch when you can watch it. Not on a Friday, not the day before a holiday, and not in the week the person who built it is away. Most of the damage from a bad launch comes from the hours it took somebody to notice.

On the day: crawl the live site and check the status codes, run your old address list against it, check the robots file, check for blocking tags, confirm the sitemap is correct and submit it, and confirm analytics is actually recording. Ask for indexing of your most important pages by hand. All of that is an hour of work and it catches almost everything.

Expect a wobble and do not panic at it. Rankings commonly move around for a few weeks while the new pages are crawled and reassessed, and a modest dip that recovers is normal behaviour rather than a fault. What is not normal is a cliff on the first day. That is a technical problem, it is almost always redirects or a blocking instruction, and it is fixable within hours if somebody is looking.

Then watch weekly for a couple of months. Crawl errors, how many pages are indexed, impressions by page, and your top landing pages compared against the file you saved before the launch. Comparing against your own before file is the only honest measure, because the season and the market have moved too.

Most people arrive at this subject after the fact, with a graph that fell off a shelf and a supplier saying it will settle down. Work through it in order rather than trying everything at once, because the causes are ranked and the first one explains most cases.

First, the addresses. Take the old address list, or reconstruct one from your analytics history and from an archive of the old site, and request every one of them against the live site. Every not found on a page that used to bring traffic is your problem, and fixing those alone recovers the majority of these situations.

Second, indexing. Is the site blocked in the robots file. Is there a blocking tag on the pages. Has the number of indexed pages collapsed. Are the canonical tags pointing somewhere sensible. These are quick checks and any one of them can be the whole answer.

Third, the content. Take the pages that fell hardest, pull their old versions from a web archive, and read the two side by side. Almost always the new one is shorter and says less. Put the substance back, in the new design.

Then fix everything you find, resubmit the sitemap, and be patient in a way that feels uncomfortable. Recovery is not instant even after a completely correct fix, because every affected page has to be crawled again before anything changes. Give it weeks rather than days before deciding the fix did not work, and resist the urge to change five more things in the meantime, because then you will never know which one mattered.