SEO internazionale: come strutturare le pagine dedicate a più paesi

Introduzione

La maggior parte dei consigli SEO parte dal presupposto che ci sia un solo sito, una sola lingua e un solo mercato. Nel momento in cui un prodotto si rivolge a utenti in più di un paese, questi consigli iniziano a vacillare. All'improvviso ci si ritrova a destreggiarsi tra:

• contenuti duplicati su pagine quasi identiche,
• motori di ricerca che mostrano la versione sbagliata agli utenti sbagliati,
• una struttura del sito che aveva senso al momento del lancio ma che diventa un ostacolo quando si espande.

I team che gestiscono bene questa situazione tendono ad avere un'abitudine in comune: definiscono il targeting per paese a livello di architettura prima ancora che qualcuno scriva una sola parola di contenuto. Se la struttura è corretta, ogni pagina pubblicata in seguito ne erediterà le caratteristiche. Se invece si commette un errore, ci vorranno anni per districarsi tra URL canonici e posizionamenti sbagliati.

Questa guida illustra le strutture che funzionano, il markup che le tiene insieme e il flusso di lavoro per verificare che ogni versione per paese si posizioni effettivamente dove dovrebbe.

Il targeting per paese inizia dall’URL

La stessa documentazione di Google sulla gestione dei siti multiregionali illustra le opzioni realistiche: domini specifici per paese, sottodomini, sottodirectory e parametri URL. L’ultima opzione è contrassegnata come “non raccomandata”, il che lascia tre valide alternative:

• I domini con codice paese (esempio.de, esempio.fr) inviano il segnale di geotargeting più chiaro, ma ciascuno può rivolgersi solo a un singolo paese, e ogni dominio che aggiungi divide la tua autorità e moltiplica il lavoro di manutenzione.
• I sottodomini sono facili da configurare, ma spesso gli utenti non riescono a capire dall’URL se “de” si riferisca alla lingua tedesca o al mercato tedesco.
• Le sottodirectory su un unico dominio globale concentrano l’autorità in un unico punto e riducono al minimo la manutenzione, motivo per cui sono diventate la scelta predefinita per la maggior parte dei prodotti internazionali.

Non esiste una scelta universalmente corretta. Esiste solo la scelta che si adatta alla vostra attività: quanti mercati servite, se le entità giuridiche differiscono da paese a paese e quanto tempo di sviluppo potete dedicare al mantenimento di strutture parallele.

Qualunque struttura scegliate, sceglietela una volta per tutte. Spostare un sito consolidato dai sottodomini alle sottodirectory, o consolidare una serie di domini nazionali, comporta la mappatura dei reindirizzamenti, una nuova scansione e mesi di posizionamenti instabili mentre i motori di ricerca ricostruiscono la loro visione del sito. I team che cambiano struttura a metà percorso di solito lo fanno perché la decisione originale è stata presa per default piuttosto che intenzionalmente. Metti per iscritto la decisione, includendo i compromessi che hai accettato, in modo che la prossima persona che erediterà il sito capisca perché la struttura è così com’è.

Il modello hub-and-spoke per un unico prodotto in molti mercati

Il caso più complesso è quello di un singolo prodotto che esiste in versioni diverse a seconda del paese. Il modello che si adatta meglio è quello “hub-and-spoke”: un unico hub canonico del prodotto, da cui si diramano pagine a livello nazionale costruite a partire da un modello condiviso, ciascuna localizzata nei dettagli che contano.

Le piattaforme di viaggio lo fanno con le pagine dedicate alle destinazioni, le aziende SaaS lo fanno con le pagine dei prezzi per paese, e questo modello va ben oltre il settore tecnologico. Anche gli operatori di scommesse lo utilizzano: la sezione “Lucky Numbers” su Hollywoodbets, una piattaforma di scommesse sudafricana, si ramifica in pagine a livello nazionale per un unico prodotto a quota fissa incentrato sulle estrazioni della lotteria di decine di paesi (un prodotto di scommesse destinato a un pubblico che ha raggiunto l’età legale per il gioco d’azzardo nei mercati regolamentati). Un prodotto, un modello, un URL centrale e una pagina secondaria per ogni mercato coperto dai contenuti.

I settori regolamentati sono esemplari in questo senso proprio perché non possono permettersi ambiguità strutturali: l’architettura deve rendere inequivocabile quale pagina sia destinata a quale pubblico.

La logica SEO di questo modello è semplice:

• L’hub accumula link e autorità per il termine principale.
• I "raggi" ereditano l’equità dei link interni e intercettano le query a coda lunga modificate in base al Paese.
• Il modello condiviso consente di verificare e migliorare centinaia di pagine ottimizzando un unico layout.

