---
type: "Use Case"
title: "Pre-rendering for SaaS platforms - marketing and docs SEO"
description: "Pre-rendering for SaaS platforms: how to make marketing, docs, changelog, and public template URLs indexable without exposing the gated app."
resource: "https://prerender.info/use-cases/saas"
tags: [use-cases, saas seo, saas pre-rendering, documentation indexing, dashboard seo, javascript spa seo]
timestamp: 2026-04-21T00:00:00Z
---

# Pre-rendering for SaaS platforms - marketing and docs SEO

Pre-rendering for SaaS platforms: how to make marketing, docs, changelog, and public template URLs indexable without exposing the gated app.

## Public surface of a SaaS application

The public surface of a SaaS application is the set of unauthenticated URLs a search engine can legitimately index: marketing pages, pricing, docs, changelog, blog, public templates, and integration directories. It excludes the signed-in app, user workspaces, and any page whose primary HTML depends on account state.

## Pain points

- Marketing pages live in the same SPA as the gated dashboard and inherit CSR-only rendering.
- Documentation lives in an MDX runtime that hydrates slowly - Googlebot sees a loading skeleton.
- Changelog and public template pages never get indexed because the SPA shell loads faster than the data fetch.

### Before vs after - typical SaaS results

Aggregated from JavaScript-heavy SaaS public surfaces across docs, marketing, changelog, and template directories. Results vary by route governance and how much of the public site stays tied to the product SPA.

| Metric | Before pre-rendering | After pre-rendering |
| --- | --- | --- |
| Indexing time for new docs pages | 3-14 days | Under 2 hours |
| AI citation visibility on docs | Rarely cited | Cited from structured pages |
| Public template / integration coverage | Patchy long-tail indexing | Stable indexed set |
| Marketing page Core Web Vitals | LCP 3.5s | LCP 1.2s (pre-rendered cache) |
| Docs-led organic growth | Flat or uneven | +180-340% over a quarter |

## ShopStream - docs moved from delayed discovery to first-crawl visibility

A B2B ecommerce SaaS moved its MDX-based docs set of 1,200 pages behind pre-rendering, then added the same route policy to public template pages and release notes. Within 72 hours the core docs surface was indexable on first crawl, and over the quarter organic traffic from the docs surface grew 340% without changing the authenticated app.

**Result:** +340% organic traffic (docs surface, Q1)

## What breaks first on SaaS sites

The first template to disappear is usually documentation, not the homepage. Marketing pages are often short, cached, and linked heavily from navigation, so they still get crawled. Docs pages are deeper, more numerous, and often depend on client-side MDX hydration for code samples, tabs, and callouts. That makes them the first place where Googlebot sees a shell instead of a finished answer.

The second failure point is the in-between layer: changelog entries, template galleries, integration pages, and public examples. These URLs matter because they capture product-adjacent intent with lower competition than broad marketing terms. They are also the pages most teams forget to segment, which is why this page should sit next to [crawl budget fundamentals](/guides/crawl-budget.md) rather than only brand-level acquisition planning.

A useful rule for SaaS teams is blunt: the more your public surface behaves like a knowledge base, the less you can afford to make indexing depend on a JavaScript render queue.

## Docs, marketing, templates, and changelog should be treated as different URL families

Most SaaS teams already know that docs and pricing pages are different. The operational mistake is still giving them one TTL, one purge policy, and one routing rule. Documentation pages need completeness first. Changelog pages need fast recrawl on release. Template galleries and integration directories often need both completeness and long-tail coverage. Static brand pages can tolerate slower refresh if the copy changes once a quarter.

The practical ordering usually looks like this: docs first, public template or integration pages second, changelog third, evergreen marketing pages fourth. Docs earn the first render budget because they answer high-intent queries and feed AI citations. Templates and integrations follow because they map to long-tail product-led demand. Marketing pages matter, but they are rarely the hardest URLs to get indexed.

If the team is still deciding whether to solve this inside the framework instead of at the crawler layer, compare those trade-offs in [dynamic rendering vs SSR](/technology/dynamic-rendering-vs-ssr.md).

## The app boundary matters more than the framework choice

SaaS teams often frame the decision as React versus Next.js, or SPA versus SSR. The real boundary is simpler: which URLs are public documents, and which URLs are account state. Public documents can be snapped, cached, and served to crawlers. Account state should stay behind auth, redirect rules, or noindex boundaries exactly as before.

In practice, pre-rendering does not require the signed-in app to change. The routing layer only forwards unauthenticated routes such as `/docs`, `/blog`, `/pricing`, `/templates`, or `/integrations`. Workspaces, billing pages, onboarding flows, admin consoles, and support inboxes stay on the live app path. Teams that blur this line usually create fear about cloaking when the actual problem is poor route governance.

What most guides skip is that auth-safe pre-rendering is more about URL hygiene than rendering technology. If the route map is clean, the implementation is usually boring.

## What changes by company size

Early-stage SaaS companies with 50-200 public URLs can often start with docs and pricing only. The goal there is speed: fix indexability without spending a quarter on a platform rewrite. Mid-market SaaS teams with 500-5,000 public URLs usually need segmentation by template family because docs, integrations, changelog, and blog all move at different rates. Enterprise SaaS sites with multilingual docs, product directories, academy content, and solution pages need explicit render-budget rules or the crawl surface drifts out of control.

The bigger the company, the less useful one global default becomes. A startup can survive on a simple public-route allowlist. A mature product needs ownership by template: developer docs, marketing, release notes, and template galleries each need separate freshness expectations and purge triggers. That operational view also connects naturally to [JavaScript rendering cost](/guides/javascript-rendering-cost.md), because scale turns every vague cache rule into real infrastructure spend.

## What to pre-render first on a SaaS site

