Skip to content
All guides
SEO

The Technical SEO Checklist for Next.js Sites

A practical technical SEO checklist for Next.js App Router sites: metadata, canonical URLs, sitemaps, structured data and Core Web Vitals.

Craftigent EngineeringWeb Platform9 min read

Next.js gives you the primitives for excellent technical SEO and no obligation to use them correctly. This checklist covers the decisions that actually move rankings on an App Router codebase, in the order we work through them on client engagements.

Get metadata right at the route level

The App Router resolves metadata per segment, so a layout can own defaults and each page overrides only what differs. Export a static metadata object where the content is fixed and generateMetadata where it depends on data.

The two failures we see most often: a title template applied so aggressively that every page reads the same, and dynamic routes that fall back to layout metadata because generateMetadata threw and nobody noticed.

  • Set metadataBase once in the root layout so relative OG images resolve
  • Give every indexable page a unique title and description
  • Emit canonical URLs through alternates.canonical, including on paginated routes

Make crawling cheap

Crawl budget is not a concern for a 40-page site and is decisive for a catalogue with faceted navigation. Generate sitemap.ts from the same data source that generates your routes so the two can never drift.

Block parameter permutations in robots.ts rather than relying on canonical tags alone. Canonicals are a hint; disallow is a rule.

  • Generate sitemaps from data, never hand-maintain them
  • Return real 404s for missing content instead of soft 200s
  • Keep redirect chains to a single hop

Ship structured data that matches the page

Article, BreadcrumbList and Organization cover most of what a consultancy or SaaS site needs. Render JSON-LD from the same object that renders the visible content so the markup cannot describe a page that does not exist.

Validate in the Rich Results Test before launch, then re-check after any template change. Structured data breaks silently.

Treat Core Web Vitals as a build gate

LCP is usually a hero image or a font swap, INP is usually hydration of components that did not need to be client components, and CLS is usually an image without dimensions. All three are fixable in a day once measured.

Put Lighthouse CI in the pipeline with a budget that fails the build. Performance regressions that only show up in a monthly report never get fixed.

  • Preload the LCP image and self-host fonts with next/font
  • Push interactivity down: keep 'use client' at the leaves
  • Set explicit width and height on every image

Want us to run this for you?

We do this work on client systems every week. Tell us where you are and we will say what we would do first.

Book a Call