Back to Blog

Next.js SEO: A Complete Technical Checklist

November 22, 2026

Most technical SEO problems on Next.js sites aren't exotic — they're a handful of recurring, checkable mistakes that quietly suppress indexing or dilute ranking signal. This is the checklist I actually run through when auditing a Next.js site's technical SEO.

Table of Contents

Canonical Tags: The Most Common Silent Failure

The single most common technical SEO bug I see on Next.js sites: every page inheriting the same canonical URL from a root layout.tsx's metadata.alternates.canonical, because Next.js metadata merges down the component tree and no individual route overrides it. The result — every page on the site telling Google it's a duplicate of the homepage — is invisible unless you specifically check each route's rendered <link rel="canonical"> tag. This one bug can suppress indexing across an entire site while every other signal looks fine.

Check it directly: fetch several different routes and grep for the canonical tag — don't assume it's correct because the homepage's is.

curl -s https://example.com/about | grep -o '<link rel="canonical"[^>]*>'
curl -s https://example.com/blog/some-post | grep -o '<link rel="canonical"[^>]*>'

Every route should show its own URL, not a shared one.

Metadata Completeness Per Route

Every route should independently set (via generateMetadata for dynamic routes, export const metadata for static ones): title, description, openGraph (including url and type), twitter, and alternates.canonical. A common gap: dynamic routes ([slug]) setting openGraph fields but forgetting alternates.canonical entirely — see my Next.js Metadata API guide for the full pattern.

Structured Data (JSON-LD)

At minimum: WebSite and Person/Organization schema on the homepage, BlogPosting or Article schema on content pages, and BreadcrumbList for any deep navigation hierarchy. Validate every JSON-LD block with Google's Rich Results Test before shipping — a syntax error in structured data fails silently, it doesn't throw a visible error, so it's easy to ship broken JSON-LD without noticing.

Sitemap Correctness

Using Next.js's file-based sitemap.ts, verify: every URL in the sitemap actually returns 200 (not a redirect or 404), lastModified dates reflect real content update times (not a hardcoded build timestamp for every entry, which signals nothing useful to crawlers), and the sitemap's host matches your canonical domain exactly (if your site redirects apex to www or vice versa, the sitemap should use the canonical host, not the one that immediately redirects).

export default function sitemap(): MetadataRoute.Sitemap {
  const posts = getAllPosts();
  return posts.map((post) => ({
    url: `https://www.example.com/blog/${post.slug}`,
    lastModified: new Date(post.updatedAt ?? post.publishedAt), // real date, not Date.now()
    changeFrequency: "monthly",
    priority: 0.6,
  }));
}

Robots.txt and Indexing Controls

Confirm robots.ts (or a static robots.txt) correctly references your sitemap's canonical URL, and that no unintended Disallow rules are blocking content you want indexed — a leftover Disallow: / from a staging environment configuration accidentally carried into production is a real, recurring incident, not a hypothetical one.

Core Web Vitals in a Next.js Context

Next.js gives you the tools (next/image for optimized images with correct sizes/priority attributes, next/font for font loading without layout shift, streaming Server Components for faster perceived load) but doesn't apply them automatically — using a raw <img> tag instead of next/image, or not marking your LCP image with priority, are common misses that directly hurt Core Web Vitals scores despite using a framework capable of much better results.

Redirect Hygiene

Every redirect is a small ranking-signal cost — chains of multiple redirects (A → B → C) should be collapsed to a single hop (A → C) directly. Check your apex-to-www (or vice versa) redirect is a single 301/308 hop, not accidentally chained through an intermediate redirect from a previous domain migration or DNS change.

The Full Checklist

  • Every route has its own correct alternates.canonical, not inherited from root layout
  • generateMetadata used for all dynamic routes, not hardcoded static metadata
  • openGraph.url and type set correctly per route
  • JSON-LD validated with Google's Rich Results Test, no syntax errors
  • Sitemap URLs all return 200, use real lastModified dates, match canonical host
  • robots.txt sitemap URL matches canonical host, no unintended Disallow rules
  • LCP images use next/image with priority set
  • Fonts loaded via next/font to avoid layout shift
  • No redirect chains longer than one hop
  • metadataBase set in root layout so relative OG image URLs resolve correctly

FAQs

How often should I re-check this checklist? After any significant routing change, metadata refactor, or domain/hosting migration — these are the changes most likely to silently reintroduce one of these issues.

Does fixing canonical tags immediately improve rankings? Not immediately — fixing the signal removes an active penalty on how Google interprets your site, but re-crawling and re-indexing takes time (weeks, sometimes longer), and ranking improvement follows re-indexing, not the fix itself.

Is Google Search Console sufficient to catch these issues, or do I need to check manually? Search Console surfaces some of these (canonical mismatches, sitemap errors) under Coverage and Sitemaps reports, but it doesn't catch everything automatically and reports can lag — direct verification (curling routes, checking rendered HTML) catches issues faster and more precisely.

Do these issues apply equally to a small personal site and a large e-commerce site? The principles apply universally; the blast radius scales with site size — a canonical bug on a 10-page site is a smaller problem than the same bug on a 10,000-page e-commerce catalog, but it's worth fixing at any scale.

Key Takeaways

  • Canonical tag misconfiguration (every page pointing to the homepage) is the most common and most damaging silent technical SEO bug on Next.js sites — verify it directly, don't assume.
  • Every route needs complete, independent metadata — dynamic routes commonly miss alternates.canonical even when other fields are set correctly.
  • Sitemap and robots.txt correctness (real dates, matching canonical host, no accidental Disallow rules) are cheap to verify and easy to get subtly wrong.

Related Reading

Next Steps

Want a technical SEO audit of your Next.js site? Get in touch — this is exactly the kind of thing worth catching before it costs you months of suppressed rankings.

LinkedIn