SaaS Website Migration: Keep Your SEO (Checklist)

A SaaS website migration is the moment a lot of founders find out how much of their pipeline came from search. The new site looks better, the team is proud of it, and then sign-ups from organic traffic drift down for weeks because old URLs return 404s, page titles went missing and the blog moved to a new path without redirects. None of that is bad luck. It is a checklist that was skipped. This guide is the checklist I work through when I move a SaaS marketing site to a new platform, design or URL structure, written from the developer's side, so you can run it yourself or hold whoever does the work to it.

I run Mujeeb Technologies, a small engineering studio that rebuilds websites for B2B SaaS teams on fixed fees. Everything here is practical advice from that work and from Google's own documentation, which I link where it matters.

What counts as a SaaS website migration?

Any change that alters the URLs, content or technical setup search engines already know about. The common ones for SaaS teams:

• Platform change. Moving from a website builder or CMS to a custom-built site, or the other way round.
• Redesign with new information architecture. Pages merged, split, renamed or moved into new folders such as /features/ or /solutions/.
• Domain or subdomain change. A rebrand, or moving the blog from blog.yourapp.com to yourapp.com/blog.
• Protocol or structure clean-up. HTTP to HTTPS, trailing-slash rules, removing www.

The more of these you combine in one launch, the harder it is to diagnose problems afterwards. If you can, change the design first and the domain later, not both on the same day.

Why migrations lose traffic

Search engines rank URLs, not brands. When a URL disappears without a redirect, the history attached to it (links pointing to it, its place in the index) has nowhere to go. Google's guidance on site moves with URL changes is clear that you should map every old URL to its new counterpart, use permanent server-side redirects, and expect some temporary ranking fluctuation while Google recrawls the site. The fluctuation is normal. Permanent losses usually come from four mistakes:

1. Old URLs with no redirect, returning 404.
2. Many old URLs redirected to the home page instead of the closest matching page.
3. Content that ranked being cut or thinned out in the redesign.
4. Technical regressions: missing titles, a stray noindex, canonical tags pointing at staging, or a much slower site.

Before launch: the SaaS website migration checklist

1. Crawl and export every current URL

Crawl the live site with a crawler such as Screaming Frog, and export the URL list from your sitemap. Then add the URLs a crawler will not find on its own: pages that only get traffic from search, old campaign landing pages and orphaned blog posts. Pull these from Google Search Console's Pages and Performance reports and from your analytics landing-page report. This combined list is your source of truth.

2. Mark which pages actually matter

For each URL, note organic clicks, conversions (trials, demo requests) and whether other sites link to it. You now know which pages you cannot afford to lose. For a SaaS site these are usually the home page, pricing, the main feature or use-case pages, comparison pages and a handful of blog posts that bring in most of the search traffic.

3. Build the redirect map

A spreadsheet with two columns: old URL and new URL. Every old URL gets one row. Rules I follow:

• Redirect each old page to the closest equivalent new page, not the home page. Google specifically warns against redirecting many old URLs to one irrelevant destination such as the new home page.
• Where you merge three old pages into one, redirect all three to the merged page. That is fine.
• Where a page is retired with no equivalent, let it return a 404 or 410 rather than forcing a misleading redirect.
• Point every redirect straight to its final URL. No chains like old → interim → new.

4. Keep the content that ranks

Redesigns often "simplify" pages by cutting copy. If a page ranks for valuable terms, keep the substance of what made it rank: the topic, the headings, the answers to the questions people search for. Improve the design around it, rewrite for clarity if you want, but do not replace a detailed page with three lines and a hero image.

5. Carry over metadata and structured data

For every important page, check the new version has a unique title tag, meta description, one clear H1, Open Graph tags, and any structured data the old page had (Organization, FAQ, Article, Product). On custom-built sites these are easy to forget because they are invisible in the design review.

6. Lock down staging

Staging should be password protected or set to noindex. The classic launch-day accident is copying that noindex or a staging canonical URL to production. Put "remove staging noindex" on the launch checklist with a name next to it.

