Website Redesign SEO: How to Keep Your Rankings

Most of the redesign damage I get called in to fix was preventable, and it was preventable months earlier, in the planning stage. The rankings a site holds took years to earn. They can be given away in an afternoon by a rebuild that changed URLs without a mapping, dropped content nobody thought was being read, or left a staging noindex in place.

This is the process I would follow on any website redesign where search traffic matters. Capture the baseline first, map every URL, redirect properly, then verify before and after go live.

Why Redesigns Damage Rankings

A redesign is not one change. It is dozens of changes happening at once: new URLs, new templates, new headings, altered internal links, sometimes a new domain or content management system. Search engines have to re-evaluate all of it, and any one of those changes can remove the signals a page was ranking on.

What Search Engines Re-evaluate After a Rebuild

When a page changes, the systems reassess the content, the structure, the internal links pointing at it and the technical signals around it. If the new page answers the query less clearly than the old one, or if the old URL now resolves to an error, the position goes somewhere else.

That is also why preserving the content that already earns traffic matters so much. Ahrefs reports in its 2026 SEO statistics that "96.55% of all pages get zero search traffic from Google." Almost none of a website's pages bring anything. The handful that do are carrying the entire organic channel, and they are usually the ones a redesign treats most casually, because they are not the pages the business likes looking at.

The Three Most Common Causes of Traffic Loss

Missing or wrong redirects come first. The second is content removed during the rebuild because nobody owned it. The third is a technical setting carried over from staging, usually a noindex tag or a robots.txt rule that blocks the whole site.

All three are planning failures. None of them require better design, they require a checklist and a person accountable for it.

Capture a Baseline Before You Touch Anything

The baseline is the evidence you will argue from later. Without it, you cannot prove that traffic dropped, quantify by how much, or demonstrate that it recovered.

Exporting Your URLs, Rankings and Traffic

Export every indexed URL from a crawl and from the sitemap before the rebuild starts. Pull twelve months of organic traffic and landing page data from analytics and Search Console, and record the keywords and pages that matter commercially, not just the ones with the highest volume.

Store the exports outside the website project so nobody accidentally overwrites them in the build folder.

Taking Screenshots and Backups You Can Reverse

Screenshot the pages that earn traffic, including the headings, the title tags and the content blocks. Take a full site backup and confirm you can restore it, then keep the old site accessible on a staging or archive environment for the duration of the project. Reversibility is the cheapest insurance in the entire redesign.

Build a Complete URL Mapping Spreadsheet

The mapping spreadsheet is the single deliverable that prevents guesswork. Every old URL gets a row and a decision, and the decision is made before launch rather than after.

Mapping Every Old URL to a New Destination

For each live URL, record the closest equivalent on the new site and the intended destination for a redirect. Where the page is being kept but the URL changes only slightly, still map it and redirect it. Where two old pages consolidate into one new page, redirect both to the surviving version.

Handling Pages With No New Equivalent

Not every page needs a redirect. Decide deliberately. Content that genuinely no longer exists should return a proper 410 or 404 rather than being redirected to the homepage, because sending every retired page to the homepage teaches search engines that your redirects are meaningless and gives users a page that does not answer their question.

Where an old page has links and a related new page exists, redirect it as closely as the content allows. Where it has no links and no relevance, let it go.

Redirect Rules That Protect Your Equity

Redirects are the mechanism that carries what your existing URLs have earned to their new home, which is why the common defects around them are so expensive.

301 Redirects Done Properly

Use a permanent 301 for URL changes. Each redirect should point to a single, final destination, resolve in one hop, and match the old page to the new page as closely as the content allows. The reassurance from Google Search Central is direct: "Don't worry about link credit. 301 and other permanent redirects don't cause a loss in PageRank." That statement is worth quoting to anyone who argues against redirecting, because the real risk during a redesign is not redirecting too much. It is redirecting too little, or to the wrong place.

Redirect Chains, Loops and Common Errors

Redirect chains are the most common defect I find. Page A redirects to page B, which redirects to page C, and sometimes the chain resolves to a page that no longer exists. Each hop dilutes the process and slows the crawl, and chains usually accumulate because the mapping was done in stages without anyone checking the result.

Loop errors are worse, but they are rarer and easier to spot. Before launch, crawl the redirect map and confirm every entry resolves in a single hop to a final 200 response.

Preserve Titles, Headings and Valuable Content

A redesign is an opportunity to improve content, not an excuse to rewrite everything that was working.

What to Keep and What to Improve

Keep the core content, the primary heading and the factual detail on pages that already earn traffic, unless you have evidence that a rewrite will perform better. Improve what is demonstrably weak: thin pages, duplicate sections, headings that never described the content.

Where you do change a title or a heading, change it for a reason and note the change in the mapping spreadsheet so you can measure the effect later.

Guarding Your Highest Value Pages

Identify the small number of pages that carry your organic traffic and your enquiries, and treat them as protected. They get the closest URLs, the most careful redirects and the least editorial invention. Everything else can be redesigned more freely.

Internal Linking and Site Architecture

Internal links are how search engines understand which pages matter and how users move through the site. Rebuilds break both when navigation and linking are treated as a design decision alone.

Rebuilding Navigation Without Orphaning Pages

Export the current internal link graph before the rebuild. After the new architecture is designed, check every previously linked page still has at least one internal link pointing at it. Pages that lose all internal links become effectively orphaned and often drop out of the index.

Updating Internal Links to New URLs

Every internal link that pointed at an old URL should be updated to point at the new one directly, rather than relying on a redirect. Relying on redirects for internal links slows the crawl and leaves chains in place long after launch, and it is a common oversight when new pages are built from new templates.

