Website Migration Guide for Marketers 2026: Protect Rankings, Traffic, and Pipeline

Organic search is the highest-ROI acquisition channel for most B2B SaaS companies. It's also the channel most likely to take a significant hit during a website migration - not because migrations are inherently dangerous, but because most of the damage is caused by skipping steps that should be non-negotiable.

The difference between a migration that retains 95% of organic sessions within 30 days and one that drops 40% and takes six months to recover is almost entirely process. Not platform. Not design quality. Process.

This guide covers the complete migration process for 2026 - written for the marketing leaders who own the business outcome, not just the developers who execute the technical steps. That means clear ownership, realistic expectations, and the specific signals that tell you whether your team or your agency is ready to do this properly.

What Counts as a Website Migration (and Why Marketers Should Care)

A website migration is any change that affects how search engines crawl, index, or evaluate your site. That definition is broader than most teams expect.

‍

‍

Recovery windows assume a complete, properly executed migration process with full redirect mapping and post-launch monitoring. Poorly executed migrations can result in permanent ranking losses for affected pages. Source: Google Search Central, site move documentation.

Why marketing owns this outcome even when development executes it: the traffic and pipeline impact lands in marketing's metrics. A 30% drop in organic sessions is a pipeline problem, not a development problem. Marketing must define the success criteria, approve the content decisions, and verify the business outcomes - regardless of who writes the redirect map.

The Marketer's Role vs. the Technical Team's Role

The most common cause of migration failures is not technical incompetence. It's ownership ambiguity. Marketing assumes the developer is handling SEO. The developer assumes marketing approved the URL structure. The content team doesn't know the migration is happening until two weeks before launch.

‍

‍

Marketing must own the timing decision. Migrating during a major product launch, during a high-spend paid campaign period, or in the four weeks before a significant demand generation event compounds risk. The migration introduces a temporary instability window. Running that window alongside a campaign creates compounding exposure.

Phase 1: Strategy, Benchmarking, and Planning

70-80% of migration success is determined in this phase. Teams that rush through planning to start building are the ones that spend six months recovering traffic they didn't need to lose.

Define Goals and Success Metrics

Before any technical work begins, define what success looks like in measurable terms:

• Organic sessions within 5% of pre-migration baseline within 30 days
• Rankings for target keywords maintained at 90% of pre-launch positions within 30 days
• Demo/trial conversion rates at or above pre-migration baselines within 60 days
• Core Web Vitals pass rate on mobile at 90% or above on launch day
• Zero broken redirect chains on launch day

These targets are agreed before Phase 2 begins. They are the criteria against which post-launch performance is evaluated.

Full Site Audit and URL Inventory

A crawl of the current site produces the foundational document for the entire migration. The deliverables:

• Complete URL inventory with HTTP status codes for every page
• Organic traffic and ranking data per URL (from Google Search Console and analytics)
• Inbound backlink count per URL (from a link analysis tool)
• Internal link structure and anchor patterns
• Canonical tags, hreflang, and structured data inventory
• Core Web Vitals scores per page group

Every URL with organic traffic, inbound backlinks, or rankings in positions 1-20 is a priority asset. These pages cannot be deleted, merged, or moved without a deliberate redirect decision.

Content Decisions: Keep, Prune, Merge, or Rewrite

The migration is the right moment to clean up the content inventory. Not doing so carries the old site's underperforming content forward into the new architecture.

For every page in the inventory, the decision criteria:

Keep as-is: Ranking in positions 1-20, generating organic traffic, or has inbound backlinks. Migrate with redirect to the same new URL where possible.

Update and keep: Ranking but underperforming on conversion. Migrate and update content in parallel with the build.

Merge: Two or more pages targeting the same query with diluted traffic between them. Consolidate to one URL and redirect the others.

Prune: No traffic, no rankings, no backlinks, no conversion value. Remove and redirect to the nearest relevant page or category.

Marketing owns these decisions. The content team cannot hand them to a developer to resolve during build.

Build the Complete 301 Redirect Map

The redirect map is a spreadsheet with one row per current URL. Columns:

