# SaaS website migration SEO

> Redesigns, rebrands and CMS moves without losing rankings: URL mapping, redirect QA, staged launch, a rollback trigger and a fourteen day watch list.

Source: https://saas-marketing.net/playbooks/saas-website-migration-seo/
Topic: SaaS SEO
Type: playbook
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/playbooks/saas-website-migration-seo/

## Short answer

A SaaS site migration keeps its rankings when three things are true: every old URL with clicks, links or internal links resolves in a single 301 hop to the closest matching new URL, the new templates ship with the same indexable content and hreflang as the old ones, and nothing else changes for two weeks either side of the switch. Capture a crawl and a 16 month Search Console export before you touch anything, because you cannot recreate that baseline afterwards.

## Key takeaways

- Export a full crawl and 16 months of Search Console data before launch, because that baseline cannot be recreated later.
- Redirect every old URL in one hop to its closest match, and never redirect a deep page to the homepage.
- Retire rather than redirect any URL with zero clicks, zero referring domains and zero internal links over 12 months.
- A staging robots.txt or an x-robots noindex header shipped to production is the single most common cause of total loss.
- Freeze content and template changes for two weeks either side of the switch so any loss has one identifiable cause.
- Define the rollback trigger in writing before launch day, because nobody can make that call calmly at 2am.

---

A migration is the only SEO project where nothing happening counts as a win. Nobody gets a bonus for holding traffic flat through a replatform, and everybody remembers the quarter organic fell 40 percent because a staging robots.txt went live with the rest of the build.

This is the runbook for the three moves SaaS companies actually make: a redesign on the same domain, a CMS replatform, and a rebrand onto a new domain. The order of operations matters more than any single tactic in it.

## Which of the three migrations are you running?

Name it out loud before you plan anything, because the risk profile and the freeze window differ by a factor of three. A redesign that preserves URLs is a two week project with modest downside. A rebrand onto a new domain touches every signal you own at once.

The most common real world version is a replatform from WordPress or HubSpot CMS onto [Webflow](/guides/technical-seo-for-saas/) or a Next.js build on Vercel, driven by a marketing team that wants to ship pages without engineering. That move is usually correct. It also changes URL patterns, rendering and sitemap generation in one go, which is why it belongs in the medium to high row.

Marketing wants the new design, product wants the new CMS, and the founder wants the new name. Shipping all three in one release means that if organic falls 22 percent, three teams will spend six weeks arguing about which change caused it. Sequence them. Ship the replatform on identical URLs and identical copy, verify two weeks of flat data, then change the design, then change the name.

## The baseline you cannot recreate after launch

Capture the current state before a single file moves, because Search Console only holds 16 months and crawl data of a site that no longer exists is impossible to regenerate. This is the step teams skip when the launch date slips and it is the step that makes recovery possible.

**Pre migration capture, all dated and stored outside the CMS**

That last item earns its place. When a page loses rankings after a replatform, the fastest diagnosis is a side by side diff of old and new rendered HTML, and you can only do that if you saved the old one.

Sort the crawl by clicks and referring domains. The output is your priority list: usually 50 to 200 URLs that generate almost all the organic signups, plus a long tail that nobody has looked at in three years. Treat those two groups completely differently. The [technical SEO audit checklist](/checklists/saas-technical-seo-audit/) covers the wider site health work that should already be done before a migration adds to it.

**16 months** Maximum Search Console history available, which is why the pre launch export is not optional

## URL mapping rules, including what to retire rather than redirect

Map every old URL to exactly one new URL, in one hop, to the closest matching intent. Where no close match exists, do not invent one. Retire the page properly instead.

The decision rules that hold up:

| Situation | Action | Why |
| --- | --- | --- |
| Same page, new URL pattern | 301 to the equivalent page | One hop, direct match, no ambiguity |
| Three thin posts consolidated into one guide | 301 all three to the guide | Consolidation is legitimate when the new page genuinely covers all three |
| Old page with clicks but no equivalent | Build the equivalent, then 301 | Redirecting to a parent category loses the ranking within weeks |
| Zero clicks, zero referring domains, zero internal links in 12 months | 410 Gone | Retiring cleanly is better than a redirect to a weak match |
| Old integration or docs URL linked by a partner | 301 and keep it permanently | Partner directories update on a multi year cycle, if ever |
| Paginated or faceted URL from the old CMS | 410 or leave to 404 | These were never meant to rank and the redirect map should stay readable |

The rule everyone breaks is the fourth one. There is an instinct to redirect everything somewhere, and it produces a map where 900 dead URLs point at the blog index. Google treats an irrelevant redirect as a soft 404 anyway, so you get the same outcome with extra confusion in your reporting.

