Hreflang e ricerca interna: perché l'e-commerce multilingua non trova i prodotti

Un e-commerce multilingua può avere hreflang perfetti e perdere comunque il cliente straniero. Hreflang decide quale URL mostrare in SERP; non decide cosa trova l'utente quando, arrivato sullo store francese o tedesco, scrive nella barra di ricerca con le sue parole.

Gli audit SEO/AEO/GEO internazionali controllano annotazioni, canonical e sitemap per mercato, e si fermano all'atterraggio. La ricerca interna, che interroga un indice costruito dal catalogo tradotto, resta fuori da qualunque strumento SEO.

Vediamo come funziona davvero hreflang alla luce di quanto ha spiegato Google sugli "alternate names", perché le AI trattano le pagine tradotte come un unico contenuto, e perché lo stesso catalogo tradotto parola per parola produce ricerche senza risultati sugli store esteri. Infine, cosa fare in Meilisearch, Algolia ed Elasticsearch.

Come funziona hreflang: routing, non ranking

Hreflang non è un segnale di posizionamento. È una tabella di corrispondenze: dice a Google che un URL è l'equivalente italiano di un altro, che un terzo è destinato agli anglofoni del Regno Unito, un quarto all'Australia. Google usa queste relazioni per scegliere quale URL presentare a un utente, non per decidere quanto in alto posizionarlo.

Se la pagina americana si posiziona già nel Regno Unito, aggiungere l'alternate britannico non crea un nuovo punteggio. Cambia solo l'indirizzo mostrato per un posizionamento già calcolato.

Lo spiega bene Bill Hunt, consulente di strategia digitale globale e presidente di Bisan Digital, tra i nomi più noti della SEO internazionale, in un articolo pubblicato su Search Engine Journal il 28 ottobre 2026. Hunt racconta di aver seguito decine di migliaia di implementazioni di hreflang senza mai vedere una pagina salire in classifica per effetto dell'annotazione in sé. La sua sintesi: hreflang instrada, non posiziona.

Per capire perché, bisogna separare cinque fasi che di solito pensiamo come un'unica sequenza. Con la scoperta Google trova gli URL attraverso sitemap, link interni e annotazioni hreflang. Con la canonicalizzazione decide se sono risorse diverse o varianti quasi identiche dello stesso contenuto. Con l'indicizzazione memorizza come documento autonomo solo ciò che lo merita. Con lo scoring calcola il posizionamento sul membro scelto del gruppo. Con il serving, al momento della risposta, sceglie quale URL mostrare a quell'utente, in quel paese e in quella lingua. Hreflang lavora soprattutto in quest'ultima fase.

Alternate names: cosa ha spiegato Gary Illyes sugli URL hreflang

Nel 2018 Glenn Gabe, consulente SEO americano fondatore di GSQi e noto soprattutto per le sue analisi degli aggiornamenti dell'algoritmo di Google, documentò un caso strano. Un sito canonicalizzava le versioni britannica e indiana verso quella americana, contro le indicazioni di Google. Eppure gli URL "sbagliati" comparivano correttamente nelle SERP locali, mentre Search Console li dava come non indicizzati.

Gabe chiese spiegazioni a John Mueller, all'epoca il portavoce di Google più presente nel dialogo con i webmaster. Mueller confermò che il comportamento era reale, senza chiarirne il meccanismo. Gabe lo battezzò il "trucco di magia" di hreflang.

Nell'agosto 2026 il meccanismo ha avuto un nome. Gary Illyes, analista del team Google Search e una delle voci ufficiali di Google sui temi tecnici, ha risposto su LinkedIn a una domanda proprio su questo scenario. Quando Google canonicalizza un URL, ha spiegato, gli altri URL del gruppo di duplicati da cui è stato scelto possono diventare alternate names: non sono indicizzati in senso proprio, ma possono comparire nei risultati quando la ricerca dell'utente li richiede. Gli alternate hreflang, ha aggiunto, rientrano in questa categoria.

