SEO Internazionale: 35 Slide da Google (tradotte)

Rendere un sito web multi-lingua, o comunque adeguarlo per il supporto di più varianti di una stessa lingua, richiede una serie di accorgimenti specifici. Maile Ohye, di Google, ha realizzato un interessante video, piuttosto ampio e dettagliato, sull’utilizzo del rel=”alternate” hreflang nel processo che porta alla creazione di un sito multi-lingua ed ha toccato molti aspetti sia tecnici che di usabilità ai quali dobbiamo saper fare attenzione.

Il video: rendere il tuo sito multi-lingua

Maile Ohye ha diffuso, assieme al filmato, una presentazione composta da 35 slide sull’argomento. Potete consultarla liberamente, in lingua inglese, in questa pagina. Per favorirne la diffusione in Italia, tuttavia, abbiamo pensato di tradurre, commentare e arricchire il materiale pubblicato da Google. Vi proponiamo, slide per slide, la nostra spiegazione sperando che possa esservi utile e possa contribuire a generare attenzione su un tema così strategico in un periodo nel quale guardare all’esterò sta diventando sempre più una necessità piuttosto che una scelta.

2) Di cosa parleremo:

• Quali sono i problemi SEO per i siti internazionali
• Alcune domande da porsi prima di iniziare
• 2 casi pratici
• Come utilizzare il rel=”alternate” per rendere il proprio sito più search-friendly
• Best practices generali

3) I possibili problemi:

• A chi cerca da una particolare regione o in una determinata lingua potrebbe non essere mostrato in SERP il miglior URL, anche se effettivamente ne esiste uno.

Nell’esempio, ad un utente sulla versione britannica di Google viene mostrato un sito in inglese americano. Probabilmente l’utente è comunque in grado di comprendere il messaggio, ma il risultato non è comunque il migliore possibile se esiste una versione .co.uk del sito in questione o se sul .com esiste una versione /en-gb/.

4) I possibili problemi:

• La SERP potrebbe presentare due risultati molto simili dallo stesso sito, confondendo l’utente. Ad esempio sulla stessa SERP potrebbe essere presente sia la pagina /en-us/ sia /en-gb/ e questo disorienterebbe sia chi cerca dagli Stati Uniti sia chi cerca dall’Inghilterra.
• Il motore di ricerca potrebbe non conoscere tutte le versioni nelle varie lingue di ogni singola pagina.

Vediamo come possiamo provare a prevenire questi problemi.

5) Riflessione interna prima di iniziare

Proviamo, per prima cosa, a capire quali sono le intenzioni della tua azienda (e quindi del tuo sito):

• La tua azienda sta cercando di creare un’esperienza d’uso differente a seconda delle della lingua parlata dalle persone e di dove vivono? State creando un’esperienza basata sul loro linguaggio ma anche sulla loro cultura e sul loro mercato?
• I tuoi colleghi si limiteranno a creare contenuti per le varie lingue o si preoccuperanno anche di mantenerli aggiornati?
• Il tuo team darà supporto (ad esempio via mail) ai clienti provenienti dalle nazioni e parlanti le lingue per le quali stai preparando il sito?

6)

Essere posizionati in un paese per una determinata lingua non vuol dire essere automaticamente posizionati in un nuovo paese o per una nuova lingua. Espandersi a nuovi mercati implica un impegno maggiore.

7) Caso pratico 1: Variazioni regionali della solita lingua

Un sito ha due pagine, una per regione (in questo caso gli Stati Uniti e la Gran Bretagna): la prima pagina ha URL https://www.example.com/, prezzi in Dollari ed è scritto in American English; la seconda pagina ha URL https://en-gb.example.com/, prezzi in Sterline ed è scritta in British English.

8) Caso pratico 2: Traduzioni complete

In questo esempio il sito ha due pagine: https://www.example.com/ scritta in lingua inglese, https://es.example.com/ scritta in spagnolo.

9)

Dati i due casi pratici descritti sopra, quali sono le metodologie che possiamo utilizzare per renderli search friendly? Entrambe passano da un markup corretto.

Google ha, infatti, creato il rel=”alternate” hreflang per permetterti di comunicare al meglio al motore di ricerca quale sia l’architettura del sito e come siano gestite le varie lingue e/o i vari paesi. L’hreflang costituisce un suggerimento del webmaster a Google, non è una direttiva stringente pertanto anche con tutti i setup corretti il motore di ricerca si riserva di comportarsi diversamente da come suggerito se ritiene che gli altri segnali di rilevanza di una pagina siano tanto forti da far passare l’hreflang in secondo piano. (Per i puristi: perdonate se non utilizzerò sempre la forma estesa rel=”alternate” hreflang=”x”).

10/11) rel=”alternate” hreflang