Hreflang, passo dopo passo

La struttura indica ai motori di ricerca cosa esiste; hreflang indica loro a chi è destinata ciascuna versione. La guida di Google alle versioni localizzate delle pagine elenca tre modi equivalenti per dichiararle: tag di collegamento nell’intestazione HTML, intestazioni HTTP o una mappa del sito XML. Utilizzarne più di uno non apporta alcun vantaggio aggiuntivo nella ricerca, quindi scegliete quello che il vostro stack gestisce in modo più affidabile e mantenete la coerenza.

Tre regole prevengono la maggior parte dei disastri legati a hreflang:

1. Rendilo reciproco. Se la pagina del Regno Unito punta alla pagina tedesca, la pagina tedesca deve puntare a sua volta alla pagina del Regno Unito. Le annotazioni che non vengono restituite potrebbero essere ignorate, e un singolo tag di ritorno mancante può compromettere silenziosamente un intero cluster.
2. Imposta sempre un x-default. Il valore x-default riservato intercetta gli utenti la cui lingua e regione non corrispondono a nessuna delle tue versioni, ed è la destinazione corretta per qualsiasi pagina di selezione del paese.
3. Annotate ogni pagina, compresa se stessa. Hreflang funziona a livello di pagina, quindi ogni pagina del cluster elenca il proprio URL oltre a tutte le sue alternative. La creazione di un modello per questo è esattamente il tipo di lavoro che appartiene al layout a raggiera piuttosto che alla memoria di qualcuno.

Prestate attenzione anche ai codici stessi. I valori hreflang combinano un codice lingua con un codice regione opzionale, e i due risolvono problemi diversi:

• en-GB e en-US possono puntare a due pagine nella stessa lingua localizzate per mercati diversi;
• un semplice "es" può coprire gli utenti di lingua spagnola ovunque non sia disponibile una versione specifica per paese.

Un codice di regione da solo non è valido, e anche codici che sembrano plausibili possono non funzionare: la documentazione di Google sottolinea che «UK» non è un codice di regione valido, quindi «en-UK» non ha alcun effetto laddove «en-GB» funziona. Errori come questi sono uno dei motivi più comuni per cui le annotazioni falliscono silenziosamente la convalida.

L’hreflang è un’operazione tecnica di routine, ma fa la differenza tra il fatto che le vostre pagine accuratamente localizzate vengano mostrate agli utenti giusti e il fatto che Google debba indovinare.

Le SERP locali sono mondi a sé stanti

Fonte: Magnific

Anche con un’architettura e un markup perfetti, la stessa query produce risultati diversi in paesi diversi. Concorrenti locali, intenzioni di ricerca locali, diverse funzionalità delle SERP e diversi livelli di concorrenza fanno sì che una pagina che si posiziona al terzo posto in un mercato possa trovarsi alla quarta pagina in un altro con contenuti identici.

Ecco perché il lavoro internazionale non può essere gestito basandosi sulla visione dei risultati di una singola località. Controllare la SERP effettiva in ogni paese di destinazione, proprio come fa uno strumento di verifica delle SERP per qualsiasi paese, regione o città che gli indichi, ti mostra la realtà competitiva che ogni pagina “spoke” deve effettivamente affrontare: chi si posiziona, con che tipo di pagina e quali funzionalità della SERP si frappongono tra te e i clic.

Spesso la lezione è scomoda. Una pagina “spoke” scarsa e basata su un modello predefinito, che funziona bene in un mercato poco competitivo, potrebbe aver bisogno di contenuti realmente locali, riferimenti locali e link locali per competere in un mercato affollato. Considerate il modello come la base di partenza che ogni mercato riceve il primo giorno, poi lasciate che sia la SERP in tempo reale a dirvi quali pagine “spoke” meritano un investimento maggiore. In pratica, questo di solito significa:

• una manciata di mercati prioritari ottiene sezioni personalizzate, dati locali e link building dedicata;
• la coda lunga dei mercati più piccoli utilizza il modello condiviso finché i numeri non giustificano un approccio diverso.

La ricerca delle parole chiave ricomincia da zero in ogni mercato

La seconda trappola è dare per scontato che il tuo elenco di parole chiave sia trasferibile. La traduzione diretta non coglie il punto: gli utenti di paesi diversi non usano solo parole diverse; effettuano ricerche con intenti diversi e volumi diversi. Una categoria di prodotto che in un mercato è un termine principale ad alto volume può essere una query di nicchia in un altro, e il termine colloquiale che genera tutto il traffico potrebbe non avere nulla in comune con la traduzione del dizionario.

