SEO per un sito multilingua: URL, hreflang e contenuti localizzati
Per una SEO efficace su un sito multilingua servono URL separati per ogni lingua, hreflang reciproco e contenuti localizzati, non semplicemente tradotti. Evita i redirect automatici basati su IP o cookie e verifica che ogni versione sia indicizzabile, ricorrendo a rendering lato server o prerendering quando i testi arrivano via JavaScript. Il resto dell’articolo mostra come applicare ciascun elemento.
In breve:
- Per piccole imprese e negozi online, le sottodirectory concentrano autorevolezza e manutenzione; i domini nazionali o i sottodomini si giustificano con mercati distinti.
- Ogni pagina elenca tutte le varianti, compresa la propria; aggiungi x-default alla selezione linguistica e mantieni l’indirizzo canonico sulla stessa pagina.
- In Search Console, confronta l’HTML iniziale con quello renderizzato: le traduzioni inserite dopo chiamate API possono sfuggire alla scansione e non entrare nell’indice.
- Individua le query nel paese di destinazione e assegna ciascuna a una sola pagina; per le pagine commerciali, scegli una traduzione professionale.
- Proponi un cambio di lingua con un avviso e ricorda la scelta tramite cookie, senza reindirizzare automaticamente né modificare l’indirizzo.
Indice
- Multilingua o multiregionale: quale strategia scegliere
- Architettura URL: ccTLD, sottodomini o sottodirectory
- Implementare hreflang e usare x-default
- Canonical e duplicati: combinarli con hreflang
- Indicizzazione dei contenuti tradotti con JavaScript
- Traduzione, localizzazione e keyword research per altre lingue
- Selettore lingua, UX e redirect automatici
- Checklist tecnica per lancio o audit
- Il nostro metodo per i progetti multilingua
- Demo in 12 ore e siti pensati per crescere in più lingue
- Domande frequenti
- Fonti
Multilingua o multiregionale: quale strategia scegliere
Prima di toccare un URL devi decidere chi vuoi raggiungere. Un sito multilingua offre gli stessi contenuti in più lingue, senza legarsi a un paese preciso: un pubblico di lingua spagnola, per esempio, sia in Spagna sia in America Latina. Un sito multiregionale si rivolge invece a utenti di paesi diversi, anche quando la lingua è la stessa: prezzi in valute differenti, spedizioni e normative locali cambiano da mercato a mercato.
La scelta pesa su tutto il resto. Un progetto per paese spinge verso domini nazionali o sezioni dedicate, con hreflang che combina lingua e regione. Un progetto per lingua si accontenta di codici lingua generici e di una sola versione per idioma.
- Scegli il modello multilingua se il tuo limite è la lingua e l’offerta è identica ovunque, come un servizio digitale o un blog.
- Scegli il modello multiregionale se cambiano prezzi, valuta, disponibilità o obblighi legali tra un paese e l’altro.
- Combina i due modelli solo quando hai risorse per mantenere contenuti distinti: spagnolo per la Spagna e spagnolo per il Messico sono due pagine da curare, non una copia.
Il consiglio pratico: parti da una sola lingua aggiuntiva per il mercato che porta più richieste e allarga solo dopo aver misurato i risultati.
Architettura URL: ccTLD, sottodomini o sottodirectory
Secondo Google Search Central, ogni versione linguistica deve vivere su un URL univoco e raggiungibile, senza cookie o parametri di sessione a decidere quale testo mostrare. La struttura può poggiare su tre soluzioni, ognuna con vantaggi di gestione tecnica e di targeting geografico.
- ccTLD (.it, .de, .fr): il segnale geografico è il più netto e il dominio comunica fiducia locale. Il costo sta nel gestire più domini, più certificati e un’autorevolezza che riparte da zero su ciascuno.
- Sottodomini (it.sito.com): si configurano con facilità, anche su server separati, ma i motori possono trattarli come entità distinte e il profilo di link si frammenta.
- Sottodirectory (sito.com/it/): tutta l’autorevolezza resta su un solo dominio e la manutenzione è semplice. Il targeting per paese è meno marcato, ma si compensa con hreflang e contenuti locali.
Per una piccola impresa o un negozio online in avvio, le sottodirectory sono quasi sempre la scelta più sensata: un dominio, un hosting, un solo sito da far crescere. Realtà enterprise con team locali, magazzini e normative diverse per paese possono giustificare ccTLD o sottodomini separati, accettando il carico gestionale che comportano.
Implementare hreflang e usare x-default
L’attributo hreflang dice a Google quali varianti linguistiche e regionali esistono per una pagina, così che ogni utente veda la versione giusta nei risultati. Senza, il motore può scambiare le versioni per contenuti duplicati o mostrare quella sbagliata.
Come spiega la guida per webmaster di Google, puoi dichiararlo in tre modi: tag HTML <link> nell’head, intestazione HTTP o sitemap XML. I tag HTML vanno bene per siti piccoli o medi, l’intestazione HTTP serve per file non HTML come i PDF, la sitemap è la via più gestibile su cataloghi grandi. Non mescolare i metodi sulla stessa pagina.
- Elenca tutte le varianti della pagina, con codice lingua e, se serve, regione (it-IT, de-CH).
- Inserisci la lista completa su ogni variante, compresa la pagina stessa: è la regola di reciprocità.
- Controlla che gli URL coincidano con quelli canonici e siano raggiungibili.
- Aggiungi x-default puntando alla pagina di selezione lingua o alla versione di riserva per chi non rientra in nessuna lingua dichiarata.
- Verifica i codici: una lingua scritta male o un URL che reindirizza invalida la riga.
Un consiglio: se una variante non rimanda a tutte le altre, Google ignora l’intera coppia: dopo ogni nuova lingua, riesamina anche le pagine già pubblicate.
Canonical e duplicati: combinarli con hreflang
Rel=canonical e hreflang rispondono a domande diverse. Il canonical indica quale URL rappresenta una pagina tra più copie identiche, hreflang collega versioni equivalenti in lingue diverse. Se li mescoli male, annulli l’uno con l’altro.
- Ogni versione linguistica ha il canonical su sé stessa. Una pagina tedesca con canonical verso quella italiana dice a Google di ignorare la tedesca, e hreflang diventa inutile.
- Usa il canonical tra copie vere, per esempio la stessa pagina raggiungibile con parametri di ordinamento o tracciamento nella stessa lingua.
- Non nascondere varianti utili: due pagine in inglese per Regno Unito e Stati Uniti con prezzi diversi non vanno unificate.
- Nei cataloghi prodotto, ogni scheda tradotta punta a sé stessa come canonical e dichiara le sorelle via hreflang; le varianti di colore o taglia che non cambiano il contenuto possono convergere sulla scheda principale della stessa lingua.
Se riorganizzi gli URL, mantieni i vecchi indirizzi con un redirect ben configurato, così il valore accumulato non va perso.
Indicizzazione dei contenuti tradotti con JavaScript
Google lavora in due fasi: prima scansiona l’HTML grezzo, poi esegue il rendering del JavaScript. Come descrive la guida su come risolvere i problemi di ricerca legati a JavaScript, se le traduzioni compaiono solo dopo che l’indicizzazione è terminata, quel contenuto può non essere indicizzato. Un sito che cambia lingua con uno script lato browser rischia quindi di mostrare a Google una sola versione.
- Rischio principale: testi tradotti caricati in ritardo da chiamate API, invisibili nell’HTML iniziale.
- Soluzione robusta: rendering lato server (SSR), così l’HTML contiene già il testo nella lingua giusta.
- Alternativa: prerendering delle pagine, utile quando riscrivere l’applicazione costa troppo.
- Una lingua, un URL: il cambio lingua non deve avvenire solo con uno stato interno dell’app, senza che l’indirizzo cambi.
Per controllare cosa vede davvero il motore, usa lo strumento di ispezione URL in Search Console e confronta l’HTML renderizzato con quello grezzo; la documentazione ufficiale elenca anche i test per il debug.
Un consiglio: se il testo tradotto non compare nel codice sorgente della pagina, non contare su Google per recuperarlo: sposta la traduzione sul server.
Traduzione, localizzazione e keyword research per altre lingue
Tradurre significa riportare le parole in un’altra lingua. Localizzare significa adattare il messaggio al mercato: formati di data, valute, modi di contattare l’azienda, esempi e aspettative culturali. Il blog di Google Search Central osserva che le traduzioni automatiche non revisionate possono essere giudicate di scarsa qualità e non aiutano il posizionamento.
Anche le parole chiave non si traducono: un termine molto cercato in italiano può avere in tedesco un equivalente poco usato, e il pubblico potrebbe usare una formula diversa. Un processo ordinato aiuta:
- Definisci il mercato e l’intento di ricerca: informativo, di confronto o di acquisto.
- Raccogli le query nella lingua di destinazione con strumenti di keyword research impostati sul paese giusto, partendo da ciò che cercano le persone e non dalla traduzione dei tuoi titoli.
- Analizza chi si posiziona per quelle query e che tipo di pagina compare.
- Mappa ogni parola chiave su una pagina, evitando di far competere due versioni tra loro.
- Scegli il livello di lavoro: traduzione professionale per le pagine che vendono, revisione umana di una bozza automatica per i contenuti di supporto, localizzazione completa per home e schede prodotto principali.
Un caso concreto: un servizio di check-in multilingue per strutture ricettive deve parlare all’ospite nella sua lingua in ogni passaggio, dai moduli alle comunicazioni, non solo nelle pagine di presentazione.
Selettore lingua, UX e redirect automatici
Il selettore deve essere visibile in ogni pagina, in genere nell’intestazione, con i nomi delle lingue scritti nella lingua stessa (Deutsch, Español) e non solo con le bandiere, che indicano paesi e non idiomi. Meglio che il selettore porti alla pagina equivalente nell’altra lingua e non alla home.
La guida di Google sconsiglia i redirect automatici basati sulla lingua del browser: ostacolano la scoperta delle versioni linguistiche da parte dei motori e peggiorano l’esperienza di chi viaggia o usa un dispositivo impostato in altra lingua. Il crawler, tra l’altro, parte spesso da indirizzi statunitensi e vedrebbe una sola versione.
- Offri un banner suggerito, non un redirect forzato: «Vuoi vedere il sito in italiano?».
- Ricorda la scelta dell’utente con un cookie, senza che questo decida l’URL mostrato.
- Collega ogni versione alle altre con link interni e hreflang, così il percorso resta sempre percorribile.
- Usa x-default per la pagina di selezione quando non puoi dedurre il mercato.
Checklist tecnica per lancio o audit
Procedi in quest’ordine: prima ciò che impedisce l’indicizzazione, poi ciò che ne migliora la qualità. Le raccomandazioni SEO di AGID richiamano gli stessi pilastri: robots.txt, sitemap, architettura informativa, velocità, gestione dei duplicati e link interni.
- URL: una versione per lingua, indirizzi stabili, codifica UTF-8.
- robots.txt e sitemap: nessuna lingua bloccata, sitemap con tutte le varianti.
- hreflang e canonical: reciproci, coerenti, senza conflitti.
- Rendering: testo tradotto presente nell’HTML.
- Velocità e dati strutturati: tempi accettabili su mobile, markup nella lingua della pagina.
- Search Console: controlla copertura, ispezione URL e rendimento filtrato per paese e lingua.
| Priorità | Intervento | Quando |
|---|---|---|
| Critico | URL separati, robots.txt, hreflang reciproco, testo nell’HTML | Prima del lancio |
| Importante | Canonical coerenti, sitemap, velocità, link interni | Entro le prime settimane |
| Opzionale | Dati strutturati localizzati, link building per lingua | Dopo i primi dati |
Dopo la pubblicazione, le azioni sull’indicizzazione di un sito nuovo valgono per ogni lingua aggiunta.
Il nostro metodo per i progetti multilingua
Nel nostro lavoro partiamo da una demo realistica, perché vedere il sito aiuta a decidere meglio che discutere preventivi. Poi controlliamo l’impianto tecnico (URL, hreflang, rendering, velocità) e pubblichiamo una lingua alla volta, misurando prima di estendere.
Dopo il lancio guardiamo la copertura nell’indice, il traffico per lingua e i tempi di caricamento, perché un’ottima traduzione non serve se la pagina non viene scoperta o impiega troppo ad aprirsi. Chi ha risorse limitate dovrebbe resistere alla tentazione di tradurre tutto: meglio una versione minima ma curata, con home, pagine di servizio principali e contatti, e solo dopo ampliare il catalogo. Una lingua fatta bene rende più di tante fatte a metà.
— Alessandro
Demo in 12 ore e siti pensati per crescere in più lingue
Se preferisci affidare a noi l’impianto tecnico, ti mostriamo come sarà il tuo sito, senza costi iniziali e senza preventivi infiniti. Realizziamo siti vetrina ed e-commerce con design personalizzato, ottimizzazione SEO, velocità curata, area amministrativa per gestire ordini, contenuti e pagamenti, e supporto dopo il lancio. È una strada per piccole imprese e negozi online che vogliono partire in fretta e strutturare bene le lingue. Scopri le soluzioni e i canoni di mantenimento nella pagina prodotti e chiedi la tua demo.
Domande frequenti
Che cos’è la SEO di un sito?
È l’insieme di interventi tecnici, di contenuto e di autorevolezza che aiutano un sito a comparire nei risultati di ricerca organici. Per un sito multilingua include anche URL per lingua, hreflang e contenuti localizzati.
Come si chiama un sito web tradotto in più lingue?
Si parla di sito multilingua, mentre un sito pensato per paesi diversi si definisce multiregionale. Le due cose possono coesistere, ma richiedono scelte di URL e hreflang differenti.
Quanto guadagna un SEO al mese?
Dipende da esperienza, ruolo e tipo di rapporto, e non esiste un valore unico. Per cifre attendibili conviene consultare le rilevazioni sulle retribuzioni di fonti specializzate.
La SEO è a pagamento?
Il traffico organico non si paga per click, ma richiede tempo e lavoro, interno o affidato a professionisti. È diverso dalla pubblicità a pagamento, che smette di produrre risultati quando smetti di investire.
Servono davvero URL separati per ogni lingua?
Sì: Google raccomanda che ogni versione linguistica abbia un URL univoco e raggiungibile. Mostrare lingue diverse dallo stesso indirizzo in base a cookie o preferenze del browser impedisce ai motori di scoprirle tutte.