Next.js Internationalization Guide: Locales, Routing, and SEO

A site in twenty-five languages is not twenty-five translation jobs; it is one routing design, one dictionary contract, one set of SEO signals that must agree, and a workflow that keeps every locale complete. Get the structure right and adding a language is adding a file; get it wrong and every language is a separate site with its own bugs. This guide covers routing, dictionaries, SEO, detection, performance, and AI-assisted translation in Next.js, drawing on FISTA Solutions' web and mobile practice, which runs this site in 25 languages. The routing foundations are in nextjs app router explained and search visibility in nextjs seo guide.

Which routing strategy fits?

Strategy	Example	Fits	Watch for
Path prefix, default unprefixed	/ai-agents and /es/ai-agents	Most sites; crawlable; one domain	Middleware must rewrite cleanly
Path prefix for all	/en/ai-agents and /es/ai-agents	Sites with no dominant locale	Redirect from root
Subdomains	es.example.com	Regional teams; separate analytics	Cookie and auth scope
Separate domains	example.es	Legal or brand reasons per country	Cost; duplicated setup
Query parameter	?lang=es	Nothing indexable	Avoid

Path prefixes with an unprefixed default keep one domain, crawl cleanly, and let a locale registry drive everything.

How should dictionaries and routing be wired?

A locale registry lists each locale with its coverage status; middleware resolves the locale from the URL and rewrites to the shared route; a server-side loader deep-merges the locale's dictionary over the source locale so missing keys fall back visibly; and components receive strings through the loader rather than hard-coding. Internal links go through a localization helper so navigation never drops a visitor back into the default language. Adding a language becomes a registry row plus a dictionary file. Platform architecture is in the modern web platform architecture whitepaper.

How do hreflang, canonical, and sitemaps stay consistent?

Every indexable page emits alternates for each indexed locale including itself and a default; the canonical points to the page's own locale URL; and the sitemap lists each locale URL with matching alternates. All three are generated from the same registry so they cannot drift. Only locales at full coverage enter alternates and the sitemap; partial locales are served but not indexed. Metadata handling is in the nextjs seo guide.

How should locale be detected without breaking things?

Resolve from the URL first, then a stored preference, then the accept-language header. When the visitor appears to prefer another locale, show a suggestion banner rather than redirecting. Redirects based on IP or country break travelers, crawlers that arrive from elsewhere, and shared links, and they confuse search engines. Country detection can inform the suggestion; it must not force it. Edge middleware is the natural place for this; see edge rendering and cdns.

How is translation coverage managed?

A coverage script compares every locale's dictionary against the source and reports missing keys per locale; locales below full coverage are marked partial in the registry and excluded from indexing; and adding a page means adding its strings to every dictionary before it ships. Page-level metadata such as titles and descriptions is part of the dictionary contract so every locale has unique, correct metadata. Localization of blog content follows the same contract; see ai translation workflow.

How does AI-assisted translation fit?

AI translation with a glossary of product terms, brand names, and legal phrases produces first drafts for every locale quickly; human reviewers check terminology, tone, cultural fit, and legal content; and reviewed locales advance to full coverage. Machine-only locales are served as partial and not indexed until reviewed. The workflow scales coverage without sacrificing quality. The pipeline is in how to build an ai translation workflow.

What about performance and formatting?

Load only the requested locale's dictionary on the server; keep dictionaries out of client bundles except for the strings client components need; format dates, numbers, and currencies with locale-aware APIs; handle right-to-left layouts and text expansion in the design system; and cache per locale at the edge. Performance verification is in the nextjs performance checklist.

What mistakes are common?

Locale in query parameters; IP-based redirects; hreflang without matching canonical and sitemap; partial locales indexed; strings hard-coded in components; internal links that drop the locale; and translation done without a glossary, so product terms drift across languages.

What does sound practice look like?

A company serves its site in many languages with path-prefixed locales and an unprefixed default, a registry that drives routing, alternates, and sitemaps, dictionaries deep-merged over the source with a coverage check in CI, middleware that resolves locale and suggests rather than redirects, AI-drafted translations reviewed by humans before a locale is marked full, and locale-aware formatting from the design system. Adding a language takes a registry row and a dictionary, and search engines index each locale correctly.

How FISTA Solutions builds internationalized Next.js sites

FISTA Solutions builds Next.js platforms with registry-driven locale routing, dictionary contracts with coverage checks, consistent hreflang, canonical, and sitemap generation, suggestion-based locale detection, and AI-assisted translation workflows with human review, as it does for its own site. The web and mobile practice delivers the platforms, AI enablement supplies the translation workflow, and forward deployed engineers embed with client product teams. The record behind the approach is 150+ projects across 12+ countries.

To serve every market from one well-structured site, message FISTA on WhatsApp, or read the nextjs seo guide for the search signals each locale needs.