Website Migration SEO for SaaS: How to Switch Platforms Without Losing Rankings

Every SaaS company eventually outgrows its website platform. The redesign looks incredible. The new tech stack is faster. Then you launch — and organic traffic drops 40%. We've audited 70+ funded SaaS sites and seen the aftermath of botched migrations. Here's how to do it right.

Why Website Migrations Go Wrong

Here's the uncomfortable truth: most SaaS website migrations are led by design or engineering teams who don't think about SEO until it's too late. The conversation goes like this:

• Week 1: "We're redesigning the site! New platform, new look, new everything."
• Week 8: "It looks amazing. Ship it."
• Week 10: "Why did our organic traffic drop 50%?"
• Week 14: "Can someone call an SEO person?"

By week 14, the damage is done. Google has crawled the new site, found hundreds of broken URLs, and dropped your rankings. The backlinks pointing to your old URLs? They're hitting 404 pages. Your carefully optimized meta tags, schema markup, and internal links? Gone — replaced by whatever the new platform generated by default.

Types of Website Migrations (And Their Risk Levels)

Not all migrations are equal. Here's how they stack up by SEO risk:

The rule: change as few things as possible at once. If you're switching from WordPress to Next.js, keep the same URLs. If you're also rebranding, do the platform migration first, stabilize rankings, then do the domain migration separately. Stacking changes multiplies risk.

Before Migration: The SEO Baseline

Before you change anything, document exactly what you have. This baseline is your insurance policy — if something goes wrong, you need to know what "normal" looked like.

1. Crawl the entire current site

Use Screaming Frog, Sitebulb, or even a simple script to get every URL on your current site:

# Get all URLs from sitemap
curl -s https://yoursite.com/sitemap.xml | grep -oP '<loc>\K[^<]+'

# Or crawl with wget
wget --spider -r -nd -nv https://yoursite.com 2>>&1 | grep '^--' | awk '{print $3}'

For each URL, record:

• Full URL path
• HTTP status code (200, 301, etc.)
• Title tag
• Meta description
• H1 tag
• Canonical tag
• Word count
• Internal links (count and destinations)
• Organic traffic (from Google Analytics or Search Console)

2. Export Google Search Console data

Download the last 16 months of data from Search Console:

• Performance: Queries, pages, clicks, impressions, CTR, position
• Coverage: Indexed pages, excluded pages, errors
• Links: External links, internal links, top linking sites
• Core Web Vitals: LCP, FID/INP, CLS scores

3. Map your backlink profile

Use Ahrefs, Moz, or Google Search Console to export every external link pointing to your site. Group by:

• Landing page (which URLs have the most backlinks)
• Referring domain authority
• Anchor text

4. Screenshot key SERP positions

For your top 20 ranking keywords, screenshot the search results showing your current position. This gives you visual proof of where you stood before the migration — useful for diagnosing problems later.

The 301 Redirect Map — Your Most Important Document

If you do nothing else from this guide, do this: create a complete 1-to-1 redirect map from every old URL to its new equivalent.

A redirect map is a spreadsheet with two columns:

Rules for redirect maps

1. Every old URL gets a redirect. No exceptions. Even pages you're removing should redirect to the most relevant remaining page (not the homepage).
2. Match intent, not just topic. If /features/analytics talked about your analytics dashboard, redirect it to the new page that covers your analytics dashboard — not to a generic features overview.
3. Use 301s, not 302s. A 301 is permanent and passes ranking signals. A 302 is temporary and doesn't. This is the most common mistake.
4. No redirect chains. Old URL → New URL. One hop. If old URL → intermediate URL → final URL, collapse it to old URL → final URL.
5. Keep redirects forever. "We'll remove the redirects after 6 months" is a myth. Backlinks from 2019 still point to old URLs. Keep the redirects as long as the domain exists.

How to implement redirects

Next.js (in next.config.js):

module.exports = {
  async redirects() {
    return [
      {
        source: '/old-page',
        destination: '/new-page',
        permanent: true, // 301
      },
      {
        source: '/blog/:slug',
        destination: '/articles/:slug',
        permanent: true,
      },
    ]
  },
}

Vercel (in vercel.json):

{
  "redirects": [
    { "source": "/old-page", "destination": "/new-page", "permanent": true },
    { "source": "/blog/:path*", "destination": "/articles/:path*", "permanent": true }
  ]
}

Nginx:

# Single redirect
rewrite ^/old-page$ /new-page permanent;

# Pattern redirect
rewrite ^/blog/(.*)$ /articles/$1 permanent;

WordPress (.htaccess):

Redirect 301 /old-page /new-page
RedirectMatch 301 ^/blog/(.*)$ /articles/$1

Content Migration: What to Keep, Cut, and Consolidate

A migration is the perfect time to audit your content — but resist the urge to delete everything that isn't performing. Here's the decision framework:

Keep (migrate 1:1)

