SaaS SEO migration: a plan for marketing site, docs and app

A SaaS site is rarely one site. There is a marketing site, an app on a subdomain, documentation, a changelog, integration pages, maybe a help center and a blog on yet another host. When one of those moves to a new CMS, framework, domain or folder, the SEO risk is spread across all of them, and the signup flow has to keep working the whole time.

If you want a specialist to plan and check the move, see our SEO migration services.

This guide covers what is different about a SaaS migration and gives a plan you can run before launch, on launch day and after. It is the SaaS-specific companion to our general SEO migration checklist.

What makes a SaaS migration different

A brochure site has a few dozen pages and one job. A SaaS property has several jobs at once: attract searchers, explain the product, document it, take signups and keep paying customers logged in. A few things follow from that.

• Many surfaces, many owners. Marketing owns the homepage and pricing page, engineering owns docs and the app, support owns the help center. Each can be moved on a different schedule by a different team, so the URL inventory has to cover all of them.
• Templated and programmatic pages. Integration pages, comparison pages, glossary entries and changelog entries are often generated from data. One template change can alter thousands of titles, canonicals or internal links at once.
• JavaScript rendering. Many SaaS sites use a JavaScript framework. A framework change can change what Google sees even when the page looks identical in a browser.
• Locales. If you publish in several languages, every language version has to point at the others correctly after the move.
• Signup, login and tracking. A redirect that breaks a signup link, or a consent banner that stops firing, can cost you more than a ranking dip, and you will not see it in Search Console.

Choose the type of move first

Google documents two families of site move. A move with URL changes (new domain, new URL structure, HTTP to HTTPS) needs a URL mapping and redirects. A move without URL changes, such as switching hosting or a CDN, leaves the address users see untouched and follows a different set of steps. Google describes the second kind as migrations "that don't affect the user-visible URL."

Moving to a new CMS is often both at once, because the new system tends to generate different URLs. Decide early whether you can keep URLs the same. Every URL you keep is a redirect you do not have to get right. Changing the domain and the platform in the same release gives you two things to diagnose if traffic drops, so separate them when you can.

SaaS surfaces, what can break and what to check

Pre-launch plan

1. Take a full URL inventory. Crawl the live site and combine it with your sitemaps, analytics landing pages and Search Console data. Include the subdomains and folders owned by other teams.
2. Save a baseline. Export Search Console performance data and a crawl of titles, canonicals, status codes and internal links, so you can compare after launch.
3. Build the redirect map. The rules are in the next section.
4. Review staging. Check titles, canonicals, structured data, internal links, hreflang, sitemap contents and robots.txt. Keep staging out of the index with noindex or password protection. Google states that robots.txt "is not a mechanism for keeping a web page out of Google."
5. Check rendering. View the rendered HTML of each template, not only the source. If the new framework renders content in the browser, confirm that Google can see it (see the JavaScript section below).
6. Test the money paths. Walk from a search landing page to pricing, signup and first login. Confirm consent and tracking fire.
7. Write the launch checklist and give every line an owner. Include who can roll back and what triggers it.

Redirect mapping rules

Google's guidance for moves with URL changes is direct: "We recommend server side permanent redirects from the old URLs to the new URLs as you indicated in your mapping." It suggests permanent redirects such as 301 and 308. These rules follow from Google's site move guidance and its redirect documentation.

• One line per old URL. Map every old URL to the closest equivalent new URL, never to a generic parent page.
• Avoid catch-all redirects. Google warns that sending many old URLs to one unrelated page "might be treated as a soft 404 error."
• Point to the final destination. Google advises "redirecting to the final destination directly." If chains are unavoidable, it says to keep them "ideally no more than 3 and fewer than 5."
• Use server-side redirects. Google says to use JavaScript redirects only if you cannot do server-side or meta refresh redirects.
• Retire pages deliberately. If a page has no equivalent, let it return a 404 or 410 instead of redirecting it to something unrelated.
• Keep redirects a long time. Google says: "Keep the redirects for as long as possible, generally at least 1 year."

Our free redirect map generator turns a list of old and new URL pairs into Apache, Nginx or Cloudflare rules and flags chains, loops and homepage catch-alls. The page says processing happens in your browser.

Launch day