L’hreflang può essere inserito in diverse parti e si è liberi di scegliere quella più semplice per te da implementare. Le possibilità sono:

• Sulla pagina, nell’head del documento HTML
• Nell’header HTTP
• In un’unica Sitemap contenente tutte le varianti di ogni singolo URL
• In una Sitemap per lingua, se i contenuti sono su più siti e ciascun sito è verificato sugli Strumenti per Webmaster di Google.

12) rel=”alternate” hreflang

Con l’hreflang puoi definire solo la lingua (esempio “en” per l’inglese) o la coppia lingua-regione (esempio “en-gb” per i britannici che parlano inglese). Se si utilizza la seconda opzione, si consiglia di definire una pagina generica per chi parla la lingua pur non provenendo da alcuno dei paesi specificati.

13) rel=”alternate” hreflang

Qualora non si scelga un URL al quale assegnare solo la lingua e non il paese (esempio: se non si ha un URL con il solo campo “en” ma soltanto un URL con “en-gb” ed un URL con”en-us”) Google cercherà di rispondere alle ricerche in quella lingua ma da una nazione non specificata (esempio: l’Australia) nel migliore dei modi possibile come avrebbe fatto prima dell’introduzione dell’hreflang (in questo caso, sceglierà quale tra la versione britannica e quella americana è più rilevante per l’utenza australiana).

14) rel=”alternate” hreflang

Ci sono dei casi nei quali il valore dell’hreflang deve essere “x-default“. Deve succedere quando la pagina è pensata per l’atterraggio di persone da più stati e in più lingue. Esempi:

• L’URL si occupa soltanto di eseguire un redirect verso la versione nella lingua corretta
• La pagina ha un contenuto differente in base alla provenienza geografica dell’IP che la richiede
• La pagina serve all’utente soltanto per scegliere in quale lingua vuole continuare la navigazione

15) rel=”alternate” hreflang

Un caso d’esempio nel quale si può utilizzare l’hreflang=”x-default” è il Play Store di Google.

La home https://play.google.com/store, infatti, cambia la lingua dei contenuti in base all’IP dell’utente, senza redirigere verso un nuovo URL.

16) rel=”alternate” hreflang

In caso di URL duplicati, ad esempio URL con un ID di sessione, è sufficiente utilizzare il solo rel=”canonical” verso l’URL canonico.

Sull’URL canonico, invece, dovrà essere implementato l’hreflang con riferimenti ai vari URL canonici nelle altre versioni della pagina: non è necessario, infatti, utilizzare l’hreflang sugli URL non canonici.

17) rel=”alternate” hreflang

Vediamo un esempio: https://example.com/en/page?item=1&sid123 è la versione della pagina https://example.com/en/page?item=1 durante la sessione 123 e, per evitare duplicazione, avrà un canonical verso appunto https://example.com/en/page?item=1. Su questa versione, non canonica, potremo evitare di segnalare con l’hreflang la corrispondente pagina tedesca (https://example.com/de/page?item=1&sid123).

Sulla pagina canonica, e dunque https://example.com/en/page?item=1, avrà invece senso segnalare la versione in lingua tedesca con un rel=”alternate” hreflang verso https://example.com/de/page?item=1.

Per semplificare la cosa possiamo seguire questa regola: utilizziamo nei rel=”alternate” hreflang solo URL canonici.

18) rel=”alternate” hreflang

Nell’implementare il rel=”alternate” hreflang per un indirizzo ricordiamoci di elencare gli URL verso ogni versione disponibile, non dimenticandoci di inserire nell’elenco delle alternative anche l’indirizzo stesso.

19) rel=”alternate” hreflang

Le varie versioni dello stesso contenuto possono essere in cartelle differenti, su sottodomini differenti, possono avere differente top level domain e, addirittura possono essere su domini completamente diversi. La versione giapponese del contenuto presentato in www.example.com/en/page.html, ad esempio, potrà quindi essere in maileohye.com/ja/page.html.

Il consiglio comunque è di mantenere una struttura coerente tra le varie lingue in modo d’aiutare l’euristica dell’algoritmo sia nel crawling che nell’indicizzazione.

20) Dare a un sito come target uno specifico paese (per siti con un TLD generico)

Se si ha la necessità di assegnare come mercato di riferimento per un dominio, un sottodominio o una cartella una singola nazione si può continuare a utilizzare la pagina di localizzazione degli Strumenti per Webmaster di Google. Attenzione però, questo target funziona solo a livello di nazione e non sempre ad uno stato corrisponde una lingua: se il portoghese è parlato in Portogallo come in Brasile; in Svizzera si parlano sia l’italiano che il tedesco.

21) rel=”alternate” hreflang

