SEO

Next.js SEO Checklist (2026): Metadata, Sitemaps, Structured Data, and Performance

A field-tested Next.js SEO checklist covering everything from crawlability to structured data. Built for classic search rankings and AI-powered search answers alike.

LXT Development

SEO & Web Development Specialist

9 min read

A field-tested Next.js SEO checklist covering everything from crawlability to structured data. Built for classic search rankings and AI-powered search answers alike.

You picked Next.js because it's fast, flexible, and renders real HTML that search engines can actually read. Good call. But the framework won't do your SEO for you. It gives you the tools. You still have to wire them up correctly.

This checklist covers the things that actually move the needle: making sure Google can find and understand your pages, getting your metadata right, feeding structured data to search engines (and the AI models that now sit on top of them), and keeping your Core Web Vitals from quietly killing your rankings.

No fluff. No theory. Just the stuff you need to check, fix, or implement.

Start Here: Can Google Actually Crawl Your Site?

Before you touch metadata or structured data, answer this question: is Google even seeing your pages? A surprising number of Next.js sites ship with indexing problems they never notice.

Check your rendering strategy first. If you're using the App Router (and you should be), your pages are server-rendered by default. That means Googlebot gets fully-formed HTML without needing to execute JavaScript. This is a massive advantage over client-side-only React apps. But if you've sprinkled 'use client' directives everywhere and your key content only renders after hydration, you could still have gaps.

Quick test: open your site in Chrome, view source (not Inspect, actual view source), and look for your page content in the raw HTML. If it's not there, search engines aren't seeing it either.

Pick the right rendering mode for each page type. Static Site Generation (SSG) is your best friend for content that doesn't change often, like blog posts, landing pages, and documentation. It's the fastest option and pre-renders at build time. Use Incremental Static Regeneration (ISR) when content updates periodically but you still want static performance. Server-side rendering (SSR) is for pages that genuinely need real-time data on every request, like user dashboards or live pricing.

The rule of thumb: use the most static rendering option each page can tolerate. Faster pages rank better, and static pages are the fastest.

Metadata and Open Graph: The Stuff People Actually See

Next.js 15's Metadata API is one of the framework's best SEO features, and most developers barely scratch the surface.

For static pages, export a metadata object from your page.tsx or layout.tsx with a unique title, description, and canonical URL. For dynamic pages (blog posts, product pages), use generateMetadata to fetch data and return page-specific metadata at build or request time. Both approaches are native to the App Router and require zero additional packages.

Don't skip Open Graph tags. These control how your pages look when shared on LinkedIn, Slack, X, and every other platform. A page with a broken or missing social preview gets fewer clicks, period. Include og:title, og:description, and og:image (1200x630px) at minimum, plus twitter:card set to summary_large_image. All of these go in the same metadata object alongside your regular title and description.

Next.js also supports file-based OG images. Drop an opengraph-image.tsx file in your route folder, and it generates images dynamically at build time, cached with hashes. This is cleaner than maintaining a library of static images and ensures every page gets a unique preview.

The metadata mistake most people make: duplicating the same title and description across multiple pages. Every page needs unique metadata. If you have 50 product pages with the same description, Google sees 50 pages competing with each other for the same query.

Sitemaps and robots.txt: Telling Crawlers Where to Go

Next.js makes sitemap generation almost too easy to skip. Create a sitemap.ts file in your app/ directory and export a default function that returns an array of URL objects with url, lastModified, and priority fields. That's it. Next.js serves it at /sitemap.xml automatically.

For large sites with hundreds or thousands of pages, use generateSitemaps to split your sitemap into chunks. Google's limit is 50,000 URLs per sitemap file, but smaller, well-organized sitemaps are easier to debug.

robots.txt works the same way. Create a robots.ts file that exports a function returning your rules (user agent, allow, disallow) and sitemap URL.

Things people forget: blocking staging environments from indexing (add noindex headers or robots.txt blocks on non-production domains), including the sitemap URL in robots.txt, and updating the sitemap when new pages are added. If your sitemap is stale, it's barely better than not having one.

Structured Data: Speak Google's Language (and the AI's)

Structured data is how you tell search engines exactly what your page is about in a machine-readable format. It's also becoming critical for AI-powered search. Google's AI Overviews, ChatGPT search, Perplexity, and similar tools all rely on clearly structured content when deciding what to cite.

Use JSON-LD for structured data. It's Google's preferred format, and it's easy to implement in Next.js by adding a <script type="application/ld+json"> tag to your page or layout with a dangerouslySetInnerHTML prop containing your stringified schema object. Create a reusable <StructuredData /> component if you're adding it to many pages.

Which schema types matter most?

For most business sites, start with Organization (on your homepage), WebSite (also homepage, enables sitelinks search), Article or BlogPosting (for content pages), and FAQPage (for pages with Q&A sections). If you sell services or products, add Service, Product, or LocalBusiness as relevant.

For pages with step-by-step instructions, HowTo schema can earn rich results in Google and makes your content highly citable by AI search engines.

Validate everything. Use Google's Rich Results Test (search.google.com/test/rich-results) before deploying. Broken structured data is worse than no structured data because it erodes Google's trust in your markup over time.

