Website Migration SEO: Redesign Without Losing Rankings
Most redesigns that damage rankings do so for reasons nobody noticed on launch day. This is the process we run before, during and after a migration so that does not happen.
By Khushbu Solanki, Founder, AmplifyKlicks · 16+ years in SEO & digital marketing · Updated September 2026
Why Redesigns Lose Rankings — and It Is Rarely the Design
A business spends months on a new site. It launches. It looks vastly better. Six weeks later enquiries have halved and nobody can explain why, because the obvious suspect — the design — is not the culprit.
Google does not rank sites on aesthetics. What it does notice is that the URLs it had indexed now return 404s, that the page which used to carry 900 words of detail now carries 200 words of headline copy, and that the tidy new navigation quietly removed forty internal links. Those are the things that cost rankings, and every one of them is invisible in a design review.
Definition
Website migration SEO is the work of preserving accumulated search equity — rankings, indexed URLs, backlinks and internal link structure — through any change to where content lives or how it is served. It applies to redesigns, replatforms, domain changes, HTTPS moves and URL restructures alike. Store replatforms carry the highest risk of all, which is why migration planning sits inside our ecommerce store SEO engagements.
Four causes account for almost every migration ranking loss: URLs changed without one-to-one redirects, page content shortened or removed, internal links dropped by a new navigation, and a noindex tag carried over from staging. All four are preventable and none is a design decision.
The Pre-Launch Benchmark
This is the step that separates a controlled migration from a hopeful one, and it takes an afternoon. If you record nothing before launch, you cannot later prove whether a drop was caused by the migration, an algorithm update, or seasonality — and you cannot tell which pages to prioritise fixing.
Capture and store all of this before anything ships:
| What to record | Where from | Why it matters afterwards |
|---|---|---|
| Full URL crawl | Screaming Frog or Sitebulb | The master list every redirect is mapped from. Without it you are guessing what existed. |
| Impressions and clicks by page and query | Search Console, 12 months | Tells you which URLs actually matter, so effort concentrates there rather than spreading evenly. |
| Indexed page count | Search Console → Indexing | The fastest early warning after launch. A falling count precedes a ranking fall by weeks. |
| Priority keyword positions | Rank tracker, dated export | The before picture in any before-and-after argument. |
| Top pages by organic traffic and conversions | GA4 | Identifies the small number of URLs that must not break under any circumstances. |
| Backlink profile by target URL | Ahrefs or Semrush | Externally linked URLs are the most expensive to break, because you cannot ask every site to update. |
| Core Web Vitals field data | PageSpeed Insights | A new build is often heavier than the old one. This is how you find out before Google tells you. |
Store the exports somewhere neither agency can quietly revise. A benchmark that lives only in the vendor’s account is not a benchmark.
Redirect Mapping: The Step Everyone Skips
Redirect mapping is tedious, invisible in a demo, and the single highest-risk item in the project. It is skipped more often than any other step for exactly those reasons.
The rules are not complicated:
- One old URL to one closest-equivalent new URL. Not to a category. Not to the homepage.
- Use 301, not 302. A 302 signals a temporary move and delays signal transfer indefinitely if left in place.
- No chains. Old to interim to new loses value at every hop and slows crawling. Map old directly to final.
- Where no equivalent exists, return 410. Honest removal is better than redirecting to something irrelevant, which Google treats as a soft 404 anyway.
- Test before launch, on staging. Every redirect, not a sample — a crawler will check thousands in minutes.
Bulk-redirecting every retired URL to the homepage is the most common serious mistake we inherit. It looks tidy, produces no 404 errors, and destroys the ranking signals of every page it touches. Google reads an irrelevant redirect as a soft 404 and treats the old URL as gone.
Keep redirects in place permanently. Removing them after six months because the file is long undoes the migration and severs every external link still pointing at an old URL.
What Must Survive the Move
Redirects preserve the address. They do not preserve the reasons a page ranked. These have to be carried across deliberately, and a redesign brief that says “cleaner, less text” will quietly destroy several of them.
- Body copy, at full length. The most common silent cause of migration loss. Modern designs favour short blocks; the 900 words that earned the ranking do not survive that instinct.
- Title tags and meta descriptions. New CMS platforms frequently auto-generate these and overwrite what was there.
- Heading hierarchy. A design that renders the old H1 as styled body text removes the strongest on-page relevance signal.
- Internal links. Simplified navigation and removed sidebars can delete hundreds of links. Crawl both sites and compare inbound link counts per URL.
- Structured data. Schema is usually attached to templates, so a template rebuild removes it silently.
- Image filenames and alt text. Re-uploaded images often lose both, which costs image search traffic.
- Canonical tags and hreflang. Especially where a site serves several countries or languages — see international SEO.
If the new site must have less text on screen, keep the content and change how it is presented — accordions, tabs and progressive disclosure all keep copy in the HTML. Deleting it to achieve a cleaner look trades rankings for whitespace.
Launch Day: The Sequence
Order matters, and most launch-day damage happens in the first hour.
- Remove the staging block. Delete the noindex tag and any Disallow rule left in robots.txt. This single line has cost more rankings than every other migration error combined.
- Verify redirects live. Crawl the old URL list against the live site and confirm every one returns a single 301 to a 200.
- Submit the new XML sitemap in Search Console, and temporarily keep the old sitemap available so Google rediscovers the retired URLs and processes their redirects.
- Check canonical tags resolve to the new URLs, not to staging or to the old domain.
- Confirm analytics and Search Console are recording. For a domain change, add the new property and use the Change of Address tool.
- Spot-check rendering with the URL Inspection tool — confirm the main copy and internal links appear in the rendered HTML, not only in the browser.
- Request indexing for the highest-value URLs rather than waiting for a natural recrawl.
Then monitor indexed page count daily for two weeks. It is the earliest reliable signal that something is wrong, and it moves before rankings do.
The Recovery Window: What Is Normal, What Is a Fault
We publish this because businesses deserve to know it in advance, and because the alternative — explaining it only after a client panics — sounds like an excuse.
Some volatility after a large migration is expected. Google has to recrawl every URL, follow every redirect and reassign signals, and it does not do that instantly.
| Timeframe | Normal | Investigate immediately |
|---|---|---|
| Week 1–2 | Fluctuation, some positions dipping, indexed count moving as URLs swap over. | Traffic collapse of 50% or more, or indexed pages falling sharply and continuing to fall. |
| Week 3–4 | Dip beginning to stabilise; new URLs appearing in Search Console. | Old URLs still indexed alongside new ones — redirects are not being followed. |
| Week 5–8 | Recovery toward previous levels, often exceeding them if the new site is faster and better structured. | Still declining. This is a fault, not patience — run a full diagnostic. |
| Beyond 12 weeks | Performance settled at or above the benchmark. | Any sustained shortfall against the pre-launch benchmark needs a root-cause audit. |
If you are past week five and still falling, our ranking drop diagnostic identifies whether the cause is the migration or something unrelated that happened to coincide with it.
Migration Types and Their Risk Profiles
Not all migrations carry equal risk. Knowing which type you are running determines how much protection the project needs.
| Type | Risk | The specific danger |
|---|---|---|
| Visual redesign, same URLs | Low to medium | Content shortened for aesthetics; internal links removed by simplified navigation. |
| URL restructure | High | Every redirect must be correct. Errors here are the classic cause of a lasting drop. |
| Replatform (WordPress to Shopify, etc.) | High | Forced URL patterns, auto-generated meta tags, and lost schema from template changes. |
| Domain change | High | Requires the Change of Address tool, and every external link now depends on your redirects. |
| HTTP to HTTPS | Low, if done properly | Mixed content warnings and internal links still hard-coded to the insecure protocol. |
| Several at once | Highest | If something breaks you cannot tell which change caused it. Sequence them separately wherever possible. |
The last row is the advice most often ignored and most often regretted. A new domain, a new platform and a new URL structure launched together is three experiments with one result.
“Our Developer Says This Is All Handled”
Often it genuinely is. But developers and SEOs mean different things by handled, and the gap between the two definitions is where migrations fail.
To a developer, a migration is complete when the new site works: pages load, forms submit, nothing errors. All true, and none of it addresses whether the URL Google indexed still resolves, whether the copy that earned the ranking survived, or whether schema left with the old template.
Four questions worth asking before launch. They are not adversarial — a good developer will welcome them, because a ranking collapse becomes their problem too:
- Can I see the redirect map as a spreadsheet of old URL to new URL?
- Has the staging noindex been removed from the production build?
- Are title tags and meta descriptions carried over, or regenerated by the new platform?
- Is the main body copy present in the HTML source, or rendered by JavaScript?
If the redirect map does not exist as a document, it does not exist. That single question predicts migration outcomes better than any other.
Migration SEO FAQs
Will a website redesign hurt my Google rankings?
It can, but the design itself is almost never the cause. Rankings are lost when URLs change without one-to-one redirects, when page copy is shortened or dropped, when internal links disappear from a new navigation, or when a noindex tag from staging reaches production. A redesign that preserves URLs, content and internal linking carries little ranking risk.
What should I record before a website migration?
A full crawl of the existing site, priority keyword positions, Search Console impressions and clicks by page and query, indexed page count, top landing pages by organic traffic, your backlink profile by target URL, and Core Web Vitals field data. Without a pre-launch benchmark you cannot prove what the migration did or did not cause.
How long does it take to recover rankings after a migration?
A dip of two to four weeks is normal while Google recrawls and reassigns signals. Recovery usually follows within four to eight weeks when redirects and content are correct. A drop still worsening after six weeks is a fault, not a waiting game.
Can I redirect all old pages to the homepage?
No. Google treats a redirect to an irrelevant destination as a soft 404 and the old URL’s ranking signals are largely lost. Redirect each old URL to its closest equivalent. Where none exists, a 410 is more honest and more useful than a homepage redirect.
Do I need redirects if my URLs are not changing?
If every URL is genuinely identical, no. In practice URLs change more often than expected through trailing slashes, altered category paths, removed date prefixes or an HTTP to HTTPS move. Crawl both sites and compare the URL lists rather than assuming.
What is the difference between a redesign, a replatform and a migration?
A redesign changes appearance and often templates. A replatform changes the CMS. A migration is any change to where content lives — a domain change, an HTTPS move or a URL restructure. Each carries a different risk profile, and projects often combine several at once, which is when the most damage happens.
Planning a Redesign or Replatform?
The cheapest time to involve an SEO is before launch, not after the traffic falls. We benchmark, map redirects and verify the build before it ships.