You keep your SEO through a redesign by protecting the signals Google already trusts. Record your current rankings and top pages first, map every old URL to its new home with a 301 redirect, carry over your titles, headings, schema and internal links, then watch Search Console closely for the first month. Done in that order, a redesign holds your rankings and usually improves them because the new site is faster.
Traffic only collapses when a rebuild throws those signals away, which is exactly what cheap redesigns do when they skip the redirect map. This guide is the full technical process we use on every migration, deep enough to follow yourself: the pre-launch audit, how to build the redirect map by hand, what to check on launch day, and the week-by-week Search Console routine that catches problems before they cost you enquiries.
- Does a Redesign Actually Affect SEO?
- Step 1: Record Everything Before You Touch the Site
- Step 2: Build a 301 Redirect Map
- Step 3: Carry Over Your On-Page Signals
- Step 4: Launch Day Checks
- Step 5: The First Four Weeks in Search Console
- Traffic Dropped After a Redesign? A Recovery Plan
- The Website Redesign SEO Checklist
- Frequently Asked Questions
Does a Redesign Actually Affect SEO?
A redesign affects SEO only when it discards the signals Google uses to rank you. Rankings do not live in your design. They live in your URLs, your content, your page titles and headings, your internal links and your backlink profile. Change the paint and keep those intact, and Google barely notices. Change the structure and lose the redirects, and the rankings go with them. That single distinction explains almost every redesign traffic story you have ever read.
The chart below shows the pattern we see again and again. A planned migration dips a little in the first fortnight while Google recrawls, then recovers and climbs because the new site is faster and better structured. A rebuild with no redirect map falls off a cliff and claws back only slowly. Same design work, opposite outcome. The difference is the process on this page. You can see how we build that process into every project on our website redesign service.
View data table
| Weeks after launch | Planned migration | No redirects |
|---|---|---|
| 0 | 100 | 100 |
| 1 | 98 | 71 |
| 2 | 97 | 57 |
| 3 | 99 | 55 |
| 4 | 103 | 61 |
| 6 | 107 | 70 |
| 8 | 112 | 79 |
Step 1: Record Everything Before You Touch the Site
Before a single page changes, you take a snapshot of what the current site earns. This baseline is what you protect, and it is the reference you check against after launch. Skip it and you are redesigning blind, with no way to prove whether the new site held its ground. The audit takes an afternoon and saves months of guesswork.
What to Capture in the Baseline
Pull each of these and save it somewhere you can compare against later. A spreadsheet is fine. The point is to have the numbers frozen before the rebuild starts.
| What to record | Where to get it | Why it matters |
|---|---|---|
| Top 50 landing pages by organic traffic | Google Search Console, GA4 | These are the pages you cannot afford to break |
| Ranking keywords and positions | Search Console, Ahrefs or SEMrush | Your before/after comparison after launch |
| Full list of indexed URLs | Screaming Frog crawl, sitemap | The master list every redirect maps from |
| Current page titles and meta descriptions | Screaming Frog export | Signals to carry across, not rewrite blindly |
| Backlink profile and most-linked pages | Ahrefs, Search Console links report | Links point at old URLs; those URLs must survive |
| Core Web Vitals baseline | PageSpeed Insights, Search Console | Proves the new site is faster, not slower |
Export a full crawl on day one. A Screaming Frog crawl of the live site gives you every URL, title and status code in one file. It becomes the backbone of your redirect map and your proof of what existed before launch.
Step 2: Build a 301 Redirect Map
The redirect map is the single most important document in a migration, and the one step that separates a safe rebuild from a traffic disaster. A 301 is a permanent redirect: it tells Google a page has moved for good and passes almost all of that page's ranking value to the new address. Every old URL that is changing needs one, pointing to its closest match on the new site. Google calls the whole thing a site move with URL changes.
How to Build the Map
Start from the crawl you exported in step one. Put every old URL in one column. Next to each, write the new URL it should point to after launch. Match like for like: the old about page goes to the new about page, not to the home page. Sending everything to the home page is the classic lazy shortcut, and Google treats those as soft 404s that pass no value.
| Old URL | New URL | Redirect type |
|---|---|---|
| /services.html | /services/ | 301 |
| /about-us.php | /about/ | 301 |
| /blog/2024/05/old-post | /blog/old-post/ | 301 |
| /products?id=44 | /shop/product-name/ | 301 |
| /contact-us.html | /contact/ | 301 |
Where hundreds of URLs share a pattern, a regular expression saves hours. A rule like /blog/\d{4}/\d{2}/(.*) mapped to /blog/$1/ redirects every dated blog URL to its clean equivalent in one line. Handle the high-traffic and most-linked pages individually, then use pattern rules for the long tail. Test the map on a staging environment before it goes anywhere near the live site.
One hop only. Redirect old URLs straight to their final destination. Chains, where A points to B which points to C, leak ranking value and slow the page. If you have redirects from a previous move, update them to point at the new final URL.
Step 3: Carry Over Your On-Page Signals
Redirects protect the address. On-page signals protect the meaning. Google reads a page through its title, its headings, its body content and its internal links, so a redesign that rewrites all of them at once throws away context the old page had earned. Keep what works and improve deliberately, rather than replacing everything by accident.
The Signals That Move the Needle
Carry your page titles and meta descriptions across, refining them rather than binning them. Keep the H1 and heading structure that matches what people search for. Migrate the body content that ranks, and resist cutting word count just because the new design looks tidier with less text. Rebuild your internal links so the new pages point at each other the way the old ones did, because internal linking is how ranking value flows around your site. Move your schema markup across too, since structured data drives rich results and is easy to forget in a rebuild.
When we rebuilt Fine Luxury Property, the site carried more than 300 premium listings, each one an indexed page with its own rankings and inbound links. We crawled every URL, mapped each listing to its new address with a 301, and kept the titles and structured data that Google already trusted. The site moved to clean, fast code and passed Core Web Vitals, and the listings held their positions through the switch rather than dropping and clawing back. The redirect map was the difference between a migration and a gamble.
Step 4: Launch Day Checks
Launch day is where careful planning either pays off or unravels in an hour. Work through a fixed checklist rather than trusting memory, because the failures here are quiet: a stray noindex tag or a blocked robots file can hide a brand-new site from Google for weeks before anyone notices the traffic gap.
Before and Just After You Go Live
Confirm the redirect map is live and every rule fires with a single 301, not a 302 or a chain. Check that the robots.txt file allows crawling and that the staging site's blanket noindex has been removed from the production pages. Make sure the canonical tags point to the new URLs. Submit the new XML sitemap in Search Console and use the URL Inspection tool on your most important pages to request indexing. Spot-check ten of your top old URLs by hand and watch them redirect to the right place.
Step 5: The First Four Weeks in Search Console
Google does not recrawl a whole site overnight, so a redesign shows its true effect over the weeks after launch, not the day of. A short monitoring routine turns that waiting period from anxiety into control, catching the two or three issues that do slip through before they cost real traffic.
A Week-by-Week Routine
In week one, watch the Page Indexing report for a spike in crawl errors or a jump in "not found" URLs, which means a redirect is missing. Check the Performance report daily against your baseline. In weeks two and three, confirm impressions and clicks are recovering toward the old numbers, and re-inspect your top pages to see they are indexed under the new URLs. By week four you should be at or above the baseline. If a specific page has not recovered, inspect it individually, confirm its redirect and its canonical, and request indexing again. Most wobbles resolve inside a month when the redirects are sound.
Traffic Dropped After a Redesign? A Recovery Plan
If traffic has already fallen after a redesign, the cause is almost always missing or broken redirects, and it is fixable. Do not panic and do not roll back. Work through the diagnosis in order, because a rushed second change on top of the first usually makes the pattern harder to read.
How to Diagnose and Recover
Start in the Search Console Page Indexing report and look for a surge in "not found" or "crawled, not indexed" URLs. Crawl the old URL list from your baseline and note every one that now returns a 404 instead of a 301. Those broken pages are your lost rankings. Build the redirect map you should have had, point each dead URL at its new match, and resubmit the sitemap. Re-inspect the highest-traffic casualties and request indexing. Recovery usually begins within a week or two of the redirects going live, though a badly handled migration can take a couple of months to fully recover. The cost of fixing it retrospectively is almost always higher than doing it right the first time, a point we cover in what a website redesign costs.
Common Migration Mistakes to Avoid
- No redirect map — the single biggest cause of lost rankings after a redesign, and the first corner cheap rebuilds cut.
- Redirecting everything to the home page — Google treats these as soft 404s that pass no ranking value.
- Leaving the staging noindex live — a single leftover tag can hide the whole new site from search for weeks.
- Redirect chains — A to B to C leaks value and slows pages; always send old URLs straight to the final address.
- Cutting content to suit the design — less text often means less of what ranked; migrate first, trim deliberately later.
- Forgetting schema and canonicals — structured data and canonical tags are easy to lose in a rebuild and quietly cost rankings.
- Not monitoring after launch — the effect shows over weeks, so no Search Console routine means problems surface as lost enquiries.
The Website Redesign SEO Checklist
Everything above condensed into a working checklist. Sort it by phase and use it as the running order for your migration.
| Phase | Task | Tool |
|---|---|---|
| Before | Record top pages, rankings and backlinks | Search Console, Ahrefs |
| Before | Crawl and export every live URL | Screaming Frog |
| Before | Baseline Core Web Vitals | PageSpeed Insights |
| Build | Draft the 301 redirect map | Spreadsheet |
| Build | Carry over titles, headings, content and schema | Crawl export |
| Build | Rebuild internal links on the new pages | CMS |
| Launch day | Deploy and test every redirect | Redirect checker |
| Launch day | Remove staging noindex, check robots.txt | Browser, Search Console |
| Launch day | Submit sitemap, request indexing on top pages | Search Console |
| After | Monitor indexing and performance for four weeks | Search Console |
8 Frequently Asked Questions
No. A redesign only hurts SEO when it discards the signals Google ranks you on: your URLs, redirects, content, titles and internal links. Handled properly, with a full redirect map and the on-page signals carried across, a redesign holds your rankings and usually improves them, because the new site is typically faster and better structured. The damage stories come from rebuilds that skip these steps, not from redesigns in general. The process, not the redesign itself, decides the outcome.
A 301 redirect map is a document listing every old URL on your site next to the new URL it should point to after launch. A 301 is a permanent redirect that tells Google a page has moved for good and passes almost all of its ranking value to the new address. It matters because rankings and backlinks are attached to specific URLs. If those URLs change without redirects, Google finds dead pages where your rankings used to be, and the traffic disappears until you fix it.
Where you can, yes. Keeping a URL exactly as it was is the safest option, because there is nothing to redirect and no ranking value to pass. Change URLs only when there is a real reason, such as fixing a messy structure or moving off a platform that forces ugly addresses. When you do change them, every old URL needs a 301 to its new match. The rule is simple: keep what you can, redirect what you must, and never change a URL without a redirect behind it.
With a clean migration, expect a small dip for one to two weeks while Google recrawls, then a return to the previous level and often a rise beyond it by week four. A migration that launched without redirects takes longer, commonly one to three months, because Google has to rediscover the site once the redirects are finally added. The stronger your redirect map and the faster your new site, the quicker the recovery. Monitoring Search Console weekly tells you exactly where you are in that curve.
Yes. Build and test on a staging site so you can check the redesign, the redirects and the on-page signals before anything goes live. The one risk to manage is indexing: staging sites are usually set to noindex or password-protected so Google does not crawl the unfinished version, and that block must be removed from the production site at launch. A leftover staging noindex is one of the most common reasons a new site vanishes from search, so it belongs at the top of your launch-day checklist.
Yes. Generate a fresh XML sitemap of the new URLs and submit it in Google Search Console on launch day. It is the quickest way to tell Google about the new structure and speeds up recrawling. Leave the old URLs out of the new sitemap, since they should be handled by your 301 redirects rather than listed as live pages. Resubmitting the sitemap does not replace the redirect map; the two work together, one telling Google what exists now and the other explaining where the old pages went.
The usual cause is that the new site changed URLs without 301 redirects, so Google lost the pages it had ranked. It is fixable. Crawl your old URL list, find every address that now returns a 404, and redirect each one to its closest match on the new site, then resubmit the sitemap and request indexing on your top pages. Recovery usually starts within a week or two of the redirects going live. Do not roll the site back, as that adds a second disruptive change on top of the first.
While it lives on a staging URL, yes, so Google never indexes the half-finished version. The critical step is removing that noindex when the site becomes the live production site. Deploy checklists should include confirming that production pages are indexable and that the robots.txt file is not blocking crawlers. Forgetting this is one of the fastest ways to lose all your traffic at once, because a noindex tag tells Google to drop the page entirely, redirects and rankings notwithstanding.
A redesign should make your site faster and win you more enquiries, not cost you the rankings you already have. Every migration we run starts with the audit and the redirect map on this page, and we monitor Search Console for weeks after launch so nothing slips. At Cambria Digital we have rebuilt 100+ UK websites without losing rankings. Book a free discovery call and we will review your current site and tell you exactly how to protect its SEO through the rebuild. For the full scope, see our website redesign service or read our guide to technical SEO.