On this page
Key takeaways
- Migrations don’t lose rankings because the design changed — they lose rankings because URLs changed and nobody mapped them. Every old URL needs a 301 to its new home.
- A safe migration is mostly preparation: a full crawl, a 1:1 redirect map, and preserved titles, meta, schema and content — agreed before launch day, not patched after.
- Expect a small dip for two to four weeks even when you do everything right. A redesign that quietly drops content, blocks crawlers or loses redirects is a different story — that one doesn’t recover on its own.
It’s the horror story every founder should fear: the shiny new website goes live on a Friday, everyone admires it over the weekend, and by Wednesday organic traffic is down 60%. The redesign looked like an upgrade. To Google, it looked like the old site vanished and a stranger took its place. A migration done right is invisible to your rankings. Done carelessly, it can erase years of SEO in a single deploy — and here’s the checklist that keeps that from happening to you.
Why do website migrations lose Google rankings?
Migrations lose rankings because the things Google ranks — specific URLs, their content, their links and their signals — get broken or moved without a forwarding address. The design is rarely the culprit. Changed URLs with no redirects, dropped content, and a staging ‘noindex’ left switched on are what actually tank traffic.
Think about what Google has spent years building: an index where this exact URL ranks for these queries, backed by the links pointing at it and the content on it. A migration that changes the URL without a 301 redirect snaps that thread. The old URL 404s, the ranking has nowhere to go, and the link equity pointing at it leaks away. Multiply that across a few hundred pages and you haven’t redesigned a site — you’ve quietly deleted it and rebuilt a brand-new one with zero history. The five usual killers: missing or broken redirects, URL structures that changed for no reason, lost titles and meta descriptions, a ‘noindex’ tag carried over from staging, and content that got ‘cleaned up’ out of existence.
What actually counts as a website migration?
A migration is any change that affects how your site is structured, served or addressed — not just a move to a new domain. A redesign on the same domain, a replatform from one CMS to another, a switch from HTTP to HTTPS, or a restructure of your URL folders all count. Each carries its own ranking risk.
Founders tend to assume ‘migration’ only means changing the domain name. In SEO terms it’s broader, and the type decides how much can go wrong. The common ones we see across Indian businesses:
- Redesign (same domain) — new look, often new templates and new URLs. Looks low-risk, frequently isn’t, because URLs and on-page content change underneath the visuals.
- Replatform — moving CMS or stack (say WordPress to a new build, or onto Shopify for e-commerce). URL patterns, metadata handling and page structure all shift at once.
- Domain change — a new domain or a rebrand. The highest-stakes move; every single URL changes and authority has to be passed across deliberately.
- HTTP to HTTPS — technically a protocol migration. Lower risk if handled cleanly, but still needs site-wide 301s and updated internal links and sitemaps.
- Restructure — reorganising URL folders, merging or splitting pages, changing the navigation hierarchy. Same domain, but the address book is rewritten.
What should you do before you launch?
Before anything goes live, you need a complete inventory of what exists and a plan for where each piece lands. That means a full crawl of the current site, a URL list, a 1:1 redirect map, and a decision to preserve titles, meta, schema, content, image alt text and internal links. Preparation is where migrations are won.
The single most useful artefact is a before/after table. List every important URL on the old site, decide its fate on the new one, and confirm a redirect for anything whose address changes. Crawl the live site with a tool like Screaming Frog, export the URLs that earn traffic (pull them from Google Search Console and GA4), and don’t forget the long tail of old blog posts that quietly bring in visitors. This is also the moment to audit your current titles and meta — a redesign is a chance to improve them, not a reason to lose them. If your web development team treats the redirect map as an afterthought, stop the launch until it exists.
Staging hygiene deserves its own line because it’s where Indian SMB migrations most often quietly self-destruct. The new site is almost always built on a staging URL — a subdomain, a temporary link, or a developer’s server — and to keep that draft out of Google it’s usually locked behind a password or a site-wide ‘noindex’. The problem is what happens at go-live: half the time the redesign is pushed across with that very block still baked in, and a perfect-looking site quietly tells Google to forget it exists. Equally, if staging was left open during the build, Google may have indexed the draft and will now serve duplicate, half-finished pages. Decide both before launch: keep staging blocked while it’s a draft, and make ‘remove the block’ the very first line of your go-live checklist.
| Step | Do this BEFORE launch | Do this AFTER launch |
|---|---|---|
| Crawl & inventory | Crawl the live site; export every URL, plus traffic-earning pages from Search Console and GA4 | Re-crawl the new site to confirm every URL resolves and nothing 404s |
| Redirect map | Build a 1:1 301 map: every old URL → its closest new URL (avoid chains and loops) | Spot-check redirects in bulk; fix any that 404, chain or point to the wrong page |
| On-page signals | Preserve titles, meta descriptions, H1s, schema, image alt text and internal links page by page | Verify titles, meta and schema actually rendered on the new pages |
| Indexing controls | Keep staging blocked (noindex / robots / password) so it never gets indexed | Remove the staging block on the live site — confirm no stray noindex shipped |
| Content | Keep the content that ranks; don’t ‘tidy’ pages out of existence | Compare word counts and key pages old vs new; restore anything dropped |
| Sitemap & GSC | Prepare an updated XML sitemap with the new URLs | Submit the new sitemap in Search Console; for a domain move, use the Change of Address tool |
| Performance | Test mobile speed on the new build before launch | Re-check Core Web Vitals; a slower site can cost rankings even with perfect redirects |
How do you build a 301 redirect map that works?
A redirect map is a two-column list: every old URL on the left, the single best matching new URL on the right, each served as a permanent 301. Map like-for-like — old service page to new service page, old post to new post — and never lazily point everything to the homepage. That shortcut throws rankings away.
The craft is in the matching. For pages that move to a near-identical new address, the 301 is obvious. For pages you’re merging or retiring, redirect to the closest equivalent that still satisfies the same search intent — a discontinued product to its category, an old guide to the updated one. A few rules that save you: avoid redirect chains (A→B→C makes Google work harder and bleeds equity — point A straight to C); never create loops; use 301 (permanent), not 302 (temporary), for migrations; and keep redirects in place for the long haul, not a fortnight. If old URLs sit on a different domain or HTTP version, those need site-wide 301s too. Done right, the redirect map is the rope that carries every ranking safely from the old SEO foundation to the new one.
- Export every old URL, prioritising the ones with traffic, links and rankings.
- Match each to the single closest new URL by intent — not just by title similarity.
- Use permanent 301s; flatten any chains so each old URL hits its final destination directly.
- Redirect retired pages to the nearest relevant page, not blindly to the homepage.
- Test the whole map in bulk after launch and keep the redirects live indefinitely.
What do you do on launch day?
On launch day the job is to flip the site live cleanly and immediately confirm Google can crawl and index it correctly. Remove the staging block, push the redirects, submit the new sitemap in Search Console, and test a sample of redirects and key pages by hand. The first hour after deploy is when problems are cheapest to catch.
Run launch like a checklist, not a celebration. First, confirm the dreaded staging ‘noindex’ or robots block is gone from the live site — this single oversight de-indexes more migrations than anything else. Then verify the 301s are firing: hit a dozen old URLs and confirm they land on the right new pages with a 301, not a 404 or a 302. Submit your updated XML sitemap in Google Search Console (and, for a domain change, run the Change of Address tool). Check that titles, meta and schema actually rendered. Confirm internal links point to new URLs, not through redirects. Glance at GA4 to see tracking is still firing. Catch the noindex and the broken redirects today and you’ve avoided 90% of migration disasters.
What should you monitor after going live?
After launch, watch crawl errors, rankings, indexed-page counts and 404s closely for several weeks — Search Console is your dashboard. A handful of 404s on minor pages is normal; a cliff in indexed pages or impressions is a redirect or indexing problem you need to fix today, not next month.
Set a simple monitoring rhythm. In Google Search Console, watch the Pages report for a spike in ‘not found (404)’ and ‘excluded’ URLs, and the Performance report for impressions and clicks against the week before launch. Track your priority keywords in a rank tracker so you can tell a normal settling-in wobble from a genuine drop. Re-crawl the new site to surface broken internal links, orphan pages and missing metadata. And keep an eye on Core Web Vitals — if the redesign shipped heavier than the old site, speed alone can drag rankings even when every redirect is perfect. The brands that recover fastest are the ones watching the data daily in week one, not the ones who reopen Search Console a month later and discover the damage.
A migration isn’t finished when the new site goes live — it’s finished when Search Console is calm two weeks later. Everyone celebrates on launch day; the professionals are still watching the data on day fourteen.— Murtaza Udaypurwala, DESENO
How long until rankings recover after a migration?
Even a flawless migration usually causes a small, temporary dip while Google re-crawls and re-evaluates the new URLs — typically a few weeks, often recovering within two to four. Google has to discover the new pages, follow your redirects and pass the old signals across, and that takes time. A short wobble is expected; a sustained slide is a warning.
Here’s how to read it. A clean migration dips a little, then climbs back to roughly where it was — sometimes higher if you improved speed, structure and content along the way. What you should not accept is a drop that keeps going or never recovers after four to six weeks: that almost always means broken redirects, lost content, an indexing block, or pages that no longer match the intent they used to rank for. The fix is to go back to the checklist — re-crawl, audit the redirect map, compare old and new content — and find what got dropped. Don’t panic at a week-one dip and start ripping things out; do investigate hard if there’s no recovery by week six.
The bottom line
A website migration only loses rankings when you let the URLs, content and signals fall through the cracks — and every one of those cracks is preventable with preparation. Crawl first, map every old URL to a 301, preserve your titles, meta, schema and content, kill the staging noindex, submit the sitemap, and watch Search Console for a fortnight after. Do that, and your new site keeps every ranking the old one earned. Skip it, and the prettiest redesign in India will cost you years of SEO overnight. Treat the migration as an SEO project that happens to involve a new design — not a design project that happens to touch SEO.
Frequently asked questions
It can, but it doesn’t have to. Rankings drop when a redesign changes URLs without 301 redirects, loses titles and content, or ships a staging ‘noindex’ tag. A redesign that keeps the same URLs and content, or maps every changed URL to its new home, can launch with little or no impact on rankings.
A 301 is a permanent redirect that tells Google a page has moved for good. It matters because it forwards both visitors and the page’s ranking signals and link equity from the old URL to the new one. Without 301s, old URLs return 404 errors, rankings have nowhere to go, and the authority you built up leaks away.
For a clean migration, expect a small dip that usually recovers within two to four weeks as Google re-crawls and re-evaluates the new URLs. If rankings are still falling or flat after four to six weeks, that’s not normal settling — it points to broken redirects, lost content or an indexing block you need to find and fix.
Two tie for first. The most damaging is leaving the staging ‘noindex’ tag or robots block switched on when the site goes live, which de-indexes the whole site. A close second is a missing or lazy redirect map — either no 301s at all, or pointing every old URL to the homepage instead of its true equivalent.
Only if you have a real reason to. Every URL you change needs a 301 redirect and carries some risk, so keep URLs identical wherever you can — it’s the safest path. If a restructure genuinely improves clarity or hierarchy, do it deliberately and map every old URL to its new address, rather than letting URLs change by accident.
Yes. After launch, submit an updated XML sitemap with the new URLs in Google Search Console so Google discovers the new structure faster. For a domain change, also use the Change of Address tool. Resubmitting the sitemap speeds up re-crawling and helps Google follow your redirects to pass the old rankings across.
