CMS Migration SEO Checklist for Zero Traffic Loss

CMS migrations have a well-documented failure pattern: 50% or more traffic loss, followed by a recovery that can stretch beyond a year if the root causes aren’t diagnosed quickly.

Whether your migration tanks your rankings or preserves them is determined by what happens in the 6 weeks before cutover and the 2 weeks that follow after.

This checklist will cover: 

• The pre-migration audit. 
• Redirect mapping at scale. 
• Metadata preservation. 
• AI citation continuity.
• The launch window.

We’ll also share a practical diagnostic playbook for managing week-one ranking drops, but for a broader introduction to CMS migration strategy, Multidots’ existing guide is the right starting point.

Why CMS Migrations Lose Rankings

Whereas well-run migrations recover in 2 to 6 weeks, botched ones average over 500 days to recover, per a study of 892 migrations. This asymmetry is the reason the checklist matters more than the platform choice.

When the process is right, migrations have produced documented year-over-year traffic increases of 200% or more. But arriving at this type of outcome is determined by execution, not by which CMS you’re moving to or from.

Coordination between teams usually decides the outcome. Engineering owns the cutover: DNS, deployment, staging validation, and the final go/no-go decision. SEO owns everything that follows: rankings, indexation, and citation continuity.

Failing to properly align these teams is how significant ranking losses can happen, even when everyone believes they’ve followed best practices.

This typically shows up in one of 3 ways:

1. Redirect gaps that leave valuable URLs returning 404s. 
2. Canonical drift that quietly rewrites your original configuration. 
3. Metadata that doesn’t survive the migration intact.

The good news is that every one of these issues is detectable before you launch. None should become an unpleasant surprise after cutover, which is exactly what the audit below is designed to prevent.

Pre-Migration SEO Audit and Baseline

Before a single redirect rule is written, you need a reliable source of truth. That’s what the audit provides, and every phase that follows depends on it.

URL inventory snapshot

Start with a full Screaming Frog crawl of your current domain, then export the last 16 months from Google Search Console (GSC). The crawl shows what’s live and indexed. GSC shows what’s ranking. While crawls miss indexed pages without internal links, GSC misses de-indexed pages that are still attracting backlinks.

Redirect map seed file

Export backlink targets from Ahrefs, then combine them with your crawl and GSC exports into a single CSV, following Google’s site move guidance. Every URL with traffic or backlinks belongs here before you start writing pattern rules.

Structured data and metadata baseline. Export Schema.org markup, meta titles, descriptions, canonicals, hreflang, alt text, and robots directives for every URL. This becomes the benchmark your staging environment is validated against.

AI citation baseline. Sample the top 50 to 100 queries your site currently ranks for across ChatGPT, Perplexity, and AI Overviews, then record which URLs are cited. As AI citations don’t inherit 301 redirects the same way traditional crawl signals do, you’ll use this baseline to monitor post-launch performance.

Pre-launch trap radar. Surface many-to-one redirects, redirect chains, redirect loops, canonical conflicts, and headless rendering gaps during the audit rather than during cutover. They’re inexpensive to fix in staging and far more painful once the domain has switched.

Building Your Redirect Map

A 50,000-page site can easily generate anywhere from 5,000 to 50,000 redirect rules once historical URL structures, soft-deleted pages, and taxonomies that don’t map cleanly to the new CMS are factored in. Building that map takes weeks. Multidots’ 2TB Sitecore migration shows what that process looks like at enterprise scale, while WordPress VIP migrations typically develop redirect rules alongside engineering throughout the project.

For permanent URL changes, use 301 redirects. Temporary redirects such as 302 or 307 may be appropriate when the original URL is expected to return.

Map URL Patterns Before Individual Pages

Start by grouping URLs into template types: articles, products, categories, taxonomies, and archives. Pattern rules written at the template level cover thousands of URLs simultaneously and form the foundation that the individual exceptions are layered onto.