• Pages with organic traffic (any amount)
• Pages with backlinks from external sites
• Pages that rank for target keywords (even if not #1)
• Core pages: homepage, pricing, product, about, contact

Consolidate (merge into stronger page)

• Multiple thin pages covering the same topic → one comprehensive page
• Old blog posts that overlap with newer, better versions
• Feature pages for deprecated features → redirect to current feature page

Cut (redirect to relevant page, then remove)

• Pages with zero traffic AND zero backlinks for 12+ months
• Duplicate content (printer-friendly versions, AMP copies)
• Temporary campaign landing pages that expired

Technical SEO Parity Checklist

Your new site must match or exceed the old site on every technical SEO element. Here's what to verify before launch:

Launch Day: The Migration Sequence

Don't just flip a DNS switch and hope. Follow this sequence:

T-24 hours

1. Final crawl of old site — confirm baseline is current
2. Test all redirects on staging environment
3. Verify new sitemap is ready (not yet submitted)
4. Confirm Google Search Console access for new site
5. Notify team: "Migration happens tomorrow at [time]. Expect [X] hours of transition."

Launch (T-0)

1. Deploy new site
2. Activate 301 redirects (verify with curl -sI old-url — should return 301 + Location header)
3. Submit new XML sitemap to Google Search Console
4. Use Google Search Console's "Request Indexing" on your top 10 pages
5. If domain change: submit Change of Address in Search Console
6. Test 20 random old URLs — verify they redirect correctly

T+1 hour

1. Check robots.txt is serving correctly (not blocking Googlebot)
2. Verify no noindex tags on the new site
3. Test mobile rendering
4. Check page speed on key pages
5. Verify analytics is tracking

T+24 hours

1. Check Google Search Console for crawl errors
2. Review server logs for 404s from Googlebot
3. Spot-check rankings for top 10 keywords
4. Verify all internal links point to new URLs (no internal redirect chains)

Post-Migration: The 90-Day Monitoring Plan

The migration isn't done when the new site is live. The real work is the 90 days after.

Week 1: Daily monitoring

• Google Search Console: crawl errors, indexing status, coverage report
• Organic traffic vs. baseline (expect a 10-20% dip — this is normal)
• Ranking positions for top 20 keywords
• Server logs: 404 errors from Googlebot (= missed redirects)

Weeks 2-4: Weekly check-ins

• Index coverage: are new URLs being indexed? Are old URLs being removed?
• Ranking recovery: are positions returning to baseline?
• Backlink check: are referring domains resolving correctly through redirects?
• Fix any new 404s that appear (Googlebot finds URLs you missed)

Months 2-3: Bi-weekly assessment

• Compare organic traffic to pre-migration baseline
• Identify pages that haven't recovered — investigate and fix
• Check redirect performance (are redirects adding latency?)
• Look for cannibalization: old indexed URLs competing with new ones

8 Migration Mistakes That Kill SaaS Rankings

1. No redirect map

"We'll figure out redirects after launch." By then, Google has already crawled your 404 pages. Every day without redirects is a day your rankings bleed. Build the redirect map before you write a single line of new code.

2. Using 302 redirects instead of 301

302 means "temporary" — Google keeps the old URL in its index, waiting for it to come back. 301 means "permanent" — Google transfers the ranking signals to the new URL. Check with: curl -sI old-url | grep "HTTP/". You want to see 301.

3. Redirecting everything to the homepage

Lazy redirect: all old URLs → homepage. Google treats this as a soft 404. You lose all page-specific ranking signals. Every old URL must redirect to its most relevant new equivalent. Yes, even if you have 500 URLs to map.

4. Changing URLs unnecessarily

New platform, new URL structure — right? Wrong. If /blog/seo-guide was working fine, keep it as /blog/seo-guide on the new platform. Every URL change is a risk, even with perfect redirects. Change URLs only when the current structure is genuinely harmful.

5. Forgetting internal links

You set up redirects for external traffic, but your own site still links to old URLs internally. Every internal link through a redirect is a wasted crawl and a speed hit. Update all internal links to point directly to new URLs — no redirect chains within your own site.

6. Launching on Friday

If something goes wrong on a Friday migration, you don't discover it until Monday — and by then, Google has spent 72 hours crawling a broken site. Migrate Tuesday through Thursday, morning, when your team is available to fix issues immediately.

7. Not preserving meta tags

The new site uses the new platform's default title tags and meta descriptions. All your carefully optimized SEO metadata is gone — replaced by auto-generated defaults. Export old meta tags in your baseline and manually apply them to the new site.

8. Skipping the staging test

You can't test redirects after they're live. Set up a staging environment that mirrors the production redirect configuration. Test every redirect. Test rendering. Test page speed. Test schema. The 2 hours you spend testing saves 2 months of recovery.

Platform-Specific Migration Guides

We've written detailed guides for the most common SaaS platform migrations:

Regardless of which platforms you're moving between, the principles in this guide apply. Baseline → Redirect map → Technical parity → Monitor.

Complete Migration SEO Checklist

Frequently Asked Questions

Related Guides

• Technical SEO Checklist for SaaS Companies
• Next.js SEO: Why Your SaaS Website Isn't Getting Indexed
• Webflow SEO: 9 Issues We Find in Every Audit
• WordPress SEO: 10 Issues Hiding Behind Your Plugins
• Core Web Vitals for SaaS: Speed Optimization Guide
• How to Fix Noindex and Canonical Issues
• SEO Audit Results: 70+ Funded SaaS Sites
• International SEO for SaaS: How to Rank in Multiple Countries