SEO multilingue: hreflang, struttura degli URL e terminologia tecnica
Come impostare le versioni linguistiche del sito di un costruttore che pubblica cataloghi, pagine prodotto e documentazione ricambi in più mercati: annotazioni hreflang, architettura degli URL, metadati localizzati e governance della terminologia.
Il problema non è il sito, è il catalogo
La SEO multilingue viene quasi sempre presentata come una questione di siti vetrina. Per un costruttore italiano che esporta, il problema ha una forma diversa e molto più concreta: esistono un catalogo prodotti con centinaia di codici, una serie di pagine di gamma, le schede tecniche, i manuali scaricabili e la documentazione ricambi. Tutto questo deve esistere in cinque, otto o dodici lingue, deve restare allineato quando cambia una specifica e deve essere trovato da un ufficio acquisti tedesco che cerca un componente con il nome che gli è familiare.
Le difficoltà che ne derivano non sono quelle di un blog tradotto. Sono tre, e sono strutturali.
La prima è la scala: un catalogo genera migliaia di URL per lingua, e ogni errore di impostazione si moltiplica per il numero di mercati. La seconda è la terminologia: lo stesso gruppo meccanico può avere tre denominazioni nella stessa lingua, e la scelta determina se la pagina viene trovata o no. La terza è la manutenzione: una revisione di prodotto tocca il manuale, la scheda, la pagina web e il catalogo ricambi, in tutte le lingue, e se i quattro documenti divergono la credibilità tecnica ne risente prima ancora del posizionamento.
La conseguenza pratica è che l'impostazione tecnica — hreflang, URL, metadati — è una condizione necessaria ma non è la parte difficile. La parte difficile è la coerenza dei contenuti nel tempo.
Struttura degli URL: sottocartelle, sottodomini o domini nazionali
La prima decisione è dove far vivere le versioni linguistiche. Le tre configurazioni possibili hanno costi e conseguenze diverse.
Sottocartelle sullo stesso dominio — esempio.it/de/, esempio.it/en/. È la configurazione più comune e la più semplice da gestire: un solo dominio, un solo certificato, un solo insieme di risorse tecniche, e l'autorità acquisita dal dominio è condivisa da tutte le lingue. Per la maggioranza dei costruttori è la scelta corretta.
Sottodomini — de.esempio.it. Utili quando le versioni linguistiche sono gestite da infrastrutture o da filiali diverse, con sistemi di pubblicazione separati. Il costo è la frammentazione: ogni sottodominio va seguito come una proprietà a sé.
Domini nazionali di primo livello — esempio.de, esempio.fr. Sono il segnale di localizzazione geografica più forte e il più costoso da mantenere: registrazione, gestione, contenuti e collegamenti in entrata vanno costruiti da zero per ciascun dominio. Hanno senso quando esiste una struttura commerciale locale reale — una filiale, un magazzino ricambi — non quando esiste solo una versione tradotta del sito italiano.
Due precisazioni utili. La prima: lingua e Paese non coincidono. Un sito in tedesco serve Germania, Austria e Svizzera; un sito in spagnolo serve la Spagna e l'America Latina, con differenze terminologiche reali nella meccanica. Impostare la struttura per lingua e, solo dove serve davvero, per lingua e Paese evita di moltiplicare pagine quasi identiche. La seconda: gli identificativi di percorso vanno tradotti, perché fanno parte del contenuto della pagina, ma vanno decisi una volta sola. Cambiare gli URL a distanza di due anni comporta una catena di reindirizzamenti che è sempre meglio non dover gestire.
hreflang: che cosa fa e dove si sbaglia
L'annotazione hreflang serve a dichiarare ai motori di ricerca che una determinata pagina ha versioni equivalenti in altre lingue, in modo che all'utente venga proposta quella corretta. Non unifica il posizionamento delle versioni e non è un comando: è un'indicazione che il motore può seguire o ignorare.
Può essere dichiarata in tre modi, e la scelta dipende dal tipo di contenuto:
- negli elementi
linkdell'intestazione HTML, il metodo abituale per le pagine web; - nelle intestazioni HTTP, l'unico praticabile per i file non HTML — ed è il caso dei PDF di manuali, schede e cataloghi ricambi;
- nella sitemap XML, il metodo più gestibile quando le pagine sono migliaia, perché evita di appesantire ogni pagina con decine di righe.
Il valore combina il codice di lingua secondo la ISO 639-1 e, facoltativamente, il codice di Paese secondo la ISO 3166-1 alpha-2: de per il tedesco, de-AT per il tedesco destinato all'Austria. L'errore ricorrente è usare il codice di Paese da solo, che non è una lingua.
Gli altri due errori sono più insidiosi perché non producono messaggi di errore visibili. Il primo è la mancata reciprocità: se la pagina italiana dichiara quella tedesca ma la tedesca non dichiara l'italiana, l'annotazione può essere ignorata. Ogni pagina deve elencare tutte le sue alternative, compresa se stessa. Il secondo è il disallineamento con il canonical: un hreflang che punta a una pagina il cui canonical indica un altro indirizzo produce indicazioni contraddittorie.
Su un catalogo con migliaia di pagine, l'unico modo sostenibile di gestire tutto questo è generare le annotazioni dal sistema che governa i contenuti, non scriverle a mano.
x-default, redirect automatici e il vincolo del geo-blocking
Il valore x-default indica la pagina da proporre quando nessuna delle versioni dichiarate corrisponde alla lingua dell'utente. Nella pratica di un costruttore è la pagina in inglese, oppure una pagina di scelta del mercato.
Sulla pagina di scelta del mercato conviene essere prudenti: una schermata che obbliga il visitatore a selezionare un Paese prima di vedere qualunque contenuto è un ostacolo per l'utente e un ostacolo per la scansione. La soluzione preferibile è servire subito il contenuto e offrire il selettore come elemento sempre disponibile, non come sbarramento.
Il reindirizzamento automatico in base all'indirizzo IP merita un discorso a parte, perché è la soluzione che quasi tutti propongono e quasi nessuno verifica. Sul piano tecnico è dannoso: un utente italiano in trasferta in Cina si ritrova sul sito cinese, e chi scansiona il sito da un unico Paese può non vedere mai le altre versioni.
Sul piano normativo esiste inoltre un vincolo esplicito. Il Regolamento (UE) 2018/302, che vieta i blocchi geografici ingiustificati nel mercato interno, stabilisce che il professionista non può reindirizzare il cliente verso una versione dell'interfaccia online diversa da quella cui aveva inizialmente cercato di accedere senza il suo consenso esplicito, e che la versione inizialmente richiesta deve restare accessibile. Per un costruttore che vende in tutta l'Unione, il reindirizzamento automatico e silenzioso non è soltanto una cattiva pratica tecnica: è una pratica da rivedere. Il selettore di lingua con memoria della scelta dell'utente risolve entrambe le questioni.
I metadati non si traducono, si riscrivono
Il tag title e la meta description non sono testo del documento: sono lo spazio commerciale della pagina nei risultati di ricerca. Tradurli letteralmente dall'italiano produce risultati prevedibilmente deboli, per tre ragioni.
La prima è la lunghezza. Il tedesco e il polacco sono sensibilmente più lunghi dell'italiano a parità di contenuto; un title tradotto parola per parola viene troncato. La seconda è la query reale: il termine con cui un manutentore tedesco cerca una guarnizione non è la traduzione letterale del termine italiano, e va verificato sul mercato di destinazione. La terza è la convenzione locale: le formule che funzionano in una lingua risultano goffe in un'altra.
Nella pratica questo significa fare tre cose per ciascun mercato. Verificare i termini effettivamente usati nella lingua di arrivo, invece di dedurli. Riscrivere i title attorno a quei termini, rispettando i limiti di lunghezza della lingua. Ottimizzare le meta description in funzione del clic, non della fedeltà all'originale: la meta description non incide direttamente sul posizionamento, ma determina quanti dei risultati mostrati diventano visite.
Lo stesso ragionamento vale per gli elementi che i motori usano per comprendere la pagina: intestazioni, testo alternativo delle immagini, didascalie, denominazioni dei file scaricabili. Un catalogo in cui i PDF si chiamano tutti catalogo_generale.pdf in ogni lingua è un catalogo che rinuncia a una parte del proprio potenziale. La distinzione fra tradurre e adattare è trattata in dettaglio nell'articolo su localizzazione e traduzione.
La terminologia tecnica è un fattore di posizionamento
Su un sito industriale la scelta terminologica ha un effetto diretto sulla visibilità, ed è il punto in cui la SEO multilingue smette di essere una disciplina tecnica e diventa una questione di governo della documentazione.
Il problema si presenta in tre forme. La prima è la variazione interna: se la pagina prodotto usa un termine, il manuale un altro e il catalogo ricambi un terzo, nessuno dei tre riceve tutto il peso, e il cliente che confronta i documenti percepisce disordine. La seconda è la differenza fra il termine di catalogo e il termine d'uso: la denominazione commerciale di un componente e la parola che il manutentore digita nel motore di ricerca spesso non coincidono, e una pagina ben fatta deve contenerle entrambe in modo naturale. La terza è la variazione fra mercati della stessa lingua: spagnolo europeo e spagnolo latinoamericano divergono nella meccanica; lo stesso vale, in misura minore, fra tedesco di Germania e tedesco di Svizzera.
La contromisura non è una tecnica di ottimizzazione, è uno strumento di lavoro: un glossario approvato per lingua, condiviso fra ufficio tecnico, marketing e fornitore linguistico, e una memoria di traduzione che conservi le rese già validate. È l'impianto descritto nell'articolo sui CAT tool e le memorie di traduzione, e sul sito produce due effetti immediati: le pagine parlano la stessa lingua dei documenti tecnici, e l'aggiornamento di una revisione di prodotto costa una frazione del rifacimento.
Un ultimo elemento riguarda i codici articolo e le unità di misura. I codici non si traducono e non si riformattano; le unità vanno adattate al mercato dove necessario, ma senza mai perdere il valore originale. Un valore convertito e arrotondato in una scheda tecnica è un errore che si propaga per anni.
Pagine prodotto, cataloghi ricambi e documentazione scaricabile
Su un sito industriale il contenuto che porta traffico qualificato non è quasi mai la homepage: sono le pagine di prodotto e la documentazione. Vale la pena impostarle con criteri distinti.
Le pagine di gamma e di prodotto sono quelle su cui investire la riscrittura. Devono contenere il termine con cui il prodotto viene cercato nel mercato di destinazione, i dati tecnici in forma leggibile e non solo dentro un'immagine, e le informazioni che un ufficio acquisti cerca davvero: materiali, tolleranze, alimentazioni, conformità dichiarate, disponibilità di ricambi.
Il catalogo ricambi genera un numero enorme di pagine molto simili fra loro. Pubblicare una pagina indicizzabile per ogni codice raramente conviene: produce moltissime pagine di scarso contenuto in ogni lingua. La soluzione ragionevole è indicizzare i livelli di raggruppamento — famiglia, gruppo funzionale, modello di macchina — e lasciare la ricerca per codice a uno strumento interno non indicizzato.
I documenti scaricabili sono la parte più trascurata. Manuali, schede e certificati sono spesso l'unico contenuto realmente tecnico del sito, e vengono pubblicati come PDF senza annotazioni di lingua, senza titolo utile e senza collegamento dalla pagina di prodotto corrispondente. Per questi file l'annotazione hreflang va dichiarata nelle intestazioni HTTP, i nomi dei file vanno resi espliciti e ogni documento va collegato dalla pagina cui appartiene.
Va infine ricordato che la lingua della documentazione di una macchina non è una scelta di marketing: la direttiva 2006/42/CE impone che le istruzioni accompagnino la macchina nella lingua ufficiale dello Stato membro in cui viene immessa sul mercato. Il sito è il luogo dove quella documentazione diventa consultabile e trovabile, e le due esigenze conviene affrontarle insieme.
Perché un catalogo tradotto a macchina e non revisionato danneggia due volte
La tentazione è comprensibile: un catalogo di quattromila voci in otto lingue è un volume che nessun budget assorbe facilmente, e i motori di traduzione automatica producono oggi un testo che a un lettore italiano sembra corretto. Il danno che ne deriva è però doppio.
Il primo danno è sul posizionamento. Le linee guida antispam di Google trattano come abuso di contenuti su larga scala anche la pubblicazione di testo tradotto con uno strumento automatico senza revisione umana prima della pubblicazione. Non è una questione interpretativa: è un comportamento descritto esplicitamente fra gli esempi. Pubblicare migliaia di pagine tradotte automaticamente e non revisionate espone quindi a un rischio che nessun guadagno di velocità compensa.
Il secondo danno è commerciale, ed è quello che pesa di più. Un ufficio acquisti tedesco che legge una descrizione di prodotto sintatticamente corretta ma con il termine tecnico sbagliato non pensa che il sito sia tradotto male: pensa che il fornitore non conosca il proprio prodotto. Nella documentazione industriale la lingua è una prova di competenza, ed è spesso il primo elemento su cui il potenziale cliente si forma un'opinione, prima di aver visto una macchina.
Esiste una via di mezzo praticabile e legittima, che è il post-editing con processo definito: traduzione automatica seguita da revisione umana completa, secondo la norma ISO 18587. È adatta esattamente ai contenuti ad alto volume e a bassa variabilità — voci di catalogo, distinte, descrizioni ripetitive — mentre le pagine di gamma, i testi commerciali e la documentazione di sicurezza vanno trattati diversamente. I criteri di scelta sono discussi nell'articolo su traduzione automatica e traduzione umana.
Canonical, pagine quasi identiche e contenuti fra mercati
Due chiarimenti eliminano gran parte della confusione che circola sul tema dei contenuti duplicati.
Il primo: le traduzioni non sono contenuti duplicati. Una pagina in tedesco e la sua corrispondente in italiano sono due contenuti diversi, e il rapporto fra le due si dichiara con hreflang, non con il canonical. Indicare come canonical della pagina tedesca quella italiana la esclude di fatto dai risultati: è un errore che si incontra ancora con frequenza e che azzera il lavoro fatto sulle lingue.
Il secondo: il caso realmente critico è la stessa lingua su più mercati. Una versione per la Germania e una per l'Austria, entrambe in tedesco, con testi quasi identici, sono pagine che competono fra loro. Vanno mantenute distinte solo se esiste una differenza sostanziale — listino, disponibilità, assistenza, conformità locale — e in quel caso la differenza va resa esplicita nel contenuto. Se non esiste, conviene una sola versione in tedesco.
Sul piano operativo restano poche regole applicabili: canonical autoreferenziale su ogni pagina nella propria lingua; nessun canonical fra lingue diverse; sitemap per lingua o sitemap unica con annotazioni complete; e verifica periodica che le pagine effettivamente indicizzate per ciascun mercato siano quelle attese. Su un sito costruito con un sistema di gestione dei contenuti, tutte e quattro vanno impostate a livello di modello di pagina e non pagina per pagina.
Governance: chi possiede le lingue
L'aspetto che decide la riuscita di un progetto multilingue non è tecnico. È stabilire chi decide che cosa, e questo è il punto in cui la maggior parte dei costruttori si ferma.
Le versioni linguistiche di un sito industriale hanno tipicamente tre proprietari potenziali: il marketing della casa madre, la filiale o il distributore locale, e il fornitore linguistico. Se nessuno dei tre ha l'ultima parola, il sito diverge: il distributore modifica un termine sulla propria pagina, il marketing pubblica una revisione senza avvisare, il fornitore lavora su una versione superata.
Un assetto che funziona si regge su quattro decisioni.
- Il glossario è di proprietà del committente ed è vincolante per tutti, filiali comprese. Le proposte di modifica passano dall'ufficio tecnico.
- La revisione locale è prevista ma delimitata. Il distributore può segnalare termini d'uso e riferimenti commerciali; non riscrive dati tecnici né indicazioni di sicurezza.
- Le memorie di traduzione appartengono al committente e vengono consegnate a ogni chiusura di progetto. Senza questa clausola, cambiare fornitore significa ricominciare da zero.
- Le revisioni di prodotto attivano un flusso unico che tocca insieme manuale, scheda, pagina web e catalogo, in tutte le lingue.
Quest'ultimo punto è quello che produce il ritorno maggiore, e vale anche per chi vende online: le implicazioni specifiche del commercio elettronico sono trattate nell'articolo su come tradurre un sito e-commerce, mentre l'impostazione complessiva del progetto rientra nella localizzazione di siti web.
Che cosa misurare, e in che ordine
Un progetto multilingue si valuta per mercato, non in aggregato. Il dato complessivo di sessioni nasconde esattamente ciò che interessa sapere.
Le misure utili sono poche e vanno lette nell'ordine. Copertura: quante pagine per lingua sono effettivamente indicizzate rispetto a quante ne sono state pubblicate. È il controllo che smaschera gli errori di impostazione, ed è quello che quasi nessuno fa per primo. Corrispondenza fra lingua e mercato: verificare che i visitatori di un Paese arrivino sulla versione attesa e non su un'altra. Rendimento per gruppo di pagine: gamma, prodotto, documentazione, ricambi. Le quattro famiglie si comportano in modo diverso e mediarle non aiuta. Conversioni per mercato: richieste di preventivo, download di documentazione, contatti, letti per lingua.
Vale infine una raccomandazione di metodo: non confrontare i risultati di un mercato nuovo con quelli del mercato italiano. Il sito italiano ha anni di storia, collegamenti in entrata e riconoscibilità del marchio; una versione tedesca pubblicata da sei mesi non è paragonabile e non va giudicata su quella scala.
Nella maggior parte dei casi, la sequenza di intervento più redditizia è la stessa: prima si sistemano annotazioni e struttura degli URL, poi si riscrivono i metadati e le pagine di gamma sui termini realmente usati nel mercato, poi si mette in ordine la documentazione scaricabile, e solo alla fine si estende il lavoro alle pagine di dettaglio. Chi parte dall'ultimo passaggio spende molto e vede poco. Le implicazioni sui contenuti sono trattate anche nel servizio di traduzione di siti web.
Verifiche tecniche prima di pubblicare una nuova lingua
Annotazioni hreflang reciproche
Ogni pagina dichiara tutte le alternative, se stessa compresa, con codici di lingua ISO 639-1 corretti.
Canonical autoreferenziale
Nessun canonical che punti a una lingua diversa: escluderebbe la nuova versione dai risultati.
URL definiti una volta sola
Identificativi di percorso tradotti e stabili, per non dover gestire catene di reindirizzamenti a distanza di anni.
Nessun reindirizzamento automatico
Selettore di lingua con memoria della scelta, in linea con il Regolamento (UE) 2018/302 sui blocchi geografici.
Metadati riscritti, non tradotti
Title e meta description costruiti sui termini realmente cercati nel mercato e sulla lunghezza della lingua.
Documentazione scaricabile collegata
PDF con hreflang nelle intestazioni HTTP, nomi di file espliciti e collegamento dalla pagina di prodotto.
Domande frequenti sulla SEO multilingue
Cataloghi e documentazione tecnica in più lingue, con terminologia coerente
Gestiamo le versioni linguistiche di siti industriali con glossario approvato, memorie di traduzione di proprietà del committente e revisione di un secondo linguista. Inviateci struttura del sito e lingue di destinazione: vi restituiamo perimetro, tempi e preventivo.