Run the pattern rules first, then handle the exceptions. Generate redirect rules from those pattern clusters, then implement them at the most appropriate layer for your architecture. Depending on your hosting environment, that could mean CDN or edge redirects, web server redirects, application-level redirects, or WordPress-level redirects.

Soft-deleted pages need their own attention. Old product pages, retired categories, and deprecated tags may no longer exist in the CMS but can still be crawled by Googlebot.

Test Redirect Rules in Staging

Before anything goes live, crawl the staging environment with Screaming Frog and enable “follow redirects.” You’ll quickly surface redirect chains, loops, and 404s while they’re still easy to fix.

Next, compare canonicals with redirect destinations. If URL A redirects to URL B, while URL B canonicalizes back to URL A, you’ve created a configuration Google explicitly flags because it can suppress indexation for both pages.

Finally, spot-check the results manually: the top 100 URLs by traffic, the top 100 by backlinks, plus a random sample of 200 long-tail URLs. If they all land where they should, you can be confident your pattern rules are behaving as expected before approving cutover.

Preserving SEO Data Through Cutover

Seven SEO fields need to make the journey intact: meta titles, meta descriptions, canonicals, hreflang, structured data, alt text, and robots directives. Each one has to be migrated and verified separately because each can fail in its own way – as Multidots’ OCM-to-WordPress walkthrough demonstrates.

Silent canonical loss is the biggest trap. Most CMS platforms default to self-canonicals during import. So even if your export file contains the correct canonical, the new CMS may quietly overwrite it with one pointing at the new URL. One default setting. One missed check. Potentially, every imported page becomes a de-indexing candidate. Spot-check staging URLs against the canonical baseline created during the audit to resolve this. If they don’t match, don’t move forward. 

Schema migration drives both rich-result eligibility and AI citation, so compare rendered schema on staging against Google’s site-move guidance before approving cutover. And don’t stop at the raw markup. If schema exists in the HTML but is injected or modified by JavaScript, validate it in the fully rendered page rather than relying only on the initial HTML response. Validation should always confirm the rendered output Google is actually able to process.

Headless render gaps are the least visible failure mode. Googlebot processes JavaScript with a delay, so titles, descriptions, and structured data injected client-side may never be visible when the page is crawled. Diff the rendered HTML on staging against the source at first contentful paint to confirm exactly what Googlebot will see.

Protecting AI Search Citations During Migration

Traditional redirects help search engines discover and consolidate signals for the new URL, but AI-powered search and answer engines may use different retrieval, indexing, and citation mechanisms. Because of this, citation continuity should be monitored separately from traditional search rankings. So when URLs change, citations in ChatGPT, Perplexity, and AI Overviews can drift or disappear altogether, even when every redirect is working and every SEO signal has transferred perfectly. That’s why AI citation continuity needs its own workstream alongside your redirect map.

Your pre-migration audit already tells you which URLs are cited and for which queries. After launch, check again at weeks 1, 2, and 4 to confirm those citations have followed the new URLs rather than breaking.

If they haven’t recovered by week 4, publish a linkable update targeting the affected URL cluster, backed by the structured data and entity signals that reinforce the connection between the new URL and the topic the old one ranked for. Then validate the schema before checking again.

Launch and the First 48 Hours

Following a clear launch sequence helps reduce the risk of avoidable indexing and crawl issues in the first few hours after migration. The launch sequence has 4 steps in order: 

1. DNS cutover. 
2. Sitemap re-submission in GSC. 
3. Change of Address tool submission. 
4. Removal of the staging robots.txt block.

That last step is easy to miss, but consequential. Leave the staging robots.txt in place after cutover and Googlebot can’t crawl your live site. Worse, it won’t announce that it’s happening.

Content lock should begin 24 to 72 hours before cutover, once staging-redirect testing is signed off. Give one named owner responsibility for reviewing every in-flight content update during that window. Changes published after staging validation but before launch can introduce redirect gaps that were never part of the test set.

