A site migration is one of the few moments in a B2B marketing calendar where a single planning gap can erase years of organic growth in a matter of weeks. Rebranding, replatforming off a legacy CMS, consolidating multiple regional sites, or merging a newly acquired company’s domain into the parent brand are all normal business events. The organic traffic loss that so often follows them is not. It is almost always a redirect mapping failure, not an algorithm penalty, and it is entirely preventable with a documented process run in the right order.
Google’s own site move documentation is explicit that a migration is expected to cause temporary ranking fluctuation while its systems re-crawl and re-index the new URLs, and that the size of the disruption is directly tied to how complete the redirect map was at cutover.1 For a B2B SaaS, fintech, or e-commerce site where organic search is a primary pipeline source, that makes the redirect map the single highest-stakes document in the entire project, not a task to hand off at the last minute to whoever is doing the technical build.
The Migration Integrity Stack: a 5-layer framework
This is the sequence we run for any client migration, whether it is a full replatform, a domain consolidation after an acquisition, or a subdirectory restructure. Each layer has a specific artifact it produces, and skipping a layer to save time is exactly where the traffic loss comes from.
Layer 1: baseline capture
Before anything on the new site goes live, crawl the entire existing site and export the results alongside a ranking snapshot for your tracked keyword set, a full backlink export, and the exact indexed URL count from Search Console. This baseline is what every later reconciliation check gets compared against, and teams that skip it are the ones arguing weeks later about whether traffic actually dropped or whether it just feels lower. Pull server logs for the two weeks prior as well; they show you which URLs Googlebot is actually still requesting, including old paths that stopped appearing in your CMS years ago but are still receiving crawler hits from external links.
Layer 2: redirect map construction
Build a single spreadsheet with one row per old URL that has any indexed history, backlinks, or ranking presence, and map it to the exact new URL that replaces it. A page being retired with no direct replacement should redirect to the most topically relevant surviving page, never to the homepage as a default; a blanket homepage redirect signals to Google that the specific content is simply gone, which is functionally the same as a 404 for ranking purposes. Keep every redirect a single hop from old URL to final destination. Google’s crawlers will follow up to ten redirect hops, but each additional hop adds latency and dilutes the signal, and Google’s own guidance is to avoid chaining redirects entirely.2
Layer 3: staging verification
Crawl the staging environment against the finished redirect map before cutover, not after. Confirm every mapped source URL actually resolves to its intended destination with a single 301, that canonical tags on the new templates point to the correct new URLs rather than defaulting to a staging domain, and that structured data and hreflang tags, if the site serves multiple regions or languages, carried over from the old templates. This is also the point to confirm the staging robots.txt is not accidentally left in place after launch, which we have seen block an entire new site from indexing for weeks after an otherwise flawless migration.
Layer 4: cutover and signal submission
For a same-domain restructure, cutover means the DNS or CDN change, immediately followed by submitting an updated XML sitemap covering only the new URL structure. For a domain change, every affected property, including www and non-www variants of the old domain, needs a Change of Address submission in Search Console; this is now an explicit requirement in Google’s own site move documentation rather than a nice-to-have.1 On a large site, Google’s own recommendation is to move in sections where technically possible, since a phased rollout makes it far easier to isolate which change is causing an unexpected drop rather than diagnosing everything at once.1
Layer 5: reconciliation windows
Set four fixed check-in points from day one: day 14, day 30, day 90, and day 365. At each point, compare indexed URL count, ranking position for your tracked keyword set, and 404 or soft-404 hit rate in server logs against the layer 1 baseline. Search Engine Journal’s own migration recovery guidance points to four to twelve weeks as the typical stabilization window for a well-executed move with no domain change, with John Mueller citing a similar four-to-twelve-week range depending on site size and scale.3 The day 365 check-in exists for one specific decision: whether to sunset the redirects. Google recommends keeping redirects in place for a minimum of one year, since its systems need to see a URL change confirmed across several recrawl cycles before treating it as permanent.4
Subdomain vs. subdirectory: a decision most migrations force
Almost every replatform or rebrand raises the same structural question at least once, usually for docs, a blog, or a help center: should this section live on a subdomain or in a subdirectory of the primary domain. The two are not interchangeable from an SEO standpoint, even though they can look identical to a site visitor.
The default should be a subdirectory whenever there is no hard technical constraint forcing a split, since it keeps every backlink and ranking signal reinforcing one root domain instead of splitting authority across two properties that Google evaluates somewhat independently. A subdomain is the right call when a section genuinely cannot share infrastructure with the marketing site, most commonly a documentation platform like a hosted knowledge base tool or an application login, but that decision should be made deliberately during layer 2 of the migration, not discovered after launch when the redirect map is already built around the wrong assumption.
What a reconciliation report actually looks like
Stakeholders outside the SEO team rarely want a spreadsheet of redirect hit codes; they want to see whether the migration is on track against the baseline. The mockup below illustrates the format we build for a day-30 reconciliation check. The numbers are invented for illustration and are not drawn from any real client account.
Why the stakes are higher for B2B SaaS, fintech, and e-commerce
A consumer content site can often absorb a rough migration and recover on its own timeline with limited business impact. A B2B SaaS company where organic search feeds a meaningful share of demo requests, a fintech platform where a compliance-driven rebrand forces a domain change, or an e-commerce catalog where category and product pages carry years of accumulated backlinks and reviews cannot afford the same wait-and-see approach. Search Engine Journal’s guidance on migration recovery is direct on this point: unresolved technical issues, not an algorithmic penalty, are what stretch a recovery from a matter of weeks into a matter of quarters, and the fix is almost always found in the redirect map or in structured data and canonical tags that did not survive the move.3 Running the Migration Integrity Stack in order, with a real baseline and a verified redirect map before cutover, is what keeps a migration a routine infrastructure project instead of an unplanned quarter of traffic recovery.
If your team is planning a replatform, domain consolidation, or CMS migration and wants a second set of eyes on the redirect map before cutover, our site migration team runs the full baseline-to-reconciliation process alongside in-house engineering teams. For a broader look at the technical foundation issues that tend to surface during a migration audit, see our technical SEO audit checklist for B2B SaaS, and if you want a fast read on where your site’s crawlability and AI citation visibility stand right now, a GEO audit covers both in one pass.
Frequently asked questions
What should be on an SEO migration checklist?
A real SEO migration checklist has five stages: capture a full baseline of the old site before anything changes (crawl, log files, rankings, backlinks), build a one-to-one redirect map for every indexed and backlinked URL, verify that map on staging before cutover, submit the right signals to Google at cutover (Change of Address tool for domain moves, updated sitemap), and run reconciliation checks at fixed intervals afterward. Skipping the baseline or the staging verification step is what turns a routine migration into an unplanned traffic recovery project.
How long should 301 redirects stay in place after a site migration?
Google’s own guidance, reiterated by Search Advocate John Mueller, is to keep redirects in place for at least one year. Google’s systems need to see a redirect multiple times over several recrawl cycles before treating the URL change as permanent, and removing redirects early can cause a ranking drop to resurface on pages Google had not fully migrated yet.
How long does it take to recover organic traffic after a website migration?
A well-executed migration with a complete redirect map and no domain change typically shows recovery within four to twelve weeks, per Google’s own recrawl guidance for medium-sized sites. Migrations that also change domains, restructure URLs at scale, or leave redirect gaps take longer, since Google treats a domain change as a distinct signal that needs its own confirmation cycle. Recovery time is driven almost entirely by how complete the redirect map was at cutover, not by how the migration was announced or timed.
Should a B2B SaaS company use a subdomain or a subdirectory?
A subdirectory (example.com/docs) consolidates all authority signals under one root domain and is the safer default for content types like blogs, docs, and help centers when there is no hard technical reason to separate them. A subdomain (docs.example.com) makes sense when a section runs on genuinely different infrastructure, such as a documentation platform or app that cannot share a codebase with the marketing site, but it is treated more like a distinct entity by search engines and typically takes longer to build independent authority.
What causes the most organic traffic loss during a site migration?
Incomplete or incorrect redirect mapping is the single largest cause, specifically old URLs left with no redirect, redirects pointed at the homepage instead of the most relevant new page, and redirect chains of more than two or three hops. The second most common cause is losing structured data, canonical tags, or internal linking context in the move to a new template or CMS, which can suppress a page’s visibility even when the URL itself redirects correctly.
Do you need to notify Google about a site migration?
For a domain change, yes: Google Search Console’s Change of Address tool should be submitted for every affected property, including www and non-www variants, and this is now an explicit requirement in Google’s own site move documentation rather than an optional step. For a same-domain restructure with no domain change, an updated XML sitemap and a clean redirect map are sufficient; the Change of Address tool only applies when the root domain itself changes.
Sources
1. Google Search Central, “Site Moves With URL Changes,” Google for Developers. ↩
2. Google Search Central, “Redirects and Google Search,” Google for Developers. ↩
3. Search Engine Journal, “Ask An SEO: How Can We Recover A 30% Drop In Organic Traffic From A Site Migration?” ↩
4. Search Engine Journal, “Google: Keep 301 Redirects In Place For A Year,” citing Google Search Central guidance and Search Advocate John Mueller. ↩
Share this article
Ryan Brooks leads technical SEO at MV3 Marketing, specializing in schema architecture, entity graphs, crawlability, and the structural signals that determine whether AI answer engines cite a page.
Ready to audit your organic growth opportunity?
$2,500 flat. 5 business days. Six deliverables tied to pipeline , not rankings. No retainer required.
Get the Organic Growth Audit →