Website migrations are the highest-risk SEO project a B2B SaaS company runs. A clean migration preserves rankings, traffic, and pipeline contribution through the transition. A poorly executed migration drops 20 to 60 percent of organic traffic and takes 4 to 9 months to recover, if the recovery happens at all.
B2B SaaS sites migrate more often than most B2B verticals because the brand, the product, and the marketing site evolve faster. Rebrands after Series B funding rounds, platform changes from WordPress to Webflow or headless CMS, URL restructures driven by product taxonomy updates, domain changes after acquisitions or rebranding. Each migration type has specific failure modes that generic migration checklists do not address. This is the operator framework for preserving rankings through a B2B SaaS migration: the pre-migration baseline, URL mapping methodology, redirect strategy, technical preparation, migration-day execution, the 90-day monitoring window, and the recovery playbook for migrations that go wrong.
01 / Why B2B SaaS sites get migrated so often
B2B SaaS sites migrate more frequently than B2B sites in most other verticals. Five migration types account for the majority of B2B SaaS site moves.
Five migration drivers
Driver 1, rebrand after funding round. Series B and Series C funding typically triggers a brand refresh including new visual identity, new positioning, and frequently a new domain name. The migration scope covers the brand, the marketing site, and sometimes the product application URLs.
Driver 2, platform change. WordPress to Webflow, Webflow to a headless CMS (Contentful, Sanity, Strapi), or any other CMS migration. The URL structure usually changes during the platform migration because the new platform has different conventions for slugs, taxonomy, and permalinks.
Driver 3, URL restructure for product taxonomy alignment. The product adds new categories or restructures existing categories, and the marketing site URLs need to align with the new taxonomy.
Driver 4, domain change after acquisition. The company gets acquired and consolidates onto the parent company's domain. Or the company acquires another vendor and consolidates that vendor's marketing site into its own domain.
Driver 5, marketing site separation from product. The marketing site splits from the product application infrastructure, often moving from a shared domain (app.company.com plus company.com) to a clearly separated marketing-first domain with the product on a subdomain. This connects to the broader technical SEO sub-pillar covering the discipline.
02 / The pre-migration baseline
The baseline is the comprehensive snapshot of the current site's SEO state, captured 30 to 60 days before the migration. Programs that skip the baseline have nothing to compare against when traffic drops post-migration.
What to document
Rankings. Pull the full ranked-keyword export from Ahrefs or Semrush plus the Search Console performance report. Capture position, search volume, and URL for every keyword ranking in positions 1 to 50.
Traffic. Pull GA4 sessions by URL for the trailing 90 days. Document the top 500 URLs by traffic with traffic volume per URL.
Backlinks. Pull the full backlink export from Ahrefs or Majestic. Document every URL receiving 5 or more referring domains because these need redirect preservation specifically.
Internal linking. Crawl the site with Screaming Frog or similar. Document the internal linking graph because the new site needs to preserve the highest-leverage internal links.
Indexing. Pull the indexing report from Search Console showing currently indexed URLs. Compare against the sitemap.
Why the baseline matters
When traffic drops post-migration, the team needs to diagnose which specific URLs lost rankings, which specific keywords dropped, and whether the loss is concentrated or distributed. Without a baseline, the team is debugging blind. With a baseline, the team can identify the affected URLs within hours rather than weeks. Google's Search Central documentation on site moves with URL changes covers the baseline documentation pattern from the search engine's perspective.
03 / URL mapping methodology
URL mapping is the work of defining the destination URL on the new site for every URL on the old site. This is the single most important migration deliverable.
Three mapping approaches
Approach 1, manual mapping for high-value URLs. The top 200 to 500 URLs by traffic and backlinks get manual mapping from a human who understands the content. Manual mapping catches the cases where the content has no exact equivalent on the new site and requires a judgment call.
Approach 2, pattern-based mapping for long-tail URLs. The next tier of URLs (typically several thousand) follows pattern-based mapping: "/blog/[slug] becomes /insights/[slug]" or "/products/[name] becomes /solutions/[name]". The pattern handles 80 to 90 percent of the remaining URLs cleanly.
Approach 3, default-to-relevant-parent for everything else. URLs that do not match any pattern and do not warrant manual mapping redirect to the nearest relevant parent page (the sub-pillar, the category page, or the homepage as last resort).
What to avoid
Default-to-homepage for any significant traffic URL. This destroys the page-level ranking signal that the redirect should have transferred. Multi-step redirect chains (URL A to URL B to URL C). Google handles 1 to 2 redirect hops cleanly; 3+ hops degrade signal transfer. Mapping URLs to pages that do not yet exist on the new site. The destination must exist before the redirect goes live.
04 / The redirect strategy
Redirects implement the URL mapping. The redirect strategy covers which status codes to use, how to handle pattern-based redirects, and how to verify the redirects work correctly.
301 versus 302
301 redirects signal permanent moves. Google transfers ranking signal from the old URL to the new URL across a 301. This is the default for every migration redirect. 302 redirects signal temporary moves. Google may transfer some signal but does not treat the new URL as the replacement. Google's documentation on 301 redirects covers when each status code is appropriate.
For migrations, 301 is correct in almost every case. 302 is correct only when the move is genuinely temporary (a/b testing, scheduled maintenance) and the original URL will return. Programs that default to 302 because the team is unfamiliar with HTTP status code semantics lose ranking authority that should have transferred.
Pattern-based redirect implementation
Most migrations include thousands of redirects. Implementing each as a hardcoded rule is impractical. Pattern-based redirects using regular expressions or wildcards handle the long-tail efficiently. The implementation runs in the web server config (nginx, Apache), the CDN (Cloudflare, Fastly), or the hosting platform (Vercel, Netlify) depending on infrastructure.
Verification
Every redirect gets verified before going live: source URL returns 301, destination URL returns 200, no redirect chain longer than 1 hop. Verification typically runs as an automated check across the full URL list. Manual spot-checks confirm the high-value redirects work correctly in production.
05 / Technical preparation
Beyond URL mapping and redirects, several technical components need explicit migration handling. Programs that miss any one introduce migration-day issues that compound the redirect risk.
Sitemap updates
The new sitemap must reflect the new URL structure. Submit the new sitemap to Search Console on migration day. Keep the old sitemap accessible for 30 to 60 days post-migration so Google can crawl old URLs and discover their redirects.
Robots.txt review
The robots.txt file on the new site must allow crawling of all URLs that should be indexed. The most common migration mistake: launching with robots.txt blocking all crawlers because the file was copied from a staging environment without adjustment.
Internal linking
Internal links throughout the site point to old URLs. These produce redirect chains when followed, which works but is inefficient. The discipline is updating internal links to point directly to the new URLs after migration. This work runs in the 30 days post-migration as the team finds and updates old-URL references in published content.
Structured data and schema
Schema markup needs review on migration. Article schema mainEntityOfPage URLs, BreadcrumbList URLs, and any other URL-bearing schema properties get updated to the new URL structure. The integration with the broader B2B SaaS technical SEO checklist covers the schema audit pattern in depth.
Canonical tags
Every page on the new site needs a canonical tag pointing to its own new URL. The most common migration mistake: canonical tags still pointing to the old URLs because the templating logic was not updated.
06 / Migration day execution and the first 72 hours
Migration day execution is the operational moment when the new site goes live, the redirects activate, and the team monitors for issues. The 72-hour window after migration day is where the worst issues surface.
Hour 0 to 4
Deploy the new site. Activate the redirects. Submit the new sitemap to Search Console. Submit the change of address in Search Console if the domain changed. Confirm DNS propagation completes. Verify the top 50 URLs by traffic redirect correctly to their mapped destinations.
Hour 4 to 24
Crawl the new site with Screaming Frog or equivalent. Surface any broken internal links, missing pages, 404s, or redirect chains longer than 1 hop. Fix critical issues in real time.
Hour 24 to 72
Monitor Search Console for indexing errors, crawl errors, and manual actions. Monitor analytics for traffic anomalies. Verify the top 200 URLs by historical traffic show traffic on the new URLs. Most issues that affect rankings surface in this window if they are going to surface at all.
What to do if traffic crashes
A 30 to 50 percent traffic drop on day 1 is often normal as Google discovers and processes the migration. A 70+ percent drop on day 1 signals a configuration error (robots.txt blocking, canonical tags broken, redirects not activated). Diagnose the configuration error before considering rollback.
07 / Post-migration monitoring, the 90-day window
Rankings on the new site reach their new baseline within 60 to 90 days for most migrations. The monitoring discipline during this window catches issues and avoids panic-driven rollbacks.
Weeks 1 to 4
Daily checks on Search Console for indexing status, crawl errors, and manual actions. Daily traffic monitoring with comparison against the pre-migration baseline. Weekly ranking checks on the top 50 target keywords.
Weeks 5 to 8
Weekly checks on Search Console and analytics. Monthly comprehensive ranking review against the pre-migration baseline. The 30-to-60-day window typically shows the first signs of recovery if there were initial issues.
Weeks 9 to 12
Comprehensive 90-day review against the pre-migration baseline. Compare rankings, traffic, and pipeline contribution on the new URLs to the old URLs in the equivalent period last year. The comparison identifies any specific URLs that did not recover and require additional remediation.
The patience discipline
The biggest mistake programs make in the 90-day window is rolling back the migration at week 2 because traffic is down 40 percent. Most migrations recover 80 to 95 percent of pre-migration traffic within 90 days. Rollbacks before week 6 cause more damage than the original migration. This integrates with the broader B2B SaaS SEO maturity model that frames migration risk within the longer-term program trajectory.
08 / Common failure patterns and recovery playbook
Five failure patterns recur across B2B SaaS migrations. Each has a specific corrective discipline.
Failure 1, 302 instead of 301
The migration uses 302 redirects throughout, signaling temporary moves. Google does not transfer ranking signal cleanly. Recovery: change all redirects to 301 immediately. Rankings recover over 30 to 60 days as Google reprocesses the redirects with correct status codes.
Failure 2, redirect chains
Old URL redirects to intermediate URL redirects to new URL. Ranking signal degrades across each hop. Recovery: audit redirect chains and collapse them to single-hop redirects. The audit takes 4 to 8 hours; the recovery from the fix takes 30 to 45 days.
Failure 3, default-to-homepage redirects
URLs with no clear mapping all redirect to the homepage. Page-level ranking signal destroyed for those URLs. Recovery: re-map the affected URLs to relevant parent pages or category pages. Ranking recovery takes 60 to 90 days for the re-mapped URLs.
Failure 4, broken canonical tags
The new site's canonical tags point to old URLs because the templating was not updated. Google treats the new pages as duplicates of the old pages. Recovery: fix the canonical tags in the templating layer. The fix propagates within hours; ranking recovery follows within 14 to 28 days.
Failure 5, robots.txt blocking
The new site's robots.txt blocks crawling of pages that should be indexed. The new site does not get crawled or indexed. Recovery: fix the robots.txt immediately. The site re-enters the index within 3 to 7 days for most pages.
09 / FAQ
These are the questions B2B SaaS marketing and technical leads ask most often about preserving SEO through a website migration.
How long does a B2B SaaS website migration usually take?
End-to-end migration projects for B2B SaaS sites typically run 6 to 12 weeks from baseline documentation through 90-day post-migration monitoring. The active build and execution phase runs 4 to 6 weeks; the baseline phase before and the monitoring phase after add the remaining time.
What percentage of traffic should we expect to lose?
A well-executed migration loses 5 to 15 percent of organic traffic in the first 30 days and recovers to baseline within 60 to 90 days. A poorly executed migration loses 30 to 60 percent in the first 30 days and may take 6 to 12 months to recover, with some URLs never fully recovering. The pre-migration baseline plus thorough URL mapping plus correct redirect implementation determines which outcome occurs.
Should we time the migration around algorithm updates?
Yes when possible. Migrating during a known core algorithm update adds variability that complicates diagnosis if rankings drop. Schedule migrations between known core update windows. Google announces core updates publicly through the Search Status Dashboard, which provides the timing reference.
Do we need to keep the old domain after a domain change?
For 6 to 12 months minimum. The old domain continues to receive inbound links, direct traffic, and Google crawl activity for many months after the move. Maintaining the redirects on the old domain during this window preserves the signal transfer to the new domain. After 12 months, the redirect traffic should be minimal and the old domain can be retired.
How do we handle the Search Console change of address?
The change of address tool in Search Console is the formal signal to Google that one domain replaces another. Use it for domain changes (company.com to newcompany.com) but not for URL restructures within the same domain. The tool requires verification of both domains and processes the change within hours. Google's documentation on the change of address process covers the verification requirements.
What is the difference between a migration and a redesign?
A redesign changes the visual design and possibly the content structure of the site without changing URLs. A migration changes the URLs (and often the underlying platform). Redesigns rarely affect SEO if URLs remain stable. Migrations always carry SEO risk because URLs change. The discipline in this post applies to migrations, not redesigns, although the pre-migration baseline documentation is useful for both.
Rizwan Khan
