Migrating to a Custom CMS Without Losing SEO Traffic: The 50-Point Checklist

A poorly executed migration can cost you years of SEO progress overnight. We have seen sites lose 60-80% of their organic traffic in a matter of weeks, all because a few technical details got missed during a replatform. One client came to us after losing 71% of their traffic in three weeks post-launch. The entire cause: 340 URLs that had been mass-redirected to the homepage instead of their equivalent new pages. Google treated every single one as a soft 404 and stripped the ranking signals those pages had built up over four years. The good news? Almost every migration disaster is preventable. Below is the exact 50-point checklist we use to move sites to a custom CMS without handing Google a reason to drop your rankings.

Why Migrations Go Wrong in the First Place

Most migration failures do not come from one big mistake. They come from a pile of small ones that add up: a few hundred broken redirects, some missing meta descriptions, a sitemap that never got updated. Google notices all of it, and it notices fast.

The other thing that trips people up is timing. Teams get excited about the new design or the new CMS features, and SEO becomes an afterthought that gets bolted on right before launch. By then, it is too late to catch the stuff that actually matters.

The fix is simple in theory: treat SEO as part of the migration project from day one, not a QA step at the end. Here is how to actually do that.

Who Should Own This Checklist

A CMS migration touches every layer of your site, which means it needs more than one person watching it. Here is how responsibility should be split across a typical team:

One practical note: the person running the post-launch GSC monitoring should not also be the person executing the launch. You need a second set of eyes on the live site within the first 48 hours.

Checklist at a Glance

This checklist is split into five phases. Phase 1 is where 80% of your traffic protection actually happens. If you rush it, nothing in Phases 2 through 5 will save you.

Phase 1: Pre-Migration Audit and Planning

This is where 80% of your traffic protection happens. Skip this phase and no amount of post-launch fixing will fully save you.

1. Crawl your entire current site using Screaming Frog or Sitebulb, and export every single URL. This is your baseline.
2. Pull your full backlink profile from Ahrefs, Semrush, or GSC so you know exactly which pages have link equity worth protecting.
3. Export Google Search Console data for the last 16 months, covering clicks, impressions, and rankings by page.
4. Identify your top-traffic pages using Analytics, and flag them as high priority for the migration team.
5. Document every indexed URL using a site: search, since your CMS crawl and Google's index do not always match.
6. List all current meta titles and descriptions so nothing gets lost when content gets moved.
7. Audit your current URL structure and decide upfront whether it is changing. Changing URLs unnecessarily is one of the biggest traffic killers in any migration.
8. Map old URLs to new URLs in a spreadsheet, one row per page, no exceptions. This is the single most critical deliverable of the entire project.
9. Identify orphaned pages that still get traffic but are not linked from anywhere obvious.
10. Check for existing redirect chains so you do not build new redirects on top of old broken ones.
11. Audit your internal linking structure, especially breadcrumbs, footer links, and related-post modules.
12. Review your current robots.txt and note anything being blocked or allowed on purpose.
13. Pull your current XML sitemap and compare it against your crawl to catch discrepancies.
14. Document structured data currently in use, including schema markup for reviews, FAQs, products, local business, and anything else.
15. Check current page speed and Core Web Vitals so you have a benchmark to compare against post-launch.
16. Confirm hosting and server setup for the new CMS, including SSL certificate handling.
17. Set a realistic migration timeline. Rushed migrations are where most mistakes happen. Give yourself at least four weeks of staging time for a site over 500 URLs.
18. Build a staging environment that mirrors the new CMS exactly, and make sure it is blocked from indexing with a noindex meta tag and a Disallow: / in robots.txt. You will remove both of these before going live. Keep that on a checklist you cannot lose.

Phase 2: URL Structure and Redirects

This is the single most important technical piece of any migration. Get this wrong and everything else you did right will not matter.

19. Create 301 redirects for every single URL, not just the important ones. Google penalises gaps, not just wrong redirects.
20. Avoid redirect chains (URL A to B to C). Redirect straight from old to final destination.
21. Never mass-redirect everything to the homepage. Google treats this as a soft 404 and it tanks trust fast. Every URL needs its own destination that genuinely matches the original content.
22. Test every redirect on staging before launch, not after.
23. Preserve URL structure where possible. If you do not have a strong reason to change URLs, do not change them.
24. Use 301s, not 302s, for permanent moves. This one gets missed constantly and it matters for link equity transfer.
25. Check for case sensitivity issues between old and new URL structures.
26. Confirm trailing slash consistency across the new CMS.
27. Set canonical tags correctly on every page in the new system.
28. Update or redirect any UTM-tagged or parameter URLs that were driving traffic or conversions.

Phase 3: Content and On-Page Elements

Redirects get you to the right page. This phase makes sure that page is still worth ranking.

