In shortSearch rankings are attached to URLs, not to designs. Keep the URLs — or map every one you change to its closest replacement — and a redesign is a low-risk change.
The fear is reasonable. The cause is boring.
Nearly every business that has been online for a decade knows somebody whose traffic collapsed after a relaunch. It is the single most common reason a redesign gets postponed for another year, and the fear is well founded: it does happen, and when it happens it is expensive.
What is less well known is that the cause is almost never the design. Google does not rank a site because of how it looks. It ranks pages, and it remembers those pages by their addresses. A redesign that changes how a page looks is a small change. A redesign that changes where a page lives, without telling anyone, is a large one.
Almost every post-relaunch traffic loss traces back to one of five things. None of them are subtle, and all of them are cheaper to prevent than to recover from.
The five things that actually cause the drop.
In rough order of how often they are the culprit, and how much damage they do.
URLs changed and nothing was redirected
The old page ranked. The new site has the same content at a different address. Anyone who follows the old link — a search result, another site, an email from two years ago — gets a 404. Google eventually drops the old URL and starts the new one from nothing, with none of the history that earned the ranking. This is the big one, and it is entirely avoidable.
Pages were quietly dropped
A rebuild is a natural time to tidy up, and thin-looking pages are the first to go. But "thin" to a designer and "ranking for something valuable" are unrelated properties. A 200-word page about a specific service can be the entry point for the highest-intent traffic on the whole site. If nobody checked what each page was earning before deleting it, some of what was deleted was earning something.
The content got shorter
Modern design tends toward less text. That is usually right for readability and often wrong for search. If a page that ranked on a detailed explanation is rewritten down to three lines and a photograph, it no longer answers the question it used to answer, and the ranking follows the answer. Reformat the content; do not evaporate it.
Titles and headings were rewritten for style
Page titles and H1s are the strongest on-page signals of what a page is about. Replacing a title like "Emergency plumber, Springfield — 24 hour callout" with "Get in touch" is a design improvement and a search catastrophe. Rewriting them is fine. Rewriting them without knowing what the old ones were earning is not.
The new site blocks crawlers
Staging sites are usually set to noindex so they do not compete with the live site. That is correct — and shipping that setting to production is the most embarrassing way to lose all of your traffic at once. It is also the fastest to fix, if anyone checks.
What to do before the redesign starts.
All of this happens before any design work. It is unglamorous and it is the entire ballgame.
Take a complete URL inventory
Every address the current site serves — not the ones in the navigation, all of them. Export from the CMS, crawl the site with a tool, and pull the list of pages that have received search traffic from Search Console. The three lists will not match, and the gaps are the point: pages nobody remembers are often the ones quietly earning.
Find out what each page is worth
For each URL, note the search traffic it receives and the number of other sites linking to it. Most pages will be worth nothing measurable, and that is fine — you are looking for the small number that are, so you know which ones must survive the move intact.
Decide the fate of every URL, on paper
Three options: keep the address exactly as it is, move it to a new address, or retire it. Keeping is free and should be the default — there is rarely a good reason to change a URL that already works. Every "move" needs a destination written down. Every "retire" needs a reason better than "it looked old".
Write the redirect map
A two-column list: old address, new address. Every URL marked "move" or "retire" needs a row. A retired page redirects to the closest equivalent — the parent service, the relevant category — not to the homepage. A pile of redirects pointing at the homepage tells a search engine those pages are simply gone, which is the same outcome as the 404 you were trying to avoid.
Carry the titles across deliberately
Take the existing page titles and H1s into the new site as the starting point, then improve them on purpose. This is not a rule against rewriting; it is a rule against rewriting by accident, which is what happens when a designer fills in placeholder headings and nobody compares them to what was there.
Launch day checks.
Half an hour of work. Skipping it is how a preventable problem becomes a three-month problem.
The site is not set to noindex
Check the robots meta tag on the live site itself, not on staging. This single setting can remove an entire site from search results, and it is invisible to anyone just looking at the page.
robots.txt does not block anything important
A staging robots.txt that disallows everything is a common thing to ship by accident, with the same effect as the noindex flag.
Every redirect in the map actually works
Test them, do not assume. Redirect rules are written by hand and typos are silent — a rule that does not match simply does nothing, and the page 404s.
Redirects are permanent, not temporary
A 301 says "this moved, transfer what you know about the old address". A 302 says "this is temporary, keep the old one". Shipping 302s means the move never fully takes effect.
Redirect chains are collapsed
If an old URL redirects to a second URL that redirects to a third, point the first straight at the final destination. Chains are slow for visitors and lossy for crawlers.
The sitemap lists the new URLs and not the old ones
A sitemap still advertising retired addresses works against the redirect map you just wrote.
Canonical tags point at the new addresses
A canonical tag left pointing at the old URL tells search engines to ignore the page they are looking at in favor of one that now redirects. It is a loop, and it wastes the move.
Analytics and Search Console are still recording
Tracking code is easy to lose in a rebuild. If it is missing you will not be able to tell whether anything went wrong, which is worse than the original risk.
The new site is submitted for recrawling
Search engines will find the changes on their own eventually. Telling them shortens "eventually" considerably.
What to expect afterward, honestly.
Even a well-executed migration usually shows some movement in the first few weeks. Search engines have to recrawl every changed URL, follow every redirect, and reassess pages whose content moved. That takes time, and during it, rankings can wobble in both directions.
A modest dip that recovers over several weeks is normal and is not evidence that something broke. A sharp drop that does not recover is a signal to go back to the checklist above — in our experience it is nearly always a redirect that does not fire, or a noindex flag nobody checked.
What nobody can promise you is that a redesign will improve your rankings. A faster, better-structured, more useful site removes obstacles, and removing obstacles helps. But rankings depend on what competitors do, on how search engines change, and on demand you do not control. Anyone who guarantees you a position is telling you something they cannot know.
Questions worth asking any agency before you sign.
You do not need to be technical to ask these. The quality of the answers tells you most of what you need to know.
- Will you take a full inventory of our existing URLs before design starts, and can we see it?
- Which of our current URLs are you planning to change, and why is each change worth making?
- Who writes the redirect map, and will we see it before launch?
- How will you decide which existing pages to keep, and what will you look at to make that call?
- What is your launch-day checklist, and can we have a copy of it?
- If traffic drops after launch, what happens next, and is that work included?