A redesign does not cost you traffic. A change of address does.
That distinction is the whole subject. If your new site keeps every page at exactly the address it has today, there is very little search risk in redesigning it. The moment those addresses change — a new page structure, a tidier permalink scheme, a move to a different platform, a new domain — you are no longer redesigning, you are migrating. Migrations have a checklist, and skipping it is what produces the story every business owner has heard secondhand: the site looked better and the enquiries stopped.
Nearly everything below is drawn from Google's own documentation on moving a site with URL changes, rather than from the recycled percentages that circulate in redesign articles. Where a number could not be traced back to a source you can open and read yourself, we have left it out and said so.
If you are still deciding whether to rebuild at all, start with our guide to the signs your website needs a redesign. This article assumes the decision is made.
Step 1: Work out whether you are actually moving anything
Redesign projects fall into three tiers, and they carry very different levels of risk.
- New design, same addresses. Every page keeps its exact URL. This is the safest option by a wide margin and there is nothing to redirect. Most of this article does not apply to you — skip to the launch-night section.
- Same domain, new addresses. The pages move: /services/web-design.html becomes /web-design, or a category layer appears or disappears. This is the common case, and it needs a full redirect map.
- New domain. A rebrand, a merger, or finally dropping a domain you never liked. Everything in the second tier applies, plus a Change of Address request in Search Console.
Be strict about what counts as a changed address. These are all different URLs to a search engine, even when the page on screen looks identical:
- http:// and https://
- www.example.com and example.com
- /about/ and /about — the trailing slash matters
- /About and /about — capitalisation matters on most servers
- Any change to a slug, however small, including removing a stray word or a date
A surprising number of redesigns that were briefed as "same pages, new look" turn out to be tier two once someone checks the trailing slashes.
Step 2: Build the URL inventory before design starts, not after
The most valuable document in any redesign is a complete list of the addresses the site has today. Google suggests four places to assemble it from, and they complement each other rather than overlapping:
- Your XML sitemaps. Your most important URLs are probably already submitted there.
- Server logs or analytics. These show which URLs actually receive traffic, which is how you decide what to prioritise.
- The links report in Google Search Console. This shows which of your pages other websites link to. Those pages carry value that a broken redirect throws away.
- Your CMS. The admin listing of every page, post, product and category.
Google adds one instruction that almost every checklist omits: include embedded content in the plan — videos, images, PDFs, JavaScript and CSS files. Images and downloads may already be receiving traffic or links of their own, so they need to be accounted for rather than quietly renamed. If your PDF price list has been linked to by a trade association for six years, that link is an asset.
Put it all in one spreadsheet with a column for the old URL, the new URL, the redirect type, whether it has been implemented, monthly traffic, and the number of external links pointing at it. The last two columns are what let you make sensible decisions when two old pages have to merge into one new one.
Step 3: Map every old URL to its closest new one
This is the step that decides whether the migration works. Five rules cover almost all of it.
Use permanent, server-side redirects. Google's guidance is to use a permanent server-side redirect whenever possible, as the best way to make sure both people and Search end up on the correct page. The 301 and 308 status codes both mean permanently moved. A temporary redirect tells Google the old URL is coming back, which is not what you want after a redesign.
Do not worry about lost link value. Google's site move documentation is explicit: permanent redirects do not cause a loss in PageRank. Older advice about 301s "leaking" a percentage of link equity has been superseded, and it is not a reason to avoid restructuring a site that needs it. What loses value is a redirect that is missing, broken, or pointed somewhere irrelevant.
Map one-to-one, to the closest relevant replacement. Assess each valuable old URL individually and send it to the new page that genuinely replaces it. The lazy alternative — pointing everything that no longer exists at the homepage — is worse than useless, because a visitor looking for a specific service lands on a general page and leaves.
Never chain redirects. If A used to point to B, and B now points to C, update A to point straight at C. Chains are slower for visitors and waste crawl effort, and each extra hop is another thing that can break in two years when someone tidies up the redirect file.
Be honest about pages that are genuinely gone. If a page has no equivalent on the new site, returning a 404 or a 410 is more honest than sending someone somewhere unrelated. Redirect when there is a real replacement; let it go when there is not.
Step 4: The four things that go wrong on launch night
In our experience these four account for nearly every redesign that loses traffic, and all four are preventable in the hour before go-live.
1. The staging noindex tag ships to production. Development sites are almost always blocked from search on purpose, either with a robots meta tag or a site-wide setting. If that block travels with the new design, pages begin disappearing from search within days and nobody notices until the enquiries stop. Check the live site for a robots meta tag, check for an X-Robots-Tag in the HTTP headers, and remove any password protection left over from staging.
2. The old URLs get blocked in robots.txt. This one is counter-intuitive and it is the reason careful migrations still fail. Blocking the old addresses to "clean them up" means Googlebot can no longer fetch them, which means it never sees the redirect you built, which means the signals never move across. Leave the old URLs crawlable.
3. Internal links keep pointing at the old addresses. Google's documentation says to replace, based on the mapping you already created, all the URLs that point to your own pages. That means navigation, footers, buttons and links inside body copy. Redirects exist to catch visitors arriving from outside — your own site should link directly to the final address. Old links inside your own content are the most common source of accidental redirect chains.
4. Pages that were working get shortened. A redesign is a tidying exercise, and tidying tends to mean less text. If a page is currently bringing in visitors, treat its content as a fixed requirement rather than something the new layout gets to negotiate with. Shorter and cleaner is a design goal, not a search one.
Step 5: Change one thing at a time
Google's advice on this is short and worth taking seriously. If you change the domain, the platform, the design and the URL structure on the same night and traffic drops the following week, you have four plausible causes and no way to isolate any of them. If your project really does need all four, sequence them: move the domain, let it settle, then redesign on top.
The same logic applies to content. Migrating your existing pages and rewriting them at the same time makes it impossible to tell whether a drop came from the move or from the new copy.
Step 6: Tell Google, using the tools it provides
If you are changing domain, use the Change of Address tool in Search Console. Three details are easy to get wrong:
- You must be verified as an owner of both the old and the new property before you can use it.
- Google recommends a 301 from the old homepage to the new homepage, plus 301s for the canonical pages on the old site, before you submit the request.
- Submit the request for both the www and the non-www variant of the old domain. Missing one leaves part of the migration signal incomplete.
A Change of Address request can be cancelled for 180 days after it is made, which is a useful safety net.
Three more Search Console points that apply to any migration, domain change or not. Submit the new sitemap as soon as the site is live, and keep the old sitemap in place — the Sitemaps report will warn that its URLs redirect, and Google says that warning is expected and not a reason to remove the old sitemap or switch the redirects off early. If you ever uploaded a disavow file for the old site, upload it again under the new property. And do not limit Googlebot's crawl rate on either site; remove any existing limit on the old one, because Google adjusts crawling automatically when it detects a move.
A launch-day checklist you can hand to your developer
Run this in the first hour after the new site goes live, not the following week.
- Crawl the complete list of old URLs from your spreadsheet and confirm each one returns a redirect to a page that returns 200.
- Check that no redirect passes through a second hop.
- View source on the homepage and two inner pages and confirm there is no robots noindex tag.
- Open /robots.txt on the live site and confirm nothing important is disallowed.
- Confirm the HTTP headers carry no X-Robots-Tag blocking indexing.
- Confirm canonical tags point at the new URLs, not the old or the staging ones.
- Submit the new sitemap in Search Console.
- Send a test message through every form, from a phone, and confirm it arrives.
- Check that analytics and any conversion tracking are still firing on the new templates.
- Set up 404 monitoring so that anything you missed surfaces in days rather than months.
Our small business website checklist covers the rest of the launch, the parts that are not specific to a migration.
What to expect afterwards, honestly
You will find a lot of confident numbers about how far traffic drops after a migration and how long it takes to come back. We are not going to repeat them, because the ones in circulation cannot be traced to a study you can read. What we can tell you is what Google publishes about the process itself, and it is more useful than a percentage.
A site move is only complete once Googlebot has visited every URL on both the old and the new site at least once. There are no fixed crawl frequencies, and the speed depends on the size of the site and how fast it can be crawled. Crucially, the move happens on a per URL basis. That is why a migration rarely looks like one clean dip and recovery: your homepage and main service pages tend to be recrawled quickly and settle first, while older or rarely linked pages take considerably longer.
Practical consequences. Watch Search Console rather than yesterday's traffic figure, and watch impressions on your top pages rather than a single site-wide total. Give it weeks rather than days before drawing conclusions. And leave the redirects in place permanently — removing them a few months later, once things look normal, throws away exactly what they were protecting.
The one clause to get into the contract
It is not the only clause worth checking before you sign. Our guide to who owns your website after launch covers the rest - copyright assignment, the domain, the accounts and the third-party licences.
If you take a single thing from this article into your next conversation with a web designer, make it this: ask, in writing, who is responsible for the redirect map, and ask to see it before launch.
It is a fair question and a good agency will have a ready answer, because the map is real work — someone has to go through the inventory line by line and decide where each old page now belongs. If the answer is vague, or if redirects are described as something that can be sorted out after go-live, that is worth resolving before you pay a deposit. Our guide to choosing a web design company covers the other clauses worth pinning down at the same time.
In summary
Redesigning a website is not inherently risky for search. Changing addresses without a plan is. Work out whether your project actually changes URLs, build the inventory before design starts, map every old address one-to-one onto its closest replacement with permanent server-side redirects, keep the old URLs crawlable, update your own internal links, and do not let a tidier layout quietly delete content that was earning its place. Then be patient, because the recovery happens one URL at a time. If search visibility is the reason you are rebuilding in the first place, our explainer on what SEO is and how it works sets out what actually moves the needle afterwards.
Frequently asked questions
Will a website redesign hurt my Google rankings?
Only if it changes your URLs without redirecting them, or if it ships with noticeably less content than the old site. Google states plainly that 301 and other permanent redirects do not cause a loss in PageRank, so a redesign that keeps every address the same, or maps every old address one-to-one onto its closest new equivalent, has no reason to lose rankings. The damage almost always comes from a missing redirect map, a noindex tag left over from staging, or pages that were earning traffic being rewritten much shorter.
Do I need redirects if the new site keeps the same page addresses?
No. If every URL stays character for character identical, you have a redesign rather than a migration and there is nothing to redirect. Check that carefully before you assume it, though. Moving from http to https, from www to non-www, from a trailing slash to no trailing slash, or to a tidier permalink structure all produce different URLs as far as a search engine is concerned, even when the page looks unchanged.
What is the most common mistake when launching a redesigned site?
Shipping the staging noindex tag to production. Development sites are usually blocked from search on purpose, and if that block goes live with the new design, pages start dropping out within days. The second most common is blocking the old URLs in robots.txt to tidy things up, which stops Googlebot from ever seeing the redirects you carefully built and prevents the signals from moving across.
How long does it take to recover after a site migration?
Google does not publish a number and neither will we. What Google does say is that a move is only complete once Googlebot has visited every URL on both the old and the new site at least once, that there are no fixed crawl frequencies, and that the move happens on a per URL basis. In practice your most important pages tend to settle first and the long tail takes longer. Leave the redirects in place permanently rather than removing them once traffic looks normal again.
Should I redesign and move to a new domain at the same time?
Try not to. Google advises changing one thing at a time, and the reason is diagnostic rather than technical. If the domain, the design, the platform and the page structure all change on the same night and traffic then falls, you have four plausible causes and no way to test any of them. Move the domain first, confirm it has settled, and redesign afterwards.
Planning a rebuild and want the redirect side handled properly? Tell us what your current site looks like and we will map it out with you — our web design service treats the URL inventory as part of the build rather than an afterthought.
