Next.js i18n SEO

Next.js i18n SEO: routing, metadata, hreflang, and sitemaps

A framework guide for building multilingual Next.js pages that are server-rendered, indexable, internally linked, and clear to search engines.

/ The short answer

Next.js i18n SEO is not only about translating strings. It is the combined system of locale routing, server-rendered content, translated metadata, canonical URLs, hreflang relationships, internal links, and sitemap discovery.

/ 01

Routing

Choose a route model that search engines can crawl

A locale should be part of the URL or domain structure, not only a cookie or browser preference. App Router layouts let you share page structure while resolving content for [locale].

  • Use /fr/page, fr.example.com/page, or a documented country-domain model.
  • Avoid serving multiple languages from one URL based only on detection.
  • Keep route and locale validation in one boundary.
A locale-aware App Router
app/
  [locale]/
    products/
      [slug]/
        page.js
        opengraph-image.js
    layout.js
    sitemap.js

// /fr/products/widget
// /de/products/widget
/ 02

Rendering

Resolve language content before the response

Static interface copy, database content, API responses, and metadata should agree on the active locale. Server Components and server-side helpers make that relationship explicit and keep credentials away from the browser.

  • Use stable translation keys for runtime values.
  • Forward the locale from Next.js to separate APIs.
  • Return source-language content when a translation is not ready.
Resolve dynamic content on the server
const copy = await altified.resolve(locale, [
  { key: `product.${product.id}.name`, defaultValue: product.name },
  { key: `product.${product.id}.description`, defaultValue: product.description },
]);
/ 03

Metadata

Keep titles, descriptions, canonicals, and alternates aligned

A French page should have French page metadata and a French canonical URL. Generate its language alternatives from the same route data used to render the page so a renamed or unpublished route does not create stale links.

  • Translate title and description fields.
  • Add a self-canonical URL for every locale page.
  • Add reciprocal alternates for the complete published language set.
Locale-aware page metadata
export async function generateMetadata({ params }) {
  const { locale, slug } = await params;
  const product = await getProduct(slug);
  const path = `/products/${product.slug}`;

  return {
    title: product.seoTitle[locale],
    description: product.seoDescription[locale],
    alternates: {
      canonical: `https://example.com/${locale}${path}`,
      languages: {
        en: `https://example.com/en${path}`,
        fr: `https://example.com/fr${path}`,
        de: `https://example.com/de${path}`,
      },
    },
  };
}
/ 04

Discovery

Link and submit the full language set

Internal links, the site sitemap, and a supplemental translated sitemap should all point to real published routes. Do not use a translation sitemap to hide missing application routes or broken metadata.

  • Link language versions from navigation or a language switcher.
  • Include dynamic pages in the site-owned sitemap.
  • Submit the relevant sitemap URLs in Search Console.

/ Production checklist

Verify the language experience before launch.

  • Locale routing is deterministic.
  • Pages render the selected language on the server.
  • Metadata is translated and route-aware.
  • Canonicals and hreflang agree.
  • Dynamic routes are included in the sitemap.
  • Language pages link to each other and to the source-language page.

/ Frequently asked questions

Questions teams ask before implementing multilingual SEO.

What is the most important Next.js i18n SEO decision?

Choose a crawlable URL model first. Once each language has a stable URL, you can align rendering, metadata, hreflang, internal links, and sitemaps around it.

Can the App Router share one page across languages?

Yes. A locale segment and shared layouts can reuse the page structure while resolving language-specific content, metadata, and route data.

Does a client-side language switcher provide SEO by itself?

No. The switcher helps users navigate, but search engines still need direct language URLs that return the correct server-rendered content and metadata.