A practical technical SEO checklist for Next.js 15

Start with the route inventory

List public, indexable routes separately from account, search, preview, and utility routes. For each public route record its canonical URL, intended search purpose, page owner, and whether it should be indexed. This catches accidental duplicates and private pages before you tune tags.

Choose one canonical host and protocol at the infrastructure layer. Redirect alternate hosts and HTTP consistently; a canonical link is a signal, not a substitute for redirects or correct internal links.

Render useful metadata per route

In the App Router, export static metadata for stable pages or generateMetadata when title or description depends on route data. Keep the title and description accurate to the visible page. Give each meaningful route its own canonical path and social title/description/image.

For dynamic routes, return notFound() for missing content instead of rendering an empty success page. Avoid generating near-identical titles from slugs without editorial review.

Illustrative example — not executed

import type { Metadata } from "next";

export const metadata: Metadata = {
  title: "Technical SEO for Next.js | Example",
  description: "A route-specific, accurate summary of this page.",
  alternates: { canonical: "/services/technical-seo" },
  openGraph: {
    type: "website",
    url: "https://example.com/services/technical-seo",
    title: "Technical SEO for Next.js | Example",
    description: "A route-specific summary.",
    images: ["/social/technical-seo.png"],
  },
};

Make crawl paths explicit

Publish a sitemap containing canonical, indexable URLs and a robots.txt that permits the intended public sections. Keep sitemap entries aligned with actual route output and remove redirected, noindex, or nonexistent URLs.

Use ordinary crawlable links for navigation and related content. A sitemap helps discovery; it does not guarantee indexing. Check important pages in Search Console after deployment and investigate access, canonical selection, and content quality signals there.

Use structured data conservatively

Add JSON-LD only when it describes visible, current page content and matches the schema type's documented properties. Escape serialized data safely, validate the JSON syntax, and never mark up content that a visitor cannot see. Breadcrumb markup can describe the page hierarchy; it does not guarantee a search enhancement.

Keep structured data generation close to the content model so names, URLs, and dates cannot silently diverge. Remove stale schema when a page changes type or is retired.

A repeatable diagnostic pass

Run the same checks against a representative route matrix: static page, dynamic page with data, dynamic page with missing data, and a route that should not be indexed. For each, request the production URL without following redirects first, then follow the chain and record status codes, final URL, and response headers. Inspect the final rendered HTML rather than assuming source exports map one-to-one to output.

Compare the `<title>`, description, canonical, robots directive, H1, and JSON-LD against the route inventory. Check internal links for the intended canonical URL. Parse JSON-LD as JSON and then validate properties against the relevant official schema or Google documentation; parsing alone is only a syntax check.

For sitemap review, fetch the deployed sitemap and sample its URLs. Each listed URL should resolve directly to the intended canonical page, return a successful response, and be allowed for indexing. For robots.txt, verify rules against the actual route plan and confirm that disallow rules do not hide assets or pages you expect a crawler to fetch.

Acceptance criteria for a release

A release is ready for technical review when every intended indexable route has a stable 200 response, unique and accurate title and description, one intended canonical, a useful primary heading, and crawlable links. No private, duplicate, redirected, missing-data, or noindex route should appear in the sitemap.

Robots rules should match the documented crawl policy. Structured data should parse, describe visible content, and pass the applicable validator without unsupported fields or content. Redirects should converge on one host and protocol. Record any exceptions with a reason and owner rather than silently treating them as passes.

These checks establish implementation behavior, not indexing. After release, inspect important URLs and sitemap processing in Search Console. Google may choose a different canonical, delay crawling, or decline indexing; treat those outcomes as monitoring signals, not something this checklist can guarantee.

Release checks and limits

After deployment, inspect rendered HTML for the canonical, robots directives, title, description, headings, and JSON-LD. Confirm redirects and status codes with an HTTP client, then use Search Console URL inspection and sitemap reporting to observe Google's processing.

A source-level checklist cannot establish that Google crawled, indexed, or selected a canonical URL. Search appearance and rich result eligibility depend on Google's systems and current policies; neither metadata nor valid schema guarantees a ranking or enhancement.