Next.js SEO: Rendering Modes and What They Cost You

The rendering mode you choose per route in Next.js decides whether a crawler sees your content at all, and that is a more consequential SEO decision than any on-page tweak you make afterward. Two pages with identical copy and identical internal links can rank very differently if one serves fully formed HTML on the first response and the other ships an empty shell that only fills in once JavaScript has loaded and run.

Next.js hands you four rendering modes to pick from per route — static generation, server-side rendering, incremental static regeneration and client-side rendering — each trading freshness, server cost and crawlability differently, and the framework's own App Router versus Pages Router split changes which controls apply to each one. Get the choice wrong on a route that needs to rank, and no amount of keyword work in the copy fixes it afterward.

The Four Rendering Modes, In Terms of Consequences

Rather than start from the jargon, ask one question about each mode: what does the very first HTTP response actually contain, before any JavaScript runs?

In practice, that means not reaching for a client component with a data fetch inside a useEffect for anything that needs to rank — if the text a searcher wants only appears after that fetch resolves, the page has the CSR failure mode built in by accident.

• Static generation (SSG) builds a page's HTML once, ahead of any request, so a crawler gets complete content immediately. It's the fastest, most crawl-friendly option, at the cost of freshness — a good fit for marketing pages and evergreen guides.
• Server-side rendering (SSR) generates that same complete HTML per request, at the moment it's asked for. Crawlability matches static generation; the tradeoff moves from staleness to added server load on every hit, worth paying for routes that must reflect current state.
• Incremental static regeneration (ISR) serves pages from a static cache that Next.js regenerates in the background after a set interval. Crawlers still get complete HTML every time; content can simply lag reality by up to one revalidation window.
• Client-side rendering (CSR) sends a near-empty shell, with content assembled by JavaScript after the bundle downloads and runs. A crawler requesting the raw page gets little useful in that first response. Search engines can run a delayed second pass to execute JavaScript, but it's queued and not guaranteed to behave the same for every page, and other crawlers relevant to a site's traffic often don't execute JavaScript at all. The plain rule: content that exists only after client-side JavaScript runs is content you're asking a crawler to do extra work for, and every extra step is a chance for it to be missed.

App Router vs Pages Router: Why Half the Advice You'll Read Doesn't Apply

Next.js currently ships two routing systems side by side, and this is worth flagging explicitly because it's the single biggest source of outdated or simply wrong guidance on this subject. An answer written for one router can be actively misleading applied to the other.

The practical consequence: an older article about Next.js SEO almost certainly describes the Pages Router model built around getStaticProps and next/head. On an app/-based project that guidance is a starting point at best — the caching and rendering mechanism is different enough that following it literally can misfire, and a next/head tag dropped into an App Router client component does nothing useful there. Before applying any fix found online, check which router the project uses and which router the source article was written against.

• On the Pages Router (pages/), rendering mode is chosen per page through exported functions: getStaticProps for static generation, getServerSideProps for server-side rendering, and a revalidate value returned from getStaticProps for incremental regeneration. Metadata is set imperatively inside each page component via the next/head component.
• On the App Router (app/), rendering defaults to static unless the route's own code forces dynamic behaviour — reading cookies or headers, an uncached data fetch — and the framework decides per route based on what that code does. Metadata is declarative instead: a metadata object or generateMetadata function exported per route, composing down through layouts, with React Server Components and streaming available by default.

Metadata: Titles, Descriptions, Canonicals and Open Graph

Both routers let you control the metadata that matters for search results and for how a shared link previews, but the App Router's approach solves a problem the Pages Router left to hand-rolled discipline: composition. A metadata object — or an async generateMetadata function when values depend on data — can be exported from any layout or page segment, and Next.js merges them going down the tree. A root layout sets a default title template; an individual page overrides just the title while inheriting the rest, which solves a common Pages Router failure: a batch of static pages sharing one title because nobody added a per-page override.

For templated pages — product pages, listings, anything generated from a data source — metadata has to be built dynamically from that page's own record: generateMetadata reading the same data the page renders and constructing a real title, description and canonical URL from it, and explicitly handling the case where the record doesn't exist rather than letting every route under a dynamic segment fall back to one generic title.

Canonical tags deserve a specific mention because Next.js doesn't set one for you automatically, and it matters most on any route reachable through more than one URL: filter parameters, tracking parameters, trailing-slash variants, a paginated view that duplicates a list shown elsewhere. Open Graph fields should be drawn from that same metadata source rather than a separate hand-written set, or the two quietly drift apart the first time the page content changes and the Open Graph tags don't.

• Title and description resolved per route, not silently inherited from a parent layout nobody checked.
• A canonical URL set explicitly wherever more than one path reaches the same content.
• Dynamic routes that handle a missing record with real, specific metadata rather than a blank or generic title.

The Failure Modes That Show Up Again and Again

Most Next.js SEO problems in practice aren't exotic — they're a small set of failure modes the framework makes easy to introduce without noticing.

