Article

Technical SEO for Next.js: What Actually Matters (2026)

By DevCritters • July 8, 2026 • 9 min read

Technical SEO for Next.js: What Actually Matters (2026)

Short answer: Next.js gives you better technical SEO primitives than most React frameworks — Metadata API, built-in sitemap and robots generation, image optimisation, static rendering — but none of it ships configured. You still need unique titles and descriptions on every route, a correct canonical on every indexable page, a sitemap that matches those canonicals, structured data that reflects what's actually in the HTML, and a rendering strategy that serves crawlers finished content without waiting on JavaScript. Skip any of that and you've just built a fast site Google can't rank properly.

This is the implementation guide — not a repeat of WordPress vs Next.js SEO. If you're running headless WordPress with a Next.js front end, pair this with our headless WordPress + Next.js setup guide. If you're migrating and worried about rankings, read WordPress to headless CMS before you touch redirects.

What technical SEO means on a Next.js site

Technical SEO is everything that helps search engines find, crawl, understand, and index your pages — without relying on content quality alone. On Next.js that breaks down into five layers: crawlability (can Google reach the URL?), indexability (should it be in the index?), metadata (what should the SERP show?), structured data (what type of page is this?), and performance (does it pass Core Web Vitals?).

WordPress bundles most of this behind SEO plugins. Next.js puts it in your codebase. That's an advantage if someone owns it. It's a liability if nobody does — and that's the pattern we see on half the Next.js audits we run.

Start with metadataBase — everything else depends on it

In the App Router, set metadataBase once in your root layout.tsx to your production URL — including the www if that's your canonical host. Without it, relative canonical URLs and Open Graph image paths resolve incorrectly in production. We've seen sites where every canonical pointed at localhost or a Vercel preview domain because nobody set this before launch.

From there, every indexable route needs a unique title and description. Static pages export a metadata object. Dynamic routes — blog posts, product pages, location pages — use generateMetadata so titles pull from your CMS or database at build time. Duplicate titles across 40 blog posts is still duplicate titles, regardless of stack.

Keep titles around 50–60 characters before your brand suffix. Put the detail in the meta description, not the title. Google truncates long titles anyway.

Canonicals: one preferred URL per page

Every public page should declare alternates.canonical pointing at the URL you want indexed. Match your trailing-slash convention site-wide — pick trailingSlash: false in next.config and stick to it. Mixed /about and /about/ variants split signals for no reason.

On headless WordPress builds, the classic failure is two canonical sources competing: Yoast or Rank Math outputting a sitemap and canonicals from the WordPress origin, while Next.js serves the public site on a different domain. Disable SEO plugin sitemap and robots output on the WordPress backend. The Next.js frontend owns canonicals, sitemap, and robots — full stop. Two sitemaps listing different URL patterns is how migrations lose 30% of traffic without anyone noticing for weeks.

Sitemap and robots — use the built-in file conventions

Next.js App Router generates /sitemap.xml from app/sitemap.ts and /robots.txt from app/robots.ts. No plugin required. Your sitemap should list every indexable URL with realistic lastModified dates — not today's date on every entry, which tells Google nothing.

Exclude utility routes: API paths, preview URLs, draft mode endpoints, admin, staging. In robots.ts, disallow /api/ and any authenticated areas, then reference your sitemap URL explicitly. Remember: robots.txt blocks crawling, not indexing. A page with external links can still appear in results. Use robots: { index: false } in metadata for pages you don't want indexed at all.

After deploy, submit the sitemap in Google Search Console once. Re-submit after major content changes or migrations — not weekly out of habit.

Rendering strategy is a technical SEO decision

This is where Next.js teams get it wrong most often. Defaulting every route to server-side rendering because it feels flexible adds latency, hurts LCP, and produces variable HTML that some crawlers handle inconsistently. For marketing sites, blogs, and documentation, static generation or ISR is usually the right default — crawlers get complete HTML immediately from the CDN.

A practical split for business sites:

  • SSG — homepage, about, service pages, blog posts that don't change hourly
  • ISR — headless CMS content that updates on publish via webhook revalidation
  • SSR — pages that genuinely need per-request personalisation or live data
  • Client-side only — avoid for any URL you need indexed; if content only renders after JavaScript, you're betting on Google's renderer

If you're rebuilding from WordPress, map each template type to a rendering strategy before development starts — not during launch week. See migration cost and timeline for why scoping matters.

Structured data: JSON-LD in the page, not wishful thinking

Next.js doesn't generate schema for you. You add JSON-LD — typically via a <script type="application/ld+json"> in the page or layout. Common types for business sites: Organization, WebSite, Service, BlogPosting, FAQPage, BreadcrumbList.

FAQ schema only works if the FAQs are visible on the page in plain HTML — not hidden in a collapsed accordion Google can't see. Match the schema text to the visible content exactly. Mismatched FAQ schema is a fast track to rich result removal.

