Come Costruire un Sito Web Next.js in 10 Lingue (Guida all'App Router 2026)

Costruire un sito web multilingue è uno degli investimenti a più alto rendimento che si possano fare in termini di SEO e conversione. Il settantasei percento degli acquirenti online preferisce acquistare prodotti con informazioni nella propria lingua madre (CSA Research, 2020), eppure meno del 5% dei siti web attivi supporta più di tre lingue. Recentemente abbiamo lanciato Frida Marketing in 10 lingue su Next.js 15 App Router — senza next-intl, senza un SaaS di traduzione e senza 10 codebase separate. Ecco esattamente come l'abbiamo costruito.

Punti chiave

• Il 76% degli acquirenti preferisce acquistare nella propria lingua madre; il 40% non acquisterà mai da siti che non la offrono (CSA Research, 2020)
• L'inglese copre solo il 49,7% dei contenuti web globali — costruire un sito multilingue sblocca l'altro 50,3% (W3Techs, giugno 2026)
• Un segmento dinamico [lang] + un calcolo del prefisso API servono 10 lingue da un singolo set di file di pagina
• Gemini 2.5 Flash traduce un post HTML completo di 3.000 parole per lingua in meno di 90 secondi a costo quasi zero

Perché costruire un sito multilingue è più economico di quanto si pensi

L'argomento del costo contro i siti multilingue è quasi sempre esagerato. Next.js 15 App Router gestisce l'intero livello di routing attraverso un singolo segmento dinamico. Il livello dei contenuti — titoli, corpo, metadati — proviene dalla tua API per lingua. E il livello di traduzione può essere completamente automatizzato.

L'inglese rappresenta il 49,7% di tutti i contenuti dei siti web per lingua. Lo spagnolo e il tedesco detengono ciascuno il 6,0%, il giapponese il 5,0% e il francese il 4,6% (W3Techs, giugno 2026). Supportare solo le prime cinque lingue non inglesi copre circa il 70% dei contenuti web globali indicizzati. Next.js è utilizzato dal 2,7% di tutti i siti web a livello globale e dal 17,9% degli sviluppatori intervistati lo utilizza (Stack Overflow Developer Survey, 2024) — il che significa che gli strumenti e il supporto della comunità per Next.js multilingue sono migliori che mai.

Il costo reale non è il codice, ma il contenuto. Una volta che il routing è a posto, aggiungere una lingua è una chiamata API per ogni post pubblicato. Abbiamo pubblicato 7 post in 10 lingue con zero costi di manutenzione per lingua. La decisione architetturale è l'investimento; il runtime è gratuito.

Il 96% delle aziende che hanno investito nella localizzazione ha riportato un ROI positivo, con il 65% che ha raggiunto almeno un ritorno 3x (DeepL Business Survey, 2024). Il caso aziendale è solido. La barriera tecnica è molto più bassa di quanto la maggior parte degli sviluppatori si aspetti.

Come strutturare il tuo segmento dinamico [lang]

Next.js App Router trasforma il tuo filesystem nel tuo router. Crea una directory src/app/[lang]/ e ogni rotta al suo interno ottiene automaticamente params.lang. Quel singolo parametro è l'intera base di un sito in 10 lingue.

`` src/app/ ├── page.tsx ← English homepage (/) ├── blog/[slug]/page.tsx ← English blog posts ├── admin/layout.tsx ← English admin └── [lang]/ ├── page.tsx ← All other language homepages (/fi, /fr, /de…) ├── blog/[slug]/page.tsx ← Language blog posts └── admin/ └── layout.tsx ← Language admin (same file, reads params.lang) ``

L'inglese si trova alla radice. Ogni altra lingua si trova sotto [lang]. Scrivi un file e lascia che params.lang guidi la logica — mai copie di pagine specifiche per lingua.

Definisci la tua configurazione linguistica in un unico file canonico:

```typescript // src/lib/languages.ts export const LANGUAGES = [ { code: 'fi', urlPrefix: 'fi', apiPrefix: 'fi_', name: 'Finnish' }, { code: 'fr', urlPrefix: 'fr', apiPrefix: 'fr_', name: 'French' }, { code: 'de', urlPrefix: 'de', apiPrefix: 'de_', name: 'German' }, { code: 'it', urlPrefix: 'it', apiPrefix: 'it_', name: 'Italian' }, { code: 'no', urlPrefix: 'no', apiPrefix: 'no_', name: 'Norwegian' }, { code: 'ch', urlPrefix: 'ch', apiPrefix: 'pt_', name: 'Swiss German' }, // ⚠️ API uses pt_ { code: 'sr', urlPrefix: 'sr', apiPrefix: 'sr_', name: 'Serbian' }, { code: 'es', urlPrefix: 'es', apiPrefix: 'es_', name: 'Spanish' }, { code: 'sw', urlPrefix: 'sv', apiPrefix: 'sw_', name: 'Swedish' }, // ⚠️ URL uses sv ];

export const LANG_CODES = LANGUAGES.map(l => l.code); ```

Due stranezze da documentare immediatamente: ch (tedesco svizzero) usa pt_ come prefisso API per ragioni storiche di denominazione, e sw (svedese) usa sv come prefisso URL per corrispondere allo standard ISO. Queste discrepanze non causeranno bug se centralizzi la configurazione, ma confonderanno ogni sviluppatore che si unisce al progetto senza questa documentazione.

Collegamento delle rotte linguistiche alla tua API di backend

L'intera integrazione API multilingue è un unico calcolo:

``typescript const prefix = params.lang ? ${params.lang}_ : ''; const posts = await fetch(${API_URL}/api/${prefix}posts); ``

Quando params.lang è 'fi', questo recupera /api/fi_posts. Quando è undefined (radice inglese), recupera /api/posts. Ogni pagina, ogni chiamata di dati, ogni operazione di amministrazione utilizza lo stesso schema. Non esiste un helper di fetch per lingua, nessuna istruzione switch, nessun caso speciale.

Eseguiamo questo schema su 10 lingue e 5 tipi di contenuto — post, prodotti, pagine, autori e categorie — in produzione. L'unico caso limite che abbiamo riscontrato: alcuni endpoint API hanno strutture diverse per l'inglese rispetto alle versioni specifiche per lingua. Nella nostra configurazione, /api/{lang}_posts/by-url/{slug} esiste per ogni lingua, ma l'equivalente inglese è un controller completamente diverso (/api/resolve-route?url=...). Controlla sempre le tue rotte API inglesi separatamente — spesso sono strutturate in modo diverso da quelle specifiche per lingua, specialmente sui backend Laravel dove le rotte inglesi sono state costruite per prime.

Il pannello di amministrazione utilizza lo stesso schema di prefisso:

``typescript // src/app/[lang]/admin/posts/page.tsx export default function AdminPostsPage({ params }: { params: { lang?: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; // Fetch from /api/${prefix}posts // Build edit/delete links with /${params.lang}/admin/edit-post/${id} } ``

Un singolo componente AdminPostsPage serve tutti i 10 pannelli di amministrazione linguistici. L'amministrazione inglese si trova su /admin/posts; quella finlandese su /fi/admin/posts. Stesso file.

Generazione di pagine statiche per tutte le 10 lingue

La generazione statica è il punto in cui i siti Next.js multilingue ottengono il loro vantaggio in termini di prestazioni. Usa generateStaticParams per pre-renderizzare ogni variante linguistica al momento della build:

```typescript // src/app/[lang]/page.tsx — static language homepages export async function generateStaticParams() { return LANG_CODES.map(lang => ({ lang })); // Returns: [{lang:'fi'},{lang:'fr'},{lang:'de'},...] }

// src/app/[lang]/blog/[slug]/page.tsx — static blog posts per language export async function generateStaticParams({ params }: { params: { lang: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; const res = await fetch(${API_URL}/api/${prefix}posts); const data = await res.json(); return data.data.map((post: { url: string }) => ({ slug: post.url })); } ```

Le pagine statiche appaiono come ● nell'output di next build. Vengono pre-renderizzate in HTML al momento del deployment, vengono inviate alla CDN edge di Vercel e si caricano in millisecondi a livello globale. Per un sito in 10 lingue, questa è la differenza tra un TTFB di 50ms e un hit all'origine di 800ms su ogni richiesta.

Una regola da memorizzare: non combinare mai generateStaticParams con fetch { cache: 'no-store' } nella stessa pagina. Nelle build di produzione di Next.js 15, questo genera Error: Page changed from static to dynamic at runtime — un bug che si manifesta solo in produzione, non in sviluppo. Usa invece ISR:

``typescript const res = await fetch(${API_URL}/api/${prefix}posts, { next: { revalidate: 3600 }, // Regenerate stale pages every hour }); export const dynamicParams = true; // Allow new slugs without a full rebuild ``

next-intl registra 2,3 milioni di download settimanali da npm a giugno 2026, rendendola la libreria dominante nel settore. È la scelta giusta se hai bisogno di formattazione sensibile alla locale o di gestione di stringhe UI hardcoded. Per i siti CMS basati sui dati, è opzionale — il routing puro di App Router gestisce tutto ciò di cui hai effettivamente bisogno.

SEO per un sito in 10 lingue: Hreflang e generateMetadata

Hreflang indica a Google quale versione linguistica servire a quale pubblico. Senza di esso, le tue 10 pagine linguistiche competono tra loro per le stesse query. L'implementazione di App Router è pulita:

```typescript // src/lib/hreflang.ts const HREFLANG_CODE: Record = { fi: 'fi', fr: 'fr', de: 'de', it: 'it', no: 'no', ch: 'de-CH', // Swiss German internal code → BCP 47 de-CH sr: 'sr', es: 'es', sw: 'sv', // Internal code sw → ISO sv (Swedish) };

export function getAlternates(routeKey: string, lang?: string) { const BASE = 'https://fridamarketing.com'; const enUrl = ${BASE}/${routeKey};

const languages: Record = { 'x-default': enUrl, en: enUrl, };

for (const [code, hreflang] of Object.entries(HREFLANG_CODE)) { const urlPrefix = code === 'sw' ? 'sv' : code; languages[hreflang] = ${BASE}/${urlPrefix}/${routeKey}; }

return { canonical: lang ? ${BASE}/${lang === 'sw' ? 'sv' : lang}/${routeKey} : enUrl, languages, }; } ```

Usalo in generateMetadata su ogni pagina:

``typescript export async function generateMetadata({ params }: Props): Promise { const post = await fetchPost(params.lang, params.slug); return { title: post.meta_title, description: post.meta_description, alternates: getAlternates(blog/${post.url}, params.lang), }; } ``

Questo genera un set hreflang completo per ogni pagina — x-default, en e tutte le 9 varianti linguistiche — con zero manutenzione manuale. Nessun blocco hreflang della sitemap XML da mantenere sincronizzato; Next.js li inietta come tag nell' renderizzato.

Secondo la ricerca SEO multilingue, le aziende che investono nella localizzazione registrano un aumento del traffico organico del 300-500% dai mercati internazionali (MotionPoint, 2025). Il livello hreflang è ciò che cattura quel traffico. Senza di esso, Google ignora i segnali linguistici o mostra la versione sbagliata per ogni locale.

Automazione della traduzione: Gemini API nella tua pipeline di pubblicazione

La traduzione manuale in 10 lingue è il modello sbagliato per qualsiasi team senza un budget di localizzazione dedicato. La traduzione umana costa $0,15–$0,30 per parola — un post di 2.500 parole costa $375–$750 per lingua, o $3.375–$6.750 per tutte e 9 (Seatongue, 2025). La post-editing della traduzione automatica riduce questo costo del 50–70%. Ma per contenuti HTML strutturati da un CMS, la traduzione API completamente automatizzata con un prompt preciso è ancora migliore.

Ecco la chiamata di traduzione principale che usiamo con Gemini 2.5 Flash:

``javascript async function translatePost(content, targetLang) { const prompt = Translate the following JSON to ${targetLang}. Rules: - Translate all text values: title, intro, body, meta_title, meta_description - Preserve ALL HTML tags, attributes, and structure in body exactly as-is - Generate a URL-safe localized slug and return it as "url" - Keep brand names, code examples, and proper nouns in English - Return valid JSON only: { title, intro, body, meta_title, meta_description, url }

Content: ${JSON.stringify(content)}`;

const response = await gemini.generateContent(prompt); return JSON.parse(response.text()); } ```

Abbiamo eseguito questo in produzione per 7 post pubblicati, ciascuno tradotto automaticamente in 9 lingue. La qualità è pronta per la pubblicazione per finlandese, francese, tedesco, spagnolo e italiano senza revisione manuale. Norvegese e svedese necessitano di controlli occasionali. Il serbo necessita di una rilettura — Gemini è meno affidabile con il cirillico in contesti HTML complessi. Per un sito ricco di contenuti, questo approccio riduce i costi di traduzione di oltre il 90% rispetto anche ai flussi di lavoro di post-editing della traduzione automatica.

Il tempismo è importante. Un post HTML di 3.000 parole richiede a Gemini 2.5 Flash circa 60–90 secondi per lingua. Questo significa 9–13 minuti per tutte le 9 traduzioni. Imposta sempre un timeout di annullamento di 150 secondi su ogni chiamata API e implementa il backoff esponenziale — il modello occasionalmente si blocca sotto alta domanda:

``javascript const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 150000); try { const res = await fetch(GEMINI_URL, { signal: controller.signal, ...opts }); clearTimeout(timeoutId); return res; } catch (err) { clearTimeout(timeoutId); if (err.name === 'AbortError') { // Retry with exponential backoff await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 5000)); } } ``

L'84% dei marketer afferma che la localizzazione dei contenuti ha contribuito ad aumentare i loro ricavi, e le aziende che hanno investito nella traduzione avevano 1,5 volte più probabilità di vedere un aumento dei ricavi (Redokun, 2025). L'automazione rimuove l'ultimo vero ostacolo — il costo operativo della gestione delle traduzioni su larga scala.

---

Stai costruendo un sito Next.js multilingue? Progettiamo e costruiamo siti web Next.js per un pubblico globale — routing i18n completo, SEO hreflang e pipeline di traduzione automatizzate incluse. Scopri i nostri servizi di sviluppo Next.js o contattaci per discutere il tuo progetto.

---

Domande Frequenti

Ho bisogno di next-intl per costruire un sito Next.js multilingue?

No. Next.js 15 App Router gestisce il routing multilingue nativamente tramite un segmento dinamico [lang]. Librerie come next-intl aggiungono valore per la formattazione sensibile alla locale (date, valute, pluralizzazione) e la gestione di stringhe UI hardcoded. Se i tuoi contenuti provengono da un CMS o un'API, non ne hai bisogno per il routing, la generazione statica o la SEO.

Come posso mappare i prefissi di lingua URL agli endpoint API in Next.js?

Calcola un prefisso a runtime: const prefix = params.lang ? \`${params.lang}_\` : '';. Usalo in ogni chiamata fetch — ad esempio, /api/${prefix}posts. Questo schema gestisce tutte le 10 lingue da un unico file di pagina condiviso. Nessuna pagina specifica per lingua, nessuna istruzione switch, nessun caso speciale.

Qual è il modo migliore per tradurre automaticamente un sito Next.js in più lingue?

Usa Gemini 2.5 Flash o GPT-4 nella tua pipeline di pubblicazione. Invia il contenuto inglese come JSON con un prompt di sistema per tradurre tutti i valori di testo preservando i tag HTML e generando uno slug URL localizzato e sicuro. Aggiungi un timeout di 150 secondi e un backoff esponenziale. La post-editing della traduzione automatica costa il 50–70% in meno rispetto alla traduzione umana completa (Seatongue, 2025), e l'automazione API completa riduce ulteriormente questo costo.

Come posso aggiungere i tag hreflang a un sito Next.js 15 App Router?

Crea una funzione getAlternates(routeKey, lang) che restituisce un oggetto alternates di Next.js. Mappa i codici URL interni ai codici lingua BCP 47 — sw → sv per lo svedese, ch → de-CH per il tedesco svizzero — e includi x-default che punta al canonico inglese. Restituiscilo da alternates.languages all'interno dell'export generateMetadata di ogni pagina.

Quante lingue dovrebbe supportare il mio sito web?

Inizia con 2-3 che corrispondono alle tue principali fonti di traffico, quindi espandi. L'inglese copre solo il 49,7% dei contenuti web globali (W3Techs, giugno 2026), quindi qualsiasi seconda lingua apre un nuovo pubblico raggiungibile con un costo marginale quasi nullo una volta che il tuo routing e la pipeline di traduzione sono a posto. Le aziende che investono nella localizzazione riportano un ROI positivo del 96%, con il 65% che raggiunge almeno un ritorno 3x (DeepL, 2024).

Conclusione

Un sito Next.js in 10 lingue non è 10 volte il lavoro. È un segmento dinamico [lang], un calcolo del prefisso API, un helper hreflang e uno script di traduzione — moltiplicati nella tua pipeline di pubblicazione. Abbiamo costruito questo per Frida Marketing e funziona in produzione su 10 lingue senza costi di manutenzione per lingua e senza abbonamento a un SaaS di localizzazione.

Il routing è un lavoro di una mattina. L'hreflang è un lavoro di un pomeriggio. La pipeline di traduzione è un progetto del fine settimana. E il guadagno — raggiungere il 50,3% del web che non è inglese — è permanente.

Inizia oggi con il segmento [lang]. Aggiungi hreflang questa settimana. Collega l'API di traduzione Gemini questo mese.