--- title: "How to Migrate or Redesign Your Site Without Losing Rankings" description: "A practical step-by-step guide to managing a site migration or redesign without losing rankings - covering URL mapping, 301 redirects, sitemap resubmission, speed testing, and post-launch monitoring." author: "Ari Ber" category: "AI-Transformed Workflows" date: 2026-09-29T08:00:00.758Z canonical: "https://contentagents.dev/blog/how-to-migrate-or-redesign-your-site-without-losing-rankings-b636" --- # How to Migrate or Redesign Your Site Without Losing Rankings ![Dual-monitor workstation showing a URL spreadsheet and site architecture diagram, with a desk lamp casting amber light.](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/024a6468-4c4c-4195-b8c2-21b4170617d4/d885753f-27c7-4795-be86-ce1c92835ec5/afc5f302-bd23-4500-b691-0a2dd3874762.jpg) > A practical step-by-step guide to managing a site migration or redesign without losing rankings - covering URL mapping, 301 redirects, sitemap resubmission, speed testing, and post-launch monitoring. A site migration done right can preserve every ranking you've earned. Done wrong, it can erase months of organic growth in a week - and recovering that ground takes longer than most teams expect. This guide is for SEO practitioners who understand the mechanics and need a single, consolidated reference. Some of what follows comes from direct experience - URL auditing, redirect planning, and sitemap management are all part of how we run migrations at Content Agents. The more specialized technical territory (server-level redirect configuration, crawl budget optimization at scale) draws on established SEO practice from sources like Search Engine Land's migration guides. Where the line falls, we'll say so explicitly. ## Step 1: Map Every Old URL to Its New Home Before You Touch Anything URL mapping is non-negotiable. Google has spent months or years building equity into your existing URLs - the authority, the links, the indexation signals. Without a complete map of where every old URL is going, that equity has nowhere to land on your new site. Picture a 500-page site going through a domain migration. Forty pages drive 80% of organic traffic. If even ten of those get missed in the redirect map, you're looking at a traffic drop that won't fully recover until Google re-crawls and re-indexes the new equivalents - which can take weeks. The math on that is brutal when you're mid-migration with leadership watching the dashboard. The actual mechanics are straightforward. Export your current site structure using Google Search Console, Screaming Frog, or your CMS's export function. You want every URL - not just the top performers, but the long tail too, because consolidated pages and deleted URLs both need decisions. Then, for each old URL, assign a destination: same slug on a new domain, restructured path, merged into another page, or explicitly retired. That last category matters - pages you're deleting still need a redirect to the most relevant surviving page, not a 404. URL mapping is something we do in-house for our own migrations. Handling redirect logic for edge cases - like paginated content, faceted navigation, or parameter-heavy URLs - is where dedicated SEO expertise adds real value. If your site has significant technical complexity in those areas, that's where to bring in a specialist. ### What this means in practice - Use a spreadsheet or redirect mapping tool to track old URLs to new ones, with a status column for each (redirect, consolidate, delete). - Identify pages being consolidated or deleted before launch - they still need a redirect destination, not a dead end. - Flag your highest-traffic pages separately and double-check their redirect assignments manually before anything goes live. - Don't start the redirect implementation until the mapping is complete. Partial maps cause partial disasters. ## Step 2: Set Up 301 Redirects and Monitor Them Weekly ![](https://images.unsplash.com/photo-1552864471-e1f28411e2bc?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTQwNjJ8MHwxfHNlYXJjaHwxfHxTdGVwJTIwMiUyMHByYWN0aWNhbCUyMHN0ZXBieXN0ZXAlMjBtYW5hZ2luZ3xlbnwxfHx8fDE3ODk1MDI0MDR8MA&ixlib=rb-4.1.0&q=75&w=960&auto=format) Photo by [Erik Mclean](https://unsplash.com/@introspectivedsgn) on [Unsplash](https://unsplash.com) A 301 redirect tells Google the page moved permanently, and - critically - transfers its authority to the new URL. A 302 says the move is temporary, so Google holds onto the old URL as the canonical. For any permanent migration or redesign, 302s are the wrong tool. The Wise migration (formerly TransferWise) illustrates the stakes: when they moved from transferwise.com to wise.com, their monthly organic traffic dropped from roughly 32 million to 13 million visits. They recovered - eventually reaching 205 million monthly visits within around eight months - but that initial drop demonstrates what can happen even with a well-resourced team executing a high-visibility migration. Technical setup happens at the server level. On Apache, that's your .htaccess file. On Nginx, it's the server config. If you're on a CMS like WordPress, plugins can handle this - but server-level implementation is more reliable and doesn't add load time the way plugin-based redirects sometimes do. Wherever you implement them, test before launch. Use curl or a redirect checker tool to confirm each redirect resolves correctly and doesn't chain through multiple hops. Redirect chains (old URL to old URL to new URL) bleed equity at each step. Monitoring is where most teams underinvest. Set up weekly checks in Google Search Console specifically looking at indexation errors, 404 spikes, and coverage drops. Build a simple KPI view that tracks the status of your top-traffic old URLs - are they indexed under the new URL? Are they still showing as the old URL in search results? That lag period is normal, but if it extends past four weeks without movement, something in the redirect chain needs auditing. ### What this means in practice - Implement 301 redirects before launch, not as a post-launch cleanup task. - Test every redirect with curl or a dedicated redirect checker - do not rely on manual browser checks alone. - Monitor GSC weekly for the first eight weeks: indexation errors, 404 spikes, and coverage changes are your early warning system. - Avoid redirect chains. Old URL should resolve to new URL in one hop. ## Step 3: Resubmit Your Sitemap and Let Google Know What Changed Your sitemap tells Google which URLs exist and when they last changed. During a migration, Google needs to find the new structure quickly - waiting for Googlebot to discover it organically adds weeks you don't have. A sitemap resubmission on launch day shortens that window. Generate a new sitemap for your new domain or URL structure. Remove old URLs from the old sitemap, or let it expire naturally - you don't want Googlebot following a sitemap that points to URLs you've already redirected away. Submit both the new sitemap and, if you're doing a domain migration, the old domain's updated sitemap through Google Search Console. For domain changes specifically, use GSC's Change of Address tool - it's a direct signal to Google that you've moved intentionally, not that something broke. Timing matters here. Submit the new sitemap on launch day, not in the weeks before. If you submit it early, Google may begin crawling the new domain before your redirects are live on the old domain, creating a window where the new URLs exist in Google's index without proper redirect coverage. Launch everything together: redirects live, new sitemap submitted, Change of Address tool updated, all on the same day. ### What this means in practice - Create the new sitemap before launch, but submit it on launch day - not before. - Use GSC's Change of Address tool for domain migrations. It's a direct signal, not just a nice-to-have. - Monitor GSC's Coverage report weekly after launch to track which new URLs are getting indexed and how quickly. - If your old sitemap included URLs you've retired, update or deprecate it so Googlebot stops crawling dead ends. ## Step 4: Test Site Speed and Usability Before Launch A redesign that slows your site down can drop rankings independent of any redirect or indexation issue. [Performance signals feed into Google's Core Web Vitals assessment](https://developers.google.com/speed/docs/insights/v5/about), and the user behavior data is consistent: close to half of users abandon a page if it takes more than three seconds to load, and research cited across performance optimization literature suggests a one-second improvement in load time correlates with roughly a 7% increase in conversions. Correlation, not causation - but the direction is clear enough to take seriously. Run your new site through PageSpeed Insights, GTmetrix, or WebPageTest before launch. Not once - weekly for the month before go-live. Look specifically for unoptimized images, render-blocking JavaScript, and slow server response times. These are the most common bottlenecks introduced during redesigns when new design elements get added without a performance review. If your Largest Contentful Paint score degrades between staging and production, you want to find that before launch, not after. Usability testing runs parallel to speed testing. Research on user testing - including work cited by usability practitioners from Nielsen Norman Group - indicates that five test users surface around 85% of usability issues. You don't need a large panel. Find five people who represent your actual audience, give them specific tasks to complete on the new design, and watch where they get stuck. Navigation changes, form redesigns, and new page structures are all common sources of friction that wouldn't appear in a technical audit but will show up in user behavior signals post-launch. ### What this means in practice - Run speed tests weekly for the month before launch, not just once on staging. - Target under three seconds load time on a 4G mobile connection - that's the threshold where abandonment climbs. - Conduct usability testing with at least five real users before launch, focusing on your highest-traffic page types. - Address Core Web Vitals regressions on staging before they reach production - retrofitting performance fixes post-launch is slower and more disruptive. ## Step 5: Launch in Stages and Monitor Rankings Daily for the First Month Flipping 100% of traffic to a new site on day one is the highest-risk approach to a migration. A staged rollout gives you a controlled window to catch redirect failures, indexation problems, or performance regressions before they affect your full audience - and your full ranking footprint. A workable staged approach: route 10% of traffic on day one, hold for 24-48 hours and monitor, then move to 25% on day three, 50% on day seven, and 100% around day fourteen. The specific percentages matter less than the principle - each stage should be held long enough to surface problems, and each expansion should only happen once you've confirmed the previous stage is stable. If you're on a platform that doesn't support traffic splitting, a staged rollout by page type (blog first, then product pages, then homepage) achieves a similar risk reduction. Your monitoring setup needs to be live before launch day, not built reactively. Track rankings for your top 50 keywords daily using GSC, SEMrush, or Ahrefs. Watch organic traffic in GA4. Pull crawl error reports from GSC every 48 hours. Some ranking movement is normal in the first two weeks - Google is re-processing your URL structure, and temporary fluctuations aren't evidence of failure. What you're watching for is sustained drops after week two that don't self-correct, which typically indicate a redirect chain issue, a canonical problem, or content that didn't migrate correctly. ### What this means in practice - Launch to 10% of traffic first, hold for 24-48 hours before expanding - don't let urgency compress the monitoring window. - Check your monitoring dashboard daily for the first month. Weekly is not frequent enough during the critical recovery window. - If a key page's ranking drops and doesn't recover by week two, audit its redirect and check whether the new URL is being indexed correctly. - Have a rollback plan documented before launch day. If something goes wrong at 10% traffic, you want the revert procedure ready, not improvised. ## Track These Metrics to Confirm Your Migration Succeeded You'll know the migration worked if five specific metrics hold steady or improve over eight weeks. The Wise migration is a useful benchmark here - despite a significant initial traffic drop from approximately 32 million to 13 million monthly visits, the domain change ultimately correlated with growth to 205 million monthly visits within roughly eight months. The recovery wasn't instant, but it was measurable and directional. That's the pattern you're watching for. Organic traffic should return to baseline within four weeks. If it hasn't by week four, you have either a technical issue (redirect errors, indexation gaps) or a content issue (pages that didn't migrate with their full content and metadata). Rankings for your top 50 keywords should stabilize within two to four weeks - meaningful, sustained drops after that window suggest a canonical problem or a redirect that isn't passing authority correctly. Crawl errors in GSC should trend downward week over week. If they're climbing, Googlebot is finding dead ends your redirect map missed. Indexed pages should match your new sitemap's URL count within four weeks - a large gap between what you submitted and what's indexed means Google isn't accepting the new structure. Core Web Vitals scores should hold at or above your pre-migration baseline. Build a simple tracking spreadsheet with these five metrics measured at four points: pre-migration baseline, day one post-launch, week two, week four, and week eight. Compare each checkpoint to baseline. The trend matters more than any single data point - a dip that's recovering is a different problem than a dip that's widening. ## FAQ ### Should I use 301 or 302 redirects during a site migration? Always 301 for permanent moves. A 301 tells Google the page has moved permanently and transfers its link equity to the new URL. A 302 signals a temporary redirect - Google holds onto the old URL as the canonical, meaning the authority you've built stays attached to a URL you're no longer using. In practice: if you're migrating a domain, restructuring URLs, or consolidating pages, those are all permanent moves. Use 301s. The only case --- Source: https://contentagents.dev/blog/how-to-migrate-or-redesign-your-site-without-losing-rankings-b636