For blog posts: BlogPosting with headline, datePublished, dateModified (update this when you materially edit a post), author, and image. If you run headless WordPress, pull metadata from the CMS API but render schema on the Next.js side — don't rely on WordPress plugin schema output that never reaches the public HTML.

Core Web Vitals are part of technical SEO now

Google uses field data from real visitors when it has enough. On Next.js, the wins come from static HTML (fast LCP), controlled JavaScript budgets (better INP), and explicit image dimensions (lower CLS). Use next/image with proper sizes attributes. Self-host fonts or use next/font to avoid layout shift. Don't load analytics and chat widgets synchronously on every page.

We've documented the WordPress side in fixing Core Web Vitals without a rebuild. On Next.js, the ceiling is higher — but we've audited Next.js builds that scored worse than the WordPress sites they replaced because nobody sized images or controlled the JS bundle. Framework choice doesn't replace discipline.

Our studio site (devcritters.com) — desktop PageSpeed, May 2026: Performance 99, SEO 100, LCP 0.9s, CLS 0. Client example: Oxbridge Summer Courses — mobile Core Web Vitals passed, LCP 1.8s, INP 139ms, CLS 0.01.

Headless WordPress + Next.js: extra technical SEO checks

If WordPress is your CMS and Next.js is your public site, add these to your launch checklist:

  • 301 redirect map from every old WordPress URL to the new Next.js URL — not the homepage
  • Single sitemap on the Next.js domain; disable WordPress SEO plugin sitemaps
  • Preview and draft URLs blocked from indexing (noindex + robots disallow)
  • Metadata parity — titles, descriptions, and canonicals match or improve on the WordPress originals
  • Internal links updated — no hrefs pointing at the old WordPress theme URLs
  • Search Console monitoring for 30–60 days post-launch

Most migration traffic drops we've seen weren't caused by Next.js. They were caused by incomplete redirect maps and duplicate sitemaps. Execution risk, not platform risk — same point we make in WordPress vs Next.js SEO.

Technical SEO audit order for Next.js

When we audit a Next.js site, we work in this order:

  1. Crawl the sitemap — does it match every indexable route? Any orphan pages?
  2. Check canonicals on a sample of templates — correct absolute URLs?
  3. View rendered HTML (curl or View Source) — is content in the initial response or only after JS?
  4. Validate structured data in Google's Rich Results Test
  5. Run PageSpeed on mobile for money pages — LCP, INP, CLS passing?
  6. Search Console — index coverage errors, CWV failures, query impressions vs clicks

Most issues surface in the first three steps without paid tools.

FAQ: technical SEO for Next.js

What is technical SEO for Next.js?

The crawlability, indexability, metadata, structured data, and performance setup that helps search engines find and rank your pages. Next.js provides the tools — Metadata API, sitemap/robots conventions, static rendering — but you implement them per route.

How do I set up metadata in Next.js App Router?

Set metadataBase in root layout. Export static metadata on fixed pages. Use generateMetadata on dynamic routes. Include unique title, description, canonical, Open Graph, and Twitter card on every indexable page.

Does Next.js need a sitemap?

Yes. Create app/sitemap.ts listing every indexable URL with accurate lastModified dates. Submit to Google Search Console after deploy. Exclude API routes, previews, and admin paths.

Is SSR or SSG better for SEO in Next.js?

SSG and ISR are better defaults for content pages — crawlers get complete HTML from the CDN immediately. SSR is fine when you genuinely need per-request data. Avoid client-only rendering for pages you need indexed.

How do I add structured data in Next.js?

Output JSON-LD via a script type="application/ld+json" tag in your page or layout. Common types: Organization, BlogPosting, FAQPage, BreadcrumbList. Content in schema must match visible page content.

What are common Next.js SEO mistakes?

Missing metadataBase, duplicate titles across routes, no canonical tags, sitemap listing wrong URLs, SSR on everything hurting LCP, client-side-only content for indexable pages, and on headless builds — competing WordPress and Next.js sitemaps.

Does Next.js hurt SEO compared to WordPress?

No — when implemented correctly. WordPress SEO plugins handle metadata by default; Next.js requires you to build it. Both can rank equally. Next.js makes Core Web Vitals easier to hit; WordPress makes day-to-day metadata editing easier for non-developers.

How does technical SEO change after a WordPress to Next.js migration?

You rebuild metadata, schema, and sitemap in Next.js. Redirects must cover every old URL. Disable WordPress SEO output on the origin. Monitor Search Console for 30–60 days. See our migration guide for the full checklist.

Related resources

Bottom line

Technical SEO for Next.js isn't a plugin you install — it's a set of decisions you make per route and enforce at launch. metadataBase, canonicals, sitemap, rendering strategy, structured data, and Core Web Vitals. Get those right and Next.js is one of the strongest SEO foundations in the React ecosystem. Skip them and you've built a fast site with invisible pages.

We implement technical SEO on Next.js and headless WordPress builds for businesses worldwide. Services · Technical SEO · Performance proof · Book a consultation.

whatsapp