Una guida al targeting per lingua e paese

Qual è il modo migliore per configurare un sito Web che richiede il targeting per Paese e lingua? Bene, questo è un problema molto dibattuto tra gli esperti SEO e sfortunatamente non esiste una risposta chiara. Indipendentemente da come scegli di configurare il tuo sito Web, ci saranno delle carenze poiché ogni situazione è diversa e dipende dalla natura unica della tua attività.

Tuttavia, come introduzione all'argomento, esplorerò come affrontare la questione del targeting per lingua e paese in un ambiente di e-commerce.

Quando si considerava inizialmente il nostro approccio, c'erano molte questioni diverse che dovevano essere prese in considerazione, ma fondamentalmente c'erano due fattori importanti da tenere a mente:

1. Ottimizzazione per i motori di ricerca (SEO)
2. Ottimizzazione del tasso di conversione (CRO)

C'erano due aspetti separati da considerare per entrambi questi fattori quando stavamo scegliendo la configurazione del nostro dominio: il modo in cui ci rivolgiamo alle lingue e il modo in cui ci rivolgiamo ai paesi. Un sito multilingue è un sito Web che offre i propri contenuti in più di una lingua, ad esempio un'azienda canadese che fornisce i propri contenuti sia in inglese che in francese.

Un sito web multiregionale, d'altra parte, è un sito web che si rivolge in modo specifico agli utenti di diversi paesi. Questo viene spesso fatto per migliorare il CRO personalizzando contenuti come il processo dell'ordine, i dettagli di spedizione, la ricerca dell'indirizzo e qualsiasi altro contenuto per migliorare le conversioni in base alla posizione geografica. Oltre a queste due configurazioni individuali, è importante tenere a mente che un sito può essere sia multiregionale che multilingue.

I marchi con cui lavoriamo sono popolari in molti paesi diversi, alcuni dei quali (come il Canada), servono utenti in più paesi e questo ha aggiunto un ulteriore livello di complessità alla nostra configurazione. Come dovevamo servire agli utenti la lingua corretta fornendo loro anche un'esperienza utente su misura per la loro posizione geografica per offrire loro aspettative realistiche di spedizione, prezzo e garanzie?

COME ERA LA NOSTRA CONFIGURAZIONE PRECEDENTE?

In precedenza utilizzavamo una configurazione di sottodirectory per tutti i siti della rete MoreNiche, con la versione americana su https://brandwebsites.com/us/, la versione francese su https://brandwebsites.com/fr/ e la versione canadese del sito all'indirizzo https://brandwebsites.com/can/.

Di conseguenza, gli utenti canadesi potrebbero finire in /can/ o /fr/ a seconda della lingua in cui hanno cercato, con alcuni utenti canadesi che arrivano persino sul sito /us/ anche se la locale è stata impostata su en-US. In effetti, quasi la metà di tutti gli utenti canadesi era atterrata sul sito statunitense e si era persa molti degli importanti miglioramenti dell'usabilità che avevano dimostrato di apportare grandi benefici al CRO.

Nel complesso, quando si è trattato di scegliere come target sia la lingua che il paese, la nostra precisione è stata dell'ordine del 70%, il che significa che una buona parte degli utenti del sito non ha avuto un'esperienza ottimale. Questa è stata una performance notevolmente inferiore rispetto al sito CrazyBulk che stava già utilizzando una configurazione multi-dominio e registrava una precisione del 90%.

Ciò si rifletteva sia nei tassi di conversione che nelle classifiche dei marchi paese per paese. In generale, Google sembrava preferire la configurazione del sito in lingua e gli utenti hanno beneficiato dell'esperienza di pagamento personalizzata migliorata e degli altri nostri sforzi CRO.

A COSA SEMBRA LA SOLUZIONE PERFETTA?

Qual è quindi la soluzione ideale per una configurazione che richiede un targeting geografico e linguistico? Questa è una domanda difficile, senza una risposta perfetta. In effetti, i SEO discutono sempre di questa questione controversa.

La nostra visione a lungo termine è che tutti i siti debbano trovarsi su domini o sottodomini di lingua (ccTLD) (su un gTLD) in cui il ccTLD non è disponibile per garantire che l'esperienza sia personalizzata per il paese specifico. I paesi che richiedono più di una lingua dovrebbero eventualmente avere una configurazione multilingue, ad esempio, https://brandwebsites.ca servirebbe il sito in lingua inglese canadese principale mentre https://brandwebsites.ca/fr/ servirebbe leggermente meno importante sito in lingua francese canadese.

