Redesign Without Losing SEO: Migration Plan

The fear is reasonable. You have a site that brings in enquiries, you are about to replace it, and you have heard the stories about traffic falling off a cliff in week two.

What the stories usually leave out is that the traffic did not disappear because the design changed. Google does not rank a colour palette. It disappeared because a hundred URLs changed without redirects, or because the page that ranked for your best query was rewritten into marketing copy, or because the staging site was left open to crawlers and the live one was accidentally blocked.

Those are process failures, and process failures are preventable. This is the sequence we run, in the order we run it, and the part most people skip.

If you are still deciding whether to rebuild at all, start with website redesign services for the scope and website redesign cost in India for the budget. This post assumes the decision is made and you want the migration not to hurt.

Why do websites lose traffic after a redesign?

In almost every case it traces back to one of five things: URLs changed without one-to-one redirects, ranking content was cut or thinned during the rewrite, the staging site’s noindex or robots.txt block shipped to production, metadata and structured data were not carried across, or internal links were rebuilt around a new menu that no longer points to the pages that earn the traffic.

Notice what is not on that list. Nothing about the visual design, the framework, the CMS, or whether the new site is prettier than the old one. Rankings live in URLs, content, links and technical signals, so those are the four things a migration has to protect.

The reason this goes wrong so often is sequencing. Most projects treat SEO as a launch-week checklist. By launch week the URL structure is already decided, the copy is already written, and fixing it means redoing work somebody has already been paid for. The migration plan has to exist before the sitemap is drawn, not after.

Step 1: Take a full inventory before anything is designed

You cannot protect what you have not written down. Before the first wireframe, build a single spreadsheet with one row per existing URL and these columns:

The URL itself, pulled from a crawl of the live site plus your XML sitemap plus Search Console’s Pages report. Use all three sources. Crawls miss orphan pages, and sitemaps miss pages nobody remembered to add.
Clicks and impressions over the last 12 months, exported per page from Search Console. Twelve months, not three, so seasonal pages are not mistaken for dead ones.
Number of referring domains, if you have access to any backlink tool. A page with external links is carrying equity that is expensive to replace.
The current title tag and meta description.
The decision: keep, merge, redirect, or delete.

Sort by clicks. In most small business sites, somewhere between eight and twenty URLs account for the overwhelming majority of organic traffic. Those are the pages that need protecting individually. Everything below them can be handled in bulk.

The pages with backlinks deserve their own attention even when their traffic is low, because the equity they pass to the rest of the site is the part you cannot rebuild by writing something better.

Step 2: Map every old URL to exactly one new URL

This is the deliverable that decides whether the migration works. Two columns: old URL, new URL. Every row filled.

A few rules that matter more than they sound:

One to one, not many to one. Redirecting forty old pages to the homepage is the single most common way to lose rankings in a redesign. Google treats a redirect to an irrelevant page as a soft 404 and drops the ranking rather than transferring it. If there is genuinely no equivalent page, redirect to the closest relevant category, not to the front door.

301, not 302. A 302 says temporary and is treated accordingly. Use 301 permanent redirects for everything in a migration.

No chains. If page A already redirects to B, and you now redirect B to C, update A to point at C directly. Chains lose signal and slow crawling, and they accumulate silently across successive redesigns.

Keep the URL if you can. The safest redirect is the one you never had to write. There is rarely a good reason to change /services/plumbing/ to /what-we-do/plumbing-services/. Restructure URLs only where the existing structure is actually causing a problem, not because the new information architecture diagram looked tidier.

If you are moving platforms as well, the same map does the job, but export everything first. Metadata, structured data and redirects live in different places on every system, and the old platform stops being accessible the moment the DNS changes.

Step 3: Preserve the content that is doing the work

Open your top pages by traffic and read them next to the new design. The question is not whether the copy is good. It is whether the new page still answers the same query the old one ranked for, with at least the same depth.

Design-led rebuilds thin content almost automatically. A 1,200-word service page becomes three headline blocks and a photo grid, because that is what the layout wanted. The page looks better and ranks worse, and the cause is not obvious for months.

Where a page is ranking, keep the headings that match the query, keep the substance, and improve it rather than replacing it. Add to it if the new layout has room. If the new design has no room for the content that earns your traffic, the design is wrong, not the content.

Pages being merged need care too. When two thin pages become one strong one, the surviving page should contain the substance of both, and both old URLs redirect to it.

Step 4: The pre-launch checks nobody runs until it is too late

Run these on the staging site, in the week before launch, and again within an hour of going live.