• Current URL
• HTTP status
• Organic sessions (trailing 90 days)
• Ranking keywords
• Inbound link count
• Destination URL (new site)
• Redirect type (301)
• Notes

Every URL in the inventory gets a destination. The rules:

• Pages with traffic, rankings, or backlinks redirect to the most thematically relevant new URL - never to the homepage unless there is genuinely no relevant destination
• Pages being merged redirect each source URL to the merged destination
• Pages being pruned redirect to the nearest relevant category or parent page

This map is built in Phase 1, reviewed by marketing and SEO before development begins, and handed to the development team as a specification document - not as a to-do item for launch week.

Capture Baselines

Before any work begins on the new site, document the current state:

• Organic sessions by page (trailing 90 days from analytics)
• Keyword positions by page (from Search Console)
• Core Web Vitals field data from Search Console
• Backlink profile snapshot
• Conversion rates by page type (demo, trial, pricing, homepage)
• Schema markup inventory

These baselines are the benchmark against which the migration is evaluated. Without them, post-launch performance cannot be assessed objectively.

Phase 2: Build, Staging, and Pre-Launch Testing

Staging Environment Rules

The staging environment must be:

• Blocked from indexing via a noindex meta tag or robots.txt disallow directive
• Password-protected or access-restricted at the server level
• Running on a subdomain or staging URL that is completely separate from the production domain

The single most catastrophic staging error is allowing the staging site to be indexed before launch. Google can index staging content, create duplicate content issues, and dilute the production domain's authority before the site is live. Verify staging is blocked with a crawl tool before development begins and before every major content addition during the build.

Implement and Validate Redirects

The redirect map from Phase 1 is implemented during the build phase. Implementation methods depend on the platform:

• Webflow: The built-in redirect manager handles 301 redirects at the platform level. It must be fully populated before the domain is pointed to Webflow.
• WordPress: Redirect plugins or server-level .htaccess rules. Verify rule order to avoid redirect chains.
• Other platforms: Server-level or CDN-level configuration where possible - application-layer redirects add latency.

After implementation on staging, crawl the staging environment to verify every redirect returns a 301 status code with the correct destination. Redirect chains (A redirects to B redirects to C) degrade both user experience and the SEO equity passed through the redirect. Each chain adds latency and reduces the link equity transferred. Resolve chains to direct 1:1 redirects where possible.

Preserve On-Page SEO, Schema, and Internal Links

On the new site, verify:

• Every priority page has a meta title and meta description configured in the CMS - not left as platform defaults
• Canonical tags are set correctly on every page (self-referencing canonical on the canonical version, no canonicals pointing to the wrong URL)
• Structured data (Organisation, FAQPage, Article, BreadcrumbList) is implemented and validates in Google's Rich Results Test
• Internal links within migrated content reference the new URLs, not the old ones (old internal links with redirects in place are functional but inefficient)
• H1 tags are present and unique on every page

Schema preservation matters more in 2026 than in previous years. AI-powered search surfaces (Google AI Overviews, Perplexity, and similar) preferentially cite structured, well-marked-up content. A migration that drops schema implementation reduces not just traditional ranking signals but also answer-engine citation potential.

Tracking, Analytics, and Conversion Paths

Verify before launch:

• GA4 is configured and firing on all pages, including the new URL structure
• Conversion events (form submissions, demo requests, trial starts) are firing correctly on staging
• Any UTM parameter handling or cross-domain tracking is configured for the new domain
• Heatmapping and session recording tools are configured for the new URLs
• CRM form integrations are tested end-to-end on staging

Launching without verified tracking means the first 30 days of post-launch data - the most critical monitoring window - contain incomplete or incorrect conversion data.

Final Pre-Launch QA Checklist

Before any DNS change:

• [ ] Staging is confirmed blocked from indexing (crawl verification, not assumption)
• [ ] Redirect map is fully implemented and verified via crawl (zero broken redirects)
• [ ] All priority pages have meta titles, descriptions, and canonical tags
• [ ] Schema markup validates on priority page types
• [ ] Core Web Vitals in Lighthouse are in the "Good" range on mobile for all key pages
• [ ] GA4 conversion events verified on staging
• [ ] XML sitemap is updated and reflects the new URL structure
• [ ] robots.txt is configured for production (not the staging block)

