Skip to content
Technical SEOHow-to guide

How to Redesign a Website Without Losing SEO (8 Steps)

To redesign a website without losing SEO, write search requirements into the design brief, list the pages that earn traffic and enquiries, keep their URLs, copy and internal links unless there is a reason to change them, test everything on staging and compare the first weeks after launch with a baseline.

By Kristijan GjorgjioskiIndependent SEO consultant

Published 18 October 2026 · 7 min read

Key takeaways

  • Redesigns rarely lose rankings because of the new look; losses come from changed URLs, cut copy, weaker internal links and staging settings that reach the live site.
  • The cheapest moment to protect SEO is the design brief, before the sitemap and wireframes are signed off.
  • Keeping a URL unchanged is the safest redirect there is, so change addresses only when there is a clear reason.
  • Google recommends server-side permanent redirects, kept for at least a year, and says to expect temporary ranking fluctuation during a move.
  • Judge the new site against a baseline of rankings, traffic and enquiries per page, not against how it looks.

Most redesigns that lose traffic look better than the site they replaced.

The design team did its job. But somewhere before launch, URLs changed, service pages shrank to three lines and the staging noindex tag went live.

Nobody owned any of it.

Here's how to redesign a website without losing SEO in eight steps, written for whoever runs the project.

What a Redesign Changes (and What Google Notices)

Not every change carries the same risk. Here's how I rate the common ones:

What changes What Google notices Risk
Colours, fonts, imagery Very little, if the HTML and copy stay Low
Page templates and layout Headings, copy placement, rendered content Medium
Copy rewritten or shortened Relevance signals on every affected page High
Navigation and footer Internal links and how authority flows High
URL structure Every changed address needs a redirect High
Platform (CMS) URLs, rendering, structured data, speed Very high

The more rows your project touches, the more of this guide applies.

If you're changing platform or domain as well, treat it as a full migration and use my website migration SEO checklist alongside these steps.

Step 1: Put SEO Requirements in the Design Brief

The brief is the cheapest place to protect your rankings.

Changing a requirement now costs you an email. Changing it after the build costs you a sprint.

Add a short SEO section to the brief with these requirements:

  • Existing URLs are kept unless a change is approved and mapped.
  • Copy on top pages carries over unless there's a written reason to cut it.
  • Main content and links must be in the HTML, not loaded only after a click.
  • Analytics and enquiry tracking must work on staging before launch.
  • Staging stays blocked from search engines, with a named person to unblock it.

Then name one person who owns SEO on the project.

Agencies are good at what they're asked to do. If nobody asks about rankings, nobody checks them.

Step 2: List the Pages You Can't Afford to Lose

Before anyone touches a wireframe, find out where your organic value actually sits.

Pull the last 12 months from three sources:

  • Search Console: clicks and impressions per page
  • GA4: organic landing pages and the key events they produce
  • A backlink tool: pages with links from other sites

Combine them into one sheet and sort by value.

The top of that list is your protected pages list. It's usually shorter than people expect: often a few dozen URLs carry most of the traffic and leads.

Save this sheet with today's date. It's also your baseline for judging the new site after launch.

Pro tip: Include pages with backlinks but little traffic. They pass authority to the rest of the site, and they're the ones most often deleted for "looking unused".

Step 3: Keep URLs Unless You Have a Reason to Change Them

The safest redirect is the one you never need.

If a page is carrying over to the new site, keep its address. Push back on URL changes made for tidiness alone, like dropping a folder name or switching to a new slug style.

Good reasons to change a URL do exist:

  • The current structure no longer reflects what you sell
  • URLs contain dates, IDs or session parameters
  • Several thin pages are being merged into one

Every URL that does change needs a permanent redirect to its closest new equivalent. Google's site move guide recommends server-side permanent redirects such as 301 or 308, pointing straight at the final destination, kept for at least a year.

My guide on how to create a redirect map walks through building that sheet.

Navigation is where designers simplify and rankings quietly suffer.

A slimmer menu looks cleaner.

But if your service pages lose their place in the main navigation, they lose the internal links that every page on the site was sending them.

Before wireframes are signed off, check three things:

  1. Every protected page is linked from the menu, a hub page or the footer, not only from the sitemap.
  2. Menu links are real links. Google's JavaScript SEO basics say it can only discover links in a elements with an href attribute. Menus that open pages through script alone can hide whole sections.
  3. Click depth stays shallow. If a page moves from two clicks to five, it'll usually get less attention from crawlers and visitors.

In-content links matter too. Old blog posts often link to your service pages; make sure those links survive the content move. My internal linking strategy covers how to plan them at scale.

Step 5: Carry the Content Over, Not Just the Look

This is the step that loses the most traffic in the redesigns I'm asked to fix.

Designers work with placeholder copy. Then your real copy gets squeezed to fit a layout built around 40 words per section.

A service page that used to answer pricing, process and timescales now says "Quality work, delivered on time."

Rankings follow the copy down.

For every protected page, compare old and new side by side:

  • Title tag and meta description: carried over or deliberately improved
  • H1 and main headings: same topics covered
  • Body copy: the sections that answered searchers' questions are still there
  • FAQs, reviews and proof: not dropped to save space
  • Structured data: still output by the new templates

