How to Redesign Your Website and Not Lose Your SEO

A website redesign usually begins with good intentions.

The old site looks ancient.

Navigation needs improvement.

The content on the pages should be improved.

The mobile experience could be a lot better.

The technology that sits underneath it has become hard to maintain.

And so the decision is taken:

Website redesign in progress.

The new version looks better. It’s faster. And it’s a cleaner code. Content has been rewritten.

Then it goes on the air.

A few weeks later someone notices a drop in traffic from Google.

Some pages that were coming up in search are gone.

Some of the outside links now go nowhere.

Search Console starts reporting indexing issues

And the question is:

So what happened ?

Sometimes the answer is easy.

The new website was more than a change in design.

It altered the website’s relationship with Google.

A redesign can impact URLs, page content, internal links, canonical URLs, redirects, robots directives, sitemaps and even the way important content is displayed.

That doesn’t mean you shouldn’t redesign a website.

Therefore, the SEO migration should be part of the rebuild and not something to consider after deployment.

Here's how we approach it.

Before touching the new website, understand the old one

The first mistake is starting with the new design.

Start with the website you already have.

Make a list of its important URLs.

Not just the homepage.

Look at:

• Service pages

• Product pages

• Blog posts

• Case studies

• Landing pages

• Important category pages

• Pages receiving organic traffic

• Pages with external links

If the website is small, this can be done manually.

For a larger website, use a crawler or export the URLs from your CMS, sitemap and Search Console data.

You want to know what currently exists before deciding what the new website should look like.

This is your baseline.

Without it, you are redesigning the site with incomplete information.

Don't assume every old page needs to survive

This is where things get interesting.

A redesign doesn't mean every old URL has to be copied into the new website.

Some pages may be obsolete.

Some may contain outdated information.

Some may overlap with other pages.

Some may never have been useful in the first place.

Suppose an old website has:

/services/web-design
/services/web-development
/services/website-development

and all three pages essentially say the same thing.

Creating three identical pages again isn't necessarily a good migration strategy.

You might decide that the new website should have one stronger page:

/services/web-development

That's reasonable.

But now you have to account for the old URLs.

They don't simply disappear.

If an old page has been replaced by a new, relevant page, a permanent redirect can tell browsers and search engines where the content moved.

Google recommends server-side permanent redirects such as 301 or 308 when moving URLs.

This is why the URL list should be created before launch, not after.

Build a URL map

This is one of the most useful things you can do during a migration.

Create a simple spreadsheet.

Something like:

Now every old URL has a deliberate outcome.

You don't have to use exactly those status codes in every situation, but the important thing is that you decide what happens to each URL.

This simple document can prevent a surprising number of migration problems.

Don't redirect everything to the homepage

This deserves its own section because it is a common shortcut.

A website has 200 old URLs.

The new website has 80.

Someone creates one rule:

If the old page doesn't exist, send the visitor to the homepage.

It sounds convenient.

It isn't a good migration strategy.

Imagine someone clicks an old link to:

example.com/services/mobile-app-development

and ends up at:

example.com/

They now have to figure out where the information went.

Google also warns against redirecting large numbers of unrelated old URLs to a single destination such as the homepage. Such redirects can confuse users and may be treated as soft 404s.

Redirect an old URL to its relevant replacement.

If there isn't one, don't invent one just to avoid a 404.

Sometimes a page really is gone.

Test the new website before Google sees it

The new website should be tested before the switch.

Not just visually.

Don't stop at:

"The homepage looks good."

Check the actual URLs.

Open important pages.

Test forms.

Test navigation.

Check mobile.

Check page titles.

Check canonical tags.

Check internal links.

Check images.

Check status codes.

Check the sitemap.

Check robots.txt.

And especially check whether the staging environment is deliberately preventing search engines from crawling or indexing it.

That restriction can make sense while the website is being developed.

The problem is forgetting about it when the site goes live.

Google's current site-migration guidance specifically calls out temporary noindex and robots.txt blocks as things that need to be removed when the new site launches.

Keep an eye on canonical URLs

This is another easy one to miss.

Suppose the new page is:

https://example.com/services/web-development

Its canonical URL should not accidentally point back to:

https://old.example.com/services/web-development

or to some other variation.

During a migration, canonical tags need to reflect the new URL structure.

Google's migration guidance explicitly recommends checking canonical annotations after redirects are in place and ensuring they point to the new URLs.

This is the sort of thing that can be invisible to a normal visitor.

The page looks fine.

The menu works.

The design is excellent.

But the underlying signals are still pointing at the old website.

Update your internal links

A redirect can save an old URL.

It shouldn't become the permanent navigation system for your new website.

If the new website has changed:

/old-service

to:

/services/web-development

update your internal links.

Don't leave this:

Homepage
   ↓
/old-service
   ↓
301
   ↓
/services/web-development

when you can simply have:

Homepage
   ↓
/services/web-development

Google recommends updating internal links during a migration so they point directly to the new URLs.

It is cleaner for users, cleaner for crawlers and removes unnecessary hops.

Generate the new sitemap

Once the new website is ready, generate its sitemap from the new URL structure.

Don't carry the old sitemap into the new website unchanged.