Technical Checks Before You Launch

Most of the damage that cannot be fixed with a redirect happens here. These checks take an hour and they save months.

Robots, Noindex and Staging Leaks

Confirm the live robots.txt is not blocking anything, that no noindex tags have carried over from the staging environment, and that the staging site is not publicly accessible and competing with the live site. A staging environment that resolves and is indexable will create duplicate content problems before anyone notices.

Sitemaps, Canonicals and Server Capacity

Update and submit the XML sitemap, confirm canonical tags point at the new URLs rather than the old ones, and check that no canonical is pointing at a redirected address. Then check the infrastructure, because Google Search Central is explicit about the extra load: "Ensure that your server has enough computing resources: after a migration, Google will temporarily crawl your new site more heavily than usual."

It is also worth resisting the temptation to do everything at once. Google's guidance is to "Change only one thing at a time. Plan your changes to your site one after the other, not everything at the same time." A redesign plus a domain change plus a content overhaul in the same week leaves you with no way to tell which change caused a problem.

Before launch is also the cheapest moment to have the plan checked. If you would rather not discover a broken redirect in the weeks after go live, have your site audited before you rebuild and work from a documented mapping rather than an intention.

Launch Day and the First 72 Hours

Launch day is a verification exercise, not a celebration. Work through the list before you tell anyone the site is live.

The Post Launch Verification Checklist

Check the live robots.txt. Check that no page returns a noindex. Check that redirects resolve in a single hop to a final page. Check the sitemap is submitted and the canonicals point at the new URLs. Check the key landing pages load in under a few seconds and that forms, tracking and phone numbers all still work.

Then re-crawl the site and compare the results against your mapping spreadsheet, looking for URLs that resolve as errors, URLs that were missed and internal links still pointing at old addresses. Work through the technical SEO checklist as you go rather than relying on memory at the end of a long week.

What to Watch in Search Console

In the first days, watch coverage and indexing, the sitemap report, and any sharp rise in crawl errors. Watch impressions and average position by page rather than by site, because site level averages hide the page that has fallen off entirely.

The Weeks After Launch

Some movement after a rebuild is expected. The skill is telling normal reassessment apart from a defect.

Normal Fluctuation vs Something Actually Broken

Google Search Central sets the expectation plainly. "Expect temporary fluctuation in site ranking during the move. With any significant change to a site, you may experience ranking fluctuations while Google recrawls and reindexes your site. As a general rule: for medium-sized websites, it can take a few weeks or more for Google to gradually start showing the new URLs instead of the old ones (and for larger sites, even longer)."

Normal fluctuation moves in both directions and recovers. Something broken trends down and stays down, often with the old URLs still showing, pages dropping out of the index, or one template losing traffic across the whole site at once. If the pattern is one-sided, treat it as a technical fault to be diagnosed rather than something to wait out.

How Long Recovery Usually Takes

Within the window Google describes, most sites see the new URLs replace the old ones and positions settle. If traffic is still falling after that window has passed, stop waiting and start diagnosing. The most common causes at that stage are a redirect chain, a canonical pointing at an old address, an internal link never updated, or content that was materially thinner than the page it replaced.

When to Bring In Outside Help

Most redesigns do not need an external consultant. They need a mapping spreadsheet, a redirect test and someone accountable for the checklist. Where outside help earns its place is where the risk is concentrated: high traffic sites, sites with thousands of URLs, ecommerce, or any project that combines a redesign with a domain or platform migration.

If the organic channel carries real revenue, the cost of a pre launch review is small against the cost of a quarter of lost traffic. Run a full SEO audit before the build, or bring in an SEO consultant for the migration to own the mapping, redirect and verification work end to end. The cheapest time to find a broken redirect is before it goes live.

Frequently Asked Questions

Will I lose rankings if I redesign my website?

Not automatically, but the risk is real and it comes from execution rather than from redesign itself. Google's own guidance is to expect temporary ranking fluctuation during a significant site change, with medium sized sites often taking a few weeks or more to show the new URLs. Damage happens when URLs change without a mapping, redirects are missing or chained, or valuable on page elements are dropped.

Do I need to redirect every old URL?

You need a decision for every old URL and a redirect for every URL that changes. Map old pages to their closest new equivalent, redirect pages that are being retired to the most relevant surviving page, and serve a proper 410 or 404 where content genuinely no longer exists. A complete mapping spreadsheet is the deliverable that prevents guesswork later.

Do 301 redirects lose link equity?

No. Google states directly that 301 and other permanent redirects do not cause a loss in PageRank. The equity loss you hear about usually comes from redirect chains, redirects pointing at the wrong page, or old URLs left to resolve as errors so the links never pass anything at all.

How long does it take to recover traffic after a redesign?

Google's guidance is that for medium sized sites it can take a few weeks or more for the new URLs to be shown instead of the old ones, and longer for larger sites. In practice the wait depends on how many URLs changed and how quickly they get recrawled. If traffic is still falling after that window, treat it as a technical fault to be diagnosed, not as patience.

Should I redesign and change domain at the same time?

No. Google's guidance is to change only one thing at a time: move the domain first, then change the layout, not both together. If something goes wrong, combining changes makes it far harder to work out which one caused it.

What should I check on launch day?

Confirm the live robots.txt is not blocking anything, that no noindex tags carried over from staging, that redirects resolve in a single hop, that the XML sitemap is updated and submitted, and that canonicals point at the new URLs. Then verify the server can handle the temporary increase in crawling that follows a migration.