29. Migrate all meta titles and descriptions exactly, or improve them deliberately. Never leave them blank.
30. Preserve heading structure (H1, H2, H3) on every migrated page.
31. Migrate all image alt text, since this often gets dropped in CMS transfers.
32. Check image file names and compression did not get reset to generic defaults during the move.
33. Preserve or rebuild internal links within body content, not just navigation.
34. Migrate all structured data (schema markup) and validate it with Google's Rich Results Test.
35. Keep author bios and E-E-A-T signals intact, especially for YMYL content like health or finance pages.
36. Preserve publish and updated dates where accurate. CMS migrations often reset these to the launch date, which signals to Google that years of content is brand new.
37. Check that blog categories and tags redirect properly, not just individual posts.
38. Confirm pagination is handled correctly on blog and category pages.
39. Review and preserve FAQ sections, since these often carry featured snippet rankings.

Phase 4: Technical SEO Setup on the New CMS

40. Submit a new, clean XML sitemap to Google Search Console immediately at launch.
41. Update robots.txt to reflect the new site structure and confirm nothing important is blocked by accident.
42. Critical: Remove your staging noindex and robots.txt Disallow before going live. This is the most catastrophic and most common migration mistake. A site can look perfectly functional while being completely invisible to Google because a noindex meta tag or Disallow: / was copied from staging and never removed. Check yourdomain.com/robots.txt within the first hour of launch. Use GSC URL Inspection on your three most important pages and confirm they show as indexable. Check this before you tell anyone the site is live.
43. Verify canonical URLs render correctly across templates, not just on a few sample pages.
44. Set up 404 monitoring so you catch broken links fast instead of finding out weeks later.
45. Test mobile rendering across your key templates, since custom CMS builds can behave differently on mobile.
46. Re-check Core Web Vitals on the live new site and compare against your pre-migration benchmark.
47. Confirm hreflang tags are correct if you are running multiple regional or language versions.
48. Set up proper HTTPS across the entire site, with no mixed content warnings. Also lower your DNS TTL to around 300 seconds at least 48 hours before launch, so the new IP address propagates almost immediately after you flip DNS and minimises the window where visitors still hit the old server.

Phase 5: Post-Launch Monitoring

The work is not done at launch. This is where most teams relax too early, and where problems turn into permanent losses.

48. Monitor Google Search Console daily for the first two weeks, watching indexing status and crawl errors closely. A spike in 404s or a drop in indexed pages needs immediate attention.
49. Track rankings for your top 20 to 30 keywords daily for the first month, so you catch drops before they compound. Systemic drops across an entire section usually point to redirect, template, or metadata problems in that section.
50. Keep old redirects live for at least 12 months. Google can take a while to fully process a migration, and some backlinks in the wild never update their hrefs. Turning redirects off early is one of the most avoidable causes of long-term traffic loss.

What to Do If Traffic Drops After Migration

Some fluctuation in the first two to four weeks is normal. Google needs time to re-crawl the new site and process all the redirects. But if you see a significant, sustained drop after week four, here is how to diagnose it:

The Mistakes That Cause the Most Damage

If you only remember three things from this checklist, make it these:

Final Thought

Migrations feel risky because they are risky, but only when SEO gets treated as an afterthought. Work through this checklist properly, give yourself enough runway before launch, assign clear ownership to each phase, and keep watching the data closely after you go live. Do that, and a CMS migration becomes a growth opportunity rather than a traffic disaster.

If you are planning a migration and want a second pair of eyes before anything goes live, our custom CMS development and technical SEO teams handle migrations from planning through post-launch monitoring. Get a free audit and we will tell you exactly what your current site is risking before you move.

Frequently Asked Questions

What is the biggest SEO risk during a CMS migration?

Missing 301 redirects. Every old URL that does not redirect to its equivalent new page loses its link equity and rankings. Mass-redirecting to the homepage is almost as bad because Google treats it as a soft 404 and strips the ranking signals.

How long does it take to recover SEO traffic after a migration?

If the migration is done correctly, recovery is usually within four to eight weeks as Google re-crawls the new site and processes the redirects. If significant mistakes were made, recovery can take three to six months.

Should I keep my old URL structure when migrating to a custom CMS?

Yes, wherever possible. Changing URLs is one of the biggest traffic killers during a migration. Keep your existing URL structure unless there is a specific, compelling reason to change it.

What is a soft 404 in CMS migrations?

A soft 404 happens when a page returns a 200 OK status but shows content Google considers empty or irrelevant, like redirecting hundreds of old URLs to the homepage. Google detects these and removes the ranking equity those URLs held.

How do I check if my staging noindex is still active after launch?

Check your live robots.txt at yourdomain.com/robots.txt for any Disallow: / directives. Then use Google Search Console URL Inspection on key pages immediately after launch to confirm they are indexable.

---

Planning a migration and want someone to sanity-check the setup before you go live? Get a free SEO audit, no sales call required.