If your old site had:

/services/web-design

and the new site has:

/services/web-development

the new sitemap should reflect the new URL.

Google's migration guidance specifically recommends updating sitemaps with the new URLs.

Then submit the new sitemap through Search Console.

Check robots.txt one more time

Do this immediately before launch.

Then do it again immediately after launch.

It sounds excessive.

It isn't.

A staging environment may have:

User-agent: *
Disallow: /

because you don't want search engines crawling the unfinished website.

That's fine.

Leaving it there after launch is a completely different situation.

Also remember that robots.txt controls crawling; it isn't the general mechanism for removing a page from Google's index.

If a page should not appear in search, the appropriate approach depends on why you don't want it indexed.

Launch the new website

Now comes the actual switch.

If the domain stays the same and only the website changes, you generally don't need to treat it as a domain move.

But if URLs changed, the redirects need to be active at the same time the new URLs become available.

For a domain change, the process is broader: Google's current guidance covers the migration of the old and new properties, URL mapping, redirects, sitemaps and monitoring. Google also updated its site-move documentation in June 2026 to clarify handling of domain variants such as www and non-www.

The exact migration depends on what you're changing.

A hosting change with identical URLs is different from:

• Changing the URL structure

• Changing the domain

• Moving from HTTP to HTTPS

• Combining two websites

• Reorganising hundreds of pages

Don't treat all migrations as the same job.

Then watch Search Console

This is where the work continues.

Don't launch the website and disappear.

Open Search Console.

Check:

Page indexing

Are new pages being indexed?

Are unexpected pages dropping out?

Are there new errors?

Then check:

Sitemaps

Was the sitemap processed?

Are the expected URLs being discovered?

Then check:

Performance

Are clicks and impressions behaving as expected?

Don't panic if everything doesn't immediately look identical to the old site.

Google has to crawl and process the changes.

Google's documentation notes that significant site changes can cause temporary ranking fluctuations while Google recrawls and reindexes the site. For medium-sized sites, this can take weeks or longer; larger sites can take longer still.

The important thing is to distinguish normal migration changes from actual implementation problems.

Watch the old URLs too

This is particularly important.

You don't only want to know whether the new pages work.

You want to know what happens when someone visits the old ones.

Take a sample of important old URLs.

Open them.

They should either:

• redirect to the correct new page, or

• return an intentional response because the content really no longer exists.

Don't just test five random URLs.

Test the pages that mattered.

Pages with traffic.

Pages with backlinks.

Pages that ranked.

Pages people may have bookmarked.

Pages linked from other websites.

Those are the URLs worth protecting.

Don't make five major changes at once

There is another practical lesson here.

If you're redesigning a website, changing its content, changing every URL, changing its domain, changing its CMS and changing its hosting at the same time, troubleshooting becomes much harder.

If traffic changes afterwards, what caused it?

The new content?

The new URLs?

A missing redirect?

The domain migration?

A technical problem?

A rendering problem?

Sometimes all of them are involved.

Where possible, reduce unnecessary variables.

For larger sites, Google even recommends considering a staged migration so that you can observe the effect of moving one section before moving everything.

For a small or medium website, a complete migration can still be perfectly reasonable.

The point is to plan it, not to make the process complicated for its own sake.

The migration checklist

Before replacing an existing website, I would want these boxes checked.

Before development is finished

• Export or identify important existing URLs
• Identify pages receiving organic traffic
• Identify important external links
• Decide which pages will remain
• Decide which pages will be consolidated
• Create the old-to-new URL map
• Decide which old URLs need redirects

Before launch

• Test the new website
• Test important URLs
• Check page titles
• Check canonical URLs
• Check internal links
• Check robots.txt
• Check noindex directives
• Generate the new sitemap
• Test forms and important interactions
• Test mobile
• Test redirects
• Verify analytics and Search Console
• Check the production environment isn't accidentally blocked

Immediately after launch

• Test old URLs
• Test new URLs
• Verify redirects
• Submit/update the sitemap
• Inspect important new URLs in Search Console
• Check indexing reports
• Look for crawl errors
• Monitor organic traffic and impressions
• Check server and application logs

Over the following weeks

• Monitor old URLs
• Monitor new URLs
• Watch Search Console
• Investigate unexpected indexing changes
• Fix broken redirects
• Update internal links that were missed
• Keep the old-to-new URL mapping for future reference

A redesign should improve the website, not make Google rediscover the business

A new design is the visible part of a website rebuild.

The invisible part is everything that already exists around that website.

Search engines have discovered URLs.

Other websites may link to them.

Customers may have bookmarked them.

People may have shared them.

Google may have indexed them.

Your analytics may have years of data attached to them.

When you rebuild the website, you're not starting with a blank canvas.

You're replacing a system that already has history.

Treat that history as something worth carrying forward.

The goal isn't to preserve every old page forever.

The goal is to make deliberate decisions about what happens to what you've already built.

A good redesign should leave you with a better website.

A well-planned migration should also make sure that the work the old website had already accumulated isn't thrown away by accident.

That part doesn't show up in the design mockups.

It shows up a few weeks after launch.

And by then, it may be too late to realise what was missed.