Before mapping, check where the new pages will live in the hierarchy. If the replatform is also your chance to fix a messy URL structure, do that thinking against a proper [site architecture](/guides/saas-site-architecture/) model rather than whatever the new CMS defaults to. And if part of the move involves pulling the blog off a subdomain, read the [subfolder versus subdomain](/comparisons/subfolder-vs-subdomain/) case first, because that decision is much harder to reverse than it looks.

Keep the map in a spreadsheet with five columns: old URL, new URL, reason, 12 month clicks, referring domains. Sort descending by clicks. Somebody senior signs off on the top 100 rows by hand. The rest can be pattern matched.

## How to QA four thousand redirects without opening four thousand tabs

Run the QA twice: once against staging with a host header override, once against production 30 minutes after DNS moves. Each pass is a list mode crawl of your old URL export, checked against four columns.

**Redirect QA pass**

Comparing the staging and production crawl exports catches the class of bug that only appears at the edge, where a Cloudflare or Vercel rule takes precedence over the application redirect and quietly strips a path segment. If you need a view on which crawler to standardise on for this, the [technical SEO crawler comparison](/tools/technical-seo-crawlers/) covers the list mode differences that matter here.

## Staged launch, DNS and CDN

Lower your DNS TTL to 300 seconds at least 48 hours before launch, so a rollback propagates in five minutes rather than a day. That single change is the difference between a bad hour and a bad weekend.

The launch sequence that works:

1. Freeze the old site 48 hours before. No publishing, no edits, no new redirects.
2. Final content sync from old CMS to new, then re-run the redirect QA against staging.
3. Drop TTL, confirm propagation with `dig` from three networks.
4. Cut DNS. Verify robots.txt, a sample of 20 redirects, and the XML sitemap within 10 minutes.
5. Submit the new sitemap in Search Console. For a domain change, file the change of address on the old property.
6. Keep the old origin running for 30 days. Not the DNS, the origin. If you need to serve something from the old stack you will be glad it still boots.

Leave the old XML sitemap accessible and submitted for about two weeks after cutover. It sounds wrong, but it gives Google a fast path to recrawl exactly the URLs that now 301, which pulls forward the discovery of your new URLs. Remove it once the indexed count on the new property stabilises.

For anyone running multiple language versions, the hreflang cluster has to be rebuilt in the new templates and validated before launch, not after. The failure mode is covered below, and the wider setup lives in the [international SaaS SEO guide](/guides/international-saas-seo/).

## The three failures that cause most of the losses

Almost every serious migration loss traces back to one of three things, and all three are detectable within an hour of launch if somebody is looking.

**Redirect chains ending at the homepage.** The signal is a crawl where hundreds of URLs show 2 or 3 hops and a final URL of `/`. It usually happens when a catch-all rule sits below the specific rules and swallows anything unmatched. Effect: the pages stop ranking within two to four weeks, and because the homepage still ranks, dashboards look survivable until the monthly report lands.

**Missing hreflang on the new templates.** The new CMS renders the page fine in every locale but the alternate tags were part of the old template and nobody ported them. The signal is a rise in impressions for the wrong country and a fall in clicks from your second largest market. Fix takes a day. Detection often takes six weeks, which is the real cost.

**Staging robots.txt or noindex headers shipped to production.** The most damaging and the most preventable. Either `Disallow: /` goes live in robots.txt, or the `x-robots-tag: noindex` header set on staging follows the build into production, which no robots.txt check will catch because it lives in the response header.

Curl your homepage and five template types immediately after cutover and read the response headers as well as the body. `curl -sI https://yourdomain.com | grep -i robots` takes four seconds. A noindex header on a Webflow or Vercel deployment looks completely normal in a browser, and it will deindex the site inside a week.

## The fourteen day watch list and the rollback trigger

Watch a fixed list on a fixed cadence, and write the rollback trigger down before launch day. Nobody makes a good reversion decision at 2am with a founder on the call.

| Window | What to check | Where | Escalate if |
| --- | --- | --- | --- |
| Hour 0 to 2 | robots.txt, x-robots headers, 20 sampled redirects, canonical tags on 5 templates | curl and browser | Any noindex, any chain, any canonical pointing at staging |
| Day 1 | Full list mode crawl against production versus the staging crawl | Screaming Frog | More than 1 percent of rows differ from the mapping sheet |
| Day 1 to 3 | Server errors and 404 volume | Server logs, Search Console crawl stats | 5xx rate above baseline, or new 404s from internal links |
| Day 3 to 7 | Indexed page count versus baseline | Search Console page indexing report | Indexed pages down more than 25 percent |
| Day 3 to 14 | Clicks and impressions on the 20 highest converting pages | Search Console, compared to the same weekday | Clicks down more than 30 percent for 3 consecutive days |
| Day 7 to 14 | Signups and demo requests by landing page | Analytics and CRM | Conversions down while sessions hold, which points at broken forms, not SEO |