1. Remove temporary blocks. Google says: "Don't forget to remove any noindex or robots.txt blocks that were only needed for the migration."
2. Put the redirects live and test a sample of old URLs from every surface: marketing, docs, blog, integrations, locales.
3. Confirm the new robots.txt reflects what you want blocked. If you have no robots.txt file, Google says it should return a proper 404 status.
4. Submit the new sitemap in Search Console. Google says this helps it learn about the new URLs, and that you can then remove the old sitemap.
5. Check that Googlebot is not blocked by a firewall or DoS protection. Google's page on moves without URL changes lists this as something to verify.
6. Complete one real signup and one login on production. Check analytics and consent.

If you are moving to a new domain or subdomain, submit a Change of Address in Search Console after the redirects are live. Google's help page says to use the tool "after you've moved and redirected your site." For HTTP to HTTPS moves it says "Google will figure out your changes for you," and for moves within a site you "just add redirects, and update your sitemaps as appropriate." The page does not address a subdomain to subfolder move directly, so confirm the current wording before you rely on the tool for that case.

JavaScript rendering and locales

JavaScript

Google's JavaScript SEO basics say that "once Google's resources allow, a headless Chromium renders the page and executes the JavaScript." Three details matter for a framework migration:

• Google "can only discover your links if they are <a> HTML elements with an href attribute." Navigation built from click handlers will not pass links.
• "Don't use fragments to load different page content." Use the History API for routing.
• Client-side apps can serve soft 404 errors. Google suggests redirecting to a URL that returns a 404 status, or adding a noindex robots meta tag to error pages.

Also make sure robots.txt does not block your script files. Google says it "won't render JavaScript from blocked files or on blocked pages."

hreflang

For localized versions, Google says that "if two pages don't both point to each other, the tags will be ignored." Each version must list itself and all the others, and alternate URLs must be fully qualified, including http or https. After a move, every hreflang annotation has to be rewritten to the new URLs on both sides of each pair.

Post-launch monitoring in Search Console

Three reports do most of the work.

• Page indexing. Google describes it as showing "which pages Google can find and index on your site" and why pages are not indexed. Watch for new reasons such as blocked by robots.txt, duplicate pages or soft 404. After you fix an issue you can use Validate fix, which Google says typically takes "up to about two weeks, but in some cases can take much longer."
• Crawl stats. Google says the report is aimed at advanced users and that sites with fewer than a thousand pages generally do not need it. For a larger SaaS site it shows total crawl requests, response codes and host status. Look for a rise in 404 or 5XX responses on the new host and for host availability problems. After a hosting or CDN change, Google says a temporary drop in crawl rate is normal. After a move with URL changes it says it may crawl the new site more heavily for a while.
• Sitemaps. Confirm the new sitemap was read and lists only the new URLs. A single sitemap is limited to 50,000 URLs or 50MB uncompressed, so large sites need a sitemap index. Google uses lastmod only if it is consistently and verifiably accurate.

Alongside Search Console, re-crawl your own site each week against the baseline, check server logs for 404s from old URLs that still get traffic, and watch signups from organic landing pages. Google says that for a medium-sized site it can take "a few weeks or more" to show the new URLs in place of the old ones, and that a move is complete only once Googlebot has visited every URL on the old and new site at least once. An early dip does not prove the redirects failed, and a quiet first week does not prove they worked. Compare the same pages and queries against your baseline.

We wrote up our own move from WordPress to a static build, including the indexing lag, in our SEO migration case study. It covers one site, so use it as an example of the method and nothing more.

When to bring in a specialist

You can run this plan in-house if one team owns every surface. It gets harder when marketing, docs and the app sit on separate stacks, or when a framework change affects rendering. A second pair of eyes on the URL inventory, the redirect map and the post-launch checks is where outside help is most useful. If you want a specialist to plan and check the move, see our SEO migration services. Our technical SEO services cover crawl and indexing problems that sit under a migration, and our guide to SEO for SaaS covers the content side of the same sites.

Sources

• Google Search Central: Site moves with URL changes, read November 10, 2026.
• Google Search Central: Site moves without URL changes, read November 10, 2026.
• Google Search Central: Redirects and Google Search, read November 10, 2026.
• Search Console Help: Change of Address tool, read November 10, 2026.
• Google Search Central: JavaScript SEO basics, read November 10, 2026.
• Google Search Central: Localized versions of your pages (hreflang), read November 10, 2026.
• Google Search Central: Introduction to robots.txt, read November 10, 2026.
• Google Search Central: Build and submit a sitemap, read November 10, 2026.
• Search Console Help: Page indexing report, read November 10, 2026.
• Search Console Help: Crawl stats report, read November 10, 2026.