You launched the new site. Everything looks great. The design is modern, the performance metrics are stellar, and your team is celebrating. Then Monday morning hits. Google Search Console shows a 40% traffic drop. Your phone starts ringing.

I've been through this exact scenario more times than I'd like to admit. We've migrated sites from WordPress to Next.js, from monolithic platforms to headless architectures, from legacy CMSes to Astro -- and the traffic dip after migration is one of the most predictable (and preventable) problems in web development. The good news? In most cases, you can recover fully. Sometimes you even come out ahead. But you need to act fast and methodically.

This article is the recovery playbook we actually use at Social Animal when migrations don't go according to plan. No theory -- just the steps that work.

Table of Contents

Traffic Dropped After Website Migration? How to Recover Lost Rankings

Why Traffic Drops After Migration

Before we fix anything, let's understand why this happens. Google doesn't just "see" your new site and trust it immediately. When you migrate, several things change simultaneously, and any one of them can trigger a ranking drop.

The Most Common Causes

Cause Frequency Severity Recovery Time
Missing or broken redirects Very common High 2-6 weeks
URL structure changes without proper mapping Very common High 4-12 weeks
Content changes or removal Common Medium-High 4-8 weeks
Internal linking structure changes Common Medium 2-4 weeks
Robots.txt blocking crawlers Occasional Critical Days (once fixed)
Noindex tags left from staging Occasional Critical Days (once fixed)
Domain or protocol changes Occasional Medium 6-12 weeks
Loss of structured data Common Medium 2-6 weeks
Slower page speed Common Low-Medium 2-4 weeks
JavaScript rendering issues Common with SPAs High 2-8 weeks

Here's the thing most articles won't tell you: a temporary traffic dip of 10-20% is actually normal during migration, even when you do everything right. Google needs to recrawl and reprocess your site. That takes time. The problem is when the dip is steeper than that or doesn't recover within a few weeks.

Google's Recrawl and Reassessment Period

When Google encounters your new URLs (even with proper redirects), it needs to:

  1. Discover the redirects
  2. Crawl the new destination URLs
  3. Index the new pages
  4. Reassess content quality and relevance
  5. Update its ranking signals

This process isn't instant. For large sites (10,000+ pages), it can take weeks for Google to fully process everything. During this period, you'll see fluctuations. That's expected. What's not expected is a sustained drop beyond 4-6 weeks.

The First 48 Hours: Triage Checklist

When you notice the traffic drop, don't panic -- but do move quickly. Here's the triage checklist I run through within the first 48 hours:

Step 1: Verify Crawling Isn't Blocked

This is the single most common "oh no" moment I've seen. Someone forgets to update the robots.txt file, or the staging environment's noindex meta tags ship to production.

# Check robots.txt
curl -s https://yoursite.com/robots.txt

# Look for these red flags:
# User-agent: *
# Disallow: /

Also check your page source for noindex tags:

<!-- This will KILL your rankings -->
<meta name="robots" content="noindex, nofollow">

In Next.js, this often happens when environment-based meta tags aren't properly configured:

// Check your layout.js or _app.js
// Make sure this isn't conditionally rendering noindex in production
export const metadata = {
  robots: {
    index: process.env.NODE_ENV === 'production',
    follow: process.env.NODE_ENV === 'production',
  },
};

If you're working with our Next.js development team, we have CI/CD checks that catch this before deployment. But if you're handling it yourself, add a post-deploy verification step.

Step 2: Check Google Search Console Immediately

Go to Search Console and look at:

  • Coverage/Pages report: Are pages being indexed? Are there new errors?
  • Crawl stats: Has Googlebot's crawl rate dropped?
  • Manual actions: Did the migration trigger a manual penalty? (Rare, but check.)
  • Core Web Vitals: Did performance tank?

Step 3: Verify Your Sitemap

Make sure your new sitemap is submitted and contains the correct URLs:

curl -s https://yoursite.com/sitemap.xml | head -50

I've seen migrations where the sitemap still pointed to old URLs, or worse, to the staging domain. This sends Google conflicting signals about which URLs are canonical.

Step 4: Spot-Check Critical Pages

