Website Migration Checklist 2026: The Complete Guide To Moving Your Site Without Losing Traffic Or Rankings

Let's Build Your Webflow Website!
Partner with experts who understand your vision. Let’s create a converting user experience and build your website for future growth.
Most website migrations that go wrong were not sabotaged by technical complexity. They were sabotaged by skipped steps, compressed timelines, and the assumption that a CMS switch is just a content copy-paste job.
A migration without a proper plan loses rankings. A migration without a redirect map loses traffic that took years to build. A migration without post-launch monitoring loses the window to fix problems before Google re-crawls and re-indexes at scale.
This checklist covers every phase. Use it as a project plan, not a reference document you skim once and shelve.
Types Of Website Migrations And Risk Levels
Not all migrations carry the same risk. Understanding what you are moving and what might break is the starting point.
| Migration Type | Risk Level | Typical Traffic Impact | Recovery Time |
|---|---|---|---|
| HTTPS upgrade (HTTP to HTTPS) | Low | Minimal if done correctly | Days |
| Hosting / server move (same URLs) | Low | Minimal | Days |
| Redesign (same URLs, same CMS) | Low-Medium | 5-15% temporary dip | 2-4 weeks |
| CMS / platform switch (same domain) | Medium | 10-25% temporary dip | 4-8 weeks |
| URL restructuring (same domain) | Medium-High | 15-30% temporary dip | 6-12 weeks |
| Domain change (same content) | High | 20-40% temporary dip | 8-16 weeks |
| Domain change + URL restructure | Very High | 30-50%+ temporary dip | 12-24 weeks |
The more variables you change simultaneously, the harder it is to diagnose problems when they appear. Change as few things at once as the project allows. If you are switching CMS and restructuring URLs and changing the domain at the same time, you have created a situation where a ranking drop could be caused by any of three separate things.
Phase 1: Planning And Pre-Migration Preparation
This is the phase most teams rush. It is also where most migration failures originate.
Define Scope, Goals, And Ownership
Before any technical work begins, answer these questions in writing:
- What exactly is changing? Domain, CMS, URLs, hosting, design, or a combination?
- Who owns each workstream? SEO, development, content, marketing, and client sign-off should each have a named owner.
- What is the go-live date, and is it fixed or flexible?
- What does success look like at 30 days post-launch? Define the metrics before you migrate.
Capture Baselines
You cannot identify a problem post-migration if you do not know where you started. Before touching anything, capture and store:
- Organic traffic by page (Google Analytics, 90-day minimum)
- Keyword rankings for your primary target terms (Ahrefs or Semrush export)
- Backlink profile (Ahrefs export of all referring domains)
- Core Web Vitals scores per page (PageSpeed Insights or Search Console)
- Conversion rates for primary conversion points
- Crawl data including all indexed URLs, status codes, and internal link structure (Screaming Frog or Sitebulb)
Export everything. Store it somewhere the whole team can access. You will need it.
Build The Complete URL Map
This is the most important document in the entire migration. Every current URL needs a mapped destination on the new site. No exceptions.
The URL map should include:
- Current URL (exact)
- New destination URL (exact)
- HTTP status code of the current URL (200, 301, 404, and so on)
- Page type (homepage, product, blog, landing page)
- Priority level (high traffic, high backlinks, or conversion-critical pages get priority QA)
Pages that are being retired and not replaced should map to the most topically relevant existing page on the new site, not the homepage. Sending everything to the homepage is the most common redirect mistake and it signals to Google that the redirects are not meaningful.
Set Up The Staging Environment
The staging environment is where everything gets built and tested before it touches production. It must:
- Be blocked from search engine indexing (robots.txt disallow or noindex meta tag)
- Mirror the production environment as closely as possible
- Be accessible to the full project team for QA
Lower the DNS TTL on your live site to 300 seconds (5 minutes) at least 48 hours before the planned go-live. This means DNS changes propagate faster on launch day.
Phase 2: Technical Build, Content Transfer, And QA On Staging
Implement And Test Redirects
Every redirect in the URL map gets implemented on the staging environment and tested before launch. Use a crawler (Screaming Frog works for this) to verify:
- Every redirect returns a 301 status code
- No redirect chains (A redirects to B redirects to C is a chain; it should be A redirects directly to C)
- No redirect loops (A redirects to B redirects to A)
- No pages returning 404 that should be redirected
A redirect chain loses link equity at each hop. A redirect loop crashes the page for every visitor who hits it.
Update Internal Links
After the redirect map is built, update every internal link across the new site to point to the final destination URL directly. Do not rely on redirects to handle your own internal links. Redirects are for external links and bookmarks. Your own site should link to the correct destination without an intermediate step.
Verify Technical SEO Elements
On the staging site, audit:
- Title tags and meta descriptions: check for duplicates, missing tags, and truncation
- Canonical tags: all pages should canonicalise to themselves unless they are intentional duplicates
- Sitemap: the new sitemap should include all indexable pages and exclude redirect and no index pages
- Robots.txt: confirm the staging block is in place and that the production version will not block anything it should not
- Structured data: verify that schema markup has migrated correctly using Google's Rich Results Test
- Hreflang tags: if the site is multilingual, verify that hreflang annotations are correct across all language variants
Performance And Accessibility QA
Run PageSpeed Insights on key page templates. Core Web Vitals issues discovered before launch are free to fix. The same issues discovered after launch require a hotfix deployment under pressure.
Run an accessibility audit (WAVE or axe) on primary page templates. Accessibility failures that exist pre-migration should not be carried forward. Launch is a natural checkpoint to address them.
For organisations in regulated sectors, accessibility and performance standards are worth examining before they affect user trust or compliance. The best healthcare website design examples and best banking website design examples both illustrate how high-trust organisations treat these as baseline requirements rather than optional improvements.
Analytics And Tracking Verification
Verify on staging that all tracking is firing correctly:
- Google Analytics 4 pageview events
- Conversion events for forms, CTAs, and purchases
- Google Tag Manager container loading
- Any third-party scripts (heatmaps, session recording, advertising pixels)
Test every form submission. Test every conversion path. Tag Manager previews and GA4 DebugView are your tools here.
Phase 3: Launch Day Execution
Pre-Launch Gate Check
Before flipping the switch, confirm:
- Full site backup taken of the current production site (within the last 24 hours)
- Redirect map fully implemented and tested
- Staging environment blocked from indexing
- DNS TTL already lowered
- All team members available during the launch window
- Rollback plan documented and understood by the team
Do not launch on a Friday. Do not launch during a peak traffic period. Do not launch before a major commercial event. Launch problems need to be diagnosed and fixed quickly. You need your full team available to do that.
Go-Live Steps In Order
- Deploy the new site to production
- Remove noindex tags and staging robots.txt blocks
- Update DNS records to point to the new server
- Install and verify the SSL certificate
- Verify 301 redirects are live and returning the correct status codes
- Submit the new XML sitemap in Google Search Console
- Request indexing for the homepage and highest-priority pages via URL Inspection
- Verify Google Analytics is recording sessions on the new site
- Verify all forms and conversion paths are working on production
- Check email sending functionality if the domain has changed
Announce And Update External Properties
On launch day or within 24 hours:
- Update the URL in Google Search Console properties (add the new domain as a new property)
- Update Google Business Profile URL if applicable
- Update social media profile links
- Notify any high-value backlink sources about the domain change (for domain migrations)
Phase 4: Post-Migration Monitoring And Recovery
First 48-72 Hours
This is the highest-risk window. Monitor intensively:
- Crawl errors in Google Search Console (Coverage report)
- 404 errors (Screaming Frog re-crawl of the live site)
- Traffic levels in GA4 (compare to the same period the previous week)
- Ranking changes for primary target keywords (Ahrefs or Semrush)
- Server error logs for 5xx errors
If you see a wave of 404 errors, your redirect map has gaps. Fix them immediately. Every unfixed 404 is a lost visitor and a lost link.
Week 1-4 Monitoring
- Run a full crawl weekly and compare against the pre-migration crawl baseline
- Monitor Search Console for indexing progress (the Coverage report will show how many pages are indexed)
- Track keyword rankings daily for your top 50 terms
- Monitor Core Web Vitals in Search Console (expect a lag of 2-4 weeks before data reflects the new site)
- Check backlinks in Ahrefs to identify any that are not resolving correctly to the new URLs
30-90 Day Recovery
A temporary ranking dip after migration is normal. Google needs time to re-crawl, re-evaluate, and re-index the new site. The dip should bottom out and begin recovering within four to eight weeks for a well-executed migration. Domain changes take longer.
If rankings have not begun recovering by week eight, investigate:
- Are all redirects still in place and working correctly?
- Is Google crawling the new site at a normal rate? (Server Logs and GSC crawl stats)
- Are there duplicate content issues from the migration?
- Did any technical SEO elements (canonicals, noindex tags) get mis-applied?
The web development trends toward headless and composable architectures introduce migration complexity that traditional checklists do not fully address. If your migration involves a headless front end, verify that the API layer and CMS content delivery are functioning correctly and that Google can render the pages fully.
Ecosystem Items Most Teams Miss
Most checklists cover the website. Fewer cover everything connected to it.
Email And DNS
- SPF, DKIM, and DMARC records must be verified after any DNS change
- MX records must point to the correct mail server
- Test transactional emails (order confirmations, form notifications) from the production environment
Advertising Platforms
- Update landing page URLs in Google Ads campaigns
- Update tracking pixels in Meta Ads Manager
- Verify conversion tracking is firing correctly in both platforms
- Update any campaign UTM parameters that reference old URLs
CRM And Forms
- Verify all form submissions are routing to the correct CRM fields
- Update any CRM-embedded forms that reference old domain URLs
- Check Zapier or other automation triggers that reference the old site
Local Listings And Directories
- Update Google Business Profile URL
- Update Bing Places URL
- Update any industry directory listings that link to the old domain
Common Migration Mistakes
| Mistake | Consequence | Prevention |
|---|---|---|
| Incomplete redirect map | 404 errors, lost link equity | Crawl the full site before migration and map every URL |
| Redirect chains | Slower page loads, reduced link equity transfer | Test every redirect end-to-end before launch |
| Launching on Friday | Reduced team availability during critical first hours | Schedule launches Tuesday-Thursday |
| Removing noindex too early on staging | Google indexes the staging site | Verify robots.txt on staging before any external sharing |
| Not capturing pre-migration baselines | Cannot diagnose post-migration problems | Export rankings, traffic, and crawl data before touching anything |
| Changing too many things at once | Cannot isolate the cause of ranking drops | Minimise simultaneous changes |
| No rollback plan | Migration cannot be reversed if critical failures occur | Document and test rollback before launch |
| Forgetting third-party tracking | Conversion data gaps post-launch | Audit all tracking tags before migration |
Tools By Phase
| Phase | Recommended Tools |
|---|---|
| Pre-migration audit | Screaming Frog, Ahrefs, Semrush, PageSpeed Insights |
| URL mapping | Google Sheets, Screaming Frog export |
| Staging QA | Screaming Frog, WAVE, axe, GA4 DebugView |
| Launch day verification | Google Search Console, Screaming Frog, GTmetrix |
| Post-migration monitoring | Google Search Console, Ahrefs, GA4, Screaming Frog |
Webflow Migrations Specifically
If you are migrating to Webflow specifically, the process has some platform-specific considerations. Content import, CMS Collection setup, and redirect implementation in Webflow follow Webflow-specific patterns that differ from WordPress or Drupal migrations.
Our Webflow migration process covers what this looks like end-to-end, including how we handle redirect mapping, content transfer, and post-launch SEO monitoring for B2B marketing sites. Our Webflow development and design capability shows what the output looks like.
For organisations in design-forward sectors evaluating a platform move, the best fintech website design examples show how high-performance sites in regulated industries handle the platform and migration question in practice.
FAQs
What Is A Website Migration Checklist And Why Do I Need One?
A website migration checklist is a phased plan covering every step required to move a website from one domain, platform, or URL structure to another without losing traffic, rankings, or functionality. Without one, steps get skipped under time pressure. Skipped steps cause ranking drops that take months to recover.
How Do I Migrate A Website Without Losing SEO Rankings?
Capture pre-migration baselines. Build a complete URL redirect map. Implement 301 redirects with no chains or gaps. Test everything on staging before launch. Submit the new sitemap in Google Search Console on launch day. Monitor crawl errors, 404s, and rankings daily for the first four weeks.
How Long Does It Take For Rankings To Recover After A Migration?
A well-executed migration with no gaps typically sees rankings begin recovering within four to eight weeks. Domain changes take longer, typically eight to sixteen weeks. Migrations that change multiple variables simultaneously or have redirect gaps take longer still.
Should I Use 301 Or 302 Redirects?
301 redirects for permanent moves. A 301 transfers link equity to the destination URL. A 302 signals a temporary move and does not transfer link equity in the same way. Use 301s for all permanent migrations.
What Are The Biggest Mistakes To Avoid?
Incomplete redirect maps, launching on a Friday, not capturing pre-migration baselines, changing too many things simultaneously, and not having a rollback plan. Any one of these makes a migration harder to execute and harder to recover from when problems appear.
Do I Need A Staging Site For Every Migration?
Yes. Testing redirects, content, tracking, and performance on a live production site while it is receiving real traffic creates unnecessary risk. Staging environments exist to catch problems before visitors and search engines encounter them.
To see how we manage migrations for real B2B sites, including the decisions that affect long-term SEO and performance, our work shows the approach in practice.
A Note On Sources
Migration risk levels and recovery timelines in this article are based on widely reported industry benchmarks from tools and agencies including Semrush, Ahrefs, and Screaming Frog, as of mid-2026. Individual migration outcomes vary significantly based on site size, execution quality, and the number of variables changed simultaneously.
Google Search Console and PageSpeed Insights references reflect tool functionality as of June 2026. Google updates these tools regularly. Verify current features at search.google.com/search-console.
Core Web Vitals thresholds referenced in this article are sourced from Google's published benchmarks at web.dev/vitals.