A framework that can render anything will render the wrong thing confidently.

The single most consequential Next.js SEO question is which rendering strategy each route actually uses in production — and the answer is frequently not the one the team believes. A "use client" added three components up the tree, a dynamic function called in a layout, a cookie read during render: each quietly changes what arrives in the HTML for every route beneath it.

The diagnosis is not a code review. It is a comparison: fetch the route with JavaScript disabled, diff it against the rendered DOM, and do that per template rather than per page. What comes back is specific — this heading is present, this product description is not — and it is the finding everything else depends on.

The App Router resolves metadata by merging the nearest metadata export or generateMetadata up the segment tree. That is a good design and it produces one recurring defect: a route with no metadata of its own silently inherits the layout’s, and a dynamic route with a generateMetadata that throws or returns early gets the same treatment.

The symptom is a set of pages sharing one title. The cause is a data fetch failing quietly inside metadata generation while the page body renders fine from a separate fetch. Nothing surfaces it except reading the shipped titles across the route set, which is a five-minute check and almost never run.

The related trap is metadataBase. Unset, relative Open Graph and canonical URLs resolve against whatever the deployment thinks its origin is — which on a preview deployment is a preview URL, canonicalised into production if that build is ever promoted.

Dynamic segments and catch-alls make it easy to serve one page from several addresses: a trailing slash variant, a case variant, an optional segment present and absent, a locale prefix that is sometimes implicit. Each is a distinct URL and each returns 200.

The canonical has to be generated from a single normalisation function rather than assembled per route, or the routes drift — and they drift in the direction of whatever a developer wrote most recently. Where the framework’s own trailingSlash setting disagrees with what the canonical emits, the site contradicts itself in the head of every page.

Incremental static regeneration solves a real problem and creates a reporting one: a route regenerated on a timer has a new build timestamp and frequently identical content. A lastmod or a dateModified derived from build time then reports every page as changed on every revalidation.

That is worse than omitting it. A freshness signal that fires constantly is a signal that has been trained out of usefulness, and it is a self-inflicted one. The honest source is the content’s own last modification in whatever system authors it — the CMS timestamp, the commit date, the record’s updatedAt — not the moment the cache decided to rebuild.

This site makes the same argument about itself, and it took shipping the bug to learn it properly.

A client-side route transition has no HTTP status. Calling notFound() from a server component returns a real 404 on a hard request; a not-found state rendered inside a client component after a fetch resolves returns 200 with an apology on it, forever.

The check is direct and cheap: request a deliberately invalid dynamic segment with curl and read the status line. Sites that pass this in the browser and fail it on the wire are common, and the consequence is an index slowly filling with pages that say nothing.

A sitemap.ts generated from the same data source as the routes is the correct pattern and the reason most Next.js sitemaps are structurally sound. The defect is drift at the edges: a route excluded by middleware but present in the data, a draft record with a published flag the sitemap query does not filter, a locale enabled in config and not in content.

The sitemap is the one file where a site states its own intent unambiguously. A submitted URL that redirects, 404s or canonicalises elsewhere is the site contradicting itself in the one place it had complete control, which is why Atlas treats sitemap parity as a technical finding rather than a hygiene note.