Con la netta maggioranza del traffico proveniente dagli affiliati, abbiamo ritenuto che fosse più importante considerare prima il CRO per garantire che la maggior parte degli utenti abbia un'esperienza su misura per la loro posizione geografica.

Per supportare questa configurazione e assicurarci di non incorrere in problemi con contenuti duplicati, dovevamo essere certi di fare un uso corretto di hreflang per spiegare ai motori di ricerca esattamente cosa stavamo prendendo di mira. Inoltre, dovevamo prestare attenzione ai contenuti duplicati su più domini e considerare attentamente se utilizzare la canonizzazione o se fosse, in effetti, accettabile avere contenuti duplicati poiché ci rivolgevamo a utenti diversi in paesi diversi. Di seguito è riportato un estratto del consiglio di Google sui contenuti duplicati nel caso di siti Web specifici per lingua e paese.

Spesso, specialmente quando indossi il tuo cappello SEO, è fin troppo facile diventare eccessivamente timorosi di avere contenuti duplicati sul tuo sito web. Gran parte di questa paura è stata causata dalla natura eccessivamente zelante dell'aggiornamento iniziale di Google Panda nel febbraio 2011. Sebbene i contenuti duplicati siano sempre stati qualcosa da tenere a mente, la sua importanza è decuplicata con l'introduzione di Panda.

Durante la notte molti siti che in precedenza si erano classificati bene sono semplicemente scomparsi a causa della qualità dei contenuti e dei problemi di duplicazione che hanno sollevato una bandiera contro il sito e hanno effettivamente contrassegnato l'intero dominio come di bassa qualità. In effetti, ti consiglierei comunque di leggere questo vecchio post su Moz che fornisce alcuni consigli dettagliati sui contenuti duplicati in un mondo post-Panda.

Una cosa che vale la pena notare ora è che da gennaio 2016 Panda è effettivamente solo un'altra parte dell'algoritmo principale di Google ed è di natura molto più granulare. Ciò significa che anche nel peggiore dei casi non dovresti trovare l'intero dominio penalizzato. Ma nella remota possibilità che lo sia, dovresti essere in grado di recuperare molto più velocemente poiché non devi aspettare diversi mesi per il prossimo aggiornamento dell'algoritmo.

Inoltre, Google ha imparato abbastanza velocemente che alcuni contenuti duplicati vanno bene, specialmente se sono destinati a utenti diversi in paesi diversi. Con questo in mente, nel dicembre 2011 ha introdotto l'attributo hreflang in modo da poter indicare a Google chi dovrebbe vedere quale versione dei tuoi contenuti proviene dalla ricerca di Google.

IL NOSTRO PRIMO PASSO È ORA COMPLETATO

Quindi non siamo riusciti a passare direttamente dalla nostra configurazione precedente alla configurazione dei nostri sogni per una serie di motivi tecnici e relativi alle risorse. Invece, abbiamo fatto alcuni piccoli passi lungo la strada. Al momento, per la maggior parte dei marchi con cui lavoriamo, abbiamo i seguenti domini attivi:

https://brandwebsites.com
https://it.brandwebsites.com
https://au.brandwebsites.com
https://ca.brandwebsites.com
https://fr.brandwebsites.com
https://de.brandwebsites.com
https://brandwebsites.es
https://brandwebsites.gr

Come puoi vedere, esiste una combinazione di sottodomini nel dominio gTLD .com e ccTLD. Man mano che acquisiamo ccTLD, passeremo dal sottodominio al ccTLD per standardizzare la nostra configurazione sui ccTLD, tenendo presente alcuni altri potenziali vantaggi di cui parleremo in seguito.

Da quando abbiamo completato questa migrazione all'inizio del 2017, abbiamo aggiornato le nostre Sitemap e assicurato che i nuovi domini siano impostati correttamente negli strumenti per i webmaster di Google e Bing. Abbiamo anche impostato reindirizzamenti permanenti (301) in modo che il traffico che atterra nelle vecchie posizioni non si perda semplicemente e in modo da conservare parte del valore di altri siti Web che si collegano a pagine con la vecchia configurazione.

A partire dal 6 febbraio 2017, abbiamo anche rilasciato modifiche al server nel modo in cui gestiamo il reindirizzamento da "www". a 'non www.' domini, nonché modifiche al modo in cui garantiamo che tutto il traffico sia sicuro e reindirizza a https://.

Oltre a queste modifiche, aggiorneremo anche il file robots.txt per ciascun sito per indicare chiaramente la nuova posizione della mappa del sito e prevenire problemi comuni come l'indicizzazione delle pagine dei risultati di ricerca su alcuni siti Web di marca.