La conseguenza pratica è che l'URL britannico può comparire in SERP senza essere mai stato indicizzato da solo. Hreflang non gli ha dato un posizionamento, gli ha dato un indirizzo. E lo stato "non indicizzato" in Search Console, per una variante linguistica, non è di per sé un errore da correggere.

Il caso che Hunt porta nel suo articolo rende l'idea della scala. Un marchio globale di calzature aveva circa 98 siti di mercato, di cui 38 in inglese e quasi identici, e 22 con lo stesso simbolo del dollaro. Per l'azienda erano 38 mercati. Per Google, in larga parte, un solo gruppo di pagine equivalenti.

SEO internazionale e AI: 20 pagine tradotte sono una sola fonte

Con il retrieval semantico il quadro si stringe ancora. Hreflang è una relazione dichiarata: siamo noi a dire che due pagine sono equivalenti. I sistemi di AI quella equivalenza la riconoscono da soli, leggendo il contenuto.

L'esempio più chiaro arriva da Microsoft Web IQ, l'infrastruttura di ricerca e grounding pensata per gli agenti AI, presentata da Microsoft alla conferenza Build il 2 giugno 2026 e costruita sull'indice di Bing. Web IQ non restituisce pagine intere ma passaggi di testo da usare come prove nel ragionamento del modello. Secondo la lettura di Hunt, i suoi modelli multilingua sono progettati per rappresentare il più vicino possibile le informazioni equivalenti, anche quando sono scritte in lingue diverse.

Il risultato è che 20 pagine di mercato con le stesse specifiche, le stesse FAQ e le stesse descrizioni sono una sola unità di conoscenza con 20 indirizzi. Tradurle di nuovo, o aggiungere un ventunesimo mercato, non aggiunge niente che un'AI abbia motivo di citare.

È la conclusione a cui arriva lo stesso Hunt: hreflang non rende un contenuto locale. Il motivo per cui una pagina di mercato esiste deve stare nel contenuto, cioè in prezzi, normative, disponibilità, garanzie, consegne, casi e terminologia di quel paese.

Hunt è tornato sul punto discutendo l'articolo (con me) su LinkedIn (qui la conversazione). Ha raccontato di aver appena analizzato un'azienda i cui siti per Francia e Germania erano in francese e in tedesco, ma né la home né le pagine prodotto principali nominavano il paese: a parte il dominio nazionale, nulla indicava che fossero rivolti a quei mercati. Secondo Hunt, chi vuole visibilità specifica per mercato nelle risposte delle AI dovrà investire in adattamenti pensati per ciascun paese, perché per i modelli non esiste un equivalente di hreflang.

La ricerca interna, il punto cieco dell'audit SEO internazionale

Un audit SEO multilingua tipico verifica che le annotazioni hreflang siano valide e reciproche, che i canonical siano coerenti tra mercati, che ogni mercato abbia la sua sitemap. Sempre più spesso controlla anche le citazioni del marchio nelle AI Overview per paese. È tutto lavoro che serve a far atterrare l'utente sulla versione giusta. Quello che succede dopo l'atterraggio non lo misura nessuno.

L'utente francese arriva sullo store FR e scrive nella barra di ricerca. La query va al motore di ricerca interno, che interroga un indice costruito dal listino tradotto. Questo passaggio è invisibile a tutta la filiera SEO. Nessun crawler SEO esegue ricerche interne. Search Console non vede le query fatte sul sito. GA4 le registra al massimo come evento view_search_results, e solo se il parametro di ricerca è tracciato correttamente.

Eppure è il momento in cui l'utente ha già scelto il negozio e sta per scegliere il prodotto. Ogni ricerca senza risposta, a quel punto, è traffico conquistato con la SEO o pagato con la pubblicità che esce dalla porta.

Vocabulary mismatch: perché il catalogo tradotto genera ricerche senza risultati

Il catalogo tradotto parola per parola ha un costo doppio. Lato AI è un contenuto equivalente che il retrieval riconosce già da solo, quindi non aggiunge visibilità. Lato ricerca interna produce vocabulary mismatch: le parole dell'indice non sono quelle che usa chi compra.