As soon as DNS propagation completes, run an indexing check. Review the top 100 URLs by traffic and the top 100 by backlinks, confirming the destination URL, 200 status, and expected canonical. Then compare everything against the GSC coverage report. “URL not found” errors appearing in the first 24 hours usually point to redirect gaps that need fixing immediately.

Run real-user monitoring at the same time. Core Web Vitals should match the pre-migration baseline, and JavaScript errors shouldn’t appear at first contentful paint. Beyond confirming those SEO-critical signals are intact, standard launch monitoring is enough.

Diagnosing a Post-Migration Traffic Drop

The week-one drop has a recognizable pattern. Day two: Clicks are down 30%. GSC suddenly reports hundreds of “URL not found” errors. 9 times out of 10, you’re looking at 1 of 2 problems: canonical drift, where the new CMS overwrote the original canonical setup during import, or redirect gaps caused by URLs that never made it into the final rule set.

One study of 892 migrations found botched projects took, on average, more than 500 days to recover. Well-managed migrations typically bounce back within 2-6 weeks. The deciding factor was how disciplined the diagnostics were during those first two weeks.

Follow this order: 

• Crawl diff. 
• GSC coverage.
• Schema diff. 
• Rendered HTML diff.
• Link diff. 
• Core Web Vitals. 
• AI citations. 

Each step either confirms or rules out the most likely causes before you spend time on more expensive investigations.

Triage Canonicals, Redirects, Then Citations

When issues do appear after launch, the order you investigate them matters. Start with the problems most likely to affect indexation, then work through the remaining validation checks.

1. Canonical drift: A 30-minute spot check against the pre-migration baseline is enough. If canonicals are broken, every affected page quietly becomes de-indexable. That’s potentially a site-wide problem, which is why this check comes first regardless of what GSC reports.
2. Redirect coverage: With canonicals confirmed, filter the GSC coverage report for “URL not found” errors and compare the results with your redirect map. Missing rules are usually straightforward to fix. The real question is whether you’ve found isolated gaps or evidence that an entire template rule failed.
3. Citations third: Once canonicals and redirects are healthy, validate your schema, check AI citation status, and confirm rich-result eligibility. At this stage, you’re simply verifying that structured data survived the migration and AI citations have followed the new URLs.

How to Decide When to Escalate

If new URLs are indexed but rankings stay flat during the first couple of weeks, wait. Index refreshes take time, and flat rankings alone don’t point to a structural issue.

The real trigger for escalation is crawl coverage failure. Pages submitted through GSC still aren’t indexed by week two. Crawl reports start showing 4xx or 5xx errors. Schema breaks across a significant group of URLs. Any of those signals a problem that won’t fix itself with patience.

Recovery timelines vary for a reason. Well-managed migrations often recover within weeks, but no partner should promise a fixed timetable without first understanding what the crawl data actually shows.

When to Bring In a Migration Partner

There are four conditions where bringing in a specialist is worth the investment: 

1. You’re migrating a high-traffic site where mistakes carry real business risk. 
2. You’re dealing with more than 50,000 pages, and redirect mapping needs structured engineering support. 
3. AI citation continuity is one of your success criteria. 
4. The combined SEO and engineering workload has outgrown your team’s capacity to coordinate.

If any of these scenarios fit, look for a team that starts with the audit before the project scope is finalized, can point to case studies on your current platform (Sitecore, AEM, Drupal, or Contentful), and won’t promise recovery timelines nobody can actually control.

Credentials help narrow the field. Only around 12 agencies worldwide hold WordPress VIP Gold Partner status. It’s a strong signal of direct platform access and proven enterprise migration experience, which makes due diligence a whole lot simpler.

Zero traffic loss is won during the audit. Your URL inventory and AI citation baseline are the deliverables that shape everything that follows. Any partner worth hiring will start there, long before the migration itself begins.

Book a call with Multidots to get started. We run enterprise WordPress migrations end-to-end, with in-house technical SEO and engineering working together from the initial audit through post-launch monitoring.