Take your top 20 pages by organic traffic (from before the migration) and manually verify:

  • Do the old URLs redirect properly to the new ones?
  • Is the content on the new pages the same (or better)?
  • Are the title tags and meta descriptions intact?
  • Is the structured data still present?

Diagnosing the Root Cause

Once you've done the triage, you need to figure out exactly what's causing the drop. This is detective work, and it requires data from multiple sources.

Use Google Search Console's Performance Report

Compare the 28-day period before migration to the 28-day period after. Look at:

  • Which queries lost impressions? If specific query clusters dropped, it's likely a content or URL issue.
  • Which pages lost clicks? This tells you which specific pages are affected.
  • Did the entire site drop, or just certain sections? A site-wide drop suggests a technical issue (robots.txt, noindex). A section-specific drop suggests redirect or content problems.

Crawl the Site Like Google Does

Use Screaming Frog, Sitebulb, or Ahrefs' site audit to crawl your new site:

# Using screaming-frog CLI (if available)
screamingfrog --crawl https://yoursite.com --output-folder ./audit

# Or use a Node-based crawler for quick checks
npx broken-link-checker https://yoursite.com --recursive

Look for:

  • 404 errors on pages that should exist
  • Redirect chains (more than 2 hops)
  • Pages returning soft 404s (200 status but with error content)
  • Orphaned pages with no internal links pointing to them

Check the Redirect Map Against Reality

Your pre-migration redirect map is only useful if it was actually implemented correctly. I can't tell you how many times I've seen a perfectly planned redirect map that was implemented with typos, wrong status codes, or simply missing entries.

// Quick Node.js script to verify redirects
const https = require('https');
const oldUrls = [
  '/old-blog/my-post',
  '/products/widget-a',
  '/about-us',
  // ... your full list
];

oldUrls.forEach(url => {
  https.get(`https://yoursite.com${url}`, { method: 'HEAD' }, (res) => {
    if (res.statusCode === 301 || res.statusCode === 302) {
      console.log(`✅ ${url} → ${res.headers.location} (${res.statusCode})`);
    } else if (res.statusCode === 404) {
      console.log(`❌ ${url} → 404 NOT FOUND`);
    } else {
      console.log(`⚠️  ${url} → ${res.statusCode}`);
    }
  });
});

Traffic Dropped After Website Migration? How to Recover Lost Rankings - architecture

Fixing Redirect Issues

Redirects are the #1 cause of post-migration traffic loss. Let's get them right.

301 vs 302: It Still Matters

Use 301 (permanent) redirects for migration. Period. A 302 (temporary) redirect tells Google to keep the old URL in its index. That's not what you want.

In Next.js, your redirects live in next.config.js:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true, // This makes it a 301
      },
      {
        source: '/products/:category/:product',
        destination: '/shop/:product',
        permanent: true,
      },
    ];
  },
};

In Astro (which we use for many of our Astro development projects), redirects can be configured in astro.config.mjs or through your hosting platform.

Handling Redirect Chains

A redirect chain looks like this: A → B → C → D. Each hop loses a small amount of link equity, and after 3-4 hops, Googlebot may simply stop following. Fix chains by pointing everything directly to the final destination.

Bulk Redirect Implementation

For large sites, you'll likely need platform-level redirects. Here's how to handle them at scale with Vercel (common for Next.js deployments):

// vercel.json
{
  "redirects": [
    { "source": "/old-path", "destination": "/new-path", "permanent": true },
    { "source": "/blog/2024/:slug", "destination": "/blog/:slug", "permanent": true }
  ]
}

For Netlify:

# _redirects file
/old-path    /new-path    301
/blog/2024/* /blog/:splat 301

Recovering from Content and URL Changes

If you changed content during the migration -- even "improved" it -- Google may need to reassess the page's relevance for its target queries.

Don't Change Everything at Once

This is advice I wish someone had given me years ago: migration should be a lateral move. Change the tech stack, change the design, but try to keep the content, URLs, title tags, and meta descriptions the same initially. You can optimize content after the migration stabilizes.

If you've already changed content and lost rankings:

  1. Compare the old content (from archive.org or your backup) with the new content
  2. Identify which pages lost the most traffic
  3. Check if those pages still target the same keywords
  4. Consider reverting the content on the most impacted pages

URL Structure Changes

If you changed your URL structure (e.g., from /blog/2024/01/my-post to /blog/my-post), make sure every old URL has a corresponding redirect. Use your pre-migration crawl data to build a complete list.

A common mistake with headless CMS migrations is changing the slug format. If your old CMS generated slugs with dates and your new one doesn't, you need redirects for every single post.

Technical SEO Recovery Steps

Here's the systematic recovery process I follow:

1. Fix All Crawl Errors

In Google Search Console, go to Pages > Not Indexed and fix every "Not found (404)" and "Soft 404" error. Prioritize pages that had traffic before the migration.

2. Resubmit Your Sitemap

Remove the old sitemap from Search Console and submit the new one. Then use the URL Inspection tool to request indexing for your most important pages.

One of the most overlooked migration issues is broken internal links. Your old site might have had hundreds of internal links pointing to old URLs. If those URLs now redirect, you're passing link equity through redirects unnecessarily.

Update all internal links to point directly to the new URLs:

// A script to find old URLs in your content
const glob = require('glob');
const fs = require('fs');

const oldDomain = 'old-site.com';
const files = glob.sync('src/**/*.{md,mdx,jsx,tsx}');

files.forEach(file => {
  const content = fs.readFileSync(file, 'utf8');
  if (content.includes(oldDomain)) {
    console.log(`Found old domain reference in: ${file}`);
  }
});

4. Restore Structured Data

If your old site had schema markup (Product, Article, FAQ, BreadcrumbList), make sure it's replicated on the new site. Lost structured data means lost rich snippets, which means lower CTR, which means less traffic.

5. Verify Canonical Tags

Every page should have a self-referencing canonical tag pointing to its own URL. Check that canonical tags aren't pointing to old URLs or the staging domain.

<!-- This should point to the current page's URL -->
<link rel="canonical" href="https://yoursite.com/current-page" />

6. Check Hreflang Tags (If Multilingual)

If your site serves multiple languages or regions, broken hreflang tags after migration can cause major traffic loss in international markets.

Performance and Core Web Vitals

One of the main reasons teams migrate to modern frameworks is better performance. But sometimes the opposite happens.

Client-Side Rendering Pitfalls

If you migrated to a React SPA without server-side rendering, Googlebot might struggle to see your content. Google has gotten better at rendering JavaScript, but it's still not perfect. Rendering happens in a second wave of indexing, which means your content takes longer to appear in search results.

This is why we strongly recommend SSR or SSG for content-heavy sites. Next.js with App Router gives you server components by default. Astro renders everything to static HTML unless you opt into client-side interactivity.

Core Web Vitals Comparison

Run a before/after comparison using CrUX data or PageSpeed Insights:

Metric Pre-Migration Post-Migration Target
LCP 2.1s ? < 2.5s
INP 180ms ? < 200ms
CLS 0.05 ? < 0.1
TTFB 800ms ? < 800ms

If your post-migration metrics are worse, that's likely contributing to the ranking drop. Fix performance issues first -- they compound every other problem.

Timeline: What Recovery Actually Looks Like

Let me set realistic expectations. Based on migrations we've handled:

Scenario Expected Recovery Time
Only technical issues (robots.txt, noindex) 1-2 weeks after fix
Redirect issues on a small site (<500 pages) 2-4 weeks
Redirect issues on a large site (5000+ pages) 4-8 weeks
Content changes + URL changes 6-12 weeks
Domain change 8-16 weeks
Multiple compounding issues 3-6 months

The recovery curve isn't linear. You'll often see a sharp dip, then a plateau, then a gradual climb back. Some pages recover faster than others. High-authority pages with strong backlink profiles tend to bounce back first.

When to Worry

If you haven't seen any improvement after 8 weeks with all fixes in place, something deeper is wrong. At that point, consider:

  • A professional SEO audit
  • Whether Google is treating the migration as a site quality change
  • Whether you lost significant backlinks during migration
  • Reaching out to our team for a migration recovery assessment