Un motore lessicale confronta parole. Se l'utente francese scrive «k-way» e l'indice contiene «veste imperméable», il risultato è zero, anche se il prodotto c'è. Nessun hreflang lo risolve: il problema non è quale URL servi, ma quali parole ci sono nell'indice.

Le cause sono ricorrenti. I marchi diventati nomi comuni, come k-way in Francia o Scottex in Italia, non compaiono in nessuna traduzione professionale. Il registro tradisce la traduzione: il traduttore sceglie il termine corretto, il cliente quello che usa. Le varianti regionali colpiscono gli store che servono con un solo vocabolario inglese Regno Unito, Stati Uniti e Australia. La morfologia pesa soprattutto in tedesco, dove le parole composte non vengono trovate se l'analizzatore non le scompone.

Il problema esiste già nella lingua madre. Sugli e-commerce italiani che misuriamo nella nostra classifica, le ricerche in linguaggio naturale ottengono in media 3,7 risposte pertinenti su 10, e il 21% delle ricerche finisce su una pagina senza risultati. Sugli store esteri, dove il catalogo è una traduzione, c'è da aspettarsi di peggio.

Come localizzare il catalogo per la ricerca interna

Localizzare un catalogo non significa tradurre le stringhe. Significa mettere nell'indice le parole di chi compra in quel mercato. È l'unico intervento che lavora insieme su SERP, retrieval delle AI e ricerca interna.

Un indice per mercato, con l'analisi linguistica giusta

Ogni lingua ha bisogno della sua tokenizzazione, dei suoi plurali, delle sue stop word e, per il tedesco e le lingue nordiche, della scomposizione delle parole composte. Un indice unico con impostazioni generiche penalizza tutte le lingue tranne quella di partenza.

In Meilisearch la lingua si dichiara per attributo con l'impostazione localizedAttributes e in query con il parametro locales, che prevale sull'impostazione dell'indice. Il tokenizzatore scompone le parole composte tedesche, ma la documentazione stessa consiglia di tenere in un indice separato le lingue con parole composte come il tedesco. Per i dataset multilingua suggerisce di affiancare alla ricerca per parole una ricerca ibrida con un modello di embedding multilingua.

In Algolia la lingua si imposta con indexLanguages per l'indicizzazione e queryLanguages per le ricerche, insieme a ignorePlurals e removeStopWords. La scomposizione delle parole composte si attiva con decompoundedAttributes sugli attributi e decompoundQuery sulle ricerche, ed è disponibile per tedesco, olandese, finlandese, danese, svedese e norvegese.

In Elasticsearch si usano gli analizzatori di lingua (french, german e gli altri) e, per le parole composte, i filtri dictionary_decompounder o hyphenation_decompounder. I sinonimi si gestiscono con il filtro synonym_graph applicato in fase di ricerca, così si possono aggiornare senza reindicizzare.

In tutti e tre i motori i sinonimi vanno gestiti per indice, quindi per mercato: «k-way» è un sinonimo utile in Francia e rumore in Germania.

Raccogliere il vocabolario locale dai dati, non dal glossario

Le parole giuste non le conosce il traduttore: le scrivono i clienti. La fonte più affidabile sono i log delle ricerche interne per mercato, in particolare le ricerche senza risultati e quelle seguite da un'uscita dal sito. Subito dopo vengono le query di Search Console filtrate per paese, che dicono con quali parole gli utenti arrivano dal motore di ricerca. I marketplace e i concorrenti locali mostrano i termini usati nei titoli prodotto di Amazon.fr o Zalando.de. Il servizio clienti e le recensioni nella lingua del mercato completano il quadro.

Arricchire il dato, non solo il motore

I sinonimi nel motore sono una toppa: funzionano, ma vivono fuori dal catalogo. L'intervento duraturo è aggiungere i termini locali ai dati di prodotto, per esempio in un attributo ricercabile dedicato ai termini di ricerca di ciascun mercato, nel sistema che detiene la fonte del dato, che sia la piattaforma e-commerce o il PIM. Così gli stessi termini arrivano anche ai feed, ai marketplace e alle pagine che leggono Google e le AI.

