Next.js Internationalization for Migrated Marketing Sites

What does a nextjs i18n migration involve?

A Next.js i18n migration takes a multilingual site from a builder or WordPress and rebuilds its locales in code. You design the URL structure as routes, store translations as localized CMS fields, and generate hreflang and sitemaps yourself. Nothing is automatic, which is both the cost and the benefit.

Teams move multilingual marketing sites to Next.js when per-locale fees, CMS limits or editing workflows on builders get in the way. You pay with developer time instead of a per-locale subscription. Before choosing this route, read the multilingual website migration playbook, which covers URL strategy and translation exports that apply to every destination, and compare it with Webflow Localization, Framer Localization and Weglot.

How does locale routing work in the Next.js App Router?

In the App Router, locale routing is a dynamic segment at the top of your app folder, usually app/[locale]/, plus a small piece of request-time code that detects or enforces the locale. The Pages Router had a built-in i18n setting in next.config; the App Router doesn't, so you build routing explicitly or use a library.

• Route segment. Every page lives under app/[locale]/, so /de/pricing and /fr/pricing render the same component with a different locale.
• Static params. generateStaticParams returns each locale, and each slug per locale for CMS pages, so pages are pre-rendered.
• Locale detection. Middleware, renamed proxy in Next.js 16, can redirect the root path to a default locale or read the Accept-Language header. Keep detection to the root path, and never force-redirect search engines away from a URL they requested.
• Default locale prefix. Decide whether English lives at / or /en/. Matching what your old site did avoids redirecting your strongest pages.
• Libraries. Libraries such as next-intl handle routing, message files and formatting, which saves time on sites with UI strings in many components.

How should you structure CMS locale fields?

Use field-level localization when every locale has the same page structure with translated text, and document-level localization when locales need different sections, offers or pages. Most marketing sites are mostly field-level, with a few locale-only documents.

Payload, Contentful and Strapi support field-level localization natively, and Sanity supports both patterns through its internationalization tooling. Whichever CMS you pick, localize the slug and SEO fields as well as the body, and add a fallback rule for missing translations so a half-translated page doesn't render blanks. Our notes on setting up Payload CMS for a marketing site cover the localization config we use in production.

How do you generate hreflang in Next.js?

Generate hreflang from the same locale config and CMS slugs that build your routes. In the App Router, the alternates field returned by generateMetadata renders hreflang link tags, and sitemap entries can carry language alternates too. One source of truth means a new locale shows up in routes, tags and sitemaps together.

1. 1

   Fetch every locale's slug for the page

   When rendering a CMS page, query the slug for each locale in the same request, not just the current one.

2. 2

   Return alternates in generateMetadata

   Set a self-referencing canonical and a languages map from locale code to absolute URL, including x-default.

3. 3

   Skip missing locales

   If a page has no German version, leave German out of its alternates rather than pointing at a fallback or a 404.

4. 4

   Add alternates to the sitemap

   In sitemap generation, give each URL its language alternates so search engines see the same relationships as in the HTML.

5. 5

   Test with a crawler

   Crawl a preview deployment and check for missing return tags, relative URLs and alternates that point at redirects.

Google's documentation on localized versions of your pages is the reference for what valid annotations look like. For a deeper Next.js treatment of routing and content, see our guide to multilingual Next.js sites and i18n routing.

How do you migrate translated content and URLs into Next.js?

Export each locale from the old platform, reshape it into your CMS's locale model, and import with a script. Then build redirects in next.config or at the edge for any URL that changed. The order is content model, import, routes, redirects.

Where the content comes from changes the export work. Webflow and Framer export CMS collections but leave static page translations to be copied. WPML and Polylang store each translation as a linked post, so you need the translation group in your export, which our WPML and Polylang migration guide explains. Weglot keeps translations in its own database, covered in the Weglot to Webflow guide, and the export step is the same for a Next.js destination.

Is Next.js the right platform for a multilingual marketing site?

Next.js is the right platform when you run many locales, need market-specific logic or want to avoid per-locale fees, and you have developers available to maintain it. It's the wrong platform when a small marketing team needs to ship new pages in every language without engineering help.

If engineering time is the bottleneck, the reverse move can make sense. Our guides to Next.js to Framer and Next.js to Webflow explain when handing a multilingual site back to marketing is the better choice.