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.
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.
Step 4: Plan Navigation and Internal Links Before Wireframes Freeze
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:
Every protected page is linked from the menu, a hub page or the footer, not only from the sitemap.
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.
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:
No staging blocks remain: no noindex tags, no robots.txt disallow rule, no password.
Redirects work on production: test your top protected pages, not just a random sample.
Canonicals point at live URLs on every template.
The new XML sitemap is submitted in Search Console.
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.
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.
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.