Progettare piattaforme web multilingue: routing, contenuti e SEO

Il multilingue è una decisione di architettura, non un'attività di traduzione

La maggior parte dei team tratta il supporto multilingue come un'attività di contenuto da pianificare dopo il lancio. In pratica, le decisioni che determinano il successo o il fallimento di una piattaforma multilingue — struttura degli URL, modellazione dei contenuti, comportamento di fallback — risiedono in profondità nell'architettura, e correggerle a posteriori è tra le migrazioni più costose che una piattaforma web possa affrontare. Progettiamo regolarmente piattaforme trilingue e più ampie, e lo schema è costante: i team che fissano la strategia delle locale nella prima settimana aprono nuovi mercati in pochi giorni, mentre quelli che la aggiungono in seguito passano un trimestre a districare regressioni di routing, caching e SEO.

Scegliere una strategia di URL e mantenerla

Motori di ricerca e CDN chiedono la stessa cosa: un URL stabile e scansionabile per ogni locale. Tre strategie dominano, e mescolarle è peggio di qualsiasi scelta singola.

• Prefissi di percorso (/de/leistungen): un dominio, un certificato, un deployment. hreflang, analytics e caching restano semplici — è il nostro standard.
• Sottodomini (de.example.com): giustificati quando i mercati sono gestiti da team o infrastrutture separati, al costo di DNS aggiuntivi, certificati e analytics frammentate.
• Domini nazionali (example.de): il segnale geografico più forte e il costo operativo più alto — ragionevoli solo quando un mercato è una business unit a sé stante.

Qualunque sia la Sua scelta, non vari mai i contenuti in base all'header Accept-Language o a un cookie sullo stesso URL — cache e crawler penalizzano entrambe le pratiche. Il rilevamento della lingua spetta a un unico redirect dalla radice del dominio, e la scelta esplicita dell'utente deve sempre prevalere sull'ipotesi.

Flussi di traduzione che reggono il ritmo delle release

Le stringhe hardcoded sono il modo in cui le piattaforme multilingue si degradano. Ogni testo visibile all'utente vive in un catalogo a chiavi per locale, e l'insieme delle chiavi è un contratto applicato in CI: una build con chiavi mancanti od orfane fallisce, esattamente come un errore di tipi. Questo unico gate elimina il bug di produzione più comune dei sistemi multilingue — un fallback inglese silenzioso nel mezzo di una pagina tedesca.

Il secondo errore è trattare la traduzione come una conversione parola per parola. Le versioni linguistiche di qualità sono adattamenti: un testo legale in tedesco segue convenzioni di tono e lunghezza delle frasi diverse dalla fonte inglese. Dia ai traduttori il contesto — screenshot, limiti di caratteri, testi adiacenti — invece di righe isolate di un foglio di calcolo, e faccia revisionare ogni locale a un madrelingua prima del rilascio.

hreflang non perdona: va generato

hreflang ha una regola su cui i team continuano a inciampare: le annotazioni devono essere reciproche. Se la pagina inglese dichiara un'alternativa tedesca, la pagina tedesca deve dichiarare a sua volta quella inglese — altrimenti i motori di ricerca scartano l'intero cluster e scelgono da soli i vincitori.

• Generi le alternate per ogni locale più x-default dall'unica fonte di verità del layer di routing; un hreflang mantenuto a mano finisce sempre per divergere.
• Localizzi gli slug (/de/leistungen, non /de/services) e mantenga una mappa degli slug per entità, così gli URL alternativi restano risolvibili.
• Punti il canonical di ogni locale a sé stesso ed elenchi le alternate nella sitemap, così i crawler scoprono l'intero cluster in un solo passaggio.

Performance: una locale non deve costare un round trip

La locale nell'URL si ripaga sulla CDN: la chiave di cache è l'URL stesso, quindi ogni pagina localizzata può essere renderizzata staticamente o messa in cache all'edge senza acrobazie con l'header Vary. Suddivida i cataloghi dei messaggi per route, così un visitatore non scarica mai tre lingue per leggerne una, e crei subset dei font per sistema di scrittura — i segni diacritici albanesi e le dieresi tedesche non devono imporre a ogni visitatore un font latino esteso completo. Soprattutto, eviti il rilevamento della lingua lato client che renderizza una lingua e poi ne ridisegna un'altra: è al tempo stesso un layout shift e un problema di fiducia.

Modellare il database translation-first

La decisione sullo schema pesa più di tutto. Non allarghi mai le tabelle con colonne title_en e title_de — modelli ogni entità traducibile come una riga base che contiene identità, relazioni, media e stato di pubblicazione, più una tabella di traduzioni con chiave su entità e locale, che porta nome, slug, contenuto e campi SEO.

• Aggiungere una locale diventa un'operazione sui dati, non una migrazione dello schema.
• Un vincolo di unicità su (locale, slug) dà a ogni lingua URL puliti e senza collisioni.
• La politica di fallback diventa esplicita e interrogabile per tipo di contenuto: mostrare la lingua predefinita, oppure nascondere la voce finché la traduzione non è pronta.

Fatto bene, il multilingue è invisibile: ogni mercato riceve una piattaforma che sembra nativa, si posiziona localmente e offre prestazioni identiche. È questo lo standard per cui vale la pena lavorare — tre lingue che si comportano come un'unica piattaforma.