Website Redesign & Migration SEO: How to Protect Your Rankings

Launching a redesigned website should improve the business.

It should not wipe out years of organic visibility in the process.

Unfortunately, website redesigns are one of the easiest ways to accidentally damage SEO.

Pages get renamed. URLs change. Old content disappears. Internal links are rebuilt. Redirects are forgotten. Staging settings make their way onto the live website.

The new website can look considerably better while Google suddenly struggles to understand where everything went.

This is why website migration SEO needs to be considered before development is finished, not added as a final task the evening before launch.

A well-managed redesign should preserve as much existing search value as possible while giving the new website better foundations for future growth.

What is website migration SEO?

Website migration SEO is the process of protecting organic search visibility when a website undergoes a significant technical or structural change.

That can include:

• redesigning the website;
• changing URLs;
• moving to a different CMS;
• changing domain name;
• moving from HTTP to HTTPS;
• merging websites;
• changing website structure;
• moving to a different eCommerce platform;
• changing hosting infrastructure; or
• removing and consolidating large amounts of content.

Not every redesign is a major migration.

If the website keeps exactly the same URLs, content and domain while only the visual design changes, the SEO risk is considerably lower.

The risk increases as more fundamental parts of the site change.

Can redesigning a website hurt SEO?

Yes, if the migration is handled poorly.

A redesign does not inherently damage SEO.

The problems usually come from the changes made around it.

For example, imagine a service page currently ranks well at:

/commercial-coffee-machine-rental/

The new website launches and the developer replaces it with:

/services/coffee-machines/

If the old URL simply disappears, Google and anyone following an existing link will reach a 404 page.

Google now has to discover the replacement page and work out whether it represents the same content.

A properly implemented permanent redirect makes that relationship explicit.

Should URLs change during a website redesign?

Only when there is a good reason.

We would not change a strong existing URL simply because a different version looks tidier.

If a page already ranks, has backlinks and receives traffic, changing the URL introduces unnecessary migration work.

Sometimes URL changes are justified.

For example:

• the existing structure is confusing;
• URLs contain old product names;
• several pages are being consolidated;
• the website has moved to a genuinely better structure;
• the current URLs contain technical parameters;
• the site is changing domain; or
• the current URL no longer reflects the page.

But changing every URL because a new website is launching is rarely necessary.

Start by understanding what the existing website already has

Before rebuilding anything, we want a clear picture of the current website.

That means identifying what already performs.

Useful information includes:

• all existing indexable URLs;
• pages receiving organic traffic;
• pages generating enquiries or sales;
• keywords currently ranking;
• pages with external backlinks;
• important internal links;
• existing metadata;
• current canonical tags;
• images attracting search traffic;
• existing structured data; and
• historically important pages.

This becomes the benchmark for the migration.

Without it, there is no reliable way to know what needs protecting.

Crawl the old website before changing it

A full crawl of the current website is one of the most useful steps in any migration.

It gives you a record of:

• URLs;
• status codes;
• titles;
• meta descriptions;
• headings;
• canonical URLs;
• internal links;
• redirects;
• images;
• indexability;
• structured data; and
• other technical information.

Once the new website is ready, the two crawls can be compared.

This makes it much easier to spot missing pages, changed titles, broken links or URLs that have disappeared unexpectedly.

Use Google Search Console before the migration

Search Console provides useful information that a simple website crawl cannot.

Before launch, we would look at:

• pages receiving organic clicks;
• pages receiving impressions;
• important search queries;
• indexed pages;
• existing sitemap information;
• external links;
• crawl and indexing issues; and
• Core Web Vitals where relevant.

This can reveal pages that may not look important during a redesign but are actually attracting search visibility.

Deleting one of those without understanding its value can create an avoidable loss.

Do not assume old content is worthless because it looks dated

This is a common redesign mistake.

An old page may look visually poor and still rank extremely well.

The redesign process sometimes treats everything on the current website as something to replace.

From an SEO perspective, we would rather ask:

What value does this page currently have?

Then decide whether it should:

• remain largely unchanged;
• be improved;
• be merged with another page;
• be redirected;
• be replaced by something better; or
• genuinely be removed.

Design decisions and SEO decisions should support each other rather than operating separately.

Create an old URL to new URL mapping

If URLs are changing, create a mapping before launch.

This can be a simple spreadsheet containing:

Old URL	New URL	Action
/old-service/	/new-service/	301 redirect
/old-about-page/	/about/	301 redirect
/unused-page/	None	Review before removal

The principle is straightforward.

Every valuable old URL should have a clear outcome.