Preventing Traffic Loss in Future Migrations

Prevention is always better than recovery. Here's our pre-migration SEO checklist:

Before Migration

  1. Full crawl of the existing site -- Save every URL, its title, meta description, canonical tag, structured data, and internal links
  2. Redirect map -- Every old URL mapped to its new destination
  3. Content freeze -- Don't change content during migration
  4. Benchmark current performance -- Save Search Console data, rankings, and Core Web Vitals
  5. Test redirects on staging -- Verify every redirect before going live
  6. Check robots.txt and meta robots -- Ensure production config allows crawling

During Migration

  1. Deploy during low-traffic hours
  2. Verify redirects immediately after launch
  3. Submit new sitemap to Search Console within hours
  4. Monitor crawl stats in real-time

After Migration

  1. Monitor Search Console daily for the first 2 weeks
  2. Run a full site audit 48 hours post-launch
  3. Check ranking positions for your top 50 keywords daily
  4. Fix any issues within 24 hours of discovery

If you're planning a migration to a headless architecture, our pricing page outlines what's included in our migration packages -- including the SEO preservation work that most agencies skip.

FAQ

How long does it take to recover traffic after a website migration?

Most sites recover within 4-8 weeks if the issues are identified and fixed quickly. Simple technical problems like a blocking robots.txt or noindex tags can be resolved in days, with traffic returning within 1-2 weeks. More complex issues involving URL structure changes, content modifications, or domain changes can take 3-6 months for full recovery. The key factor is how quickly you diagnose and fix the root cause.

Is it normal to lose traffic after a site migration?

Yes, a temporary dip of 10-20% is completely normal, even with a well-executed migration. Google needs time to recrawl, reindex, and reassess your site. This processing period typically lasts 2-4 weeks. What's not normal is a drop exceeding 30% or a decline that doesn't show any signs of recovery after 6 weeks. If you're seeing those patterns, there's likely a technical issue that needs fixing.

Should I use 301 or 302 redirects for a site migration?

Always use 301 (permanent) redirects for site migrations. A 301 tells Google that the move is permanent and to transfer ranking signals to the new URL. A 302 (temporary) redirect tells Google to keep the old URL in its index, which defeats the purpose of migration. The only exception is if you genuinely plan to move the content back to the original URL -- which almost never applies during a migration.

Can changing my CMS cause rankings to drop?

Changing your CMS itself doesn't cause ranking drops -- but the side effects of a CMS change often do. Different CMSes generate different URL structures, HTML markup, internal linking patterns, and page load characteristics. If your new CMS produces different URLs without proper redirects, strips structured data, changes your content structure, or renders content client-side instead of server-side, you'll likely see a traffic impact.

How do I know if Googlebot can see my new site correctly?

Use Google Search Console's URL Inspection tool. Enter any page URL and click "Test Live URL." Google will show you exactly what Googlebot sees, including the rendered HTML. If important content is missing from the rendered output, you have a JavaScript rendering issue. You can also check the "Crawl Stats" report in Search Console to see if Googlebot's crawl rate has changed since migration.

Will I lose my backlinks after migrating to a new website?

You won't lose your backlinks if you implement proper 301 redirects from old URLs to new ones. The backlinks will still point to the old URLs, but the redirects will pass link equity to the new pages. However, it's worth reaching out to sites with your most valuable backlinks and asking them to update the URLs directly -- this eliminates the redirect hop and ensures maximum link equity transfer.

Should I change my URL structure during a migration?

Ideally, no. Keeping the same URL structure eliminates the need for redirects entirely, which is the safest approach for SEO. If you must change URLs (for example, removing date-based paths or restructuring categories), make sure you have a complete redirect map covering every single old URL. Never change URLs without corresponding 301 redirects.

What tools should I use to monitor traffic recovery after migration?

Google Search Console is your primary tool -- it shows you exactly how Google sees your site. Pair it with Google Analytics 4 for traffic monitoring, Screaming Frog or Sitebulb for technical crawling, Ahrefs or Semrush for ranking tracking, and PageSpeed Insights for performance monitoring. Check these tools daily for the first two weeks after migration, then weekly until traffic stabilizes.