SSR on Next.js App Router for SEO — what to render where, with measurements

What we measured, on what

Six funded-SaaS sites we migrated from Pages Router to App Router across the last 12 months: a developer tools homepage, a B2B compliance dashboard's marketing surface, a fintech pricing page, a healthtech blog, an ecommerce product index, and a media publisher's article template. All six were already on Next.js 13 or 14 Pages Router; the migrations took 2-5 weeks each.

For each page, we measured three signals before and after the migration:

• TTFB — CrUX p75, measured in the calendar month after migration.
• LCP — same source, same window.
• Indexability — the percentage of links visible in the rendered HTML that Googlebot can also see with JS disabled (our standard RDI metric from the JavaScript SEO study).

The same measurement loop runs against every site on our technical SEO for SaaS retainer — both before-and-after on rendering changes and as a monthly baseline that catches accidental regressions.

The four rendering modes, decoded

The App Router does not call them “modes” in the docs, but functionally these are the four distinct shapes the framework will take on a given route. Knowing which one your code triggered is the entire game.

What each mode does for SEO

Below: the measurements across the six sites we migrated. Numbers are median deltas at the page-type level. Higher indexability = better; lower TTFB and LCP = better.

Two patterns to call out. First, the static page TTFB improvements are huge because the App Router default serves cached static HTML from the CDN edge, where Pages Router on Vercel was rendering on-demand at the function edge with a cold start. Second, the dashboard's LCP gets worse than the marketing pages because the Client Components inside need to hydrate — but the dashboard is behind auth and is not indexed, so LCP-for-SEO does not apply.

Recipes per page type

Recipe 1 — Marketing pages

Goal. Maximum indexability, lowest TTFB, shareable URLs. Shape. Pure Server Component, no dynamic data, no cookies() or headers(), no fetches with cache: "no-store". The route gets statically rendered at build and serves from the CDN. This is the default shape on every SaaS marketing surface we build through our SaaS web-app development engagement.

import { Hero } from "@/components/marketing/Hero";
import { Features } from "@/components/marketing/Features";
import { Testimonials } from "@/components/marketing/Testimonials";
import { CallToAction } from "@/components/marketing/CallToAction";

// Static by default — no dynamic APIs used anywhere below
export default async function HomePage() {
  // fetch here would also default to caching unless explicit no-store
  const testimonials = await getTestimonials();
  return (
    <>
      <Hero />
      <Features />
      <Testimonials items={testimonials} />
      <CallToAction />
    </>
  );
}

export const metadata = {
  title: "Acme — the simple SaaS for X",
  description: "Acme makes X simple. Used by 4,000 teams.",
  openGraph: { /* ... */ },
};

Recipe 2 — Pricing with A/B

Goal. Indexable and personalised. Shape. Server Component that reads a variant cookie, picks a variant, renders. The page is dynamic (per-request) but the response time stays under 250ms because the work is just a cookie read + a hash.

import { cookies } from "next/headers";
import { PricingTable } from "@/components/pricing/PricingTable";
import { getActiveVariants } from "@/lib/ab";

export default async function PricingPage() {
  const variants = await getActiveVariants();
  const c = cookies();
  const variant = c.get("ab.pricing")?.value ?? "control";
  const config = variants[variant] ?? variants.control;

  return <PricingTable config={config} />;
}

export const metadata = {
  title: "Pricing — Acme",
  description: "Plans for teams of any size. Free trial, no card required.",
  alternates: { canonical: "https://acme.com/pricing/" },
};

Recipe 3 — Product index (streaming)

Goal. Shell renders fast (good for LCP); product cards stream in. Each card is still in the HTML for crawlers because Next sends the full chunked response.

import { Suspense } from "react";
import { ProductGridSkeleton } from "@/components/products/Skeleton";
import { ProductGrid } from "@/components/products/Grid";
import { PageHeader } from "@/components/products/Header";

export default function ProductsPage() {
  return (
    <>
      <PageHeader />
      <Suspense fallback={<ProductGridSkeleton />}>
        {/* This server component awaits a slow data source. The
            outer page TTFB is fast because the shell is rendered
            without waiting for it. */}
        <ProductGrid />
      </Suspense>
    </>
  );
}

The key SEO win here: crawlers receive the full streamed response, so the rendered HTML still contains every product card link. Googlebot does not stop reading when the first chunk arrives.

Recipe 4 — Dashboard (Client Components inside SSR shell)

Goal. No indexability needed (auth-gated); fast hydration; interactive widgets. Shape. Server-rendered shell with auth check; Client Components for the interactive bits inside.

import { redirect } from "next/navigation";
import { getSession } from "@/lib/auth";
import { DashboardChart } from "@/components/dashboard/Chart"; // 'use client'
import { DashboardTable } from "@/components/dashboard/Table"; // 'use client'

export const metadata = { robots: { index: false } };

export default async function DashboardPage() {
  const session = await getSession();
  if (!session) redirect("/login");

  const data = await getDashboardData(session.userId);

  return (
    <main>
      <h1>Welcome back, {session.user.name}</h1>
      <DashboardChart series={data.series} />
      <DashboardTable rows={data.rows} />
    </main>
  );
}

The rules of thumb that hold up

Across the six migrations, the rules that consistently produced the best outcome:

1. Default to Server. Add "use client" only where you need state, effects, or browser-only APIs. Most of an app does not.
2. Don't opt out of caching without a reason. Every cache: "no-store" and every cookies() read collapses static rendering to dynamic. Audit them.
3. Use Suspense streaming for slow data only. If the data is fast, streaming adds complexity for no win.
4. Keep client islands small. A Client Component should be the leaf, not the page. Hydration cost scales with the size of the client bundle.
5. Add JSON-LD on the server, not the client. The mistake we see most often when auditing JS SEO — covered in the funded SaaS JS SEO study and the schema A/B test.
6. Set metadata per route. The new metadata API is the cleanest place to put title, description, canonical, OG tags. Do it once per route.

Streaming SSR caveats

Streaming with Suspense is genuinely powerful for slow data sources, but it has two pitfalls we hit on every migration:

• Search engine bots may close the connection early. Most do not, but the very long-tail crawlers (some baidu / yandex variants) sometimes cut after the first chunk. Keep the most important content in the shell, not behind Suspense.
• Streaming breaks if a parent server component throws. Anything inside Suspense needs a sibling error.tsx at that level, or the whole stream blanks.

The Pages Router → App Router migration itself usually runs as a 3-5 week engagement on a typical SaaS marketing surface, depending on how many Client Components need to be split out from existing pages. We run this specifically through our tech-stack migration engagement so the SEO measurement loop above runs through the full migration window, not just at the end.

About the author

Ritesh — Founding Partner, Appycodes

LinkedIn

Co-authored with Soumodip Mukherjee, Technical SEO Lead

Ritesh runs engineering at Appycodes. Soumodip leads the technical-SEO practice and ran the before/after measurements behind this post — six migrations across funded SaaS clients in the last 12 months, with TTFB / LCP / indexability tracked through the same monitoring stack we use on every SEO retainer.

Last reviewed: May 17, 2026