QUALI ALTRE OPZIONI ABBIAMO CONSIDERATO?

Durante il processo decisionale per la nostra nuova configurazione abbiamo avuto diverse opzioni da considerare:
Domini specifici per paese, ad es. https://brandwebsites.es
Sottodomini su un gTLD, ad esempio https://fr.brandwebsites.com
Sottodirectory su un gTLD, ad esempio https://brandwebsites.com/el/
La nostra configurazione attuale, ad esempio come esempio 3 ma senza sito a livello di root, ad esempio https://brandwebsites.com/us/
Parametri URL, ad es. https://brandwebsites.com?lang=de

Perché non siamo rimasti con la configurazione attuale?

Abbiamo immediatamente ignorato la nostra configurazione attuale, perché non avere un sito a livello di root causava una serie di problemi:

• Gli utenti venivano spesso reindirizzati dal dominio di livello principale a una sottodirectory della lingua, rallentando il tempo di caricamento. Ciò è stato causato da una combinazione di vecchi collegamenti interni, collegamenti esterni senza cartelle della lingua o utenti che visitano direttamente il dominio tramite il browser.
• Google si aspetta che un sito Web esista a livello di root. In effetti, le classifiche di marca per il sito venivano mostrate su Google come https://brandwebsites.com anche se qui non esisteva alcuna pagina. Non stavamo semplificando il suo lavoro e questo si rifletteva nelle classifiche dei marchi per il sito statunitense di molti dei nostri marchi.
• La verifica di un dominio richiede spesso che un tag appaia sulla home page; questo può essere utilizzando l'impostazione di strumenti social o webmaster. Mentre potremmo aggirare alcuni convalidando utilizzando un altro metodo come le voci DNS, con altri non abbiamo potuto e questo ci ha causato alcuni problemi con l'integrazione sociale.
• Stavamo confondendo il targeting per lingua e Paese e rendevamo le cose più difficili del necessario per gli utenti. Ad esempio, la nostra directory spagnola è stata impostata sulla locale es_ES mentre gran parte del traffico proveniva effettivamente da utenti spagnoli in Messico (es_MX). Questa è stata l'impostazione di hreflang=“es_ES”, mentre hreflang=“es” per coprire tutti i paesi di lingua spagnola potrebbe essere stata più efficace per la SEO. Ma questo creerebbe i suoi problemi con la personalizzazione del carrello in termini di bandiere locali e fornitori di spedizioni.

In poche parole, dovevamo essere in grado di personalizzare il sito in base alla posizione dell'utente, quindi dovevamo separare il targeting per lingua e Paese.

Con questi quattro punti in mente, siamo stati immediatamente in grado di ignorare la nostra configurazione attuale e cercare alternative che ci avrebbero portato il livello di flessibilità di cui avevamo bisogno.

Parametri URL: perché sono un'idea terribile?

La successiva opzione ovvia che non volevamo nemmeno considerare era che le lingue venivano impostate come parametri URL. L'ovvia ragione di ciò è semplicemente che non puoi geo-targeting delle lingue separate negli strumenti per i webmaster.

Inoltre, è estremamente difficile per gli utenti riconoscere il sito Web e atterrare manualmente sul dominio corretto e abbiamo anche avuto dubbi sul mantenimento della lingua del sito in cui si trovava un utente e, in generale, sulla gestione efficace dei collegamenti interni.

Ci sono alcune situazioni in cui i parametri URL possono funzionare, ma questo tende ad essere quando sei meno preoccupato per la SEO e stai filtrando manualmente il traffico della pagina di destinazione. Ad esempio, i siti Web guidati interamente dal traffico di affiliazione che non si aspettano molto in termini di supporto del traffico SEO possono prosperare con una configurazione della lingua dei parametri URL.

Soppesando le opzioni rimanenti: quali erano i pro ei contro?

Quindi ci sono rimaste tre opzioni disponibili da considerare:

1. Domini specifici per paese
2. Sottodomini su un gTLD
3. Sottodirectory su un gTLD

Ognuna di queste opzioni ha i suoi pro e contro e voglio chiarire che non esiste una soluzione perfetta. Sebbene i SEO di tutto il mondo molto probabilmente saranno sostenitori di una di queste opzioni rispetto a tutte le altre, è una scelta completamente situazionale che richiede la considerazione di molteplici fattori:

• L'impatto sulle risorse del tuo team di marketing digitale
• Il costo per impostare e mantenere la soluzione
• In che modo viene influenzata l'esperienza dell'utente
• Il potenziale impatto sui motori di ricerca