Do not proceed to launch until every item is checked. These are binary pass/fail criteria, not subjective assessments.

Phase 3: Launch Day Execution

Time your launch outside peak traffic periods - midweek, mid-morning in your primary timezone, is the standard recommendation. This gives you a working day to identify and fix immediate issues before traffic volume peaks.

Immediate verification sequence (first two hours):

1. Confirm the production site is live and the old site is no longer serving
2. Verify the staging environment is no longer publicly accessible
3. Crawl a sample of priority URLs and confirm redirect status codes are 301 (not 302, not 404)
4. Confirm the production robots.txt allows indexing
5. Confirm the XML sitemap is accessible at /sitemap.xml
6. Submit the updated sitemap in Google Search Console
7. For domain migrations, use the Change of Address tool in Google Search Console (documented at support.google.com/webmasters/answer/9370220)
8. Verify GA4 is tracking live sessions correctly
9. Complete a test conversion (demo request or trial signup) end-to-end on production
10. Check that all priority pages load correctly and meta data is rendering in page source

Rollback readiness: before DNS changes, confirm the old hosting environment is still live and accessible if needed. A rollback decision made within the first four hours of launch is significantly less damaging than one made at hour 24.

Phase 4: Post-Launch Monitoring and Recovery

Daily/Weekly Monitoring Cadence

‍

‍

What a Normal Dip Looks Like vs. a Problem

A well-executed migration with complete redirect mapping typically shows:

• A temporary dip of 5-15% in organic sessions in the first 1-2 weeks as Google processes the changes
• Rankings for most target keywords returning to pre-migration levels within 4-6 weeks
• Full session recovery within 30-60 days

A problem looks like:

• Sessions down more than 20% after two weeks with no recovery trend
• A significant number of target keywords not returning to previous positions after 30 days
• Search Console showing a high volume of crawl errors or redirect errors on priority pages
• A large number of previously indexed URLs returning 404 status codes

According to Google's Search Central documentation on debugging traffic drops, the first diagnostic action is always to check for technical causes - robots.txt changes, noindex tags, manual actions, or crawl errors - before concluding that the content or redirect strategy failed.

Indexing, Crawl, and Search Console Actions

In Search Console after launch:

• Monitor the Coverage report for new 404 errors and redirect errors
• Monitor the Core Web Vitals report for any pages regressing from "Good" to "Needs Improvement"
• Check the Manual Actions report for any penalties (rare but critical to catch immediately)
• Use the URL Inspection tool to request indexing for the highest-priority pages if they are slow to appear in the coverage report

For domain migrations specifically, the Change of Address tool in Google Search Console accelerates Google's recognition of the domain move. Google's documentation states this tool helps Googlebot discover and process the migration, but it does not guarantee instant transfer of ranking signals - the process typically takes several weeks.

When and How to Escalate

Escalate to a specialist if:

• Sessions are down more than 20% after two weeks with no recovery trend
• Search Console shows a manual action or security issue
• A significant volume of redirect errors appears in Search Console that cannot be resolved by the development team
• Rankings for high-value keywords have not recovered after 60 days

Escalation at two weeks is not premature. Six months of diminished organic traffic for a B2B SaaS company with a $5,000-$50,000 monthly organic pipeline value is a costly delay.

Platform Considerations for Marketing Teams

Platform choice affects not just the migration risk profile but the marketing team's operational reality for the next three years.

The questions that matter for marketing teams evaluating platform options:

Can marketing publish and update content without developer involvement? This determines content velocity - how quickly a new landing page, campaign page, or feature update reaches the site.

Are SEO fields (meta title, description, canonical, Open Graph) configurable per page without code? A platform that requires a developer to update a meta description is creating SEO debt with every piece of content published.

How are 301 redirects managed? Platforms where redirects require server configuration or developer involvement create operational risk during future updates and campaigns.