Google explicitly recommends preparing a URL mapping when site URLs change.

Use permanent redirects properly

When an old URL has genuinely moved to a replacement page, use a server-side permanent redirect.

In most WordPress migrations this will mean a 301 redirect.

Google also supports 308 permanent redirects.

Permanent redirects tell browsers and search engines that the content has moved to a new location.

Google states that permanent redirects such as 301 and 308 are appropriate for site moves and do not inherently cause a loss of PageRank.

Do not redirect everything to the homepage

This is one of the worst migration shortcuts.

A website has 200 old URLs, so every missing page is redirected to:

/

That does not preserve relevance.

A page about commercial coffee machine servicing should redirect to the closest equivalent service page, not the homepage.

If there is genuinely no replacement and the content no longer belongs on the website, allowing the old URL to return a proper 404 or 410 can sometimes be more appropriate.

Avoid redirect chains

Redirects should ideally go directly from the old URL to the final destination.

For example:

Good:

/old-page/ → /new-page/

Less good:

/old-page/ → /older-page/ → /service/ → /new-page/

Google can follow redirect chains, but recommends keeping them short and directing users to the final destination wherever possible.

Update internal links instead of relying on redirects

If the new website still contains links pointing to old URLs, the redirect may technically make them work.

But that is not how we would leave the website.

Internal links should point directly to the final URL.

This:

/services/ → /old-seo-page/ → /seo/

should become:

/services/ → /seo/

This creates a cleaner site structure for users and search engines.

Google specifically recommends updating internal links during a URL migration.

Check canonical tags carefully

Canonical tags help search engines understand which version of a page should be treated as the main version.

After a migration, each new indexable page should normally reference its own final URL unless there is a specific reason to canonicalise elsewhere.

A common migration mistake is copying the old website and leaving canonicals pointing to the previous URLs or staging domain.

For example:

Live page:

https://example.com/seo/

Incorrect canonical:

https://staging.example.com/seo/

That sends completely the wrong signal.

Make sure staging settings do not reach the live site

Most development websites should be blocked from search engines while they are being built.

That is sensible.

The problem is forgetting to remove those restrictions when the website goes live.

Common examples include:

• WordPress “Discourage search engines from indexing this site” remaining enabled;
• a site-wide noindex meta tag;
• robots.txt blocking Googlebot;
• password protection remaining active;
• staging canonicals being copied to production; or
• HTTP headers sending noindex instructions.

Google specifically highlights forgotten noindex and robots.txt restrictions as common migration mistakes.

Do not remove valuable content simply to make the new site smaller

Redesigns often include a desire to simplify the website.

That can be a good thing.

But fewer pages does not automatically mean a better website.

If ten service pages each rank for commercially valuable searches, replacing all ten with a single generic Services page may make the navigation cleaner while destroying valuable search relevance.

Before consolidating content, understand:

• what each page ranks for;
• whether it receives organic traffic;
• whether it has backlinks;
• whether it converts;
• whether the replacement page genuinely covers the same subject; and
• whether several existing pages could sensibly be merged.

Preserve strong page intent

One of the easiest ways to lose rankings during a redesign is to weaken a page without realising it.

Imagine the old page contains 1,200 words explaining a specialist service in detail.

The redesigned page replaces it with:

“We deliver innovative solutions tailored to your business.”

followed by three icons and a contact button.

The new design might look cleaner, but Google now has substantially less information explaining what the page is actually about.

Good redesigns improve clarity without removing the substance search engines and customers need.

Keep important headings and topical signals

Page design frequently changes heading structure.

That is not automatically a problem.

But make sure the new page still communicates its subject clearly.

Important elements include:

• a clear H1;
• logical H2 and H3 headings;
• descriptive service copy;
• relevant internal links;
• useful supporting information; and
• clear calls to action.

The goal is not to preserve every heading purely because it existed previously.

It is to avoid replacing a well-understood page with something vague.

Review metadata during the migration

A redesign is a good opportunity to improve weak page titles and meta descriptions.

But do not blindly replace metadata that is already performing well.

If a page ranks strongly and receives a good click-through rate, changing everything at the same time makes it harder to understand what caused any movement afterwards.

For important pages, compare:

• old title;
• new title;
• old meta description;
• new meta description;
• target keyword; and
• current ranking performance.

Check image migrations too

Images are often forgotten during website migrations.

If image URLs are changing, consider whether those images receive Google Image traffic or external links.

Also check:

• image file paths;
• missing files;
• alt text;
• image compression;
• responsive image behaviour;
• lazy loading; and
• whether important images are still indexable.

