SaaS website migration SEO

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.

Migration type	What changes	Typical organic risk	Recommended freeze window
Redesign, same URLs	Templates, internal links, page speed	Low to medium. Losses come from content removed during the redesign, not the design itself	1 week either side
CMS replatform	URL structure, rendering method, sitemaps, redirects	Medium to high. Client side rendering and URL pattern changes do the damage	2 weeks either side
Rebrand to a new domain	Domain, brand entity, every URL, third party listings	High. Everything moves at once and brand queries reset	3 weeks either side

The most common real world version is a replatform from WordPress or HubSpot CMS onto Webflow 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.

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.

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 covers the wider site health work that should already be done before a migration adds to it.

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:

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 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 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.

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 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.

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.

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.

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.

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 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 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.

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 programme rather than the migration itself.