Website redesigns are one of the most reliable ways to tank a site that was performing well.

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.

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.

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.

Here’s exactly how to do it.

Start with a full audit before anything changes

You cannot protect what you haven’t documented.

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.

That means crawling your site and pulling together:

  • Every URL currently on the site
  • Which pages are driving organic traffic (pull this from Google Search Console or GA4)
  • Which pages have external backlinks pointing to them
  • Your current keyword rankings for target terms
  • Core Web Vitals scores and page speed data
  • Any existing technical issues (broken links, duplicate content, crawl errors)

This data is your baseline. After launch, it’s what tells you whether things improved, stayed the same, or went sideways.

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.

The pages that matter most for protecting during a redesign are:

  • High-traffic pages (the ones sending actual visitors)
  • High-converting pages (service pages, landing pages, whatever drives leads)
  • Pages with strong backlinks (especially from authoritative domains)

These are your anchors. Don’t let them get touched without a plan.

Build your redirect map before dev touches a single URL

If there’s one thing that separates a clean redesign from a disaster, it’s this.

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.

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.

Here’s the process:

  1. Pull your full URL list from the crawl you ran in the audit
  2. Document every URL on the new site architecture
  3. Map each old URL to its best corresponding new URL
  4. For deleted pages with no clear equivalent, redirect to the closest parent or category page – homepage as a last resort only

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.

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.

Don’t gut high-performing content in the name of a “cleaner” look

This one comes up constantly.

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.

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.

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.

More specifically, protect:

  • H1 tags – every page needs one, with the target keyword
  • Title tags and meta descriptions – if they were working, don’t rewrite them unless you have a clear reason
  • Body copy on pages that are already ranking
  • Alt text on images
  • Structured data (schema markup) if you had it on the old site

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.

Keep your site architecture as flat and logical as possible

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.

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.

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.

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.

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 and matching content to the right pages in your new structure.

Mobile performance is non-negotiable

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.

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:

  • Page load speed on a mobile connection (3G/4G, not just WiFi)
  • Whether content is the same on mobile and desktop (don’t hide important copy on mobile)
  • Touch targets are appropriately sized
  • Text is readable without zooming
  • Images are compressed and properly served

Google’s PageSpeed Insights 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.

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.

Technical checklist for developers

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:

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.

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.

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.

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.

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.

What to watch immediately after launch

The work doesn’t stop when the new site goes live. The first 2-4 weeks post-launch are critical.

Open Google Search Console on day one. You’re looking at:

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?

Core Web Vitals – Did the new design introduce performance regressions? This data can take a week or two to populate, but check it.

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.

Crawl errors – Any surge in 5xx server errors or 404s that weren’t in your redirect map means something fell through. Fix those immediately.

If you’re doing SEO growth forecasting, 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.

Some traffic loss is normal – here’s how to tell if you have a real problem

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.

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.

Red flags that indicate something went wrong:

  • Traffic drops 40-50%+ and doesn’t start recovering after four weeks
  • Rankings for high-priority keywords drop sharply and stay down
  • Google Search Console shows a major spike in 404 errors
  • Indexed page count drops significantly (check Coverage report)
  • The pages you flagged as high-priority are suddenly not ranking at all

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.

Common mistakes that blow up redesigns

A few patterns I keep seeing:

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.

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.

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.

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.

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.

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 works before restructuring anything.

Quick reference checklist

Before launch:

  • Full site crawl – document every URL
  • Identify high-traffic, high-converting, and high-backlink pages
  • Build redirect map for every URL that’s changing
  • Audit target keyword rankings as baseline
  • Verify staging site is blocked from crawlers
  • Test on mobile devices – not just browser emulation
  • Check Core Web Vitals on staging
  • Confirm schema markup carries over
  • Update all internal links to new URLs
  • Test JavaScript rendering on key pages

At launch:

  • Confirm staging crawler block is removed
  • Submit updated XML sitemap to Google Search Console
  • Verify redirects are firing correctly
  • Run crawl on live site to catch any missed 404s

Post-launch (first 30 days):

  • Monitor Google Search Console daily for indexing errors and 404 spikes
  • Track keyword rankings for priority terms
  • Check Core Web Vitals data as it populates
  • Monitor organic traffic in GA4 – flag anything beyond normal post-launch volatility
  • Fix redirect gaps or missing content as they surface

A redesign done right should improve your SEO, not destroy it. The sites that come out better on the other side are the ones where SEO was baked in from the start – not bolted on after the fact.

If you’re planning a redesign and want a team that’s done this without dropping the ball, LYNX handles migrations as part of our core work. We’ve seen what goes wrong and we know how to prevent it.