Technical SEO Checklist for Any CMS Migration

This is a checklist, not a narrative — the specific, concrete items that determine whether a CMS migration preserves your search rankings or quietly tanks them over the following month. Platform-agnostic; applies whether you're moving to or from any CMS.
Table of Contents
- Before Migration
- Build the Redirect Map
- During Migration
- Immediately at Launch
- The First 12 Months After Launch
- Frequently Asked Questions
- What's the single most common mistake on this checklist?
- Is a 302 ever acceptable during migration?
- How long should I actually wait before declaring the migration a success?
- The Bottom Line
- Sources
Before Migration
- Export at least 12 months of Google Search Console data — you can't measure recovery or diagnose a ranking drop without a pre-migration baseline.
- Export Core Web Vitals field data from CrUX before touching anything — post-launch performance claims are unverifiable without this.
- Crawl and export your complete current URL list (a tool like Screaming Frog, or your current CMS's own export) — this becomes the source list for your redirect map.
- Document current meta titles, descriptions, and canonical tags for every indexed page.
- Identify your highest-traffic and highest-converting pages specifically — these get manual verification priority after launch, not just automated checks.
Build the Redirect Map
A 1:1 redirect map using 301 permanent redirects must be completed before launch, not after, to preserve the link equity built into every indexed URL on the old site. Use 301 redirects, not 302s — 301s transfer link equity to the new URL; 302s signal the move is temporary and equity transfer is not guaranteed.
- Map every old URL to exactly one new URL — 1:1, not many-to-one unless genuinely consolidating pages.
- Use 301 (permanent) status codes specifically, never 302 for a real, permanent migration.
- Avoid redirect chains longer than 2 hops — each additional hop reduces equity passed and slows crawl speed.
- Test every redirect before launch, not after — a broken redirect map found post-launch has already cost you crawl budget and user trust.
During Migration
- Stage the new site on a non-indexed environment first, and verify robots.txt/meta-robots settings before it goes anywhere near production.
- Double- and triple-check that the staging environment's noindex directive does not carry over to the live launch — this specific mistake can cause index loss within days.
- Migrate structured data (JSON-LD) alongside content, not as a follow-up task — don't launch without it if the old site had it.
- Preserve or improve Core Web Vitals — verify against your pre-migration CrUX baseline, not just a lab test.
- Update your XML sitemap to reflect only new URLs, and submit it to Search Console immediately at launch.
Immediately at Launch
- Update internal links to point directly to new URLs — don't rely on redirects for your own internal linking, since that wastes crawl budget and risks redirect chains.
- Verify canonical tags point to the correct new URLs, not leftover staging or old-domain values.
- Confirm the redirect map is live and working on the actual production domain, not just staging.
- Submit the new sitemap and request re-indexing of key pages in Search Console.
- Check hreflang tags if the site is multilingual — these need updating alongside URL structure.
The First 12 Months After Launch
301 redirects should remain live for a minimum of 12 months after migration. During this window, search engines consolidate ranking signals to the new URLs and external sites re-crawl and update their links. Removing redirects before this period closes risks losing link equity and causing 404 errors for pages still being discovered via old links.
- Keep every redirect live for a full 12 months minimum — do not decommission the old URL structure early, even if it feels safe to.
- Monitor Search Console weekly for the first month, then monthly — watch for crawl errors, sudden impression drops, or unexpected 404s.
- Expect traffic to stabilize within 4-8 weeks for most sites, longer for larger sites — don't panic at week 2, but do investigate anything still declining at week 10.
- Reach out to high-value external sites linking to old URLs and ask them to update to the new URL directly, rather than relying solely on the redirect.
Frequently Asked Questions
What's the single most common mistake on this checklist?
Carrying over a noindex meta tag from the staging environment to production — a simple oversight that can cause real, fast index loss, and one that's easy to catch with a single manual check before DNS actually flips.
Is a 302 ever acceptable during migration?
Only if the move is genuinely temporary (an A/B test, a short-term promotional redirect) — for a real, permanent platform migration, 301 is the correct choice every time, since 302s don't reliably transfer accumulated ranking signal.
How long should I actually wait before declaring the migration a success?
8-12 weeks at minimum, watching Search Console the whole time — traffic typically stabilizes in 4-8 weeks, but a slower recovery on a larger or more complex site isn't automatically a failure, just worth continued monitoring.
The Bottom Line
Most SEO-damaging CMS migrations fail on execution, not platform choice — a missing redirect, a stray noindex tag, or 301s decommissioned too early. Work through this checklist in order rather than treating any single step as optional. See our companion guide on the ranking-preservation mechanics behind these steps for the reasoning behind each item.




Comments