What does the migration process look like for this platform, and what SEO tooling is built in?

Webflow specifically addresses several of these marketing pain points: the visual CMS gives marketing teams direct publishing capability, the redirect manager is marketer-accessible, SEO fields are configurable per CMS item without code, and the platform generates clean HTML that is generally performant out of the box.

The migration risk of moving to Webflow is real and manageable with the right process - the redirect mapping, staging configuration, and pre-launch QA steps in this guide apply directly. The post-migration operational benefit for marketing teams - publishing independence, SEO field control, performance baseline - typically justifies the migration investment for B2B SaaS marketing sites.

Webflow migration covers the platform-specific process in detail. For organisations evaluating Webflow's SEO capabilities before committing to a migration, Webflow SEO covers the technical implementation. For the full platform capability picture, Webflow development and design covers what a production B2B SaaS marketing site on Webflow involves.

Common Failure Modes and How to Avoid Them

‍

‍

How to Evaluate Whether Your Team or Agency Is Ready

The questions to ask before handing a migration to any team - internal or external.

Positive signals:

• They ask for a full crawl of the current site before any other work begins
• They produce a URL inventory with traffic, rankings, and backlink data before building the redirect map
• The redirect map is a Phase 1 deliverable in their process, not a launch-week task
• They have a documented pre-launch QA checklist with binary pass/fail criteria
• They know the difference between a 301 and a 302 redirect and when each is appropriate (301 for permanent moves, 302 for temporary - almost all migration redirects are 301s)
• They recommend against migrating during your peak campaign period
• They define post-launch monitoring thresholds and escalation criteria before launch

Red flags:

• They reassure you that migration is low-risk without asking to see the current site's analytics and Search Console data
• The redirect map is described as something they will "handle during development"
• They cannot explain what happens if the staging site gets indexed
• There is no post-launch monitoring plan in the project scope
• They describe the migration as "just a platform change" without acknowledging the SEO risk of URL structure changes
• They have no examples of post-migration traffic retention data from previous projects
• They propose launching the new site without a defined rollback plan

The questions worth asking directly: What does your pre-launch QA checklist include? Can you show me an example redirect map from a previous project? What thresholds trigger an escalation in your post-launch monitoring process?

Realistic Timelines, Effort, and Expectations

‍

‍

All of the above simultaneously

Timelines are for B2B SaaS marketing sites of typical complexity (50-300 pages). Larger sites with more complex IA, content volumes, or integrations require proportionally more time in the planning phase. Source: typical agency delivery data - not a guarantee.

The variable that extends timelines most consistently: content decisions left until the build phase. When marketing hasn't made keep/prune/merge decisions by the time development starts, developers are either migrating everything (including underperforming content) or making content decisions without the right data.

Work with Shadow Digital

Website migrations are the highest-risk event in a B2B SaaS marketing calendar. The process above is exactly how Shadow Digital approaches every migration - from the Phase 1 redirect map to the 90-day monitoring framework. For complex platform moves or domain migrations, the cost of getting it wrong exceeds the cost of doing it properly by a significant margin.

Book a strategy call to talk through your migration scope and risk profile before committing to a timeline. Or see our work to understand what a properly executed B2B SaaS migration looks like in practice.

A Note on Sources

Technical claims about 301 redirects, Change of Address, staging environment requirements, and post-launch monitoring are based on Google Search Central documentation: developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes and support.google.com/webmasters/answer/9370220. Verify current guidance against these primary sources before execution, as Google updates its documentation periodically. Recovery window ranges are based on observed migration outcomes under well-executed and poorly-executed process conditions - individual results vary based on site authority, content quality, and redirect map completeness. No specific statistical claims are made beyond what is directly observable from Google's documented guidance. All figures should be verified at time of publication.

Frequently Asked Questions

How Long Does It Take for Rankings to Recover After a Website Migration?

