Website redesigns are one of the most reliable ways to tank a site that was performing well.<\/p>\n
Not because redesigns are inherently bad – they’re often necessary. But because the teams running them almost always treat SEO as something to deal with after the fact. Design first, dev sprint, launch, then someone notices the traffic dropped 60% and suddenly there’s a fire.<\/p>\n
I’ve seen this go wrong in every direction. A client launches a new site on a Monday, and by Wednesday they’re watching rankings fall off in real time. Years of equity, gone – because nobody thought to map the old URLs before the dev team nuked them.<\/p>\n
The good news is that if you know what you’re doing ahead of time, a redesign can actually improve your SEO. Better site architecture, faster pages, cleaner code – these are wins you can walk away with if you protect what you already have.<\/p>\n
Here’s exactly how to do it.<\/p>\n
You cannot protect what you haven’t documented.<\/p>\n
Before a single wireframe gets sketched, before anyone talks about fonts or color palettes, you need a complete picture of what your current site looks like from a search perspective.<\/p>\n
That means crawling your site and pulling together:<\/p>\n
This data is your baseline. After launch, it’s what tells you whether things improved, stayed the same, or went sideways.<\/p>\n
Tools like Screaming Frog, Ahrefs, or Semrush will get you a complete URL inventory and backlink profile. Google Search Console gives you the traffic and rankings picture. Run all of this before anyone touches anything.<\/p>\n
The pages that matter most for protecting during a redesign are:<\/p>\n
These are your anchors. Don’t let them get touched without a plan.<\/p>\n
If there’s one thing that separates a clean redesign from a disaster, it’s this.<\/p>\n
Every time you change a URL – and in most redesigns, you will – you need to tell Google where the old page went. You do that with a 301 redirect. A 301 is a permanent redirect that passes the ranking signals from the old URL to the new one. It’s not perfect (there’s some signal loss), but it’s as close as you’ll get.<\/p>\n
What kills sites is launching with broken URLs and no redirects in place. Google hits a 404, loses the ability to crawl your content, and the link equity sitting on those pages evaporates.<\/p>\n
Here’s the process:<\/p>\n
If you can keep URLs the same, do it. The best redirect is no redirect at all. Every time a URL changes, you’re introducing unnecessary risk. Only change a URL when there’s a real reason to – cleaner structure, removing dates from blog posts, consolidating thin pages into a better resource.<\/p>\n
One more thing: don’t redirect all deleted pages to the homepage. That’s a lazy fix and Google knows it. It reads as a soft 404 and you’ll still lose the signals. If a page is being deleted and you can’t find a logical equivalent, that’s a sign you might want to reconsider deleting it.<\/p>\n
This one comes up constantly.<\/p>\n
A designer or brand team decides the site needs to feel more minimal. Big hero images, short punchy headlines, less text. It looks great in a mockup. Then it launches and the page that was ranking #2 for a commercial keyword is now a 200-word design showcase with no semantic depth.<\/p>\n
Google still reads content. The amount and quality of text on a page matters for ranking, especially in competitive niches. If a page was performing well at 1,200 words, replacing it with 150 words and a full-screen video is almost certainly going to hurt it.<\/p>\n
The right approach is to find a middle ground. You can make a page look clean and modern while preserving the content depth that earned the ranking. Move long content below the fold if you need to. Use accordions or tabs. Put detailed copy in a section that doesn’t dominate the visual design. But don’t delete it.<\/p>\n
More specifically, protect:<\/p>\n
If a page was doing its job in search, your job is to make it better – not redesign it into something that looks great and ranks for nothing.<\/p>\n
How your site is structured – what links to what, how many clicks it takes to get from the homepage to any important page – directly affects how Google values those pages.<\/p>\n
When you redesign, there’s often pressure to create a deeper hierarchy. More categories, more nesting, cleaner organization. That can make sense from a UX standpoint. But from a search standpoint, burying your most important pages five clicks deep signals to Google that they’re less important than they were when they lived two clicks from the homepage.<\/p>\n
The general rule: important pages should be close to the root. Service pages, key landing pages, high-priority blog content – these should be reachable in three clicks or fewer from the homepage.<\/p>\n
When you’re building out the new navigation and URL structure, think about what signals you’re sending. A page at \/services\/commercial-roofing\/ is treated differently than a page at \/services\/commercial\/specialty\/exterior\/roofing\/. Same content, different implied importance.<\/p>\n
Internal links also carry weight here. If you have high-authority blog content, make sure it’s linking to your relevant service or product pages. A well-ranked informational post is an asset you can use to funnel authority toward conversion pages. This is especially relevant if you’re working on how to find SEO keywords for a website<\/a> and matching content to the right pages in your new structure.<\/p>\n Google uses mobile-first indexing. That means when Google crawls and evaluates your site, it’s primarily looking at the mobile version. If your mobile experience is slow, broken, or missing content that lives on desktop, that’s what gets indexed and ranked.<\/p>\n For a redesign, mobile is not a nice-to-have. Test your staging environment on actual mobile devices – not just a browser emulation – before launch. Pay attention to:<\/p>\n Google’s PageSpeed Insights<\/a> and Core Web Vitals data in Search Console will give you a clear read on where you stand. The three metrics that matter for CWV are Largest Contentful Paint (how fast the main content loads), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). A redesign often introduces CLS issues specifically – new fonts loading late, images without explicit dimensions, dynamic elements pushing content around.<\/p>\n Page speed was already a ranking signal before Core Web Vitals. Now it’s a formal one. If your redesigned site is slower than the old one, that’s a problem worth solving before launch, not after.<\/p>\n There are several technical issues that are easy to miss in a redesign and easy to catch if you’re looking. Make sure your dev team is aware of all of these before launch:<\/p>\n Staging environment blocking. Your staging site should have a robots.txt file that blocks search engine crawlers, or be set to noindex. The last thing you want is Google indexing your in-progress staging site. Equally important: make sure those blocks are removed when you push to production. It sounds obvious. It still happens.<\/p>\n XML sitemap. Update your sitemap the moment the new site goes live and submit it through Google Search Console. Many CMS platforms handle this automatically, but verify it. The sitemap should only include 200-status live pages – no redirects, no 404s. This is how you tell Google exactly what to crawl on the new site.<\/p>\n Canonical tags. If your redesign changes URL structure or consolidates pages, make sure canonicals are set correctly. Canonical issues are easy to introduce and can cause duplicate content problems that take months to sort out.<\/p>\n Schema markup. If the old site had structured data – local business info, reviews, product data, FAQ schema – make sure it carries over. Schema doesn’t directly cause rankings to appear or disappear overnight, but losing it means losing eligibility for rich results and some of the clarity signals Google uses to understand your content.<\/p>\n JavaScript rendering. If the new site relies heavily on JavaScript to render content, test how Google sees it. Pages that look great in a browser but serve near-empty HTML to crawlers are a real issue. Google can render JavaScript, but it does so on a delayed crawl pass, and it doesn’t always do it perfectly. Use Google Search Console’s URL Inspection tool to see what Googlebot actually sees on key pages post-launch.<\/p>\n The work doesn’t stop when the new site goes live. The first 2-4 weeks post-launch are critical.<\/p>\n Open Google Search Console on day one. You’re looking at:<\/p>\n Coverage \/ Indexing report – Are the right pages getting indexed? Are there a spike in 404 errors or redirect issues? Any pages that were indexed on the old site but are suddenly missing?<\/p>\n Core Web Vitals – Did the new design introduce performance regressions? This data can take a week or two to populate, but check it.<\/p>\n Search performance – Track your target keywords daily in the first weeks. Some movement is normal. A 10-20% drop right after launch is generally expected as Google re-crawls and processes the changes. That’s different from a 50%+ drop that doesn’t recover.<\/p>\n Crawl errors – Any surge in 5xx server errors or 404s that weren’t in your redirect map means something fell through. Fix those immediately.<\/p>\n If you’re doing SEO growth forecasting<\/a>, a redesign is one of the variables that should be accounted for in your models. Expect a dip window of 4-8 weeks, followed by recovery and improvement if the migration was clean.<\/p>\n Even a perfect migration will show some traffic volatility. Google needs to re-crawl your site, process the redirects, re-evaluate the new content and structure. This takes time. For a medium-sized site, Google’s own documentation suggests this process can take several weeks.<\/p>\n A 10-15% dip in the first two to four weeks is normal. Traffic should start recovering around week four to six as Google works through the new structure.<\/p>\n Red flags that indicate something went wrong:<\/p>\n If you see any of these, go back to the redirect map first. That’s almost always where the problem is. The second most common culprit is content that got stripped or significantly changed on a page that was performing.<\/p>\n A few patterns I keep seeing:<\/p>\n Deleting blog content because it “doesn’t fit the new brand.” If those posts have backlinks, traffic, or rankings, deleting them is destroying organic assets. Refresh the content if it needs updating. Redirect if you truly can’t keep the URL. Never just delete a page with equity without a plan.<\/p>\n Letting design decisions override SEO fundamentals. Full-width hero images with no text above the fold, short punchy copy replacing the content that earned the ranking, navigation that buries important pages. Design and SEO aren’t opposites – but when they conflict, you need someone in the room advocating for the SEO side.<\/p>\n Not updating internal links after URL changes. You built a redirect map, great. But every internal link on the site that still points to the old URL is creating a redirect chain. Update the links themselves to point to the new URLs directly. Redirect chains add latency and dilute link signals.<\/p>\n Launching before testing. Run a full crawl of the staging environment before it goes live. Use Screaming Frog or a similar tool to simulate what Googlebot will see. Catch the 404s, the missing title tags, the broken internal links before the world sees it.<\/p>\n Treating SEO as a post-launch review. This is the root cause of almost every redesign disaster. SEO needs to be at the table from the first planning meeting – when the URL structure is being debated, when the navigation is being designed, when decisions are being made about what content to keep or cut. Retrofitting SEO onto a finished site is expensive and sometimes impossible.<\/p>\n For businesses with multiple locations or service areas, this is especially high stakes. A URL restructure for local landing pages without a redirect map can wipe out years of local SEO equity overnight. If that’s your situation, take a look at how local SEO for multi-location businesses<\/a> works before restructuring anything.<\/p>\n Before launch:<\/p>\nMobile performance is non-negotiable<\/h2>\n
\n
Technical checklist for developers<\/h2>\n
What to watch immediately after launch<\/h2>\n
Some traffic loss is normal – here’s how to tell if you have a real problem<\/h2>\n
\n
Common mistakes that blow up redesigns<\/h2>\n
Quick reference checklist<\/h2>\n