Text inside tabs and accordions is usually fine, as long as it's in the HTML when the page loads. Text fetched only after someone clicks is the risk.

If copy does change, you should be able to say why, page by page.

Step 6: Review the Templates on Staging

Check each template type on staging as it's built, not in launch week.

Fixes you find during the build land in a normal sprint. Fixes you find the day before launch get rushed or skipped.

For one example of each template, check:

  • Rendered HTML contains the main content, headings and links
  • Canonical tags point at the live domain, not the staging hostname
  • Mobile layout shows the same content as desktop
  • Speed in a lab test, with no lazy-loaded hero image and no layout jumping
  • Tracking records a test enquiry as a key event

Lab speed tests on staging are only a guide, but they catch the worst problems before real visitors do. My guide on improving Core Web Vitals covers what to look for. For the tracking side, my GA4 audit checklist lists the tests.

Keep staging password-protected throughout. A public staging site can get indexed and compete with your live one.

Step 7: Launch With Checks and a Rollback Plan

Launch day needs a short, written plan with names next to each task.

Within hours of go-live, check on the live site:

  1. No staging blocks remain: no noindex tags, no robots.txt disallow rule, no password.
  2. Redirects work on production: test your top protected pages, not just a random sample.
  3. Canonicals point at live URLs on every template.
  4. The new XML sitemap is submitted in Search Console.
  5. A real test enquiry reaches your inbox and your analytics.

Agree a rollback trigger before launch day. For example: "If the protected pages return errors or carry noindex tags and can't be fixed within a few hours, revert." Deciding this in advance stops a debate while traffic drains away.

Step 8: Watch the First Weeks Against Your Baseline

Some movement after a redesign is normal.

Google's site move guide says to expect temporary ranking fluctuation, and that it can take a few weeks or more for a medium-sized site's new URLs to settle.

So don't judge the new site on day two. Judge it against the baseline from Step 2.

Check daily for the first fortnight, then weekly:

  • New 404 errors in Search Console and server logs, which usually mean a missing redirect
  • Protected pages: clicks and positions compared with the baseline
  • Enquiries per landing page, because a new layout can cut conversions while rankings hold

When a protected page drops, compare its old and new versions. The cause is almost always a missing redirect, cut content or lost internal links.

I worked through exactly this on a rebuild onto entirely new URLs, where the post-launch comparison set the order of the follow-up work.

Common Redesign Mistakes That Cost Rankings

These come up again and again:

  • Bringing SEO in during launch week, when URLs and templates are already fixed
  • Redirecting everything to the homepage. Google's site move guide warns against sending many old URLs to one irrelevant page
  • Building redirects from the new sitemap, which misses old URLs with links but no menu entry
  • Deleting "unused" pages that hold backlinks
  • Launching on a Friday with nobody watching over the weekend
  • Forgetting tracking, so nobody can tell whether enquiries dropped
  • Removing redirects a few months later to tidy the server

Make SEO Part of the Redesign From Day One

The best time to start is before the first wireframe. Pull your protected pages list this week, whatever stage your project is at, and add the SEO requirements from Step 1 to the brief.

A redesign is also your chance to fix what the old site got wrong.

You can merge pages that compete for the same query, prune dead content and restructure navigation on purpose. If you want the full picture before the build, an SEO audit feeds straight into the plan, and my explainer on what technical SEO covers is a good primer.

If you'd like help keeping rankings through a relaunch, my SEO migration support covers the URL plan, staging review, launch checks and monitoring. Send me your launch date and what's changing, and you'll get an honest view of where the redesign risk sits before the build goes much further.

Frequently asked questions

Will a website redesign affect my SEO?

Almost always, a little. Google has to recrawl the new templates, and any change to URLs, copy, headings or internal links changes the signals it sees. A redesign that keeps URLs and content and only changes the visual layer usually causes small, short movement. Lasting losses tend to come from missing redirects, shortened pages or blocked indexing, which are all preventable.

How long does it take to recover rankings after a redesign?

If nothing went wrong, most sites settle within a few weeks as Google recrawls the new templates. Google's site move documentation says it can take a few weeks or more for new URLs to replace old ones on a medium-sized site, and longer on large ones. If rankings are still down after that, look for a cause rather than waiting longer.

Should I change my URLs during a redesign?

Only when you have a good reason, such as a structure that no longer makes sense, URLs stuffed with dates or IDs, or pages being merged. Every changed URL needs a redirect, and every redirect is a small risk. If the current URLs are readable and logical, keeping them is the safest choice even if the new design changes everything else.

Is it better to redesign or replatform at the same time?

Doing both at once is common, but it multiplies the risk, because a new platform often forces new URL formats and renders pages differently. If you must do both, plan it as a full migration with a complete redirect map and rendered-output checks. If you can separate them, change the platform first with the old design, let it settle, then redesign.

About the author

Kristijan Gjorgjioski

Independent SEO consultant · 6+ years in SEO · 60+ client websites worked on

I'm an independent SEO consultant with 6+ years in SEO. I run audits, migrations and content programmes for businesses in Europe, the UK and the USA, and I build the automation behind my own research.

Need help with seo migrations?

Book a free 30-minute call. I look at your site first and tell you plainly what I would fix, and in what order.