Il sintomo che porta le persone a questo tema è quasi sempre lo stesso: l’azienda ha una sezione in giapponese, la sezione è indicizzata, eppure gli utenti in Giappone continuano ad arrivare sulla pagina inglese. A volte la pagina inglese supera addirittura quella giapponese per una query in lingua giapponese.

Di solito l’hreflang fa parte del problema. Non sempre ne è l’unica causa (una pagina giapponese che nessuno cerca non si posizionerà, comunque sia annotata), ma è la parte che si può correggere in modo deterministico, e vale la pena sistemarla prima di trarre qualsiasi altra conclusione.

Che cosa fa davvero l’hreflang

L’hreflang non fa posizionare una pagina. Comunica a Google che diversi URL sono versioni alternative, per lingua o per area geografica, dello stesso contenuto, così che, quando uno di essi risulta idoneo a comparire tra i risultati, Google possa sostituirlo con la versione corrispondente alla lingua e alla posizione dell’utente.

Da questa definizione discendono due conseguenze, e la maggior parte degli errori di hreflang nasce dal trascurarne una.

La prima: è un meccanismo di sostituzione, non di potenziamento. Se la vostra pagina giapponese non ha visibilità propria e nemmeno quella inglese ne ha, un hreflang corretto non cambia nulla.

La seconda: opera su cluster di URL, non su siti. Ogni pagina ha il proprio cluster. /services/technical-seo/ e /ja/services/technical-seo/ formano un cluster; le due home page ne formano un altro. Un unico blocco di annotazioni valido per tutto il sito, che punta alle home page di ciascuna lingua ed è ripetuto su ogni pagina, è uno dei modi più comuni per avere l’hreflang senza trarne alcun beneficio.

ja o ja-JP?

Il subtag di lingua è ja. Non jp. jp è un codice paese (è quello che compare in .co.jp e in ja-JP) e da solo non è un valore di lingua valido. hreflang="jp" non è valido e viene semplicemente ignorato. È l’errore di hreflang più frequente che vediamo nelle sezioni giapponesi e, poiché le annotazioni non valide falliscono senza segnalarlo, può restare lì per anni.

Tra ja e ja-JP, la risposta onesta è che ja è corretto per la maggior parte dei siti.

  • ja significa “questa pagina è per chi parla giapponese”, ovunque nel mondo.
  • ja-JP significa “questa pagina è per chi parla giapponese in Giappone”, ed esclude chi parla giapponese ma naviga da altri paesi.

Usate il subtag di area geografica solo se avete davvero più di una versione in lingua giapponese differenziata per paese: ad esempio una pagina ja-JP con i prezzi per il Giappone e una pagina ja-SG per l’entità di Singapore. Se avete una sola pagina giapponese, ja copre tutti quelli che dovrebbero vederla, compresi i parlanti giapponesi in viaggio o residenti all’estero. Restringere a ja-JP senza motivo significa semplicemente perdere una parte del pubblico.

Se usate un subtag di area geografica, deve essere un codice paese ISO 3166-1 alpha-2, e la grafia convenzionale è ja-JP (il valore non distingue tra maiuscole e minuscole, ma la coerenza facilita gli audit).

La reciprocità è la regola su cui cade tutto

Ogni URL di un cluster deve elencare tutti gli URL di quel cluster, sé stesso compreso. Se la pagina A dichiara la pagina B come sua alternativa giapponese ma la pagina B non ricambia indicando la pagina A, Google può ignorare del tutto l’annotazione.

L’autoreferenza è davvero obbligatoria, e davvero manca spesso. La pagina giapponese deve includere una riga hreflang="ja" che punta a sé stessa, non solo la riga che punta alla versione inglese.

Per un sito con un originale inglese e una versione giapponese, lo stesso identico blocco compare su entrambe le pagine:

<link rel="alternate" hreflang="en" href="https://example.com/services/pricing/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/services/pricing/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/pricing/" />

Il modo più affidabile per garantire la reciprocità è smettere di gestirla a mano. Generate il cluster da un’unica fonte di verità, un registro delle pagine che sa in quali lingue esiste ciascuna pagina, in modo che ogni pagina del cluster produca per costruzione lo stesso elenco. Un hreflang gestito a mano si degrada la prima volta che qualcuno aggiunge una pagina.

x-default

x-default indica la pagina da mostrare quando nessun’altra versione corrisponde all’utente. È facoltativo, ed è spesso frainteso.

Fatelo puntare alla pagina che rappresenta il fallback sensato per “qualcuno per cui non abbiamo una corrispondenza migliore”. Di solito è la versione globale in inglese, oppure una vera pagina di selezione della lingua, se ne avete una. Non fate puntare x-default alla pagina giapponese: verrebbe mostrata a utenti a cui non era destinata.

Anche x-default rientra nella reciprocità: la stessa annotazione va inserita su ogni pagina del cluster, compresa la pagina a cui punta.

Una sfumatura da conoscere: x-default ha senso solo quando esiste più di una versione tra cui scegliere. Su una pagina che esiste in una sola lingua, l’intero blocco di annotazioni è solo rumore.

Dove inserirlo

Tre metodi di implementazione, tutti ugualmente validi per Google:

  • Elementi <link> nell’<head>: il più semplice e la scelta predefinita giusta per la maggior parte dei siti. Devono trovarsi nell’<head> dell’HTML grezzo, non essere iniettati via JavaScript nel <body>.
  • Header HTTP Link: l’unica opzione per file non HTML come i PDF.
  • Annotazioni nella sitemap XML: spesso la scelta più manutenibile per un sito di grandi dimensioni, perché l’intera mappa dei cluster vive in un unico file generato anziché essere distribuita su migliaia di template.

