Migrating Off a Legacy CMS Without Losing Your SEO
Rebuild on a modern stack and you can watch a decade of rankings evaporate — because the authority lives in the URLs you're about to delete. Here's the migration checklist I actually run, using this site as the example.
·8 min read ·Pradeep Saran
There’s a specific kind of pain that comes a few weeks after a proud relaunch: the new site is faster, cleaner, and built on a stack you actually like — and your search traffic is quietly falling off a cliff.
It happens because the value Google assigned to your old site isn’t attached to your brand or your design. It’s attached to URLs — hundreds of them, each carrying years of crawl history and inbound links — and a rebuild usually deletes most of them without a forwarding address.
I just did this migration on this very site. devsaran.com ran for over a decade as a Drupal site with a large blog; the rebuild is a small, modern Astro site with about ten pages. Google still had roughly 287 old pages in its index. That gap is exactly where SEO goes to die — unless you treat the migration as a redirect and consolidation problem, not a redesign. Here’s the checklist I run.
1. Inventory what Google actually knows — before you delete anything
You cannot preserve what you haven’t measured. Before the old site goes away, pull the real picture from Google Search Console:
- Page indexing report — how many URLs are indexed, and the reasons the rest aren’t.
- Performance → Pages — sorted by clicks and impressions. These are the URLs that still earn traffic; they are your priority list.
- Links → Top linked pages — the URLs other sites point at. That’s borrowed authority you don’t want to drop.
On devsaran.com this surfaced exactly what mattered: a handful of old /blog/... posts and theme pages still pulling impressions, plus a long tail of legacy paths. You’re not going to save everything — you’re going to save the URLs that carry weight.
2. Map old → new with 301s — by pattern, not by hand
A 301 redirect tells Google “this moved permanently — pass the equity to the new location.” The mistake is doing it URL-by-URL (you’ll miss hundreds) or doing it bluntly (redirect everything to the homepage).
Redirect by pattern, to the closest relevant page:
# Old Drupal sections → nearest current equivalent
/drupal-theme/* → /open-source
/project/* → /products
/content/about-me → /about
The blunt version — /* → / — feels thorough and quietly backfires. When dozens of unrelated old pages all redirect to the homepage, Google treats that as a soft 404 and declines to pass the equity anyway. A redirect only counts when the destination is a genuine replacement for the source.
So: specific rules for sections that have a real successor; the homepage only as a last resort for content that truly has no equivalent.
3. Pick one canonical host and enforce it
Pick www or the apex (non‑www) — it doesn’t matter which, but pick one and force everything else to it with a 301. I canonicalize devsaran.com to the apex, the opposite of my product sites, specifically to preserve the old site’s history (it lived on www):
https://www.devsaran.com/* → https://devsaran.com/:splat (301, forced)
http://www.devsaran.com/* → https://devsaran.com/:splat (301, forced)
Skip this and Google sees http, https, www, and non‑www as up to four versions of every page — splitting authority and triggering “Duplicate, Google chose a different canonical than the user.” A single forced host plus a self‑referencing <link rel="canonical"> on every page collapses that into one.
4. Don’t advertise your dead ends
Some pages should exist but never rank: privacy policy, 404, utility pages. Two rules, and you need both:
- Mark them
<meta name="robots" content="noindex">. - Keep them out of your sitemap.
Doing only the first is a classic own-goal. If you noindex a page and list it in the sitemap, you’re inviting Google to crawl a URL you’ve told it to ignore — which it then files under “alternate page with proper canonical tag” or similar noise. Your sitemap should contain only the URLs you genuinely want indexed. (When I added a privacy policy to this site, it shipped noindex and filtered out of the sitemap in the same change.)
5. Migrate the analytics, not just the pages
A rebuild silently breaks measurement too. The old tracking tag is gone, the new site ships without one, and you lose continuity at the exact moment you most need to watch traffic.
Re-tag the new site against the same analytics property so the history is continuous — and if you care about privacy (you should), gate the tag behind consent so it only loads after the visitor opts in. Losing your rankings is bad; losing your rankings and having no data to see it happen is worse.
6. Tell Google you’re done — then be patient
Once the redirects and canonicals are live:
- Submit the new sitemap (and 301 the old
/sitemap.xmllocation to it — old caches still hit it). - Use “Validate Fix” on the Not found (404) and Soft 404 reports. This asks Google to recrawl the affected URLs; the ones that now redirect drop out of the report over the following days.
- URL-inspect your most important pages and Request Indexing for the handful that matter most.
Then set expectations. “Crawled — currently not indexed” is the bucket where a migrated site sits while Google decides whether the new pages deserve their old standing. It doesn’t clear because you asked nicely; it clears because you gave Google fewer, better, genuinely useful pages to index. The redirects preserve equity — content is what re-earns it.
7. Accept that some things should 404
The counterintuitive part: not every old URL deserves rescuing. Content that is genuinely gone — a dead campaign page, a removed feature — should return a clean 404 (or 410). That’s a correct, honest signal, and Google drops those URLs naturally. Trying to redirect every last one into a vaguely related page does more harm than a tidy 404. Save your redirects for URLs with real equity or a real successor; let the rest go cleanly.
The mindset
A CMS migration isn’t a redesign that happens to change some links. It’s a URL migration with a new design attached. Handle it that way — inventory first, redirect by pattern to real successors, enforce one canonical host, keep dead ends out of the sitemap, re-establish measurement, then tell Google and wait — and a relaunch becomes a chance to consolidate a decade of authority instead of forfeiting it.
It’s unglamorous work. It’s also the difference between a faster site that keeps its hard-won rankings and a beautiful new site that starts from zero.
Working on a marketplace or ordering platform?
I've spent 14+ years architecting exactly these systems — happy to talk through your platform, your stack, or a partnership.