Short answer: a new look costs you nothing. Changing your addresses without mapping them costs you a great deal. Those are two different events and almost nobody separates them, which is why this question makes owners freeze for a year.
Two things that get called one thing
When somebody says redesign, they might mean either of these, and the difference is the entire answer.
The first is cosmetic. New layout, new colours, new photography, new copy, same pages at the same addresses. Your contact page is still at /contact. Nothing has moved. There is no migration happening, because nothing migrated.
The second is structural. Pages get merged, renamed, dropped or reorganised, and the addresses change. /dental-implants becomes /services/implants. Now you have moved house, and the post has to be redirected or it stops arriving.
Google treats only the second one as a site move. If your URLs do not change, there is no signal transfer to get wrong.
What Google actually says about moving
This is the part worth reading twice, because the fear is much bigger than the documented risk.
From Google's own guidance on moving a site with URL changes:
"301 and other permanent redirects don't cause a loss in PageRank."
And more bluntly, in the same document:
"Don't worry about link credit."
Keeping the redirects in place, Google says, "allows Google to transfer all signals to the new URLs". Not some. All.
12months is the minimum Google suggests you keep those redirects live, and it says to consider keeping them indefinitely.
So the mechanism for carrying your history across is documented, supported and free. It is not a gamble.
The failure Google names out loud
Here is the sentence that should actually govern how you commission a rebuild. Still Google, same page:
"We frequently see people redirecting to the wrong (non-existent) URLs on the new site."
Read that again. The thing that goes wrong is not the design, the platform, the content or the timing. It is somebody writing the redirect list and getting the destinations wrong, or not writing one at all.
That is a clerical failure, not a technical one. It is also completely preventable, and it is the single question worth asking before anybody starts building.
Two more ways to break it
Google names two others on the same page, and both are common.
The first is pointing a lot of old pages at one new page, usually the homepage, because it is quick. Google says do not do this, because it "can confuse users and might be treated as a soft 404 error". A soft 404 is Google deciding your redirect went nowhere useful. You get the worst of both: the old page is gone and the new one inherits nothing.
The second is chains. Old page goes to a second page which goes to a third. Google's instruction is to redirect "to the final destination directly".
How long the wobble lasts
This is where people panic and undo good work.
Google says that for a medium sized site "it can take a few weeks or more for Google to gradually start showing the new URLs", and longer for larger sites.
So positions moving around for a few weeks after a cutover is the documented normal case, not evidence that something broke. The mistake is reacting at week two by changing things again, which restarts the clock.
Decide in advance what you will do if rankings dip in week one. The answer should be nothing.
Should you build in parallel
Yes, and this is how every competent rebuild already works. You build the new site somewhere else, you check it properly, you cut over in one go.
What you must not do is leave that parallel copy publicly indexable, because then you have two websites with the same content competing with each other, and you have manufactured the exact problem you were trying to avoid.
There is a trap here that catches experienced people, and it is worth knowing because it is counterintuitive. If you block the staging site with robots.txt, you may stop the noindex rule from working at all. Google is explicit:
"For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file."
Because if the crawler is blocked, "the crawler will never see the noindex rule, and the page can still appear in search results."
Google also states plainly that "specifying the noindex rule in the robots.txt file is not supported by Google".
So the belt and braces answer is a password on the staging site. No crawler, no indexing question, no race.
I will be honest that I have seen this one go wrong, and the people it went wrong for were not careless. The instinct to block everything with robots.txt is a reasonable instinct that happens to produce the opposite result.
Where the risk actually sits
Distance between what owners worry about and what goes wrong.
- Layout, colours, photography
- No URLs change
- Safe
- Rewriting the copy on a page
- No URLs change
- Safe
- A page moving to a new address
- Needs a 301
- Mapped
- An old address left to 404
- Signals stop there
- Lost
- Many old pages to the homepage
- Possible soft 404
- Risky
- Redirect chains
- Slow and lossy
- Avoid
- Staging site left crawlable
- Competes with you
- Risky
The top two are what owners ask about. The bottom five are what actually costs them, and all five are decided on a spreadsheet before anybody designs anything.
What to ask before you commission anything
- Are my URLs changing at all? If the honest answer is no, most of this post does not apply to you and you can stop worrying.
- If they are changing, can I see the redirect map? A list of every old address and the specific new page it points to. Not a promise that redirects will be handled. The actual list.
- Does every old page have a destination that exists and is genuinely about the same thing?
- Is anything being pointed at the homepage out of convenience? That is the soft 404 risk and it should be a deliberate choice, not a default.
- How long will the redirects stay up? The answer should be at least a year, and ideally forever.
- Is the staging site password protected rather than only disallowed in robots.txt?
- Who is watching Search Console for the month after launch, and what will we agree not to panic about?
None of those require you to understand SEO. They are project management questions, and they are the whole ballgame.
The part that is not in the documentation
Everything above is Google's published position and you can check all of it.
Here is my opinion, clearly labelled as one. The reason redesigns get blamed for ranking losses is that a rebuild is the moment somebody finally touches a site that has not been touched in seven years. Pages get consolidated, thin pages get deleted, the structure gets rationalised. Some of those decisions are good and some are not, and the ones that are not show up as lost rankings a month later and get attributed to the new design.
The design was never the variable. The decisions about which pages still deserve to exist were the variable, and those are worth arguing about properly, before anybody opens a design tool.