The fear is reasonable and the timing is cruel. A business finally has a site that brings in calls, the design looks a decade old, and someone quotes a redesign. The question nobody can answer confidently is whether the phone will still ring afterward. Plenty of owners have heard a story about a company that rebuilt its site, watched traffic fall off a cliff, and spent a year clawing back.

Those stories are not myths, and the recovery timeline is the part that surprises people. SALT.agency's analysis of 1,052 domain migrations, published in June 2026 and drawn from its own projects plus hundreds crowdsourced from the SEO industry, found a median recovery time of 304 days, with roughly one in four recovering within 90 days. Those figures describe domain moves rather than redesigns, but a redesign that changes URLs puts the same machinery under strain, which is why the numbers are worth knowing before the project starts. The encouraging part is that many avoidable losses come from a handful of specific, preventable mistakes rather than from redesigning as such.

What causes a redesign to lose rankings

One of the most damaging causes is URL changes without redirects. Every page that ranks has an address, and search engines have years of signals attached to that address. Change the address silently and the signals stay behind at a URL that no longer exists. A visitor clicking an old Google result hits a not-found page, and the ranking that took three years to build starts to slide.

The second cause is content loss. Redesigns are often pitched as simplifications, and simplification usually means fewer words. A service page that ranked because it answered eleven specific questions gets rewritten into three elegant sentences, and the page stops matching what people search for. The design improved and the substance that earned the traffic went in the bin.

The third cause is accidental blocking. Staging sites are built with search engines blocked so the unfinished version never appears in results, and the block is supposed to come off at launch. Sometimes it does not. A site can sit invisible for weeks before anyone connects the quiet phone to a single line in a configuration file.

The fourth is internal linking. The old site had menus, footers, and in-page links pointing at the pages that mattered. A new structure can quietly orphan pages that used to get that support, and their rankings drift without any obvious cause. None of the four is a reason to avoid redesigning. It is why Optuno treats a rebuild as a migration with a design phase attached.

Inventory everything before a single page is built

Before design starts, export a complete list of the current site's URLs. Every page, not just the ones in the menu. Old landing pages, blog posts from 2019, service pages that were never linked from anywhere. Anything with a URL is on the list.

Next, pull the performance data for each of those URLs. Which pages bring organic traffic, which bring rankings, which bring conversions, and which bring nothing at all. Search Console and any analytics platform will give this in an afternoon. The result is the single most important document of the whole project, because it tells you which pages must survive in some form and which can be retired without consequence.

Then record what each surviving page ranks for and roughly where. A page sitting at position four for a term that brings real calls is an asset, and treating it as a design canvas rather than an asset is how businesses lose money on a redesign.

Finally, note the technical details that travel with each page: title tags, meta descriptions, heading structure, image alt text, and structured data. These are cheap to carry over and expensive to rebuild from memory. Taking the inventory first also settles arguments later, because everyone can see what a proposed change would cost. If you want a read on where things stand before the project begins, Optuno's free local SEO report gives a snapshot of rankings, listings, and reviews to measure against afterward.

Map every old URL to a new one

This is the step that separates a safe redesign from an expensive one. Build a spreadsheet with two columns: the old URL and what replaces it. Every single old URL gets a row, including the ones that will turn out to have no replacement.

Most rows map one to one. Some pages get merged, in which case several old URLs point at one new page. A few are retired with nothing equivalent to replace them, and those should return a 404 or 410 rather than being redirected somewhere unrelated. Google's guidance is that removed content should return a not-found status, and an irrelevant redirect, such as sending every retired page to the homepage, tends to be treated as a soft 404 anyway.

When the new site launches, the rows that have a destination become permanent redirects, which pass the accumulated ranking signals to the new addresses. Keep them in place indefinitely. Redirects are not a temporary launch measure, and removing them a year later reintroduces the original problem.

The best insurance is keeping URLs identical wherever possible. A redesign does not require new addresses. If a page currently sits at a working address and the content is staying, leave the address alone. Every unchanged URL is one that cannot break. Where the structure must change, plan the internal links at the same time, since internal linking for local SEO is part of what holds rankings in place.

Protect the content that earns the traffic

Take the pages that bring traffic and treat their text as fixed content that the design must accommodate, not the reverse. Designers reasonably want clean layouts, and clean often means shorter. On a page that ranks, shorter is a risk.

A useful rule is that a ranking page can be reorganized but not reduced. Break the text into sections, add headings, improve the typography, put the important lines higher. Do not delete the paragraph answering an unusual question, because that paragraph may be exactly why the page ranks.

Keep the title tags and headings close to what they were. These carry heavy weight, and rewriting every title in a new house style is a common way to lose positions for no benefit. If a title needs improving, change it after launch and watch the effect, rather than changing everything at once and never knowing which change did what.

Carry over any structured data that still applies, such as LocalBusiness or Organization markup, and revalidate it after launch. One caution worth knowing: review markup on your own pages, about your own business, is not eligible for review star features in Google results, so do not expect it to produce or restore stars. Losing valid markup can still remove signals Google uses to understand and display business information in Search, which is reason enough to migrate it deliberately.

Launch day and the weeks that follow

Before launch, check that search engines are not blocked, that the redirect map is loaded, and that the sitemap reflects the new structure. Those three checks catch most disasters.

In the first week, crawl the new site and look for not-found errors, redirect chains, and missing pages. Submit the new sitemap in Search Console and watch the Page indexing report for pages dropping out of the index. Some fluctuation is normal, since search engines need time to recrawl and reassess everything, and a dip in the first fortnight is not proof of failure.

Watch page speed too. New sites often carry heavier images and more scripts than the ones they replace, and speed degrades quietly. The Core Web Vitals guide covers what to measure.

Give it eight to twelve weeks before judging whether the site has settled, while bearing in mind that a migration which does go wrong takes far longer than that to come back. Do not wait to fix errors, though. Broken redirects found in week one cost almost nothing. The same errors found in month four have already cost a season of calls. If the site is due a rebuild for other reasons, the signs it is time for a redesign are worth reading alongside this.

If the technical side of a redesign is not something you want to manage, Optuno's plans cover the build and the search work together, with no long-term contracts, no setup fees, and a dedicated contact.

Frequently asked questions

Will a redesign always hurt my rankings?
No. A redesign that keeps the same URLs, the same content, and the same titles substantially lowers the risk, and can help if the site gets faster. Losses come from changing addresses without redirects, cutting content, or blocking search engines, all of which are avoidable.

How long does it take to recover if traffic drops?
Longer than most people expect when it goes badly. The data above measured moves between domains rather than same-domain redesigns, and put median recovery at around ten months. A redesign that keeps the domain and redirects properly should not take anything like that, which is the argument for getting the redirects right rather than planning to recover.

Do I need to redirect every old page?
Redirect every page that has a genuine equivalent on the new site, and do it at launch when it is cheapest. Pages whose content is simply gone, with nothing equivalent to send people to, should return a 404 or 410 instead. An unrelated redirect preserves nothing and is generally treated as a soft 404.

Can I change my page titles during a redesign?
You can, but change as few as possible at once. Titles carry significant weight, and rewriting all of them alongside every other change makes it impossible to tell what caused any movement. Adjust them individually after the site settles.

Should the old site stay online during the rebuild?
Yes. Build the new site on a separate staging address with search engines blocked, then switch over once redirects are ready. Taking the current site down during a build removes the traffic you are trying to protect.

What if my site is already rebuilt and traffic dropped?
Start with the redirect map, because missing redirects are a common cause and are still fixable. Compare the old URL list against the new site, add the redirects that are absent, then check whether ranking pages lost content in the rewrite and restore what was cut.