Strategia
SEO internazionale: architettura hreflang funzionante
Come strutturare un sito multilingue affinché ogni mercato si posizioni nella propria lingua: architettura URL, regole hreflang ed errori comuni.
La maggior parte dei siti multilingue non fallisce per la qualità della traduzione. Fallisce a causa dell'architettura — e il fallimento è spesso invisibile dall'interno dell'azienda, perché ogni dipendente visualizza il sito correttamente nella propria lingua sul proprio browser.
Ecco la versione più comune di questo errore:
Il sito "supporta" sei lingue scambiando i testi via JavaScript su un unico URL.
Esiste una sola pagina. Esiste un solo URL. Google la indicizza una sola volta, in una sola lingua. Il contenuto in tedesco esiste solo nel browser, dopo l'esecuzione dello script. Non viene mai indicizzato, perché non esiste un URL tedesco da indicizzare. Un acquirente tedesco che cerca in tedesco non lo troverà mai.
Se il vostro selettore di lingua cambia la pagina senza cambiare l'URL, non avete un sito multilingue. Avete un sito monolingue con una funzione di traduzione lato client.
Le tre architetture valide
Google supporta esattamente tre modalità per indicare lingua e regione geografica. Sceglietene una e mantenetela con coerenza.
| Architettura | Esempio | Ideale per |
|---|---|---|
| Sottodirectory | example.com/de/ | Quasi tutti |
| Sottodominio | de.example.com | Infrastrutture separate per mercato |
| ccTLD | example.de | Brand locale forte, budget elevato |
Le sottodirectory vincono per la maggior parte delle aziende. Ereditano l'autorità già acquisita dal dominio principale, non comportano costi aggiuntivi e sono semplici da gestire a livello di hosting. Un nuovo ccTLD parte da zero autorità e deve essere costruito da capo come un sito indipendente — un investimento pluriennale, giustificato solo quando la fiducia degli utenti locali richiede strettamente un dominio nazionale.
I parametri URL (example.com/?lang=de) non sono ammessi in questa lista. Google ne sconsiglia esplicitamente l'uso per il targeting linguistico. Vengono trattati in modo incoerente, generano facilmente contenuti duplicati e rendono fragile la rete dei tag hreflang.
Localizzate anche gli slug degli URL
Se avete deciso di adottare URL dedicati per ciascuna lingua, completate l'opera:
/en/services/web-design/
/de/leistungen/webdesign/
/tr/hizmetler/web-tasarim/
/fr/services/conception-web/
Non questo:
/en/services/web-design/
/de/services/web-design/
/tr/services/web-design/
La seconda versione funziona tecnicamente, ma spreca l'URL — uno dei pochi segnali on-page che i motori di ricerca leggono prima ancora di effettuare il rendering della pagina. Un utente tedesco che esamina i risultati vede un URL in tedesco e un titolo in tedesco. Entrambi incidono sul tasso di clic (CTR).
L'obiezione riguarda quasi sempre la manutenzione. Questa obiezione è valida solo se scrivete file HTML a mano. Se i vostri URL derivano da un modello di contenuti — con un campo slug per lingua — il costo è di una sola riga per pagina per lingua.
hreflang: le quattro regole che fanno fallire i siti
L'attributo hreflang è concettualmente semplice ma estremamente severo all'atto pratico. Quattro regole spiegano quasi tutti i problemi riscontrati nel mondo reale.
1. Deve essere reciproco
Se la pagina inglese rimanda alla pagina tedesca, la pagina tedesca deve rimandare indietro a quella inglese. Se non lo fa, Google ignora completamente l'annotazione — non parzialmente, ma per intero.
Questo errore si verifica più spesso quando una pagina esiste in alcune lingue ma non in altre, e la logica di generazione dei link non è simmetrica.
2. Ogni pagina deve fare riferimento a se stessa
Il set hreflang di ciascuna pagina deve includere una voce che punta a se stessa (auto-referenziale). Una pagina che elenca le versioni alternative ma omette il proprio URL presenta un set non valido.
3. Utilizzate URL assoluti
<!-- corretto -->
<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/" />
<!-- non valido -->
<link rel="alternate" hreflang="de" href="/de/leistungen/" />
Gli URL relativi non sono supportati. Questo errore fallisce in modo del tutto silenzioso senza mostrare errori evidenti.
4. I codici di lingua devono essere validi
- Solo lingua:
de,tr,fr— si rivolge ai parlanti di quella lingua ovunque si trovino - Lingua più regione:
de-AT,en-GB,pt-BR— lingua ISO 639-1, regione ISO 3166-1 Alpha-2 - La sola regione non è valida.
hreflang="at"non significa Austria.atnon è un codice di lingua valido. - Varianti di scrittura ove strettamente necessarie:
zh-Hans,zh-Hant
Ed esiste un valore speciale: x-default, per la pagina mostrata agli utenti la cui lingua non è esplicitamente mirata. Puntatelo alla versione linguistica principale o a una pagina di selezione della lingua.
Ecco un set corretto, presente su ciascuna delle tre pagine:
<link rel="alternate" hreflang="en" href="https://example.com/en/services/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/leistungen/" />
<link rel="alternate" hreflang="tr" href="https://example.com/tr/hizmetler/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/services/" />
La trappola del canonical
Questo errore distrugge silenziosamente i siti multilingue ed è fondamentale chiarirlo con precisione.
Ogni versione linguistica deve essere il canonical di se stessa.
<!-- Su /de/leistungen/ — corretto -->
<link rel="canonical" href="https://example.com/de/leistungen/" />
<!-- Su /de/leistungen/ — distrugge il sito in tedesco -->
<link rel="canonical" href="https://example.com/en/services/" />
La seconda versione comunica a Google che la pagina tedesca è un duplicato di quella inglese e non deve essere indicizzata separatamente. Abbinata ad annotazioni hreflang che dicono l'opposto, avete inviato istruzioni contraddittorie — e il tag canonical ha sempre la precedenza.
L'istinto che porta a questo errore è comprensibile: le pagine sono traduzioni l'una dell'altra, quindi possono sembrare duplicati. Ma non lo sono. Le traduzioni sono pagine distinte che rispondono a query di ricerca distinte.
Come gestire le traduzioni parziali
Nei progetti reali non si traduce tutto contemporaneamente. Si lancia in tre lingue, se ne aggiungono altre cinque nei trimestri successivi e gli articoli del blog procedono gradualmente.
Esiste un metodo corretto per gestire questa fase intermedia.
Non riempite pagine non tradotte con contenuti in inglese sotto un URL /de/ per poi indicizzarle. Creereste contenuti scarsi e duplicati in un mercato che state cercando di conquistare, mettendoli in concorrenza diretta con la vostra pagina in inglese per le medesime query.
Invece, monitorate la completezza della traduzione pagina per pagina e:
- Servite la pagina con fallback in lingua inglese affinché non si generino errori 404 e i link interni rimangano integri
- Aggiungete
<meta name="robots" content="noindex, follow">finché la copertura rimane sotto la soglia qualitativa - Escludetela dalla sitemap XML di quella lingua
- Omettetela dal set hreflang sulle versioni nelle altre lingue
- Rimuovete automaticamente tutte e quattro le limitazioni non appena la traduzione viene completata
Questo processo è facile da automatizzare se la copertura della traduzione è una proprietà calcolata in fase di build anziché una checklist manuale. Noi gestiamo questo sito esattamente così: qualsiasi pagina con meno dell'85% di testo tradotto viene generata, collegata e resa raggiungibile, ma esplicitamente contrassegnata con noindex ed esclusa dalla sitemap fino al superamento della soglia.
Il risultato è che una lingua completata a metà non compete mai negativamente nelle ricerche, e il suo rilascio definitivo non richiede alcun intervento SEO manuale.
Sitemap XML separate per lingua
Una volta superate alcune centinaia di URL, una singola sitemap diventa difficile da gestire. Dividetela per lingua e utilizzate un indice di sitemap:
<!-- /sitemap.xml -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap><loc>https://example.com/sitemaps/sitemap-en.xml</loc></sitemap>
<sitemap><loc>https://example.com/sitemaps/sitemap-de.xml</loc></sitemap>
</sitemapindex>
Potete anche dichiarare l'hreflang all'interno della sitemap tramite elementi xhtml:link, come alternativa ai tag <head> HTML. Entrambi i metodi sono validi; non utilizzateli entrambi contemporaneamente, per evitare discordanze nel tempo.
Il vantaggio pratico della separazione è diagnostico: Search Console riporta l'indicizzazione per singola sitemap, permettendo di verificare immediatamente se la versione tedesca è indicizzata al 90% mentre quella francese è al 40%, isolando subito l'anomalia.
Indirizzare i visitatori verso la lingua corretta
Esistono due approcci, e uno di essi causa gravi problemi.
Reindirizzare alla radice in base a Accept-Language. Un visitatore che accede a / viene reindirizzato con un codice 302 a /de/ se il suo browser dichiara la lingua tedesca. I crawler non inviano l'header Accept-Language, quindi accedono alla lingua predefinita. Questo metodo è approvato da Google e funziona egregiamente.
Due condizioni essenziali: usate un redirect 302, non un 301 — il reindirizzamento è subordinato alla specifica richiesta, non è permanente. E fornite sempre all'utente un modo visibile e chiaro per cambiare lingua, poiché molti preferiscono una lingua diversa da quella predefinita del browser.
Non reindirizzate mai basandovi unicamente sulla geolocalizzazione IP. Un utente di lingua tedesca in viaggio in Giappone non desidera visualizzare il sito in giapponese. Un crawler situato negli Stati Uniti vedrebbe unicamente la versione inglese, rischiando di non scoprire mai le altre lingue. La geolocalizzazione IP è la causa principale del problema "Google non indicizza le altre lingue del nostro sito".
Diagnosi di un sito esistente
Se avete ereditato un sito multilingue e sospettate problemi tecnici, verificate questi sei punti in ordine:
- Ogni lingua ha un proprio URL dedicato? Se no, fermatevi: questo è il problema principale.
- Il comando
curl -s https://example.com/de/ | grep "frase in tedesco"restituisce testo? Se no, i contenuti risiedono solo lato client. - I tag canonical puntano a se stessi? Verificate tre pagine per ciascuna lingua.
- I tag hreflang sono reciproci? Il report sul targeting internazionale di Search Console mostra eventuali errori di tag di ritorno mancanti.
- C'è qualche pagina noindexed per errore? Direttive di staging finite in produzione sono disarmantemente frequenti.
- Tutte le lingue sono monitorate in Search Console? Confrontate i conteggi delle pagine indicizzate per ciascuna sitemap linguistica.
Il nostro free SEO audit tool analizza le annotazioni hreflang, i tag canonical e le direttive di indicizzazione presenti su qualsiasi pagina, coprendo i punti da 3 a 5.
In sintesi
La SEO internazionale è in gran parte una questione di architettura, e le decisioni architetturali sono economiche prima del lancio e molto costose a posteriori. Assegnate a ogni lingua un URL reale, localizzate gli slug, mantenete l'hreflang reciproco e auto-referenziale, assicuratevi che ogni versione sia il canonical di se stessa e impostate il noindex sui contenuti non ancora tradotti invece di pubblicare testo in inglese sotto un URL straniero.
Impostate correttamente questi cinque pilastri e la qualità della traduzione tornerà a essere il vero fattore che determina i vostri risultati commerciali.
Apri strumento Verifica hreflang Verificate correttamente hreflang — scarichiamo ogni URL alternativo e controlliamo che punti a sua volta verso la vostra pagina.