Website Redesign Without Losing Rankings: 301 Redirect Map

Redesigning a business website usually starts with a visual decision: the menu looks dated, the layout falls apart on mobile, the brand identity has changed. Because the decision is visual, the project is run visually too — the design gets approved, the copy gets refreshed, the new site goes live. In the weeks that follow, visits from search engines start to fall, and nobody can show exactly where the drop is happening.

The source of the loss is almost never the design. The source is that the addresses the old site accumulated over the years are left with nothing on the other side in the new one. An address is a record in the search engine's index, a link on someone else's site, a URL shared in an email and a bookmark in a customer's browser. If nobody decided in writing what would replace that address during the redesign, the decision gets made on its own: an error page.

What follows treats a redesign not as a design job but as an address-moving job. It covers how to build the address inventory, how to set up the mapping table, and how to read a post-launch drop one address at a time. Part of this work is tedious, and that is exactly why it gets skipped.

What a redesign loses is not the design but the addresses

What a search engine knows is not your page but your address. When a page starts to match a query over the years, that match is written against the address. When the address disappears, so does the match; the fact that the content is better written on the new site does not make up for it on its own.

That is why the first deliverable in a redesign project is not a design mock-up but a list: how many addresses the old site has, which of them get visits from search engines, which of them get links from outside. A project that moves into design before that list exists cannot measure what is missing on launch day — because it has no "before" to compare against.

The second point is about expectations. Even in a redesign where the addresses were moved properly, some fluctuation can show up in the first weeks; it takes time for the search engine to recrawl the new structure and update its index records. The honest sentence here is this: a move done right reduces the depth and persistence of the fluctuation, it does not bring it to zero. Any promise that puts a number on how long recovery will take presents something unmeasurable as if it had been measured.

How to build the address inventory

The inventory does not come from a single source. It takes a combination of four, and each one shows what the others cannot see.

The existing sitemap. The old site's sitemap.xml file is the site's own declaration. It gives a quick starting point but it is incomplete: addresses deleted over the years, pulled out of the admin panel, or never added to the sitemap in the first place do not appear there.

The search console. The performance report in Search Console lists the addresses that actually earned impressions and clicks in the recent period. This list is not the site's declaration but the search engine's observation; it includes addresses that are not in the sitemap. The "indexed" list in the indexing report is exported for the same purpose.

Server access logs. Log files show which addresses both crawlers and real visitors are requesting. Old addresses that are in neither the sitemap nor the search console often surface here — especially old links shared by email and on social media.

Backlink records. Which of your addresses other sites link to is a separate list. An address may get no visits at all, but if it earns links from outside it is an asset that has to be moved.

The four lists are merged, de-duplicated and turned into a single table. The size of that table usually surprises the project team: a site they believed had forty pages can turn out to have hundreds of addresses, because tag pages, pagination URLs, old campaign pages and file links are addresses too.

Which old address goes to which new one: the five columns of the mapping table

The mapping table is the most valuable document in the project, and it is built with five columns.

No row with an empty "Decision" column is allowed to go live. That rule is the table's only function: not leaving the decision to launch day. Decisions made on launch day are made in a hurry, and they almost always come out as "redirect it to the home page".

The "Rationale" column looks unnecessary, but six months later, when someone asks "why was this page dropped", it is the only place that holds the answer. One sentence is enough, something like: "the two pages answered the same question, merged into the longer one".

A common mistake while building the table is listing only the addresses that get visits. An address that gets no visits but earns links from outside, if it is not moved, costs you both the visitor and the value that link was passing on.

A page with no counterpart: delete, merge, or point to a parent category

Not every old page will have a one-to-one counterpart on the new site, and it does not need to. A redesign is often done precisely to cut down the content. For a page left without a counterpart there are three reasonable decisions.

Merging. If two old pages answer the same question at different depths, the content is gathered on a single page and both old addresses are redirected to it. This also solves the problem of pages with the same intent suppressing each other; we wrote in detail about the framework for deciding which page should carry a topic in our article on semantic content strategy.