Ricercare ogni mercato da zero con uno strumento di ricerca delle parole chiave che supporti dati specifici per località è l’unico approccio affidabile. Il tempo necessario è reale, ma vi garantisce un vantaggio: i concorrenti che traducono automaticamente il loro targeting per parole chiave lasciano interi spazi di ricerca locali senza concorrenza.

È anche qui che il modello «hub-and-spoke» dà i suoi frutti una seconda volta. Poiché ogni «spoke» è una pagina a sé stante, può puntare al termine locale anziché a quello tradotto, senza interferire con il resto del cluster.

Misurate per mercato, altrimenti state tirando a indovinare

Fonte: Magnific

L’ultimo aspetto fondamentale è la misurazione. Le classifiche globali medie nascondono tutto ciò che devi sapere: una posizione che si è “migliorata” in media potrebbe essere crollata nel tuo mercato più importante, mentre è salita in tre mercati irrilevanti.

Monitorare le posizioni per paese e per parola chiave in uno strumento di monitoraggio del posizionamento trasforma l’architettura in un ciclo di feedback. Ogni pagina “raggio” ottiene il proprio quadro di controllo, e i problemi strutturali si rivelano come schemi ricorrenti:

• Se ogni "raggio" ha un rendimento insufficiente in un paese, sospetta che il problema sia nei segnali di targeting o nell’hreflang.
• Se una sezione ha prestazioni inferiori alle aspettative ovunque, sospettare della pagina stessa.

Questa logica diagnostica funziona solo se i dati sono segmentati per località fin dall’inizio; ecco perché il monitoraggio per singolo mercato deve far parte della checklist di lancio, piuttosto che della fase di revisione sei mesi dopo.

Un ritmo settimanale pratico per un prodotto presente in più paesi si presenta così:

1. Esamina l’andamento per paese delle pagine che generano entrate.
2. Confronta le lacune più evidenti con la SERP locale in tempo reale.
3. Segnala le pagine in cui la concorrenza locale presenta pagine strutturalmente migliori.
4. Metti in coda il lavoro di localizzazione dove i dati indicano che ne varrà la pena.

Per approfondire gli aspetti linguistici di questo lavoro, la guida di Ranktracker all’ottimizzazione di un sito web per altre lingue tratta il livello dei contenuti che si sovrappone all’architettura qui descritta.

Modalità di errore comuni che vale la pena verificare

Prima di pubblicare qualsiasi struttura multinazionale, è opportuno effettuare un audit per individuare gli errori che compaiono in quasi tutte le analisi post-mortem relative alla SEO internazionale:

• Segnali contrastanti. Un ccTLD che punta hreflang verso sottodirectory di un dominio diverso, oppure pagine nazionali canonicalizzate verso l’hub globale, il che comunica implicitamente a Google che le pagine secondarie sono duplicati che non meritano di essere posizionate.
• Reindirizzamenti automatici basati sull'IP. Impediscono sia agli utenti che ai crawler di accedere alle versioni che effettivamente desideravano. Il consiglio di Google è di evitare i reindirizzamenti automatici e di collegare le diverse versioni tra loro in modo che gli utenti possano scegliere quella di cui hanno bisogno, poiché il rilevamento della posizione basato sull'IP è in primo luogo inaffidabile.
• Testi standard non tradotti. Menu, piè di pagina e flussi di checkout lasciati in un’altra lingua su una pagina altrimenti localizzata minano sia la fiducia degli utenti sia i segnali linguistici della pagina.

Nessuno di questi è insolito. Sono ciò che accade quando un team localizza i testi senza mai rivedere la struttura sottostante, e ciascuno di essi è facile da individuare in un audit ma costoso da scoprire in un report sui posizionamenti.

La struttura è la strategia

La SEO multinazionale premia i team che svolgono con costanza attività apparentemente banali:

• una struttura URL ben definita;
• un modello «hub-and-spoke» ben strutturato per ogni prodotto;
• hreflang reciproci con un x-default;
• ricerca delle parole chiave mercato per mercato;
• monitoraggio del posizionamento per paese che chiude il cerchio.

Gli esempi sono ovunque, basta cercarli: dalle pagine dei prezzi dei servizi SaaS ai siti dedicati alle estrazioni della lotteria, e tutti insegnano la stessa lezione. Le pagine non si posizionano ovunque perché il contenuto è brillante ovunque. Si posizionano ovunque perché la struttura non lascia mai aperta all’interpretazione la domanda “a chi è rivolta questa pagina?”.