Ricerca semantica: aiuta, ma non basta

Una ricerca ibrida con modelli di embedding multilingua riduce il vocabulary mismatch, perché confronta significati e non parole. Ma un marchio usato come nome comune o un termine molto colloquiale può restare fuori dallo spazio semantico del modello. La parte lessicale, con sinonimi per mercato e dati arricchiti, resta necessaria.

Misurare per mercato

Ogni mercato va misurato separatamente: quota di ricerche senza risultati, clic sui risultati, uscite dopo la ricerca. Un valore medio su tutti gli store nasconde proprio il mercato che va peggio.

Audit SEO/AEO/GEO internazionale per e-commerce: cosa controllare prima e dopo l'atterraggio

La parte classica dell'audit resta necessaria, va solo completata con quello che succede dopo che l'utente è arrivato sullo store.

Prima dell'atterraggio si verifica che gli hreflang siano validi, reciproci e coerenti con i canonical, che ogni mercato abbia la sua sitemap e che le pagine di mercato abbiano un contenuto davvero locale: il paese nominato nei testi, prezzi, IVA, spedizioni, resi, metodi di pagamento e normative. Si misura anche come le risposte delle AI citano il marchio, paese per paese e lingua per lingua.

Dopo l'atterraggio si controlla che ogni mercato abbia il suo indice, con l'analizzatore della lingua corretta e la scomposizione delle parole composte dove serve. Si verifica che il tracciamento delle ricerche interne sia attivo su ogni store e si misura la quota di ricerche senza risultati per mercato, mai in media. Si mette alla prova il motore con una ventina di ricerche scritte da un madrelingua, non ricavate dal catalogo. Infine si raccolgono i termini locali dai log e da Search Console, e li si aggiunge ai dati di prodotto nel sistema che detiene la fonte del dato.

L'ultimo controllo è nel tempo: il vocabolario dei clienti cambia, il catalogo tradotto no. Un audit della ricerca interna per mercato va ripetuto, non fatto una volta sola.

Domande frequenti

Hreflang migliora il posizionamento?

No. Hreflang indica a Google quale versione di una pagina mostrare in base al paese e alla lingua dell'utente. Il posizionamento viene calcolato su un membro del gruppo di pagine equivalenti; hreflang interviene quando Google sceglie quale URL servire.

Cosa sono gli alternate names di Google?

È il termine usato da Gary Illyes di Google per gli URL di un gruppo di duplicati che non vengono indicizzati in modo autonomo, ma che possono comparire nei risultati quando la ricerca dell'utente li richiede. Gli URL alternativi indicati con hreflang rientrano in questa categoria.

Perché Search Console dà come non indicizzate le versioni in altre lingue?

Perché, secondo quanto spiegato da Illyes, le varianti hreflang non sono indicizzate in senso proprio: Google le conserva come nomi alternativi della pagina canonica. Possono comunque essere mostrate agli utenti del paese giusto.

Le AI citano le versioni tradotte di un sito come fonti diverse?

Di solito no. I modelli multilingua riconoscono come equivalenti i contenuti che dicono la stessa cosa in lingue diverse. Una pagina tradotta senza informazioni locali proprie non dà al sistema un motivo in più per citarla.

Perché la ricerca interna di uno store estero non trova prodotti che ci sono?

Perché l'indice contiene le parole della traduzione, mentre i clienti cercano con le loro: termini colloquiali, marchi usati come nomi comuni, varianti regionali, parole composte. Il motore confronta le parole e non trova corrispondenza.

La ricerca semantica risolve il problema delle lingue?

In parte. Riduce lo scarto tra parole diverse con lo stesso significato, ma non copre tutti i termini colloquiali o di marca. Funziona meglio affiancata a sinonimi per mercato e a dati di prodotto arricchiti con i termini locali.