Pointing to a parent page. If the page belongs to a service that is no longer offered and its subject lives on under a broader heading, the address is redirected to that parent heading. The visitor does not find exactly what they were looking for, but they land in the nearest place.

Removing. If the page's subject has ended entirely — like the registration page for a past event — the address can be removed, and the right answer is the signal that it is permanently gone. Even then, redirecting to the home page is wrong: the visitor lands on a page unrelated to what they wanted, and the search engine often treats redirects like this as if they were an error page.

Traffic should not be the only criterion when deciding. If a page gets few visits but it is the page the sales team links to in proposals, that page stays.

301 or 302, canonical or noindex: which one, when

These four tools do not substitute for one another, and when they get mixed up this is where the most expensive mistakes come from.

Permanent redirect (301). It means the address has changed for good. This is the default tool for a redesign. The visitor goes to the new address, and over time the search engine moves its index record to the new address.

Temporary redirect (302). It means the address is pointing somewhere else for the time being; the old address's record is kept. Because a redesign is a permanent change, using a 302 here tells the search engine "the old one is still valid". The most common technical mistake in redesign projects is a server that defaults to 302 and nobody checking it.

Canonical tag. On pages whose content stays accessible but opens from more than one address, it declares which address is the real one. It does not replace a redirect: if the page was removed, a canonical solves nothing.

Noindex. It means the page stays live but stays out of the index. It is used on pre-launch staging environments, and the single line someone forgets to remove on launch day can take the whole site out of the index. In redesign projects this is, measurably, the most widespread disaster, and checking for it takes ten seconds.

Chains and loops: the cost of a two-step redirect

A redirect chain is when one address points to a second address, which in turn points to a third. If the site has been through more than one redesign in its history, a chain forms on its own: the 2019 address points to the 2022 one, which points to today's.

A chain has two costs. The first is speed: every step is an extra request round trip, and on mobile the difference is noticeable. The second is uncertainty: after a certain point, browsers and search engines stop following long chains, and the value sitting at that address is left hanging.

The right move is to flatten the chain. Addresses left over from earlier redesigns are added to the mapping table as well, and each one is redirected directly to today's target. A loop is a cruder mistake: address A points to B, B points back to A, and the browser can never open the page. A loop usually forms when separate rules are written for the same address in two different layers — the server configuration and an in-application rule.

The pre-launch check is simple: every old address in the mapping table is requested one by one, and the returned status code and final address are recorded. The expected output is a 301 in a single step, landing on the correct target.

The launch-day checking order

The order matters on launch day, because some checks are meaningless until others are done.

First — access. Does the site open, is the certificate valid, does the preference between www and the bare domain work in one direction only. If the same content opens at both addresses, the same page is live at two addresses.

Second — permission to index. Is robots.txt what you expect it to be, is there a block left over from the staging environment, is there still a noindex on the pages. There is no point running the other checks before this one.

Third — redirects. The whole mapping table is requested; every row that does not return a 301 in a single step is flagged.

Fourth — is the content actually being served. It is not enough for the page text to show up in the browser; it has to be in the source as well. In setups where the content only appears after a script runs, search engines and AI crawlers see incomplete text. We explained step by step why this is an infrastructure decision and how to verify it in our guide to website infrastructure for small businesses.

Fifth — measurement. Is the analytics code running on the new site, have the conversion definitions been updated for the new addresses, does a form submission actually land in the inbox.

Sixth — declaration. The new sitemap is submitted to the search console. This step comes last on purpose: getting an incomplete site crawled delays the recrawl of the corrected version.

The first four weeks: how to read a drop address by address

After launch, the one number to look at is not total visits. The total shows that there is a drop, not why. What needs reading is the address-by-address comparison.

The method is this: from the search console's performance report, take the address-level impression and click lists for a one-month period before launch and for the period after launch, and join them with the mapping table. You are looking for three patterns.

