Technical SEO for SaaS is the same crawl, render and index work every site needs, plus a set of problems that mostly happen on software companies' websites: a marketing site built as a JavaScript app, preview and staging deployments that leak into Google, an app, docs and help center spread across subdomains, hundreds of templated integration pages, and pricing hidden behind scripts or logins. Fix them in that order. Rendering and environment leaks can wipe out a site's visibility; the rest decide how much of it ranks.
This guide covers the eight SaaS-specific fixes, with a table of which SaaS page types to index and which to keep out. For the generic checks every site needs, use the technical SEO audit checklist.
Key takeaways
- SaaS sites lost more click-through rate than almost any niche: median CTR fell to 0.53× its October 2025 level by August 2026, and 82% of 49 SaaS sites lost CTR (Outrank zero-click study).
- Render marketing pages on the server. Google renders JavaScript later; most AI crawlers don't render it at all.
- Vercel adds X-Robots-Tag: noindex to preview deployments by default, but not to a branch you've given a custom domain, which is how staging.yourapp.com ends up in Google.
- Thin integration and template pages are the most common cause of 'Crawled - currently not indexed' on SaaS sites. Index only the ones with unique content.
- Free tools earn 2.11× the CTR of the same site's articles at positions 4–10 (Outrank, 6.2M pages), and SaaS teams can usually ship them fastest.
Why SaaS technical SEO is different
Three things set SaaS sites apart. They are built by product engineers using app frameworks, so client-side rendering and deployment tooling cause problems a WordPress site never sees. They run several properties at once (marketing site, app, docs, help center, status page, changelog), often on different platforms. And their search results are under unusual pressure from AI answers.
Outrank sees this from a lot of SaaS sites: SaaS and tech is the largest industry on the platform, with 26,265 articles written for 653 SaaS sites in the 90 days to October 2026 (Outrank platform data).
0.53×
SaaS and tech median CTR, August 2026 vs October 2025
49 SaaS sites; 82% lost CTR. Zero-click study
70%
of SaaS sites using Outrank grew Google clicks
Median 265 → 765 clicks per 28 days. AI SEO agent study, 2,119 sites
653
SaaS and tech sites publishing with Outrank in the last 90 days
26,265 articles. Outrank platform data, 90 days to October 2026
The CTR squeeze matters for technical decisions: with fewer clicks per ranking, every indexing leak and every thin page that dilutes your best URLs costs more than it used to.
1. Render the marketing site on the server
If your marketing site is a single-page app that builds content in the browser, the HTML Google first fetches is an empty shell. Google renders JavaScript in a second pass that can lag behind crawling, and many other crawlers, including most AI crawlers, fetch the HTML and stop there.
The fix is to send real HTML. In Next.js, the App Router renders server components on the server by default; on the Pages Router, use static generation or server-side rendering for every public page. Nuxt, Astro, Remix and SvelteKit all have equivalent modes. Keep client-only rendering for the logged-in app, where SEO doesn't matter.
Two quick checks:
- Run
curl -s https://yoursite.com/pricing | grep -i "your plan name". If the plan names aren't in the raw HTML, crawlers that don't run JavaScript can't see your pricing. - In Search Console, URL Inspection → Test live URL → View tested page → HTML shows what Google sees after rendering. Check that navigation links are real
<a href>elements, not buttons with click handlers.
Google's documentation calls dynamic rendering (serving bots a different pre-rendered page) a workaround rather than a long-term solution, so don't build a new site around it.
2. Keep preview, staging and app environments out of Google
SaaS teams deploy constantly, and every deployment platform creates extra hostnames. Duplicates of your marketing site on those hostnames compete with the real one.
- Vercel previews. Vercel's documentation says preview deployments get an
X-Robots-Tag: noindexheader by default. The exception catches people out: once you assign a custom domain to a branch (saystaging.yourapp.com), the header is no longer added. Add it yourself or put the branch behind authentication. - Staging servers. Password protection (HTTP auth, returning 401) is the only reliable block. robots.txt doesn't remove URLs that are already indexed, and a staging robots.txt has a habit of being copied to production at launch.
- The app itself.
app.yourapp.comshould send logged-out visitors to the login page, which is fine to index (people search "[brand] login"). Screens behind authentication don't need noindex because crawlers can't reach them; just make sure no public page links to deep app URLs with session tokens.
Check what's leaked with a site:yourapp.com -www search and in the Search Console Domain property, which shows every subdomain.
3. Decide what gets indexed, page type by page type
Most SaaS indexing problems come from leaving the default on: every template, every docs version, every shared link. Use this as a starting point and adjust to your product.
SaaS page types: index or keep out?
| Homepage | Yes | ✓ | Canonical to the bare domain; one version only |
| Pricing | Yes | ✓ | Prices as HTML text; strip ?plan= and currency parameters with a canonical |
| Feature and use-case pages | Yes | ✓ | One page per job the product does |
| Integration pages | Yes, if unique | ✓ | Index pages with real setup steps and use cases; noindex logo-and-one-line stubs |
| Template or example galleries | Yes, if unique | ✓ | Each needs its own description and preview; otherwise index only the category |
| Comparison and alternatives pages | Yes | ✓ | High intent; keep claims fair and current |
| Blog and guides | Yes | ✓ | Your main source of non-brand traffic |
| Docs (current version) | Yes | ✓ | Developers search error messages and how-tos |
| Docs (old versions) | No | ✕ | Canonical to the current version or noindex |
| Help center articles | Usually | ✓ | Good for support queries; merge near-duplicates |
| Changelog | Hub yes, entries optional | ✓ | Index entries only if they explain features in depth |
| Login and sign-up pages | Yes | ✓ | People search for '[brand] login'; no need to hide them |
| Logged-in app screens | No | ✕ | Behind authentication; never linked publicly |
| Public share links (boards, docs, forms) | No by default | ✕ | User content: noindex unless the user opts in |
| Status page | Optional | ✕ | Low value for search; fine either way |
| Internal search, filters and UTM URLs | No | ✕ | Canonical to the clean URL; don't link internally with UTMs |
| Staging and preview hosts | No | ✕ | Authentication or X-Robots-Tag noindex |
Click a column header to sort.
Then check the result in Search Console → Indexing → Pages. If the indexed count is far above the number of pages you'd want a stranger to land on, something on this list is leaking. If it's far below, read our guide on crawled but not indexed pages.
4. Choose subfolders or subdomains for blog, docs and help
Google treats subdomains and subfolders as workable either way; there is no ranking rule that says one wins. The practical differences decide it:
Subfolder (/blog, /docs) | Subdomain (blog., docs., help.) | |
|---|---|---|
| Internal linking with the marketing site | Natural, shared navigation | Needs deliberate cross-links |
| Search Console | One property | Covered by a Domain property, but often reported separately |
| Platform choice | Must run on (or be proxied through) your main site | Any hosted tool (Intercom, Zendesk, Mintlify, Ghost) |
| Control of canonicals, sitemaps, schema | Full | Depends on the vendor |
Our default for SaaS: blog and guides in a subfolder, because they exist to pass relevance and links to product pages. Docs and help center can live on a subdomain if the platform is much better, as long as they link back to the relevant product pages and the vendor lets you set canonicals and sitemaps. If you already run a subdomain blog, a reverse proxy can serve it under /blog without migrating the CMS.
5. Make programmatic pages worth indexing
Integration directories, template galleries, "alternatives to X" pages and use-case pages are the SaaS version of programmatic SEO. They work when each page answers a real query with something specific: setup steps, screenshots, limits, pricing, a working template. They fail when 300 pages share one paragraph with the partner name swapped in. Google then crawls them and declines to index most, and its scaled content abuse policy (introduced in March 2024) targets mass-produced pages made mainly to rank.
A workable rule: launch the 20 pages with real search demand and real content, check how many get indexed after a few weeks, and only then expand. Our programmatic SEO guide covers templates and data sources.
6. Get pricing, docs and changelog right
Pricing. Plan names, prices and limits should be plain HTML text, not images, not rendered only after a currency script runs. AI assistants answer "how much does [your product] cost" from whatever they can fetch; if they can't read your page, they quote a review site. If you add SoftwareApplication structured data, Google's software app documentation requires a name, offers.price (0 for free apps) and either a review or an aggregate rating, and the rating has to reflect real reviews shown on the page.
Docs. Version your docs with one canonical "latest" URL per topic (/docs/webhooks, not only /docs/v3.2/webhooks), and canonical or noindex older versions so they don't outrank the current page. Put error messages in text; developers paste them straight into Google.
Changelog. One indexable hub page that lists releases with links to the feature pages they changed. Individual entries are worth indexing only when they explain a feature properly.
7. Handle international SaaS without IP redirects
If you serve several languages, give each one its own URL (subfolders like /de/ are simplest) and connect them with reciprocal hreflang tags plus an x-default. Don't redirect visitors by IP address or browser language: Google mostly crawls from US IP addresses, so an automatic redirect can hide your other languages from it entirely. A dismissible banner suggesting the local version is the safer pattern. More detail in our SEO localization guide.
8. Build free tools on your own domain
SaaS teams have an advantage most sites don't: engineers who can ship a small, useful tool in a week. It pays. In Outrank's study of 6.2 million pages across 3,332 sites, free tools and calculators earned 2.11× the click-through rate of the same site's articles at positions 4 to 10, and took 34.1% of clicks while getting 14.2% of impressions. A calculator or generator that sits next to your product's core job also earns links and AI citations that blog posts struggle to get.
Technically, treat each tool like a product page: server-rendered explanation text above the tool, its own URL, internal links to the feature it relates to.
What happens once the foundation is fixed
Technical SEO removes the ceiling; content and links do the climbing. Two SaaS examples from Outrank's case studies show what that looks like once the basics are in place. AIApply, a job-search SaaS publishing to Webflow, grew Google clicks 44% year over year (188,390 to 270,592 for May to July) and reached 109,260 clicks in June 2026. Scalelist, a B2B data SaaS, went from Domain Rating 16 to 45 in twelve months. Both published consistently and built links through Outrank's backlink exchange, on top of sites Google could crawl and index without trouble.
For more on the strategy side, see SEO for startups, the best SaaS SEO tools and our list of SEO keywords for software companies.
FAQ
What is technical SEO for SaaS?
Technical SEO for SaaS is making a software company's website crawlable, renderable and indexable, with extra attention to SaaS-specific issues: JavaScript frameworks, preview and staging deployments, app and docs subdomains, programmatic integration and template pages, pricing pages and multi-language setups. The goal is that every page meant for search ranks, and nothing else gets indexed.
Is Next.js or React bad for SEO?
No, as long as public pages are rendered on the server or at build time. Next.js does this by default with the App Router. Problems start when a marketing site is a client-side single-page app, because the first HTML Google and AI crawlers receive has no content or links.
Should a SaaS blog be on a subdomain or a subfolder?
Google ranks both, so it's a practical choice. A subfolder makes internal linking to product pages natural and keeps everything in one property, which is why most SaaS teams prefer it for the blog. A subdomain is fine for docs or a help center if the hosted platform is better and still lets you control canonicals and sitemaps.
Should SaaS integration pages be indexed?
Index integration pages that have unique, useful content: what the integration does, setup steps, limits and use cases. Pages that only show a logo and one generic sentence usually end up as "Crawled - currently not indexed" and dilute the site, so noindex them or merge them into a directory page until they have real content.
How do I stop staging or preview sites from being indexed?
Put staging behind password authentication, which returns a 401 to crawlers. On Vercel, preview deployments send a noindex header by default, but a branch with a custom domain does not, so add the header yourself there. If staging URLs are already indexed, keep them crawlable with noindex until they drop out, then lock them down.