The AI search angle: AI Overviews and answer engines favor content with clear FAQ sections, direct answers in the first 50 to 70 words of each section, and consistent entity naming throughout the page. Structured data reinforces all of this. Think of JSON-LD as your machine-readable summary, and your page content as the human-readable one. Both need to tell the same story.

International SEO: hreflang and Multilingual Setup

If your Next.js site serves multiple languages, getting this wrong means Google either ignores your translations or treats them as duplicate content.

Use the Metadata API's alternates field to generate hreflang tags. In your generateMetadata function, return an alternates object with a canonical URL and a languages map that includes every locale plus x-default for fallback.

Always include x-default. It tells search engines which version to show when no locale matches. This is the one most multilingual setups miss.

Your sitemap needs hreflang alternates too. For each URL, include alternate entries for every language version. The Next.js sitemap API supports an alternates.languages field that generates the correct xhtml:link tags automatically.

If you're using a library like next-intl, it handles the link response header for locale alternates by default, which is often sufficient. But for maximum control, especially with CMS-driven slugs that change per locale, handle it explicitly in your sitemap and metadata.

Watch your canonical tags. If your translations aren't unique yet (machine translations, placeholder content), point all locale canonicals to your primary language version until the content is genuinely distinct. This prevents duplicate content penalties during the development phase. Switch to self-referencing canonicals once each language version has real, unique content.

Performance: Core Web Vitals Are a Ranking Factor

Google has been saying this for years, and it's still true. Sites with poor Core Web Vitals rank lower. In 2026, with AI Overviews occupying the top of search results, you need every edge you can get from the organic slots below.

Largest Contentful Paint (LCP) should be under 2.5 seconds. The biggest Next.js-specific wins: use next/image with priority on above-the-fold images, avoid lazy-loading hero images, and make sure your largest content element is server-rendered (not loaded via a client-side fetch after hydration).

Cumulative Layout Shift (CLS) should be under 0.1. Always set explicit width and height on images. Use next/font to load fonts without layout shift. It inlines font files at build time, so there's no flash of unstyled text.

Interaction to Next Paint (INP) should be under 200ms. Keep client-side JavaScript lean. Every 'use client' component adds to the interaction cost. Use React Server Components for anything that doesn't need interactivity, and defer heavy client components with dynamic() imports.

Practical performance checklist:

Use next/image for every image, with descriptive alt text and appropriate sizes attributes. Prefer WebP or AVIF formats. Enable the built-in compression (Next.js does this automatically with next start). Audit your JavaScript bundle with @next/bundle-analyzer. The most common offender is shipping a massive library for a feature that could be done with a few lines of native code. Run Lighthouse in Chrome DevTools regularly, but also check real user data in Google Search Console's Core Web Vitals report. Lab scores and field data often tell different stories.

The Quick Audit Checklist

Run through this before every major deploy:

Every page has a unique <title> and meta description. Canonical URLs are set on every page. Open Graph images render correctly (test with LinkedIn's Post Inspector and X's Card Validator). The sitemap includes all public pages and is referenced in robots.txt. Structured data validates in Google's Rich Results Test. hreflang tags are present and correct on multilingual pages (including x-default). No 'use client' wrappers around content that should be server-rendered. Core Web Vitals pass in both Lighthouse and field data. Staging and preview URLs are blocked from indexing. Internal links use descriptive anchor text, not "click here."

Frequently Asked Questions

Do I still need the next-seo or next-sitemap packages?

For most projects, no. The built-in Metadata API in Next.js 15 handles titles, descriptions, Open Graph, Twitter cards, canonical URLs, and hreflang tags natively. The sitemap.ts and robots.ts file conventions replace next-sitemap entirely. Third-party packages add bundle weight and another dependency to maintain. Use them only if you have a specific edge case the built-in API doesn't cover.

Does Next.js automatically handle SEO?

It handles the hard parts, like server-rendering HTML so crawlers can read it, optimizing images, and code-splitting to keep pages fast. But you still need to configure metadata per page, create your sitemap, add structured data, and set up canonical URLs. The framework gives you the tools. The SEO strategy is still your job.

How do I optimize a Next.js site for AI search and Google AI Overviews?

Structure your content with clear question-based headings and direct, concise answers in the first 50 to 70 words of each section. Add FAQPage and HowTo structured data where relevant. Keep entity names (your brand, product names, technical terms) consistent throughout the page. Use internal links to related content to signal topical authority. AI models favor content that's well-organized, specific, and supported by verifiable details.

Should I use the App Router or Pages Router for SEO?

The App Router. It's where all new Next.js features land, including the Metadata API, file-based sitemaps and robots.txt, React Server Components, and streaming. The Pages Router still works, but its SEO setup requires more manual work (next/head, third-party sitemap packages) and doesn't benefit from newer rendering optimizations.

What's the most common Next.js SEO mistake?

Wrapping everything in 'use client' directives. When content only renders on the client, search engines see an empty shell until JavaScript executes. Googlebot can run JavaScript, but it's slower and less reliable than reading server-rendered HTML. Keep your content in Server Components, and only use 'use client' for interactive elements that genuinely need it.


Want to know where your Next.js site actually stands? We offer a free SEO and performance audit. No sales pitch, just a clear breakdown of what's working, what's not, and what to fix first. Get your free audit →

Tagged with

Next.jsSEOMetadataSitemapsStructured DataPerformanceCore Web Vitals