Hreflang e-commerce multilingua: guida errori

Hreflang e-commerce multilingua: guida agli errori

Hai uno store FR e stai aprendo una versione EN per gli US. Sembra tutto funzionare — finché non ti accorgi che, cercando il tuo brand dalla Francia, Google mostra la pagina US. I clienti francesi atterrano su una pagina in inglese e il tasso di conversione cala.

Il responsabile: un tag hreflang configurato male. Questo tag dice a Google quale versione linguistica o regionale mostrare a quale pubblico. Se fatto bene, rende ordinato il SEO internazionale. Se fatto male, crea un caos di reindirizzamenti incrociati.

Cosa risolve hreflang (e cosa non risolve)

Hreflang risolve:

Mostrare la pagina FR agli utenti francofoni, EN agli anglofoni
Distinguere fr-FR (Francia) e fr-CA (Canada) con prezzi o spedizioni diversi
Evitare contenuti duplicati tra 5 versioni linguistiche quasi identiche

Hreflang non risolve:

Il ranking in sé (hreflang non è un segnale di ranking diretto)
Le performance per mercato (i backlink locali restano essenziali per ogni mercato)
I problemi di qualità della traduzione

Se il tuo sito ha una sola lingua, non ti serve hreflang. Se hai 2+ lingue o 2+ regioni, è obbligatorio per un SEO internazionale pulito.

I 3 metodi di implementazione

Metodo 1 — Tag `<link>` nell'HTML

Il più comune. Ogni pagina elenca le sue alternative nel <head>:

<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/en-gb/products/leather-derby-shoes" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/leather-derby-shoes" />

Adatto ai cataloghi piccoli (<1000 pagine). Difficile da mantenere su grandi volumi — ogni pagina deve conoscere le sue alternative.

Metodo 2 — Sitemap XML

Ogni URL nella sitemap elenca le sue varianti:

<url>
  <loc>https://example.com/fr/products/chaussure-derby</loc>
  <xhtml:link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
  <xhtml:link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/products/leather-derby-shoes" />
</url>

Meglio per i cataloghi grandi: centralizza le relazioni in un solo file. Più facile da generare via script. È il metodo consigliato da Ecomptimize per cataloghi con oltre 5.000 schede prodotto.

Metodo 3 — Header HTTP `Link`

Per file non HTML (PDF, immagini localizzate):

Link: <https://example.com/fr/catalog.pdf>; rel="alternate"; hreflang="fr-FR",
      <https://example.com/en/catalog.pdf>; rel="alternate"; hreflang="en-US"

Raro nell'e-commerce, utile per cataloghi PDF scaricabili.

Raccomandazione: metodo sitemap per cataloghi con >1000 URL, tag HTML per il resto.

Hreflang vs canonical: non confonderli

È il malinteso più frequente.

Canonical dice: "questo è l'URL di riferimento di questo contenuto tra più URL identici o simili". Serve a deduplicare.

Hreflang dice: "queste sono le versioni linguistiche di questo contenuto, ognuna è unica per il suo pubblico". Serve a localizzare.