7. Benchmark speed before you switch

Record Core Web Vitals and PageSpeed Insights scores for your key templates on the old site. A migration is a good chance to make the site faster, and you want before and after numbers. Google's "good" thresholds are covered in our Core Web Vitals guide for SaaS sites.

8. Test the redirect map on staging

Load every old URL against staging (most crawlers can run a list) and check each one returns a single 301 or 308 to the right new page with a 200 at the end. Fix anything that chains, loops or lands on a 404 before launch, not after.

Launch day

• Deploy the redirects at the server or hosting level, at the same time as the new site. Client-side JavaScript redirects are a last resort.
• Remove staging noindex and check robots.txt allows crawling.
• Publish the new XML sitemap and submit it in Search Console, as Google's site-move guide recommends.
• If the domain changed, verify both properties in Search Console and use the Change of Address tool. It only applies to domain or subdomain moves, not to redesigns on the same domain.
• Run your redirect list against production one more time.
• Check that forms, trial sign-up, demo booking and analytics still fire. A migration that keeps rankings but breaks the sign-up form has still lost you customers.

After launch: the first weeks

Watch Search Console daily for a while

Look at the Pages report for spikes in "Not found (404)" and "Page with redirect", and use the URL Inspection tool on your most important pages to confirm Google sees the new versions. Compare clicks by page against your pre-launch export.

Fix 404s from real traffic

Your server logs and analytics will show old URLs you missed, often from email campaigns, partner sites or docs. Add them to the redirect map.

Update the links you control

Change internal links to point directly to new URLs instead of relying on redirects. Then update the external links you own: social profiles, app emails, help-centre articles, directory listings and your product's own links back to the marketing site.

Keep redirects for a long time

Google's documentation says to keep redirects for as long as possible, and generally at least a year. Google's John Mueller has said the same: keep a redirect for at least one year so Google sees it several times (Search Engine Journal). In practice, I leave them in place indefinitely. They cost almost nothing to keep.

Common SaaS-specific traps

• Docs and changelog on a different system. These often live on a separate tool and get forgotten in the redirect map, yet they attract a lot of search and backlinks.
• App and marketing site on the same domain. Make sure new marketing-site routes do not collide with app routes such as /login or /signup, and that redirects never catch app URLs.
• Pricing page URL changes. Pricing pages earn links from review sites and comparison articles. Keep the URL if you can.
• Blog moved to a subfolder. Moving from a subdomain to /blog is a common and reasonable choice, but it is a domain-level move for every post, so every post needs a redirect.

If your migration is part of a bigger rebuild, our SaaS website redesign checklist covers the design and messaging side, and what a SaaS website costs covers budgeting.

How we handle migrations

When we rebuild a SaaS marketing site, the redirect map, metadata parity, staging protection and post-launch checks are part of the written scope, not extras. You review the finished site on staging, with the redirect test results, before the final payment. You can see what each package covers on our services page and fixed fee ranges on our pricing page.

FAQ

Will I lose rankings when I migrate my SaaS website?

Some temporary movement is normal while search engines recrawl, and Google says to expect it. Lasting losses usually come from missing redirects, removed content or technical mistakes, which a proper checklist prevents.

301 or 302 redirects for a migration?

Permanent redirects (301 or 308) for a permanent move. A 302 tells search engines the move is temporary.

Do I need the Change of Address tool?

Only if the domain or subdomain changes. A redesign that keeps the same domain does not need it.

Should I migrate and redesign at the same time?

You can, but every extra change makes problems harder to trace. If timing allows, keep URLs stable during the redesign and change them in a separate, smaller step.

Get a free audit before you migrate

If a migration or rebuild is on your roadmap, have a developer look at your current site first. Send us your URL and you will get a free, personalised Loom video audit with the fixes ranked by impact, plus a fixed-price proposal. It is yours to keep either way. Get your free video audit.