A well-executed migration with complete redirect mapping typically returns to pre-migration ranking levels within 4-8 weeks for most target keywords. Full session recovery usually occurs within 30-60 days. Poorly executed migrations - incomplete redirect maps, staging blocks left live, dropped meta data - can produce losses that take 3-6 months to recover, if they recover at all. According to Google's site move documentation, the process of transferring ranking signals through a domain migration can take several weeks even when executed correctly.

What Is the Single Most Important Step in a Site Migration?

Building a complete 1:1 redirect map in the planning phase - before development begins. Every indexed URL with traffic, rankings, or backlinks needs a relevant destination in the new site. The redirect map is the document that prevents the majority of post-launch traffic losses. A redirect map built in launch week is not a redirect map - it is a risk.

Do I Need 301 Redirects if My URLs Stay the Same?

If your URLs are not changing, 301 redirects are not required for those pages. However, you still need to verify that canonical tags are correctly configured, meta data has been migrated with parity, and analytics tracking is functioning on the new platform. A platform change with identical URLs can still affect rankings if schema markup, structured data, or page performance degrades in the move.

How Do I Create a Complete URL Redirect Map?

Start with a full crawl of the current site to produce a URL inventory. Cross-reference every URL with Google Search Console data (organic traffic, impressions, keyword positions) and a backlink audit. For every URL with traffic, rankings, or inbound links, define the most thematically relevant destination on the new site. Build this as a spreadsheet with columns for current URL, traffic data, ranking keywords, backlink count, and destination URL. Every URL gets a destination - no blanket homepage redirects for pages with traffic or rankings.

What Happens if My Staging Site Gets Indexed?

If the staging site is indexed before launch, Google may create duplicate content associations between the staging and production versions, dilute the production domain's authority, and index staging pages that return errors after launch. The fix requires submitting a removal request via Google Search Console and verifying the staging environment is properly blocked. Prevention - robots.txt disallow on staging plus password protection - is the correct approach.

Should I Migrate During a Product Launch or Campaign Period?

No. The migration introduces a temporary instability window in organic performance, even when executed correctly. Running that window alongside a major product launch, a high-spend paid campaign, or a significant demand generation event creates compounding risk. Marketing should define the migration timing based on the campaign calendar. Allow a minimum four-week buffer on either side of major campaign activity.

How Do I Know if Traffic Loss Is Normal or a Problem?

A temporary dip of 5-15% in the first 1-2 weeks is normal as Google processes the migration changes. A problem looks like: sessions down more than 20% after two weeks with no recovery trend, a significant number of target keywords not returning to previous positions after 30 days, or Search Console showing high volumes of crawl errors or redirect errors on priority pages. If sessions are still below 90% of the pre-migration baseline at day 30, begin a technical diagnostic immediately - do not wait for day 60.

How Long Should I Keep the Old Redirects Active?

Permanently, for any URL that had traffic, rankings, or inbound backlinks. Redirects serve two functions: passing SEO equity to the new URL (which completes within a few weeks) and ensuring a user who follows an old link from an external site reaches the correct page. That second function is ongoing. Removing redirects after 6 months or a year risks breaking links from external sites, newsletters, and old marketing materials that may still generate clicks.

Does Moving to a New CMS (Such as Webflow) Automatically Hurt SEO?

No - not if the migration process is followed. The platform itself is not an SEO risk. The SEO risk lives in URL structure changes, redirect implementation, meta data migration, schema preservation, and performance changes. A Webflow migration with identical URLs, a complete redirect map for changed URLs, and verified meta data parity will not produce ranking losses attributable to the platform. In many cases, Webflow's clean HTML and performance characteristics improve Core Web Vitals scores post-migration, which can produce ranking improvements over time.

When Should a Marketing Team Hire Specialists for a Migration?

When two or more of the following apply: the migration involves URL structure changes, a domain change, or a platform change; the site generates significant organic pipeline (more than $20,000/month in attributed pipeline); the internal team cannot produce a verified 1:1 redirect map before development begins; the organisation lacks a documented pre-launch QA process with binary pass/fail criteria; the migration involves a tight timeline with limited buffer for issues. The cost of specialist engagement is almost always lower than the cost of a six-month traffic recovery from a poorly executed migration.