Website Migration Without Traffic Loss: A 14-Step Pre-Launch SEO Checklist

A website migration is the highest-risk change a brand can make to its organic visibility profile. CMS replatforms, domain changes, URL structure overhauls, and major redesigns all carry the same core risk: severed signal continuity between the old site and the new one. Brands that execute migrations without a structured pre-launch process consistently lose 30–70% of organic traffic and require 3–9 months to recover, if they ever fully recover. Brands that follow a structured checklist preserve visibility through the cutover with under 5% temporary fluctuation. This is the 14-step framework Capconvert uses on every client migration. Each step is concrete, ordered, and required.

Why Migrations Fail

Three categories of failure account for the vast majority of migration traffic losses.

Severed URL continuity. Old URLs return 404s or redirect to wrong pages. Search engines lose the ability to map old authority to new pages, and rankings collapse. This is the single most common failure and accounts for 60–80% of migration traffic losses.

Lost schema and metadata. Schema, canonical tags, meta descriptions, structured data, and other on-page signals don't migrate cleanly. Pages that previously triggered SERP features stop triggering them. AI bot extractability drops because the structured data they depend on is missing or wrong.

Broken signal continuity for crawlers. Robots.txt, XML sitemaps, llms.txt, and AI bot access rules need to be reconfigured on the new infrastructure. Default settings on the new platform often differ from the old, blocking crawlers that previously had access.

The 14 steps below address all three failure categories. Skipping any one step exposes the migration to one of the failure modes.

Pre-Launch (Steps 1–7)

These seven steps run during the planning and staging phase, before launch day.

Step 1: Inventory Current URLs

Crawl the existing live site with Screaming Frog, Sitebulb, or equivalent. Export every URL the crawler discovers. Cross-reference against:

• XML sitemap entries
• Google Search Console "Performance" data (every URL that received clicks in the past 16 months)
• Google Analytics URL list (every URL that received traffic in the past 12 months)
• Backlink data from Ahrefs/Semrush (every URL that has external backlinks)

The combined inventory is the master list of URLs that must be preserved or redirected. Missing URLs in the inventory means missing redirects, which means lost authority.

Common mistake: Relying only on the XML sitemap. Sitemaps frequently miss URLs that received historical traffic — those URLs need redirects too.

Step 2: Inventory Current Rankings

Pull the current ranking position for every priority keyword from Google Search Console (last 90 days) and the SEO platform (Ahrefs, Semrush). Save as a baseline file with date stamp. After launch, compare against this baseline weekly to detect regressions.

Without a pre-migration baseline, regression detection becomes guesswork. The baseline is non-negotiable.

Step 3: Crawl the Staging Site

Crawl the staging site with the same tool used in Step 1. Look for:

• 404s on URLs the redirect map should preserve
• Missing or incorrect canonical tags
• Missing meta descriptions or duplicate titles
• Broken internal links
• Missing schema markup
• Pages with noindex tags that shouldn't have them
• Pages without noindex tags that should have them (e.g., search result pages, filtered category pages)

Export the staging crawl. The diff between old and new is the work the team needs to fix before launch.

Step 4: Build the Redirect Map

For every URL in the Step 1 inventory, define the destination URL on the new site. The result is a CSV with two columns: old_url, new_url. Cases to handle explicitly:

• Direct mapping: old URL maps to a new URL with same content. Simple 301.
• Consolidation: multiple old URLs map to one new URL (when content was merged). 301 each old URL to the consolidated URL.
• Removal: old URL has no equivalent because content was retired. 301 to the most relevant parent category page or topic hub. Avoid 404s for any URL with backlinks or historical traffic.
• Edge cases: URL parameters, trailing slashes, case sensitivity. Document the canonical form and ensure redirects normalize to it.

The redirect map should be reviewed by a second person before launch. A single 50-row error in a 5,000-URL migration is enough to lose a quarter of traffic.

Step 5: Preserve Schema Parity

Document the structured data emitted by the existing site (per template — homepage, blog post, product page, category page, etc.). On the staging site, verify each template emits the same or improved schema. Validate using Google's Rich Results Test on a sample of pages from each template.

Common schema regressions during migration:

• Organization schema missing the social profile sameAs array
• Article schema losing datePublished and dateModified fields
• Product schema losing aggregateRating because the review system migrated separately
• BreadcrumbList schema using new URLs that don't match the migrated structure

