Migration Checklist: What Happens to Your Organic Traffic After Your New Site Goes Live?

What Counts as a Website Migration (and Which Type Are You Planning?)

A website migration is any structural, technical, or design change that alters how search engines crawl, index, or value your site. Before opening a checklist, identify the exact migration type you're executing, as each carries a distinct SEO risk profile.

Most B2B SaaS projects fall into one of three categories:

1. Platform Migration

You move your site from one CMS to another—for example, from WordPress to Webflow or HubSpot CMS to Webflow. Your primary domain stays the same, but underlying URL structures, code bases, page templates, and integrations change.

Subtle platform default changes. Webflow, for instance, requires a folder prefix for CMS collection items (e.g., /blog/post-name), meaning legacy root-level blog post URLs ([domain.com/post-name](https://domain.com/post-name)) cannot maintain a 1:1 path match and must be redirected. Trailing slashes, auto-generated category paths, and plugin-driven schema also frequently break during platform transitions.

2. Domain Migration

You move to a new domain name—typically due to a rebrand, acquisition, or TLD consolidation (e.g., moving regional sites or subdomains to a single root .com). Every single URL changes, requiring every ranking signal and link equity to transfer to a new address.

The Risk: Highest risk scenario. Google must discover, crawl, and re-evaluate every legacy and new URL before treating the move as complete.

3. Redesign Migration

You rebuild the visual design and frontend code on your existing domain and platform. Teams frequently underestimate this scenario. Changing heading hierarchies, consolidating pages, altering internal linking structures, or cutting body copy on ranking pages will trigger re-indexing and ranking shifts even if URLs remain unchanged.

Strive to change one major variable at a time. If your launch combines a rebrand, new domain, new CMS, and a complete content rewrite, you compound risk exponentialy. When organic performance fluctuates, isolating the root cause becomes significantly harder.

The Website Migration Checklist at a Glance

Copy this checklist into Asana, Jira, or Notion, and assign a single owner to each task before kickoff.

Pre-Migration (6 to 8 Weeks Before Launch)

• Name the migration type and assign a single accountable SEO owner.
• Export 12 months of baseline data from Google Search Console and GA4.
• Perform a full crawl of the live site and archive the database/crawl file.
• Rank-track your top 100 to 200 pipeline-driving keywords.
• Complete a content audit: assign Keep, Merge, Redirect, or Remove to every URL.
• Map 301 redirects 1:1 (old URL to new URL) in a master spreadsheet.
• Audit all active forms, scripts, tracking pixels, and MarTech integrations.
• Block the staging environment from search crawlers via basic authentication or IP whitelisting.
• Complete staging QA: metadata, canonical tags, structured data, broken links, and site speed.
• Draft the launch runbook and emergency rollback protocol.

Migration Day

• Lower DNS TTL settings to 300 seconds (24 to 48 hours prior to launch).
• Freeze content updates on the live production site.
• Update DNS records / pointing, and verify SSL certificate activation across all domain variants.
• Deploy 301 redirects and test a representative sample immediately.
• Remove staging blockades (noindex tags, robots.txt blocks, auth gates).
• Conduct end-to-end testing on conversion forms, CRM syncing, and event tracking.
• Submit the new XML sitemap to Google Search Console and Bing Webmaster Tools.

Post-Migration (First 90 Days)

• Crawl the live site and the legacy URL list to catch 404s, chains, or loops.
• Monitor Search Console Indexing and Crawl Stats reports daily in Week 1, then weekly.
• Track keyword rankings and organic traffic against baseline metrics (Days 1, 3, 7, 14, 30, 60, 90); as part of post migration monitoring, expect traffic recovery to take 1 to 5 months after migration.
• Review user feedback after launch to identify issues missed by internal QA.
• Verify form routing and pipeline source attribution in your CRM.
• Update high-value external backlinks, ad destination URLs, and social profiles.
• Keep old URLs and their 301 redirects live for at least one year after migration.

Pre-Migration Checklist: Where Rankings Are Saved or Lost

Most migration failures are decided weeks before DNS is touched. The work completed in the six to eight weeks leading up to launch determines whether go-live week is routine or a crisis.

1. Establish Your Baseline Before Anything Changes

This baseline work supports a successful migration and gives you benchmarks for the migration process. Export and archive the following before development begins:

• Google Search Console: 12 months of performance data broken down by page and search query.
• GA4 / Web Analytics: Organic sessions, conversions, and demo requests segmented by entry landing page, using Google Analytics for benchmarking.
• Crawl Data: A complete site crawl via Screaming Frog or Sitebulb to support the migration plan and migration strategy for the new website.
• Keyword Ranks: Position tracking for your top 100–200 business-critical keywords (including high-intent comparison and product terms).
• Backlink Profile: Export backlink data from Ahrefs or Semrush to identify your highest-authority landing pages.

2. Audit Content and Determine URL Destiny

Content migration is an opportunity to prune dead weight without sacrificing SEO value, but cutting pages without reviewing historical data risks destroying silent traffic drivers. Assign every live URL one of four labels:

1. Keep: Page moves as-is, ideally retaining its exact URL path.
2. Merge: Two or more thin/overlapping pages are consolidated into one comprehensive URL.
3. Redirect: The page is retired, and its equity is passed to a closely related alternative page via 301.
4. Remove: Page has zero traffic, no external backlinks, and no business utility. Serves a 404 or 410 status code.

Retired pages should map to the most relevant new page or be removed cleanly if no equivalent exists. Pruning decisions affect both users and search engines because important web pages may disappear from search results if they are merged or removed carelessly.

Do not judge content solely on traffic. A lower-funnel enterprise page receiving 30 visits a month may be heavily utilized by sales or convert at high rates. Check backlinks and conversions before pruning.

3. Build Your Master 301 Redirect Map

The redirect map is the single most critical asset in a migration. It is a structured sheet mapping every old URL to its exact replacement URL.

Core Mapping Rules:

• 1:1 Mapping: Map each legacy URL to its closest direct equivalent.
• Match Intent: Redirect /pricing-old to /pricing, not to the homepage. Do not redirect every page to the homepage; each old URL should preserve page context by pointing to the most relevant destination. Mass-redirecting legacy URLs to the homepage causes Google to treat them as Soft 404s, dropping transferred page authority.
• Eliminate Chains: Point old URLs directly to the final landing destination. Avoid multi-hop chains (A -> B -> C).

Preserve the original redirect map as the baseline for launch QA and post-launch troubleshooting.

4. Inventory Forms, Tracking, and Integrations

Technical SEO fixes won't save pipeline if lead flow breaks silently. Map out every point where your site connects to your marketing stack:

• Form endpoints (HubSpot, Marketo, Pardot) and hidden routing fields.
• GA4, Google Tag Manager containers, ad conversion pixels, and consent management banners, including any tracking updates needed when domains or subdomains change.
• Scheduling widgets (Chili Piper, Calendly) and live chat widgets.
• Subdomains remaining on legacy hosts (e.g., app.domain.com, docs.domain.com), and document those web properties if they will stay outside the main root domain during migration.

5. Prepare and QA Staging

Build and review the new site on an isolated staging server as part of a cms migration or broader web server migration. Do not rely solely on robots.txt disallows to block indexation, as search engines can still index URLs if they are linked externally. Use password protection (HTTP Basic Auth) or IP whitelisting.

Staging QA Checklist:

• Metadata (Title tags, H1s, Meta descriptions) matches or improves upon baseline URLs.
• Canonical tags are dynamic, absolute, and point to the final production URLs (not staging domains) to help prevent duplicate pages on the new site.
• Structured Data (Schema.org) is ported accurately.
• Internal links update to new canonical paths (eliminating internal links that hit 301 redirects), and update internal links in templates and modules so they point directly to final URLs.
• Page speed and Core Web Vitals performance match or exceed original site benchmarks.

6. Establish Accountability and Emergency Rollback Protocols

Assign explicit owners to every critical line item: DNS management, redirect implementation, technical QA, SEO review, and executive sign-off, with clear escalation paths before launch. Define the rollback criteria: If critical systems fail during launch, what is the exact technical step to point DNS back to the legacy host within 60 minutes?

Migration Day Checklist: The Launch Runbook

Launch day should be execution, not strategic decision-making. Execute these steps in strict sequence.

Pre-Switch Phase

1. Lower DNS TTL: Set TTL (Time to Live) to 300 seconds 24–48 hours prior to launch so DNS record updates propagate globally in minutes rather than hours.
2. Select Window: Schedule launch during off-peak traffic hours (typically Tuesday or Wednesday early morning). Avoid Fridays and campaign launch windows.
3. Freeze Content: Lock the legacy CMS from new edits or blog posts.
4. Assemble Team: Ensure developers, SEO leads, marketing ops, and DNS administrators are on active standby.

Switch Phase

1. Update DNS: Update A/AAAA records or CNAME pointers to route domain traffic to the new host.
2. Verify SSL: Ensure SSL certificates are valid and active for root, www, and secondary protocols.
3. Deploy Redirects: Activate the 301 redirect engine. Sample-check 30–50 core URLs manually, then run an automated crawl over the complete legacy URL sheet.
4. Lift Staging Blocks: Remove password protection, clear temporary noindex directives, and update robots.txt.
5. Verify Canonical Directives: Confirm live pages render canonical tags pointing to target production URLs.

Post-Switch Phase

1. Load your top 20 revenue-critical pages in an incognito window to confirm visual rendering and layout stability.
2. Submit a test conversion through every primary form type and confirm proper routing into your CRM.
3. Inspect GTM Real-Time views to confirm tracking pixels fire accurately.
4. Submit the new XML sitemap index directly inside Google Search Console and Bing Webmaster Tools.
5. Spot-check priority landing pages using GSC’s URL Inspection tool to confirm accessibility and prompt recrawling.

Post-Migration Checklist: The First 90 Days

Search engines migrate sites incrementally. Google must crawl both the legacy redirect source and the new target destination before updating its index—a process taking anywhere from a few weeks to several months depending on site footprint.

Week 1: Error Resolution

• Run a full crawl on both live production URLs and original legacy URLs to confirm zero 404s, 5xx server errors, or redirect loops.
• Review server logs and hosting analytics to catch incoming request traffic hitting unmapped legacy URLs.
• Monitor Google Search Console Crawl Stats for unexpected spikes in response times or crawl errors.
• Verify form submit volumes and lead source values against pre-launch averages.

Weeks 2 to 6: Indexation Tracking

• Track Search Console’s Page Indexing report. Legacy URLs should consistently drop as newly submitted target URLs rise.
• Monitor keyword rank movements weekly, evaluating performance by page type (e.g., product pages vs. blog posts) to prevent overall averages from obscuring localized drops.
• Outreach to key external websites, partners, and media profiles to update high-value backlinks to new domain paths.

Weeks 6 to 12: Recovery Verification

• Compare GA4 organic sessions and goal completions against pre-migration baselines.
• Audit any page group operating >20% below baseline traffic levels to check for content differences, altered header structures, or broken internal links.
• Update advertising destination URLs, email templates, and corporate social handles.

Understanding Normal Traffic Fluctuations

Temporary ranking volatility is standard as search engine indexers process structural changes. For platform switches and redesigns maintaining uniform URL paths, traffic typically stabilizes within 2 to 6 weeks.

Domain migrations require significantly longer re-indexing windows. Research from Salt Agency analyzing over 1,000 domain transitions revealed a median organic recovery timeline of ~304 days. Retaining 301 redirects permanently—and for absolute minimums of 12 months—is required to ensure signal transfer completes.

Technical SEO Reference Guide

When search engines crawl a migrated site, they evaluate multiple signals simultaneously. When these directives align, authority transfers cleanly. When they conflict, indexing delays occur.

1. Redirect Rules

• Use 301 (Permanent) or 308 HTTP status codes. Avoid 302 (Temporary) redirects, which tell search engines not to transfer link authority permanently.
• Ensure 1-hop execution. If URL A redirected to URL B on the old site, update it so URL A points directly to URL C on the new site.
• Account for protocol variants: redirect http://, http://www, and https:// variants to the final secure production path.
• Keep old URLs and their 301 redirects live for at least one year after migration to preserve SEO value and support delayed recrawls.

2. Canonicalization Protocols

• Live pages must contain self-referencing canonical tags pointing to their absolute HTTPS production URL.
• Template canonical directives must be verified to ensure staging domains are fully purged prior to launch.

3. XML Sitemap Strategy

• Ensure the new XML sitemap contains only live, canonical, indexable 200-status URLs on the new site.
• Remove outdated URLs from XML sitemaps before you submit the updated sitemap index in Search Console.
• Domain Migrations Only: Temporarily maintain the legacy XML sitemap uploaded under the old Search Console property for 4–8 weeks post-launch. This accelerates Google's discovery of the legacy 301 redirects.

4. Schema and Internal Linking

• Update internal navigation, footers, and contextual links directly to new target URLs, and make sure any site structure changes are reflected there as well, not just in raw URL swaps. Do not rely on internal 301 redirects.
• Re-validate structured data (Organization, Article, Product, FAQ schema) using Google's Rich Results Test tool.

Scenario Playbooks: Platform, Domain, and Redesign

Playbook A: Platform Migration (e.g., WordPress to Webflow)

• CMS Collection Paths: Use this website migration checklist as both a cms migration playbook and a platform migration example: map WordPress URL structures to Webflow CMS collection parameters early. Because Webflow enforces folder structures for dynamic content (e.g., /blog/), legacy root posts will require 301 redirects.
• Asset Offloading: Upload media and PDFs to the new asset library. Update inline download links, as legacy /wp-content/uploads/ paths will throw 404 errors once hosting terminates.
• Plugin Auditing: Document legacy plugin functions (SEO tags, schema injection, form handlers) and re-architect them directly within Webflow settings or native integrations, and ensure the migration plan documents SEO-impacting defaults in the new CMS before launch.
• Trailing Slashes: Configure Webflow trailing-slash settings to match legacy indexing conventions precisely to prevent duplicate content creation.

Playbook B: Domain Migration

• Search Console Verification: Verify all domain permutations (http/https, root/www) in Google Search Console for both legacy and destination domains.
• Change of Address Tool: Submit a formal request within Search Console using the Change of Address tool after redirects go live. (Note: This tool is intended strictly for domain-level changes, not HTTP-to-HTTPS protocol switches or host moves).
• Domain Moves: Domain migrations often consolidate separate web properties or subdomains into the root domain to preserve and strengthen SEO value.
• Domain Ownership: Maintain registration and active hosting on the legacy domain indefinitely to keep 301 redirects intact, since legacy external links may continue sending users and search engines through those redirects for a long time.

Playbook C: Redesign Migration

• Preserve URL Structures: Keep existing URL slugs untouched unless structural changes are explicitly necessary.
• Content Parity Audits: Compare legacy and redesign page variations for body copy volume, subheadings (H2s, H3s), and structural depth. Deleting large sections of ranking copy during visual redesigns is a primary driver of post-launch traffic drops.
• Navigation Weight: Ensure key pages retain their internal linking prominence within primary navigation and footer menus.

Preventable Migration Failures

Final Steps

A website migration does not have to cost you organic visibility. The teams that execute successfully do not rely on luck, what they do is that they baseline performance early, build comprehensive redirect maps, test conversion infrastructure thoroughly, and maintain active monitoring long after launch day.

1. Assign Ownership: Designate a single technical SEO lead before opening design files or writing code.
2. Audit Strategy: If scoping, use the At-a-Glance Checklist to align team leads and agency partners.
3. Execute High-Risk Items: If development is already underway, immediately prioritize the Redirect Map and Form/Integration Inventory.

Frequently Asked Questions

What is a website migration checklist?

An SEO migration checklist is a structured project management framework for planning a website transition across technical, content, and infrastructure tasks before, during, and after the change. Teams may also use a separate web server migration checklist when hosting, SSL, rewrites, or DNS are changing. It ensures that search visibility, user experience, and lead capture systems remain intact throughout a site build or domain change.

How long does a typical B2B SaaS website migration take?

For a standard B2B SaaS website (100 to 1,000 pages), the pre-migration and build phase typically spans 8 to 16 weeks, followed by a 90-day post-launch monitoring window. Domain migrations or enterprise sites with extensive multi-language setups require longer lead times.

Will migrating our website cause an immediate drop in SEO traffic?

Minor indexing fluctuations are standard during the first few weeks as search engines re-crawl modified URLs. However, significant or permanent organic traffic loss is not inevitable—it is almost always caused by missing 301 redirects, deleted page copy, or residual noindex tags.

How long does organic search traffic take to recover after a migration?

Many migrations recover within 1 to 5 months, especially platform moves and redesigns that preserve existing URL paths, while domain migrations in the website migration process usually take longer; empirical studies show domain-level authority transfer can take 3 to 9 months to fully stabilize.

Should every single old URL be redirected?

Every legacy URL that drives traffic, holds external backlinks, or has a direct replacement on the new site must be redirected using a 301 status code to the most relevant new page, not the homepage. Unlinked legacy pages with zero traffic or business utility can be left to return a natural 404 or 410 status code. Keep those redirects live for at least one year after launch.