Questi fattori possono essere ulteriormente suddivisi in più elementi che dovrebbero essere considerati per ciascuna opzione e la tabella seguente li riassume. Tuttavia, tieni presente che il valore di questi elementi per il tuo sito Web o organizzazione è qualcosa di completamente personale per la tua situazione.

L'importanza di questi dodici elementi varia notevolmente a seconda della situazione. Questo è il motivo per cui in definitiva non esiste una soluzione adatta a tutti per il targeting per lingua e paese. Piuttosto, è un giudizio che richiede un'attenta considerazione poiché la tua decisione avrà un impatto sul tuo sito Web e sulla capacità di cambiarlo negli anni a venire.

LE NOSTRE CONCLUSIONI

Da una prospettiva puramente SEO, esistono rischi associati alla separazione di un sito in più domini e il più grande di questi è l'effetto sconosciuto di più domini sui backlink. Tuttavia, Google è diventato molto più dettagliato nel modo in cui tratta i collegamenti, quindi sarebbe saggio concludere che presta maggiore attenzione ai collegamenti locali specifici di nicchia quando determina le classifiche in un paese specifico.

Ma i vantaggi CRO del cambiamento superano i rischi legati a qualsiasi lavoro SEO aggiuntivo necessario per garantire il posizionamento. L'utilizzo dei domini per scegliere come target un Paese e la separazione del targeting per lingua e località consente un approccio molto più accurato al targeting degli utenti del sito.

Inoltre, c'è qualche vantaggio SEO nella separazione in quanto aiuta a prevenire alcuni dei problemi che abbiamo riscontrato con il posizionamento del sito del paese sbagliato in una posizione specifica. Ad esempio, abbiamo visto abbastanza frequentemente il posizionamento del principale sito in lingua inglese degli Stati Uniti al posto della versione localizzata, ad esempio la cartella /can/ in Canada. Ci aiuterà anche in futuro a velocizzare il sito in paesi specifici, dove la domanda è considerata sufficientemente ampia, ospitando domini su server specifici per località separati.

Molte organizzazioni hanno implementato domini specifici per paese separati nello stesso modo in cui abbiamo fatto noi, inclusi Google, Amazon e Wikipedia (sottodomini). Poiché i nostri siti Web sono siti di e-commerce, li rende candidati ideali per questo livello di separazione che richiede la variazione del paese e della lingua per l'utente. Inoltre, la preoccupazione di contenuti duplicati può essere prevenuta attraverso un corretto markup hreflang e seguendo i consigli di Google sui contenuti duplicati sui siti internazionali.

QUELLO CHE VIENE DOPO?

Abbiamo completato la prima fase delle nostre modifiche ai siti Web e ora stiamo cercando di migliorare:

1. Markup Hreflang: in alcuni punti il ​​plug-in che stiamo utilizzando sembra causare problemi senza tag di ritorno. Ciò significa in effetti che non tutti i siti di varianti linguistiche e nazionali fanno riferimento a vicenda. Questo deve includere un auto-riferimento con la pagina che si collega a se stessa con il markup hreflang.
2. Espandi le variazioni della lingua una volta ottenuto un maggiore controllo su hreflang. Un perfetto esempio di ciò sarebbe creare una versione franco-canadese del sito, che sarebbe una sottodirectory nel dominio canadese. Possiamo anche cercare di spostare le variazioni di lingua non specificate della posizione predefinita su brandwebsites.com e avere più lingue sul dominio, ad esempio:
   1. <link rel=”alternate” href=”https:// uk.brandwebsites.com/ ” hreflang=”en-GB” />

   <link rel=”alternate” href=”https:// ca.brandwebsites.com/ ” hreflang=”en-ca” />

   <link rel=”alternate” href=”https:// au.brandwebsites.com/ ” hreflang=”en-au” />

   <link rel=”alternate” href=”https:// brandwebsites.com/ ” hreflang=”en-US” />

   <link rel=”alternate” href=”https:// brandwebsites.com/” hreflang=”en” />

   <link rel=”alternate” href=”https://brandwebsites.es/ ” hreflang=”es-ES” />

   <link rel=”alternate” href=”https://brandwebsites.com/es/” hreflang=”es” />

3. Più siti in lingua con procedure di pagamento su misura per il paese, inclusi fattori di fiducia come fornitori di consegna locali e bandiere. Inizia anche a esaminare gli split test specifici per paese, se del caso, poiché il comportamento dell'acquirente e le aspettative UX variano a livello globale.

Anche se queste informazioni potrebbero non aiutare i nostri affiliati direttamente con la SEO internazionale, dovrebbero darti un sacco di spunti di riflessione quando si tratta di creare il tuo sito Web multilingue.