A schema regression list documented before launch lets the team fix issues during staging instead of after launch.

Step 6: Verify Canonical Tags

Every page on the new site needs a canonical tag pointing to itself (or to the consolidation target if applicable). Common canonical errors during migration:

• Canonical tags on staging that point to staging URLs after launch (forgotten environment swap)
• Canonical tags missing on dynamic pages (filtered category pages, search results)
• Canonical tags pointing to old domain after a domain migration

Crawl the staging site filtering for canonical tags. Verify every result before launch.

Step 7: Preserve Internal Linking

Internal linking patterns that drove the old site's authority distribution should be preserved on the new site. Document:

• Top 50 internal linking patterns from the old site (which pages link to which, with what anchor text)
• Recreate or improve those patterns on the new site
• Where possible, add internal links from the new site that didn't exist on the old (improvement opportunity)

Internal linking pattern preservation is the most underrated migration step. Pages with strong internal link profiles on the old site often regress because the new site's information architecture doesn't recreate the same internal flow.

Pre-Launch (Steps 8–12)

These five steps cover crawler signals and analytics setup.

Step 8: Preserve robots.txt and llms.txt

Robots.txt and llms.txt do not migrate automatically. The new site's defaults often differ from the old. Specifically:

• Verify robots.txt allows GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, and Google-Extended (or matches the brand's deliberate AI bot policy)
• Verify llms.txt is present at the new site root with current content
• Verify llms-full.txt if used
• Verify the new site does not block Googlebot or Bingbot via accidental Disallow: / rules

Most platforms inherit a default robots.txt that disallows indexing on staging. The launch checklist must include flipping the robots.txt to production rules.

Step 9: Validate AI Bot Access on New Domain

For domain migrations specifically, AI bot access policies tied to the old domain do not transfer. Check:

• robots.txt on the new domain explicitly allows AI bots
• llms.txt on the new domain reflects the new URL structure
• Server-side bot detection (if used) recognizes AI bot user agents

A domain migration that doesn't address AI bot access can drop AI citation share to zero overnight as the engines lose the ability to crawl the new domain.

Step 10: Preserve XML Sitemaps

The new site needs XML sitemaps that reflect the new URL structure. Steps:

• Generate a new XML sitemap covering all preserved/new URLs
• Submit the new sitemap to Google Search Console and Bing Webmaster Tools after launch
• Keep the old sitemap accessible (returning 200 with the same URLs that 301 to new locations) for at least 60 days to help Google process redirects

XML sitemaps are not strictly required for indexing, but they accelerate the migration's discovery phase by 50–80%.

Step 11: Verify Analytics Continuity

The new site needs analytics tracking that matches the old:

• Google Analytics 4 property reused or new property with documented switch date
• Google Search Console verified for the new domain (if applicable)
• Bing Webmaster Tools verified for the new domain
• Server-side tagging (if used) reconfigured for the new domain
• AI visibility tracking platforms updated with new domain

Without analytics continuity, the team can't measure post-launch impact, which means regressions go undetected longer.

Step 12: Test on Staging End-to-End

A full end-to-end test on staging covers:

• Sample-redirect-test: pick 50 URLs from the redirect map and confirm each redirects correctly
• Crawl-test: full Screaming Frog crawl of staging with all live-site rules applied
• Schema-test: validate top 10 templates with Rich Results Test
• Performance-test: PageSpeed Insights on top 10 pages — confirm Core Web Vitals don't regress
• AI-bot-test: simulate GPTBot user agent and confirm pages respond correctly

The end-to-end test catches the issues that escaped the per-step verification. Plan 1–2 days for testing, plus contingency days for fixes.

Launch Day (Step 13)

Step 13: Launch Sequence

The launch itself follows a fixed sequence to minimize the window of risk.

1. DNS or routing change — point the production domain to the new site
2. Verify redirects working — sample 20 URLs immediately, confirm 301s land on correct destinations
3. Verify robots.txt — confirm production robots.txt is live (not staging robots.txt)
4. Submit new sitemap to GSC and Bing WT — accelerates discovery
5. Notify Google of redirects — use the GSC "Change of Address" tool if domain changed
6. Update llms.txt — submit any external pings/notifications relevant to AI engines
7. Initial crawl — run Screaming Frog on the live new site, confirm zero unexpected 404s
8. Stakeholder all-clear — communicate launch completion to the marketing team

Total launch sequence runs in 30–90 minutes for most brands. Schedule it during low-traffic hours (late night, weekend morning) to minimize user impact if issues surface.

Post-Launch (Step 14)

Step 14: Post-Launch Monitoring

Monitoring runs for at least 30 days post-launch with structured checks at defined intervals.

Day 1: Verify analytics is recording sessions on the new site. Verify Google Search Console shows the new site receiving impressions. Crawl the live site one more time end-to-end and resolve any 404s, broken links, or canonical errors.

Days 2–7: Daily ranking checks for top 50 priority keywords. Daily Core Web Vitals checks. Daily 404 monitoring via GSC "Pages" report. Daily AI bot crawl frequency check via server logs.

Days 8–14: Continue daily checks. Begin AI citation tracking comparison vs. pre-migration baseline.

Days 15–30: Weekly checks on rankings, traffic, conversions, AI citations. Resolve any sustained regressions. Document the migration outcome with before/after comparison.

Days 31–90: Monthly comparison against the pre-migration baseline. Most brands see full visibility recovery in this window. Brands still 10%+ below baseline at Day 90 typically have a migration error that wasn't caught — escalate for forensic review.

Rollback Plan

Every migration needs a documented rollback plan in case launch reveals catastrophic issues. The plan covers:

• DNS revert path (route domain back to old infrastructure)
• Redirect rule revert path (disable new redirects, re-enable old structure)
• Communication plan for the marketing team
• Decision threshold for rollback (e.g., "rollback if 50%+ of priority keywords drop 5+ positions in first 24 hours")

Most migrations don't need to roll back, but the plan being documented prevents panic decisions when issues surface. Brands without a rollback plan often roll back unnecessarily because they can't quickly distinguish "expected post-launch fluctuation" from "catastrophic failure."

Common Migration Mistakes

Six mistakes consistently cause migration traffic losses across brands.

1. Migrating the design without migrating the SEO infrastructure. Designers and developers focus on the visible site. Schema, robots.txt, redirects, and analytics get treated as afterthoughts. Result: site looks great, traffic disappears.

2. Skipping the redirect map review. A second pair of eyes catches errors that the original mapper misses. Skipping the review saves a day and costs a quarter of traffic.

3. Not preserving image URLs. Image URLs change during CMS migrations and break image search rankings. The full image URL migration approach is out of scope for this checklist but worth dedicated planning for image-heavy categories (e-commerce, recipe sites, news).

4. Launching during high-traffic windows. Launches that go live on Monday morning or before a marketing campaign expose users to any post-launch issues. Launch during low-traffic windows (weekend mornings, late evenings) so issues are resolved before peak audiences arrive.

5. Not updating internal documentation. Marketing teams that don't update internal docs (briefs, content style guides, URL conventions) post-migration produce content that doesn't fit the new site structure. Update docs as part of the migration deliverable.

6. Treating migration as a one-time event. The migration ends 90 days post-launch, not on launch day. Teams that declare victory at launch and move on miss the long-tail recovery work that determines whether the migration was actually successful.

Migration Timeline

A realistic timeline for a typical mid-market migration (50–500 URLs, single domain, CMS replatform):

| Phase | Duration | Activities | |---|---|---| | Discovery | 2–3 weeks | URL inventory, ranking baseline, redirect map drafting | | Build | 4–8 weeks | New site build, schema implementation, integration | | Staging | 2–3 weeks | Staging crawl, schema validation, redirect testing | | Launch | 1–2 days | Cutover sequence, initial validation | | Post-launch | 4 weeks active monitoring + 8 weeks comparison | Daily/weekly checks, regression resolution |

Total: 12–20 weeks from kickoff to declared-success migration. Compressing this timeline below 8 weeks dramatically increases failure risk. Stretching it past 24 weeks adds stakeholder fatigue without reducing risk further.

For migrations involving domain changes, scope expansion, or category overhauls, add 4–8 weeks. For migrations involving headless replatforms, see Headless CMS for SEO and GEO for additional considerations.

---

Want a migration plan reviewed before launch? Request a free AEO audit. Our team will assess your migration plan against the 14-step checklist, identify gaps, and deliver a pre-launch risk report within 5–7 business days. Capconvert has executed 100+ website migrations across 20+ countries since 2014 — this checklist is the framework we use on every one.