Sceglietene uno. Due metodi in disaccordo sono peggio di uno qualsiasi dei due da solo, ed è un esito sorprendentemente frequente quando sono attivi sia un plugin sia un template scritto a mano.

Canonical e hreflang devono essere coerenti

È qui che si rompono molte configurazioni altrimenti corrette.

Ogni versione linguistica deve avere un canonical autoreferenziale. La pagina giapponese ha come canonical sé stessa. Se la pagina giapponese riporta un <link rel="canonical"> che punta all’URL inglese (succede più spesso di quanto si pensi, di solito come residuo di un timore di contenuti duplicati), avete detto a Google che la pagina giapponese non deve essere indicizzata affatto, e l’annotazione hreflang che punta a essa perde ogni significato.

Regole correlate che derivano dallo stesso principio:

  • L’hreflang deve puntare all’URL canonico e indicizzabile: non a un redirect, non a una variante con parametri, non a una pagina noindex.
  • Usate URL assoluti, con il protocollo. Gli URL relativi nell’hreflang non sono supportati.
  • Rispettate esattamente le vostre convenzioni su slash finale, www e https. https://example.com/ja/pricing e https://example.com/ja/pricing/ sono URL diversi, e una discrepanza rompe la reciprocità anche se il browser porta nello stesso posto.

Sottodirectory, sottodominio o .co.jp

L’hreflang funziona in modo identico in tutti e tre i casi. example.com/ja/, ja.example.com ed example.co.jp possono essere annotati come alternative l’uno dell’altro, e Google gestisce senza problemi i cluster hreflang cross-domain.

La scelta della struttura degli URL, quindi, non è una decisione di hreflang: è una decisione di autorevolezza, di gestione operativa e di credibilità, che approfondiamo a parte in Serve un dominio .co.jp per posizionarsi in Giappone?. L’unico aspetto rilevante per l’hreflang: un cluster cross-domain è più difficile da mantenere reciproco, perché i due lati sono di solito gestiti da team diversi con cicli di rilascio diversi. È un rischio operativo, non di ranking, ma è un rischio reale.

Gli errori da verificare per primi

Più o meno nell’ordine in cui li troviamo:

  1. hreflang="jp" invece di hreflang="ja".
  2. Nessuna annotazione autoreferenziale su uno o su entrambi i lati.
  3. Cluster non reciproci, di solito perché la sezione giapponese è stata costruita più tardi, da un altro team, a partire da un altro template.
  4. Annotazioni valide per tutto il sito che fanno puntare ogni pagina alle due home page.
  5. Destinazioni hreflang che reindirizzano, restituiscono 404 o hanno noindex.
  6. La pagina giapponese con canonical verso la pagina inglese.
  7. Discrepanze di protocollo, www o slash finale tra l’annotazione e l’URL reale.
  8. Annotazioni iniettate tramite JavaScript lato client.
  9. Redirect automatici basati sull’IP che allontanano completamente dalle pagine giapponesi Googlebot, che esegue la scansione in gran parte da indirizzi IP statunitensi.

Quest’ultimo merita un’enfasi particolare, perché vanifica tutto il resto. Se i visitatori con IP giapponese vengono reindirizzati forzatamente su /ja/ e tutti gli altri vengono reindirizzati forzatamente altrove, le vostre annotazioni descrivono un sito che Google non riesce a scansionare. Suggerite il cambio di lingua con un banner che si può chiudere; non imponetelo.

Come verificare

Google ha dismesso il rapporto dedicato Targeting internazionale in Search Console, quindi non esiste più un validatore hreflang ufficiale su cui contare. La verifica ora spetta a voi, e non è difficile:

  • Eseguite la scansione di entrambe le sezioni linguistiche con un crawler che estrae l’hreflang, e controllate la reciprocità sull’intero insieme anziché verificare a campione una sola pagina. Gli errori di reciprocità sono sistematici: se una pagina ne ha uno, probabilmente ce l’hanno centinaia.
  • Verificate che ogni URL di destinazione restituisca 200, abbia un canonical autoreferenziale e sia indicizzabile.
  • Controllate l’HTML grezzo, non il DOM renderizzato nell’ispettore del browser: possono differire.
  • Usate lo strumento Controllo URL su una pagina giapponese rappresentativa per confermare che Google veda il canonical che avete previsto.
  • Monitorate il rapporto Prestazioni di Search Console filtrato per il Giappone, e osservate quale URL riceve le impressioni per le query in lingua giapponese. Se settimane dopo la correzione è ancora l’URL inglese, o l’annotazione non viene rispettata oppure la pagina giapponese non è un risultato credibile per quella query.

Quest’ultima distinzione è quella da tenere a mente. L’hreflang decide quale delle vostre pagine viene mostrata. Non decide se qualcuna di esse meriti di esserlo. Se la pagina giapponese è una traduzione diretta di una pagina inglese, costruita sulla domanda di ricerca inglese, annotazioni corrette porteranno in evidenza una pagina che nessuno stava cercando: è la tesi sviluppata per esteso in Perché tradurre il sito web non è SEO giapponese.

Sistemate prima il livello tecnico, perché è conoscibile e, una volta corretto, resta tale. Poi dedicatevi alla metà più difficile.

Se volete che la configurazione venga verificata a fondo, è parte del nostro lavoro di SEO internazionale per il Giappone e di SEO tecnico: inviateci gli URL e vi diremo che cosa troviamo.