• Soft 404s. A dynamic route such as /products/[slug] for a slug no longer in the data source will happily render a "not found" message while still returning HTTP 200, unless the code explicitly calls notFound() (App Router) or returns notFound: true (Pages Router). A crawler sees a 200 and treats it as a real, indexable page with thin content — worse for a site's aggregate quality signal than an honest 404.
• Client-side routing that never updates the title. Navigation through <Link> swaps content without a full reload, which is good for the user, but if a component sets document.title imperatively inside an effect instead of using the framework's metadata mechanism, navigating between routes can leave the previous page's title showing — invisible on a fresh load, present only during client navigation, and exactly the state a share preview can end up capturing.
• Hydration problems. When the HTML the server sent doesn't match what React produces once it takes over — a date formatted differently server-side than client-side, content gated on window — React discards or fights the mismatched markup. Best case a console warning; worse case the content actually indexed no longer matches what a user sees, and the visible reflow while React corrects itself works against Core Web Vitals.
• Redirects implemented client-side. A router.push() fired from a useEffect after the page has loaded means the original URL still returns a 200 with the old content baked in — a crawler doesn't reliably follow a client-side navigation the way it follows an HTTP redirect, and none of the original URL's authority consolidates onto the destination. Redirects that need to count for SEO belong in the redirects() config function or in middleware, both of which produce an actual HTTP redirect before any page component runs.
• Sitemaps that go stale on statically generated sites. A sitemap built once — a static file, or a function not re-triggered on deploy — drifts from reality: new pages ship without being added because generating the sitemap wasn't part of that build step, or old pages get removed while the sitemap keeps listing URLs that now return nothing. It needs regenerating on the same cadence as the content it describes.

Images and Core Web Vitals: Where the Framework Helps, and Where It Doesn't

The built-in image component handles real work that used to be manual: generating responsive size variants, lazy-loading offscreen images by default, serving a modern format where the setup supports it. That's a genuine improvement over a hand-written image tag for most images on a page.

What it doesn't do by default is help with the one image that most often decides a page's Largest Contentful Paint score — the hero image or above-the-fold visual that's usually the single largest element to paint. Lazy-loading is the default for every image the component renders, and lazy-loading the LCP image is the opposite of what that metric rewards, since it delays the very element being measured. The fix is one explicit prop: marking that image as a priority image so it loads eagerly and gets preloaded, rather than leaving the image the score depends on most on the default lazy path.

Past that setting, the ordinary fundamentals still apply: sizing the source image close to its actual rendered dimensions instead of shipping something far larger and scaling it down in the browser, supplying explicit dimensions so the browser can reserve space and avoid a layout shift, and choosing size hints that match how the image renders across breakpoints rather than accepting a default that serves a larger file than a given viewport needs.

Internationalised Routing

Next.js has built-in support for locale-prefixed routing — /en/, /es/, /fr/ segments generated from a configured list of locales — a convenient way to produce a URL structure search engines can associate with a specific language and region. The App Router implements this through route groups and middleware-driven locale detection rather than the built-in configuration option the Pages Router shipped, a detail worth checking against whichever router a project actually uses before following instructions written for the other one.

What matters for search sits alongside the URL structure: every localized page needs alternate-language links pointing to its other language versions, plus a self-referencing entry for its own locale, so a search engine reads the versions as translations of one another rather than duplicate or unrelated pages. In the App Router that's the language-alternates field of the metadata object, and those entries have to be generated from the actual set of locales a page has a translation for — a static, hand-maintained list drifts the moment a locale is added or removed, and linking to a variant that doesn't exist is worse than declaring none.

One more trap: detecting a visitor's likely language from browser or geography is a reasonable default for a human, but it should never intercept a crawler or force a redirect away from the exact URL requested. A crawler that requests the English version and gets redirected on an IP-based guess ends up indexing the wrong version, or nothing.

How to Verify What's Actually Being Served

Everything above is a claim about what a given route does. The only way to know whether it's actually true on a deployed Next.js app is to stop trusting the framework's defaults and look at the raw response the way a crawler receives it, not the way a browser presents it after JavaScript has already run.

The simplest check is a plain HTTP request to the live URL with no JavaScript execution involved, then reading the raw HTML that comes back — not the browser tab, where the DOM is already assembled and hydrated by the time anyone looks, but the literal bytes of that first response. If the title tag, meta description, canonical link and primary content are all present in that raw response, the route is serving what it should. If the body is a near-empty shell with little more than a root element, that route depends on client-side JavaScript for content a crawler may not reliably receive.

• View the page's actual source, or fetch it with a plain HTTP client — not the browser's element inspector, which shows the live DOM after JavaScript has already modified it.
• Confirm the title, meta description, canonical tag and primary body content are present in that raw HTML, not only after the page finishes loading in a browser.
• Check the real HTTP status code returned for pages that should and shouldn't exist, rather than assuming a rendered "not found" message means a 404 was actually sent.
• Recheck after any framework or dependency upgrade — a route's default rendering behaviour can change between Next.js versions without any explicit code change on your part.