Start with the pages that already carry search intent and fail under CSR. That usually means top documentation templates, pricing, feature pages with heavy client-side modules, and public integration or template directories. If Search Console already shows impressions on half-rendered docs pages, those should move before a homepage hero rewrite or a cosmetic framework migration.

A useful rollout sequence is: top docs sections first, then pricing and feature pages, then public template or integration pages, then changelog and blog archives, and only then any lower-value marketing long tail. This page is for teams with a meaningful public acquisition surface. It is the wrong fit for products whose public site is tiny and mostly static, or for businesses where nearly everything valuable happens behind login.

Once the public surface starts looking more like a catalogue with thousands of long-tail public pages, the operational model begins to overlap with [ecommerce](/use-cases/ecommerce.md) more than most SaaS teams expect.

## What should never be indexed or pre-rendered

Do not pre-render user dashboards, tenant subpaths, onboarding checklists, internal search results, billing areas, support inboxes, or pages that change meaning per account. Those URLs are not public documents. They are application state, and sending them through a crawler cache creates risk without adding durable SEO value.

Be equally careful with partial-public pages such as logged-out app shells, empty workspace templates, and invite flows. If the primary HTML is thin without account context, the page should not be treated as an SEO asset just because it has a public URL. The clean SaaS model is narrow and intentional: index the acquisition surface, not the product chrome.

When teams ignore that boundary, pre-rendering gets blamed for indexing the wrong things. The rendering layer is not choosing the wrong pages. The route policy is.

## What changes operationally after launch

After launch, the work shifts from framework debate to content operations. SEO decides which template families deserve crawl priority. Product marketing decides which public pages need freshness when launches happen. Engineering owns route matching, purge triggers, and monitoring. If those responsibilities stay implicit, the public surface drifts back into one undifferentiated SPA.

A clean SaaS setup usually has three controls: route classification, cache policy by template family, and event-driven invalidation for high-change surfaces such as changelog or template directories. Docs often need long-lived completeness with controlled refresh. Changelog needs fast purge on release publish. Marketing can sit on longer TTL. If parity between client state and crawler HTML becomes unstable, the debugging workflow belongs with [hydration failures and SEO](/guides/advanced/hydration-failures-seo.md), not in generic CMS QA.

### Route-level rewrite - public vs private

Keep the dashboard on the authenticated path. Rewrite only the public surface such as marketing, docs, blog, changelog, and templates to the pre-rendered cache for crawler traffic.

```typescript
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

const BOT_REGEX = /bot|crawler|spider|googlebot|bingbot|gptbot|claudebot|perplexitybot/i;
const PUBLIC_SURFACE = /^\/(|pricing|docs|blog|changelog|templates|integrations|about)(\/|$)/;

export function middleware(req: NextRequest) {
  const ua = req.headers.get("user-agent") ?? "";
  if (!BOT_REGEX.test(ua)) return NextResponse.next();
  if (!PUBLIC_SURFACE.test(req.nextUrl.pathname)) return NextResponse.next();

  return NextResponse.rewrite(
    new URL(
      `https://render.ostr.io/render?url=${encodeURIComponent(req.nextUrl.toString())}`,
    ),
  );
}

export const config = { matcher: "/((?!_next|api|app|og|static).*)" };
```

## FAQ

### Do we need to change the authenticated dashboard?

No. Pre-rendering should target only public, unauthenticated URLs. The signed-in app, workspace pages, and account state stay on the existing auth path unchanged.

### Does this work for custom docs frameworks?

Yes. Pre-rendering consumes the rendered DOM rather than the source framework. Docusaurus, Nextra, Mintlify, ReadMe, and custom MDX setups all fit as long as the page can settle into a useful public snapshot.

### What about public templates or integration directories?

They are often the best long-tail SaaS SEO assets after docs. Public templates, integration pages, and example galleries usually deserve pre-rendering before lower-value marketing pages because they target narrower, higher-intent queries.

### How does pre-rendering interact with A/B testing on marketing pages?

Serve a stable canonical variant to crawlers and keep experiments on human traffic only. The point of the crawler path is predictable HTML, not variant-level experimentation.

### Should changelog pages get the same cache policy as docs?

Usually no. Docs prioritize completeness and stable citation. Changelog pages need faster invalidation when a release ships. Putting both on one TTL usually leaves one of them under-served.

### When is pre-rendering the wrong fit for SaaS?

It is the wrong fit when the public surface is tiny and already server-rendered, or when the indexed content is heavily personalized or gated. If the primary HTML changes per user, SSR or a narrower public-document strategy is usually safer.

### What is the biggest implementation mistake SaaS teams make?

Treating every public URL as one content class. Docs, changelog, templates, and marketing pages have different value and different freshness needs. If they all inherit one rule, either cost or visibility drifts first.

## Related

- [Use case - ecommerce](/use-cases/ecommerce.md) — Adjacent pattern when the public surface starts behaving like a catalogue.
- [Compare - vs Vercel SSR](/compare/vs-vercel-ssr.md) — The main comparison for Next.js-heavy SaaS teams.
- [Guide - crawl budget](/guides/crawl-budget.md) — Why docs and integration directories disappear first.
- [Guide - JavaScript rendering cost](/guides/javascript-rendering-cost.md) — Cost model once the public surface grows past a few hundred routes.
- [Guide - cache headers](/guides/prerender-cache-headers.md) — TTL tuning for docs, changelog, and templates.
- [Advanced guide - hydration failures](/guides/advanced/hydration-failures-seo.md) — Use this when crawler HTML and client HTML drift apart.

## Source

Generated from prerender.info editorial content (single source of truth). The canonical, always-current version is the `resource` URL above. Claims reflect prerender.info / ostr.io editorial guidance and are not confirmed from third-party public documentation unless explicitly linked.