How to Translate a Next.js Site for Search Engines

Quick answer — Next.js server-renders, so translated text reaches crawlers without extra work. The real tasks are locale routing, translating metadata as its own field, and emitting reciprocal hreflang — the three things that decide whether the translated pages rank.

The hard part is already solved

Client-rendered frameworks have to solve visibility to search engines before they can solve language. Next.js does not: the HTML that arrives already contains the text.

That moves the whole problem to routing and metadata, which is a much better place for it to be.

Locale routing

A locale segment in the path gives each language its own crawlable URL, which is the requirement everything else depends on. Sub-path is the usual choice and the easiest to operate; domains are worth it only when markets are genuinely separate businesses. Whichever you choose, be consistent across the whole site. A mixture is worse than either.

Metadata is content, not decoration

Title tags, descriptions and Open Graph text are separate fields and they are where most Next.js localization stops short. A page whose body is French and whose title tag is English competes in search as an English page.

Generate metadata per locale in the same place you generate the page, so the two cannot drift apart.

hreflang has to reciprocate

Every locale version points at every other, including itself, and a self-referencing canonical on each. A one-way declaration is ignored, and a translated page canonicalising to the English original asks Google to drop it. Emit these from a single source rather than by hand per page. Hand-written hreflang is where the errors live.

Static generation and the language matrix

Pre-rendering multiplies: pages times locales. That is fine at a few hundred and becomes a build-time problem at scale, which is where incremental regeneration earns its place.

Decide which locales are pre-built and which are generated on demand. Building all of them because it is the default is how a two-minute build becomes forty.

What is still client-side

Anything rendered after hydration — a search widget, a filtered list, a cookie banner — carries strings that are not in the server HTML. They still need translating; they just do not need to be crawlable.

Content versus interface

Framework i18n handles interface strings. Content from a CMS or a database is a separate pipeline, and combining the two is a common source of a site that is half translated in a way nobody planned.

website translation covers the rendered-output side, and translation memory keeps the recurring cost proportional to what changed.

Configuration notes are on the Next.js integration page.

Middleware and locale detection

Middleware can redirect a first-time visitor to their likely language, which is useful and worth constraining: redirect once, remember the choice, and never override an explicit selection.

An aggressive detector that sends a user to a language they did not ask for on every visit is worse than no detection at all, and it confuses crawlers, which present as a fixed locale.

Images and Open Graph

Localized Open Graph images need generating per language, and a share preview still showing English is the first thing a reader sees before they click.

Where to start

Render one page in the target language and view source. If the translated text is in the HTML, search engines can read it. If it only appears after hydration, it is a client-side render and needs the server side solved first.

FAQ

Is Next.js good for multilingual SEO? Yes, because it server-renders, so translated text reaches crawlers without extra work. The remaining tasks are locale routing, per-locale metadata and reciprocal hreflang.

Should Next.js locales use sub-paths or domains? Sub-paths in most cases, because they are simpler to operate and give each language a crawlable URL. Separate domains are worth it only when the markets are genuinely separate businesses.

Why is my Next.js page ranking as English? Usually untranslated metadata. Title tags, descriptions and Open Graph text are separate fields, so a French body with an English title tag competes in search as an English page.

Does static generation cause problems with many locales? It can. Pre-rendering multiplies pages by locales, which turns a short build into a long one at scale, so decide which locales are pre-built and which are generated on demand.