The old address is still in the list, the new one is not. The redirect is working, but the search engine may not have processed the new address yet; it is reasonable to wait on this pattern.

Neither the old nor the new address is in the list. There is a break here: the redirect may be missing, the target may be wrong, or the new page may have failed to get indexed. This is the pattern that needs investigating.

The new address is in the list but the queries have changed. This is not a technical problem but a content problem: while the page was being rewritten, the question the old page used to answer may have dropped out of the text.

Over the same period you also need to watch the gap between impressions and clicks; what a page that appears on the results page but does not get clicked actually earns you is a separate discussion, and we took it up on its own in our article on measuring demand in the zero-click era.

When a phased migration is a better call than a redesign

Not every redesign has to happen in one go. The bigger the site, the bigger the risk of changing its entire address structure overnight. In two situations a phased migration is easier to defend.

When the number of addresses exceeds the team's capacity to verify them. If the volume is such that every row of the mapping table cannot be verified one by one on launch day, moving section by section limits the damage: the corporate pages first, then the blog archive. In stores carrying thousands of product addresses this work runs at a different scale; we covered product URL mapping when moving a store in a separate article.

When the address structure and the design change at the same time. When both change on the same day, it becomes impossible to tell where a drop came from. Launching the design first on the existing address structure and leaving the address change for a separate round keeps the cause readable.

The cost of a phased migration is time, and that cost is real. The decision depends on the project's risk tolerance: agreeing in writing at the scoping stage which path to take is cheaper than arguing about it on launch day. We wrote about how we set scope and delivery criteria in redesign projects on our corporate website service page; how the first month after launch is run is gathered under its own heading in our first-30-days-after-launch plan.

If you want to build the address inventory of your current site and see the risks before a redesign, you can get in touch with us.

Frequently Asked Questions

Is a traffic drop after a redesign normal, and how long does it take to recover?

Some fluctuation is to be expected when the address structure changes, because it takes time for the search engine to recrawl the new structure and update its index records. Giving a number for the duration would not be right: the size of the site, how often it gets crawled and the scope of the change determine that period, and none of them can be known in advance. The healthy approach is to set up address-level tracking instead of estimating a duration — which new address corresponds to which old one, and whether that address has started earning impressions, is far more informative than the total traffic figure.

Could we just redirect all the old addresses to the home page instead of keeping them?

This is the most common shortcut in redesign projects and the most expensive one. The visitor lands not on the content they were looking for but on an unrelated page, and in all likelihood leaves the site. On the search engine side, bulk redirects that send content to an unrelated target are often treated not as a permanent move but as if they were an error page. The right behaviour is to find the closest counterpart for every address, and where there genuinely is none, to state honestly that the address has been removed.

How does the process change if the domain name is changing too?

When two changes stack on top of each other the risk goes up, because both the address paths and the domain are being moved at once. In that case the mapping table is built on the same logic, but the redirects are defined on the old domain's server, and that domain needs to be kept for at least a year, preferably longer. On top of that, a separate property should be verified in the search console for the new domain and the provider's change-of-address notice should be used. If possible, leaving the domain change for a round separate from the design refresh keeps the source of any problem distinguishable.

How long should we keep the redirects in place?

For permanent redirects, the reasonable approach is to treat them as permanent. The search engine can update its index record in a relatively short time, but links on external sites, links in emails and users' bookmarks go on pointing at the old address for years. As long as the redirect rules can be kept without putting load on the server, there is no reason to remove them; and if they are going to be removed, the access logs should be checked first to see whether those addresses are still being requested.

What data should we back up before a redesign?

At least five items: the full address inventory, an export of the search console's performance and indexing reports, the historical reports on the analytics side, the old site's copy and images, and the current configuration files. These backups are needed not only for a disaster scenario but for comparison: the only way to measure a post-launch drop is to have a record of the period before it at the same level of detail. Taking the backups on the first day of the project is safer than taking them after the design has been approved.