Crawl staging with a crawler and compare against the inventory. Every URL in your map’s “new URL” column should return 200. Any that do not are pages you forgot to build.
Check robots.txt. Staging sites are usually blocked from crawling. That file gets copied to production more often than anybody admits. It should read Allow, not Disallow: /, on the live site.
Check for stray noindex tags. Same failure, different mechanism. A site-wide noindex on staging that survives to production will remove you from Google within days.
Confirm canonical tags point to the live domain, not to the staging subdomain or the old domain.
Carry over title tags and meta descriptions for every page that ranks. This is where the inventory spreadsheet earns its keep.
Re-implement structured data. Organization, LocalBusiness, FAQ, Product, whatever you had. It does not migrate itself, and it is the easiest thing to forget because nothing visibly breaks when it is missing. If you need a refresher on what you should have, what is schema markup covers it.
Test the redirects. Take your map, and request every old URL. Confirm each returns a 301 and lands on the intended page. Do not sample. Test all of them.
Check Core Web Vitals on the new build, on a real mobile connection, before launch rather than after. A redesign that is slower than the site it replaced will lose ground on its own, and how to improve website loading speed goes into the specifics.
Verify analytics and Search Console tracking are on the new pages. If tracking breaks at launch you lose the ability to see whether anything else broke.

Step 5: Launch day and the first 48 hours

Push the redirects live at the same moment as the site, not afterwards. A gap of even a few hours produces a wave of 404s that Google will happily crawl.

Then, on the day:

Submit the new XML sitemap in Search Console. Leave the old sitemap accessible for a few weeks as well, so Google recrawls the old URLs and finds the redirects faster.
Use the URL Inspection tool on your top ten pages and request indexing for each.
Crawl the live site for broken links and 404s.
Check that the correct domain version is canonical, and that http, https, www and non-www all resolve to one address.

If you are on a new domain rather than just a new design, use Search Console’s Change of Address tool as well. It only applies to domain moves, not to redesigns on the same domain.

Step 6: The first 30 days

Expect some movement. A fluctuation of ten to twenty percent in the first fortnight is normal while Google recrawls and reassesses, and it usually settles. What is not normal is a sustained decline past week three.

Check these weekly:

Search Console’s Pages report for a rise in “Not found (404)” or “Page with redirect” errors. A jump in 404s means URLs exist in Google’s index that your map missed.
Clicks and impressions, compared against the same period last year rather than last month. Month-on-month comparisons across a launch are distorted by seasonality and by the launch itself.
Your top twenty pages individually. Site-wide traffic can look stable while your best page has quietly dropped ten positions and something else has risen to mask it.
Core Web Vitals, which are measured on real user data and so take about 28 days to reflect the new site properly.

If traffic has not recovered by week four, work the list in order: check that the affected pages return 200 and are indexed, check the redirect for the old URL actually fires, compare the new page’s content against what is in Google’s cache of the old one, and check whether internal links to that page survived the new navigation. In our experience the answer is in that list roughly nine times out of ten.

The part that actually protects you

Everything above is process, and process only happens if someone owns it. The practical protection is to make the URL map and the redirect test a named deliverable in the contract, with a date, rather than an assumption that the developer will handle it.

Ask any provider you are considering how they plan to handle the migration. If the answer is about the design system, keep looking. If they open with the URL inventory and the redirect map, they have done this before. Our website design and development work treats the migration plan as part of the build for exactly this reason, and the inventory is the first thing we produce, not the last.

Frequently Asked Questions

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

If the migration was handled properly, most sites see rankings stabilise within two to four weeks as Google recrawls and processes the redirects. Larger sites take longer simply because crawling takes longer. A decline that is still deepening after four weeks is a sign something is broken rather than something that needs more patience.

Should I keep my old URLs during a redesign?

Yes, wherever the existing URL is sensible and readable. Every URL you change requires a redirect, and every redirect loses a small amount of efficiency and adds a point of failure. Change URLs only where the current structure is genuinely causing a problem, not to match a new site map.

Do 301 redirects pass all the SEO value?

Google has stated that 301 redirects do not cause a loss of PageRank. In practice, the value transfers well when the redirect points to a genuinely equivalent page, and transfers poorly or not at all when it points somewhere irrelevant, which is why redirecting old pages to the homepage tends to lose rankings.

What is the most common SEO mistake in a website redesign?

Redirecting every removed page to the homepage instead of mapping each one to its closest equivalent. It is fast, it clears the 404 report, and it quietly discards the rankings those pages held.

Can I test a redesign for SEO problems before launching?

Yes, and you should. Crawl the staging site and compare the URL list against your inventory, confirm every new page returns 200, check that robots.txt and noindex tags will not ship as they are, and run the redirect map against staging where your host allows it. Nearly every migration failure is visible before launch if someone looks.

Do I need to resubmit my sitemap after a redesign?

Yes. Submit the new XML sitemap in Search Console on launch day, and leave the old sitemap available for a few weeks as well so Google recrawls the old URLs and discovers the redirects more quickly than it would on its own.

Sources:

How to Redesign a Website Without Losing SEO