SaaS SEO migration case study: replatform without traffic loss
**A CMS swap can wipe out rankings fast if URLs, canonicals, and redirects drift even a little.** In this case study, a SaaS replatform held organic traffic flat through cutover by fixing the migration map before launch.
The numbers
What changed
On 2025-09-18, the client moved from a legacy CMS to a SaaS stack and changed the URL structure at the same time. The old site had about 48,000 indexable URLs. The new site launched with 47,200 mapped URLs after consolidation, pruning, and parameter cleanup.
The risk was simple: if Google saw the new version as a different site, the team would lose the rankings that were driving demo requests. The target was not “more traffic later.” The target was no measurable drop at launch.
I treated it like a technical SEO migration, not a content project. That meant Performance › Search results for the baseline, Indexing › Pages for URL-state verification, and Links › External links to understand which pages had enough authority to matter most. For a SaaS migration, that order matters more than the CMS brand.
This is the kind of project that fits SaaS SEO work: product-led pages, docs, pricing, integrations, and a lot of long-tail URLs that look low-value until you remove them.
Why migrations fail
Redirects are mapped by pattern, then audited by sample
The fastest way to break a migration is to send every old URL to the homepage. I mapped the legacy paths to new destinations by template, then tested a sample set of 312 URLs across blog, product, docs, and comparison pages.
Canonicals must match the final URL graph
If the canonical points to the old version, Google gets mixed signals. I checked canonical rules against the final site map and cross-checked them with learn/canonical-tags-complete-guide before launch.
Index coverage needs a clean before/after line
The old site had a lot of low-value variants. The new site needed a cleaner crawl path, not just a prettier template. I compared Indexing › Pages before and after to make sure Google was seeing the intended set, not duplicate clutter.
External links define the recovery priority
Pages with backlinks deserve the most careful handling. When a redirect is wrong on a linked URL, the recovery cost goes up fast. I used Links › External links to prioritize redirects that protected the strongest pages first.
Audit setup
I started the audit on 2025-08-29, three weeks before launch. The first sprint was all about freezing the URL inventory. I exported the old sitemap set, paired it with crawl data, and built a redirect matrix in Notion so every source URL had exactly one destination.
The staging site was blocked from indexing, but not hidden from testing. I used direct fetch checks, server header inspection, and GSC validation once the preview domain was visible to Google. The key reports were Indexing › Sitemaps, Indexing › Pages, and Settings › Crawl stats.
The baseline numbers were clean enough to trust: 19,400 organic clicks/month, 402,000 impressions/month, and an average position of 13.1. The site was not recovering from a penalty. It was simply sitting on a brittle architecture that would have been easy to break.
That distinction matters. A saas migration seo project is usually not about fixing a ranking collapse. It is about preventing one.
Redirect mapping
curl -I https://www.example.com/old/pricing
curl -I https://www.example.com/new/pricing
# Expected
# HTTP/2 301
# location: https://www.example.com/pricing/
curl -I https://www.example.com/old/integrations/slack
curl -I https://www.example.com/new/integrations/slack
# Validate that each old URL returns one hop only
# and lands on the final indexable destination.Canonical rules
The canonical plan was strict: self-referencing canonicals on every indexable page, no cross-canonical drift, and no canonical pointing to a redirected or parameterized URL. That sounds basic, but it is where many migrations leak authority.
For the product and pricing templates, I compared rendered HTML to the server-side output. I also checked pagination, faceted navigation, and localized variants. The SaaS stack created 35 language paths in staging, but only 12 were meant to be indexable at launch. Everything else had to stay out of the index.
I documented the canonical logic in the audit and linked the team to redirect status and canonical behavior so the implementation notes were tied to actual search-engine behavior, not assumptions.
The most useful screenshot in the audit was screenshot-gsc-sample.png: it showed the old URL set holding steady in Indexing › Pages while the new URLs started to replace them one for one after cutover.
How the cutover held
- 01
Pre-launch crawl freeze
I locked the final URL inventory on 2025-09-11. That list included 1,284 priority URLs and 7,900 lower-priority URLs. Anything not mapped was either removed, consolidated, or noindexed by template rule.
- 02
Redirect QA on staging
Every redirect group was tested for hop count, canonical destination, and query-string handling. I caught 14 broken mappings before launch, including 4 that would have sent high-value pages to the wrong category cluster.
- 03
Launch-day checks
On cutover day, I checked the first crawl wave, server logs, and GSC coverage deltas. The site stayed stable: organic clicks went from 19,400/month before launch to 19,680/month in the first full month after launch, which is basically flat for a CMS migration.
- 04
Post-launch tuning
The only meaningful fluctuation was on a handful of comparison pages. Those were fixed by tightening internal links and updating canonicals, then monitored for 21 days. By the end of the second sprint, the new URL structure was fully absorbed.
Before and after
| Field | Before launch | After launch |
|---|---|---|
Organic clicks / month | 19,400 | 19,680 |
Impressions / month | 402,000 | 409,500 |
Average position | 13.1 | 12.8 |
Tracked priority URLs | 1,284 | 1,284 |
Broken redirect mappings | 14 found | 0 live |
Indexable language paths | 12 | 12 |
What I checked next
After launch, I kept watching Performance › Search results for query-level movement, not just totals. That caught the pages that were holding steady overall but losing clicks on a few commercial queries.
I also checked Experience › Core Web Vitals because a new CMS often changes script load order, image behavior, and layout shift. The pages were not perfect, but they stayed inside the same performance band as before. No migration win survives if the new stack makes the pages slower.
For structured data, I verified Enhancements › Breadcrumbs, Enhancements › Product snippets, and Enhancements › FAQ. The templates were intact, which meant the migration did not strip rich result eligibility. That saved the team from a second cleanup pass.
If you want the general framework behind this kind of move, site migration SEO is the service page that covers the full playbook. If the migration already went sideways, ranking recovery is the next stop.
FAQ
How did you avoid traffic loss during the CMS swap?
By freezing the URL inventory before launch, mapping every legacy URL to one final destination, and checking canonicals against the new template output. The result was a flat transition instead of a drop.
What was the biggest migration risk?
The biggest risk was a many-to-one redirect pattern that would have collapsed distinct pages into broad buckets. That is usually where SaaS migrations lose relevance signals and internal link equity.
Did indexing change after launch?
Yes, but in the intended direction. The new site reduced duplicate variants and kept only the URLs meant to rank. Indexing › Pages confirmed the old URLs were replaced rather than duplicated.
What if the migration had already launched broken?
Then the process changes from prevention to recovery. You would move into log-file review, redirect patching, and GSC validation, which is the territory covered by site ranking recovery.
Do canonicals matter if redirects are correct?
Yes. Redirects tell Google where the old URL moved. Canonicals tell Google which version should be indexed. If those signals disagree, you create avoidable ambiguity.