The written rollback trigger: revert DNS to the old stack if indexed pages fall more than 25 percent from baseline by day seven, or if clicks on the priority page set drop more than 30 percent for three consecutive days and no server error, seasonality or algorithm update explains it. Reverting is not an admission of failure. It is cheaper than eight weeks of recovery.

That last row matters more than the SEO rows for a SaaS business. Sessions holding while demo requests fall means the new template broke a form or a tracking event, which is a two hour fix that otherwise gets misdiagnosed as a ranking problem for a month. The same instrumentation discipline applies to any [SEO experiment](/guides/saas-seo-experiments/) you run afterwards.

## Freeze content changes for two weeks either side

This is the position I would defend hardest. Do not rewrite copy, add pages, change titles, or prune the blog in the fortnight before or after the switch. A simultaneous redesign and content rewrite makes the cause of any loss unknowable, and unknowable causes turn into quarters of guessing.

The objection is always the same: the new site is the moment to fix everything, and holding back feels like wasted opportunity. Fair. The counter is that a two week delay costs you roughly 4 percent of a year's publishing output, and a misdiagnosed migration drop costs a quarter. Ship the content the week after the watch list closes clean, with your [keyword map](/templates/saas-keyword-map-template/) already built during the freeze so nothing is lost.

Exception: fix genuine errors immediately. A broken canonical is not a content change.

## What recovery actually looks like when it goes wrong

Assume six to twelve weeks from the moment the fix ships, not from the moment you find the problem. A 3,000 URL SaaS site that shipped a broken redirect map recovers on Google's recrawl schedule, and recrawl priority follows the pages Google already considered important.

The pattern is consistent: high value pages that still had internal links and external links recover first, often within two to three weeks of the fix. Mid tail pages follow over the next month. The long tail, especially programmatic sets, may never fully return, because the crawl budget that used to reach them has been spent on redirect resolution and the pages were marginal to begin with.

Two things speed it up. Resubmit the corrected sitemap and use the URL inspection tool on your top 50 pages, which is slow but reliable. And rebuild internal links to the affected pages from your strongest URLs, since internal linking is the lever you fully control. If the lost pages were bottom of funnel comparisons and alternatives pages, prioritise those above everything else, for the reasons set out in the [bottom of funnel page work](/courses/saas-seo-sprint/02-bofu-pages/).

## Start here

If your launch is more than two weeks out, capture the baseline this week and build the mapping sheet next. If your launch is next Friday, do the baseline capture today regardless of what else is unfinished, because everything else on this page can be fixed after the fact and that cannot.

If you have already launched and something feels wrong, run the hour zero checks now: robots.txt, response headers, a 200 URL list mode crawl. Those three checks find roughly four out of five migration disasters in under an hour, and the rest of the diagnosis belongs with your broader [SaaS SEO](/saas-seo/) programme rather than the migration itself.

## Frequently asked questions

### How long does it take Google to process a SaaS site migration?

Google Search Central says a site move with URL changes usually takes several weeks to process, and larger sites can take a few months. In practice a 400 page SaaS marketing site settles in two to four weeks, while a 5,000 page site with programmatic templates often takes eight to twelve weeks before impressions return to baseline.

### Do you lose link equity through a 301 redirect?

Google has stated publicly since 2016 that no PageRank is lost through 30x redirects. What actually causes loss is chained redirects, redirects to irrelevant destinations such as the homepage, and redirects that resolve to a page with different content and intent. The hop itself is not the problem. The destination choice usually is.

### Should I redesign and replatform at the same time?

Only if you have no choice. Doing both means a template change, a URL change and often a content change land together, so if organic drops you cannot tell which one did it. If the project must combine them, ship the replatform on identical URLs and identical copy first, then change the design two weeks later.

### What is the fastest way to QA thousands of redirects?

Put the mapping in a CSV, crawl the old URL list in list mode with Screaming Frog or Sitebulb against staging, and check four columns: status code is 301, hop count is 1, final URL matches the mapped target, and the final URL returns 200 and is indexable. Repeat the same crawl against production 30 minutes after DNS cuts over.

### How long should 301 redirects stay in place after a migration?

Google Search Central recommends keeping redirects for at least one year. For a SaaS company that has ever had documentation, integration pages or a changelog linked from partner sites, keep them permanently. The redirect map costs nothing to host at the edge, and old integration URLs keep receiving traffic from partner directories for years.

### What is a defensible rollback trigger for a site migration?

Write it before launch. A common one: if Search Console shows indexed pages down more than 25 percent from baseline by day seven, or clicks on the 20 highest converting pages down more than 30 percent for three consecutive days with no server error explaining it, revert DNS to the old stack while the cause is found.

### Does changing domain for a rebrand permanently hurt SEO?

No, but it costs more than a redesign and takes longer to settle. A clean domain change with one hop redirects, an updated Search Console change of address, and refreshed brand mentions typically returns to baseline in six to twelve weeks. The lasting damage comes from unclaimed brand queries and third party listings still pointing at the old name.