Marketing site vs SaaS dashboard: architecture differences, 2026

A marketing site is read by strangers and judged on search visibility and speed. A SaaS dashboard is used by signed-in people and judged on fresh data and safe sessions. One framework can serve both, but the defaults for each are different, and mixing them up is where most of the pain starts.

Here are the differences in marketing site vs web app architecture that matter in practice: rendering, authentication and caching, indexing, one project or two, and who changes what.

Rendering: static for the marketing site, mixed for the dashboard

Rendering strategy is the biggest architectural split. It decides when HTML is produced, how fast it arrives and what it costs to serve.

Marketing pages: SSG and ISR

Marketing pages change infrequently and depend on search visibility and fast loads. Vercel's guide to choosing a rendering strategy, published July 23, 2024, favors static generation (SSG) for them: it gives the fastest loads, strong SEO, low server load and the lowest infrastructure cost. The trade-off is that build time grows with page count, and every content change needs a rebuild and redeploy.

Incremental static regeneration (ISR) removes that drawback by refreshing specific pages after launch. The same guide recommends triggering revalidation on demand rather than on a timer, because content usually changes for a reason.

Client-side rendering (CSR) is a weak fit here. Search rankings are influenced by Core Web Vitals, and those are harder to meet when content depends on client-side fetching and large JavaScript bundles. Setting performance budgets keeps that JavaScript weight honest.

Dashboards: SSR, ISR and CSR together

Dashboards need fresh data and a lot of interactivity, so they usually combine strategies. According to the same Vercel guide:

• Server-side rendering (SSR) delivers current data, but with slower loads, a weaker time to first byte and higher server use. Caching frequently accessed data, streaming and React Suspense soften that.
• CSR works well for filtering, sorting and data exploration, because the browser can respond without a server round trip. The cost is a slower first load while the bundle downloads.
• ISR fits sections that update on a schedule, such as daily summaries, settings and billing pages.

Its sample dashboard uses SSR for the layout and real-time feeds, ISR for summary widgets and CSR for interactive exploration tools.

A quick comparison

Authentication and caching

A marketing site has no sessions. A dashboard is built around them, and that changes how you handle requests and caches.

Where sessions get refreshed

Supabase's server-side auth guide for Next.js states the core constraint: Server Components cannot write cookies, so an expired session token cannot be refreshed during a server render. The guide's answer is a proxy, which was middleware.ts in older Next.js releases and was renamed in version 16. It refreshes the token on each request and passes the new one to both Server Components and the browser. Without it, users are signed out.

Refresh tokens are generally single-use, so refreshing in two places can revoke the whole session. Users then report random logouts, which are hard to trace. Pick one place to refresh and keep it there.

Keep authenticated responses out of shared caches

The same guide has its cookie helper apply Cache-Control, Expires and Pragma headers so a CDN does not cache a response and leak one user's session to another. The rule to carry over is simple: a static shell can sit on a CDN, but any response that sets or depends on a session cookie must not be shared.

Server code should also verify tokens rather than trust them. The guide warns that cookies can be forged and says to use getClaims(), which checks the token signature, instead of getSession() in server code.

SEO and indexing needs

The two halves of a product have opposite indexing needs. The Next.js SEO rendering guide puts the principle plainly: page data and metadata should be available on page load without JavaScript. That is why it names SSG or SSR as the best options for pages that need to rank, and says CSR is not recommended for optimal SEO.

The same guide calls CSR "perfect for data heavy dashboards, account pages or any page that you do not require to be in any search engine index." Its own example mix is blog posts as static pages, a customer account dashboard rendered on the client and a news feed rendered on the server.

In practice, that means indexable content belongs on the marketing side. Dashboard routes should not be part of your sitemap, and a robots directive on them is a sensible extra guard.

One project or two

Next.js lets you pick the rendering method per page, so one project can hold static marketing routes and dynamic app routes. The question is whether it should.

Vercel's Next.js and Astro comparison, last updated October 12, 2026, describes the usual shape of each side. A marketing site is mostly static with a few interactive pieces. An authenticated dashboard needs login checks, fresh data on each request and shared navigation across many routes. Vercel hosts both frameworks and says Next.js gets deeper platform integration, so treat its lean toward Next.js as a vendor view.

Splitting comes with clear trade-offs:

• One project: shared design system and navigation, one deploy pipeline, and no framework switch if the site grows into a product.
• Two deployables: a leaner marketing site and isolated auth code, at the price of a second pipeline and harder shared navigation.

The sources do not settle this choice. A reasonable rule: start with one project when a small team owns both, and split when the dashboard's release risk or auth surface starts slowing marketing changes.

Release cadence and ownership

Marketing pages are edited often, by people who are not engineers, and a typo fix should not wait on a regression suite. Dashboard changes touch data and permissions, and they should ship behind tests and review. That difference in cadence often matters more than any framework feature. If editors own the content, see choosing a CMS for a Next.js marketing site.

Conclusion

Match each route to its freshness, interactivity and indexing needs. Static or ISR for anything strangers should find, server or client rendering behind verified sessions for anything users log in to, and no shared caching for personalized responses. Whether that lives in one repository or two is a team decision, not a technical one. If you are weighing it for a real build, Kallos Labs covers both sides in its web development work.

Frequently asked questions

Can a marketing site and a SaaS dashboard live in one codebase?

Yes. Next.js lets you choose the rendering method per page, so marketing routes can be static while dashboard routes render per request or in the browser. Splitting into two deployables is also common, and the sources do not settle it, so decide on team size and release cadence.

Should a SaaS dashboard be indexed by search engines?

Usually no. Next.js guidance describes client-side rendering as suited to data-heavy dashboards and account pages that you do not need in a search index. Keep indexable content on the marketing side.

Why is client-side rendering a poor fit for a marketing site?

Content that depends on client-side fetching and large JavaScript bundles makes Core Web Vitals harder to meet. The key SEO principle is that page data and metadata are available on page load without JavaScript.

Can a CDN cache dashboard pages?

Only the static shell. Responses that set or depend on session cookies must not be cached publicly, or one user's session can leak to another. Supabase's docs have the auth helper apply Cache-Control, Expires and Pragma headers for this reason.