Google includes images and other embedded resources in its site-move guidance because they can also be affected when URLs change.

Check JavaScript and page rendering

A redesign can change how content is delivered.

This matters particularly when moving from a relatively traditional website to a heavily JavaScript-driven framework.

The page may appear perfectly normal to somebody using a browser while important content is harder for search engines to access or render.

Check that important elements such as:

• headings;
• main page copy;
• navigation;
• internal links;
• product information;
• pagination; and
• structured data

are available in a way Google can process reliably.

Test the redesigned website before launch

Do not wait until the site is live to discover basic migration problems.

Before launch, we would normally test:

• important page templates;
• mobile layouts;
• forms;
• checkout where applicable;
• redirect rules;
• canonical tags;
• indexability;
• internal links;
• metadata;
• structured data;
• analytics;
• conversion tracking;
• page speed;
• 404 handling; and
• XML sitemaps.

The closer the staging site is to being technically complete before launch, the less chaotic migration day becomes.

Should staging websites be indexed?

Normally, no.

A staging website is usually a temporary development environment and should not compete with the live website in search results.

However, the method used to protect staging needs to be remembered during launch.

If the entire staging site has a noindex instruction, that instruction must not simply be copied into production and forgotten.

What should happen on launch day?

Migration day should feel relatively boring.

If everything has been prepared properly, the important work has already happened.

Typical launch tasks include:

1. Point the live domain to the new website.
2. Remove any staging noindex restrictions from the live site.
3. Activate permanent redirects.
4. Check key pages manually.
5. Test forms and checkout.
6. Confirm analytics is receiving data.
7. Confirm conversion tracking is working.
8. Check canonical URLs.
9. Check robots.txt.
10. Check the XML sitemap.
11. Submit the updated sitemap in Search Console.
12. Test several old URLs and confirm their redirects.

Should you submit a new sitemap?

Yes.

The sitemap should contain the final canonical URLs from the new website.

Submitting it through Search Console can help Google discover the new structure more quickly.

Google specifically recommends updated sitemap submission during site moves.

What if the domain name is changing?

A domain migration introduces additional risk because every important URL is effectively changing.

For example:

oldbusiness.co.uk/service/

becomes:

newbusiness.co.uk/service/

In addition to URL mapping and permanent redirects, you should make sure both properties are correctly verified in Search Console.

Google also provides a Change of Address tool for qualifying domain moves.

Google updated its guidance in 2026 to clarify that domain variants, including relevant www and non-www versions, should be handled correctly during domain migrations.

Do you use the Change of Address tool for every redesign?

No.

If the domain remains the same, you generally do not need the Change of Address tool.

A redesign from:

example.com

to a new website still using:

example.com

is not a domain change.

You may still have URL redirects to manage, but that is a different situation.

What if only the hosting provider is changing?

If the visible URLs stay exactly the same and only the server or hosting provider changes, Google treats that differently from a URL migration.

The main priorities are:

• prepare the new server;
• make sure Search Console verification remains intact;
• remove temporary crawl restrictions;
• update DNS;
• monitor traffic and crawling; and
• keep the old infrastructure available until the move has fully propagated.

Google notes that temporary crawl-rate changes can occur after a hosting migration while its systems adjust to the new infrastructure.

Will rankings drop after a website migration?

They can fluctuate.

Google says temporary ranking changes can occur during significant site moves while it crawls and reindexes the affected URLs.

That does not mean every migration should cause a dramatic traffic collapse.

If the website keeps its strongest content, redirects are implemented correctly and technical problems are avoided, the transition should be considerably smoother.

The objective is not necessarily zero movement.

It is avoiding unnecessary loss.

How long does Google take to process a website migration?

There is no fixed timeframe.

Google processes migrations on a URL-by-URL basis.

Smaller websites may settle relatively quickly, while large sites can take much longer for every URL to be recrawled and processed.

Google notes that medium-sized site moves can take several weeks or more before new URLs are consistently shown instead of old ones.

This is why monitoring after launch is important.

What should you monitor after launch?

The first few days and weeks after launch are not the time to assume the job is finished.

We would monitor:

• Search Console indexing reports;
• organic clicks;
• organic impressions;
• important keyword rankings;
• 404 errors;
• redirect errors;
• server errors;
• crawl activity;
• XML sitemap processing;
• conversion tracking;
• forms;
• eCommerce orders where applicable; and
• analytics traffic.

Any unusual decline should be investigated rather than dismissed as something that always happens after a redesign.

Pay particular attention to old URLs returning 404s

Not every 404 is a disaster.