Regola critica: hreflang punta a un URL diverso (la versione in un'altra lingua). canonical punta a un URL potenzialmente identico (la stessa pagina o una variante con parametri).

Una pagina deve avere sia un hreflang sia un canonical:

<!-- Canonical di questa pagina -->
<link rel="canonical" href="https://example.com/fr/products/chaussure-derby" />

<!-- Versioni linguistiche di questa pagina -->
<link rel="alternate" hreflang="fr-FR" href="https://example.com/fr/products/chaussure-derby" />
<link rel="alternate" hreflang="en-US" href="https://example.com/en-us/products/leather-derby-shoes" />

Errore grave: far puntare il canonical della versione EN alla versione FR ("canonicalizzare le traduzioni"). Google lo interpreta come "la versione EN è un duplicato della FR da ignorare" e non indicizza affatto la pagina EN. Disastro SEO.

La matrice bidirezionale

Hreflang deve essere bidirezionale: se A dice "la mia versione EN è B", allora B deve dire "la mia versione FR è A". Altrimenti Google ignora la relazione.

Esempio di implementazione corretta:

Pagina FR:

<link rel="alternate" hreflang="fr-FR" href=".../fr/..." />
<link rel="alternate" hreflang="en-US" href=".../en-us/..." />
<link rel="alternate" hreflang="x-default" href=".../en/..." />

Pagina EN US:

<link rel="alternate" hreflang="fr-FR" href=".../fr/..." />
<link rel="alternate" hreflang="en-US" href=".../en-us/..." />
<link rel="alternate" hreflang="x-default" href=".../en/..." />

Esattamente le stesse 3 righe su ogni versione. Nessuna relazione mancante, nessuna relazione asimmetrica.

Varianti regionali: fr-FR vs fr-CA vs fr-BE

Quando bisogna distinguere le regioni?

Prezzi diversi (IVA, spedizione, valuta) → sì, distingui
Contenuto leggermente diverso (taglie US vs EU, vocabolario locale) → sì, distingui
Contenuto identico, cambia solo la valuta → no, non distinguere; gestisci la valuta nel checkout

La distinzione regionale richiede URL distinti:

/fr/products/chaussure-derby     (hreflang="fr")
/fr-ca/products/chaussure-derby  (hreflang="fr-CA")
/fr-be/products/chaussure-derby  (hreflang="fr-BE")

Se non puoi mantenere 3 versioni distinte, è meglio tenere una sola versione fr e gestire le differenze (valuta, spedizione) a runtime.

x-default: perché è indispensabile

hreflang="x-default" indica quale versione mostrare quando non viene trovata alcuna corrispondenza. Per esempio, un utente in Romania che non ha né FR né EN-US né EN-GB nelle preferenze — quale versione deve vedere?

Senza x-default, Google sceglie in modo casuale. Con x-default, decidi tu (di solito la versione EN più generica).

Raccomandazione: dichiara sempre un x-default, idealmente la versione inglese generica.

Implementazione per piattaforma

Shopify

Shopify Markets (dal 2022) gestisce hreflang in modo nativo se configuri più markets con domini o sottodomini distinti. Nella maggior parte dei casi non serve personalizzazione.

Limiti: Shopify Markets non supporta tutte le combinazioni lingua/paese con granularità fine. Per casi complessi (10+ mercati), usa un'app come Langify + il suo modulo hreflang manuale.

WooCommerce

WooCommerce non ha supporto nativo. Tre opzioni:

WPML (paid): plugin multilingua leader, gestisce hreflang automaticamente
Polylang (free/paid): alternativa con buon supporto hreflang
TranslatePress (paid): più semplice per cataloghi piccoli

Attenzione: non combinare due plugin (WPML + Polylang), perché crea hreflang duplicati e rotti.

Headless o custom

Se usi un frontend custom (Next.js, Nuxt), generi hreflang lato server. Su Next.js con next-intl, la generazione è automatica se usi le route /[locale]/....

Audit hreflang in 15 minuti

Sul tuo sito attuale, verifica:

Bidirezionalità: per 10 pagine test, controlla che ogni versione faccia riferimento alle altre in modo reciproco (con Screaming Frog o hreflang.org)
x-default presente: su tutte le pagine localizzate
Nessun canonical cross-lingua: la versione EN non deve canonicalizzare verso FR
Codici ISO validi: "fr", "en" (lingua) oppure "fr-FR", "en-US" (lingua-paese). Non "french" né "uk".
Stesso URL su hreflang e canonical della stessa pagina: evita divergenze

Strumenti gratuiti:

hreflang.org — audit per URL
Screaming Frog (SEO Spider) — audit in massa
Google Search Console — report errori hreflang in Settings → International Targeting