Getting rendering and metadata right
Next.js lets you render each route as static, server-rendered, or client-only, and the choice per page decides how reliably it gets indexed. Mixing these up (for example, client-rendering a content page that should be static) is one of the most common Next.js SEO mistakes.
Metadata is the other half. Whether you're on the App Router's Metadata API or the Pages Router's Head component, titles, descriptions, canonical tags, Open Graph, and structured data need to be generated on the server so they're present in the initial HTML.
- Map each route to static, SSR, or ISR based on how its content changes
- Use the App Router Metadata API (or next/head) for server-rendered tags
- Generate canonical URLs and Open Graph server-side, not via client JS
- Add JSON-LD structured data in the server-rendered output
- Avoid client-only rendering for pages that need to rank
- Handle trailing-slash and locale routing consistently to avoid duplicates
Performance, sitemaps, and crawl control
Next.js can be extremely fast, but only if you use its tooling: the Image component for properly sized and lazy-loaded images, font optimization, and code-splitting to keep JavaScript payloads down. These directly affect Core Web Vitals, which affect user experience and page experience signals.
On the crawl side, Next.js can generate your sitemap and robots rules programmatically so they stay accurate as pages are added, and dynamic routes need correct status codes (a real 404, not a soft 200) for pages that don't exist.
- Use next/image for responsive, lazy-loaded, correctly-sized images
- Trim and split JavaScript bundles to protect Core Web Vitals
- Generate sitemap.xml and robots.txt from your route data
- Return true 404 status codes for missing dynamic routes
- Preload critical fonts and avoid layout shift from web fonts
- Confirm rendered output with the URL Inspection tool
More on technical seo
Frequently asked questions
Is Next.js good or bad for SEO?
It can be excellent, because it supports server-side and static rendering out of the box. The outcome depends on configuration. A Next.js site set up as a client-rendered single-page app throws away those advantages, while one using static or server rendering per route is very SEO-friendly.
App Router or Pages Router for SEO?
Both can rank well. The App Router's Metadata API and server components make server-side metadata and rendering cleaner, but a well-built Pages Router site is not at a disadvantage. We work with whichever your project already uses rather than pushing a rewrite.
Do I need SSR for every page?
No. Static generation is usually better for pages that don't change often because it's faster and simpler. Reserve SSR for pages whose content changes per request or too often to pre-build. The right mix is per page type, not one setting for the whole site.