Old spam URLs and genuinely removed content do not all need redirects.

But important old URLs unexpectedly returning 404s should be investigated quickly.

If the page moved, add the appropriate redirect.

If it was intentionally removed, decide whether there is a genuinely relevant alternative.

Check which pages lost traffic, not just total traffic

Looking only at total organic sessions can hide migration problems.

Suppose the website loses 40% of traffic to an important service page but gains similar traffic to an unrelated blog article.

Total organic traffic might look stable.

Commercial performance may not be.

Compare important landing pages individually.

Check rankings against the correct URLs

After a successful migration, Google should gradually associate important searches with the intended new URLs.

If an old URL is still ranking weeks later, or the wrong page has replaced it, review:

• redirects;
• canonical tags;
• internal links;
• content relevance;
• indexing status; and
• the sitemap.

Common website migration SEO mistakes

The majority of migration problems come from a relatively small group of mistakes.

Changing every URL unnecessarily

There is no SEO prize for replacing stable URLs with prettier ones during every redesign.

Forgetting redirects

If important pages move, the old URLs need a sensible destination.

Redirecting everything to the homepage

A homepage is not a substitute for every deleted service, product or article.

Deleting content without checking performance

An old-looking page may still be generating valuable search traffic.

Leaving noindex enabled

A staging setting can become a serious live-site problem surprisingly easily.

Leaving staging URLs in canonicals

Always check canonicals after a staging-to-live migration.

Forgetting analytics or conversion tracking

A beautifully migrated website is much harder to evaluate if measurement disappears on launch day.

Changing design, content, URLs and domain simultaneously

The more variables changed at once, the harder problems become to diagnose.

Google itself recommends changing one major thing at a time where practical.

Ignoring backlinks

If external websites link to URLs that are changing, make sure those URLs redirect correctly.

For particularly valuable links, it can sometimes be worthwhile asking the website owner to update the link directly.

A practical website migration SEO checklist

Before development

• Crawl the existing website.
• Export organic landing-page data.
• Export existing rankings.
• Identify pages with backlinks.
• Identify important converting pages.
• Decide which URLs can remain unchanged.

During development

• Build an old-to-new URL map.
• Preserve useful content.
• Plan permanent redirects.
• Review metadata.
• Review heading structures.
• Update internal links.
• Check canonical tags.
• Review structured data.
• Check image handling.
• Keep staging out of Google’s index.

Before launch

• Crawl the staging website.
• Compare it with the old site.
• Test redirect rules.
• Test forms and checkout.
• Check robots.txt.
• Check indexability.
• Check analytics.
• Check conversion tracking.
• Generate the final XML sitemap.

At launch

• Remove live-site noindex restrictions.
• Activate redirects.
• Check key URLs.
• Check canonical tags.
• Check the sitemap.
• Submit the sitemap to Search Console.
• Test several old URLs.

After launch

• Monitor Search Console.
• Monitor rankings.
• Monitor organic landing pages.
• Check 404 errors.
• Check server errors.
• Check redirects.
• Check enquiries and sales.
• Re-crawl the website.
• Compare performance against the pre-launch benchmark.

Should SEO be considered before the redesign starts?

Yes.

This is probably the most important point in the entire process.

SEO should influence:

• website structure;
• navigation;
• service-page requirements;
• URL decisions;
• content;
• internal linking;
• redirect planning; and
• technical implementation.

Waiting until the website is complete and then asking somebody to “SEO it” can mean discovering that the new structure has removed pages the business actually needed.

A redesign should strengthen your SEO, not simply preserve it

Migration planning is often discussed entirely in terms of avoiding losses.

That is only half the opportunity.

A redesign can also improve:

• website structure;
• content quality;
• internal linking;
• mobile usability;
• page performance;
• conversion paths;
• technical SEO;
• service targeting; and
• overall user experience.

The best outcome is not simply keeping every existing ranking exactly where it was.

It is protecting the value that already exists while building something capable of performing better afterwards.

Not every old website needs rebuilding

Before starting a migration, it is also worth asking whether a complete rebuild is genuinely necessary.

Some websites need structural change.

Others simply need better content, design improvements or technical repair work.

We have covered that decision separately in our guide to whether your website needs a redesign or just repair work.

Planning a website redesign?

If an existing website already receives organic traffic, search visibility should be part of the redesign process from the beginning.

We look at what the current site already ranks for, which pages matter, what can safely change and what needs protecting before the new website goes live.

That allows the design, development and SEO work to support each other rather than discovering migration problems after launch.

Take a look at our website design and development service, our SEO services, or schedule a consultation to discuss your website.