Il rel=”alternate” hreflang potrebbe essere trattato differentemente dai vari motori di ricerca. Quanto spiegato vale per Google.

22) Caso pratico 1: Variazioni regionali della solita lingua

Nell’esempio che si vede sopra vi sono i due <link> presenti sulla coppia di pagine. La pagina a sinistra è quella di default per chiunque parli l’inglese, la pagina di destra, invece, è pensata per chi parla inglese ed è britannico. Come si può notare su entrambe le pagine ci sono elementi rel=”alternate” hreflang sia verso l’altra pagina che verso la pagina stessa.

23) Caso pratico 2: Traduzioni complete

Implementazione molto simile: ogni pagina contiene riferimenti a tutte e due le versioni disponibili, inclusa la pagina stessa.

24) Variazioni regionali della solita lingua e traduzioni complete

Ancora un esempio: una volta capito il meccanismo non ci sono variazioni significative.

25) Benefit: rel=”alternate” hreflang

Quando è implementato correttamente il rel=”alternate” hreflang aiuta i motori di ricerca a capire le relazioni tra le pagine del tuo sito in modo che possano essere scansionate e indicizzate più accuratamente

26) Benefit: aiuta Google a scoprire nuovi URL

Supponiamo che Google trovi trai link con rel=”alternate” un URL che non ha mai visto prima: in questo caso viene pianificata la futura scansione dell’URL.

Una volta scansionata la pagina potrà essere indicizzata e poi restituita nei risultati di ricerca.

27) Benefit: risultati con URL più adatti per gli utenti

Ultimo punto: facendo arrivare gli utenti sulla versione corretta del sito, si migliora la loro esperienza d’uso.

28) Best practices

Vediamo quali sono le best practices da seguire quando si ha intenzione di internazionalizzare il proprio sito.

29) URL che possano essere condivise

Ogni URL deve poter essere condivisa e linkata: sarebbe meglio se ciasun URL restituisse sempre il medesimo contenuto indipendentemente dall’IP dell’utente o dalla lingua che ha impostato sul browser. In questo modo è più facile che ogni contenuto venga correttamente indicizzato ed è più facile che chi clicca un collegamento trovi precisamente quello che è stato originariamente linkato.

Si può utilizzare un URL con hreflang=”x-default” che rediriga il traffico automaticamente verso URL specifici per una determinata lingua o nazione, ma si scoraggia la predisposizone di redirect automatici da un URL in una determinata lingua verso un nuovo URL in un’altra lingua poiché questo comportamento può impedire a Google un corretto crawling tra le pagine.

Se invece si decide di variare il contenuto sullo stesso URL in base alla nazionalità dell’IP che lo sta accedendo, allora Google indicizzerà soltanto una versione del sito (tipicamente Google accede da IP statunitensi e dunque potrebbe non vedere mai il testo scaricato da chi accede il solito URL con un IP italiano).

30) Non usare parametri per indicare lingue e regioni

I parametri possono essere meno facili da interpretare per il motore di ricerca piuttosto che altre parti degli URL. Si consiglia pertanto di non utilizzare i parametri per passare informazioni sulla lingua o la nazione ma di preferire i country code TLD oppure le cartelle e i sottodomini per i TLD generici.

Non si tratta di direttive stringenti tuttavia quanto più sarà organizzata la gestione delle lingue, tanto più l’euristica di Google saprà ottimizzare il crawling e l’indicizzazione delle pagine del sito.

31) Utilizza l’Unicode negli URL quand’è necessario

La codifica consigliata per i caratteri non ASCII negli URL è l’UTF-8: assicuriamoci che tutti i software che gestiscono la richiesta dei contenuti supportino questa codifica (server, database, CMS, eccetera)

32) Costruisci il tuo business assieme agli utenti che parlano le tue nuove lingue

Preoccupati di trovare visitatori, clienti e fan che sappiano parlare la lingua nel quale vuoi espandere il tuo business. Questo primo gruppo di utenti potrà invitarne di nuovi o creare link, aiutando il sito a crescere.

33) Fattore velocità di pagina

Attenzione a che l’architettura del sito possa scalare sia per assecondare un maggior numero di utenti sia per coprire maggiori distanze senza troppi rallentamenti.

Per maggiori spunti sull’ottimizzazione delle performance dei siti si segnalano questo link https://developers.google.com/speed/pagespeed/ ed un precedente video.

34) Lascia la scelta all’utente

Lascia gli utenti liberi di poter scegliere la propria lingua e fai in modo che sia possibile per un americano di lingua inglese acquistare sul tuo sito nella sua lingua madre anche se è in vacanza Germania (e dunque si connette da un IP tedesco).

35) Risorse [dove possibile tradotte]

Tutto chiaro? Esperienze o domande in merito? I commenti sono aperti!