Hreflang PrestaShop: mappature linguistiche e validazione

Cosa faremmo noi

Individueremmo la causa di un'alternativa errata o mancante prima di scegliere un modulo. La soluzione dipende dal tema esistente, dai moduli SEO, dalle integrazioni che importano traduzioni o cambiano URL, dalle mappature del catalogo, dai mercati e dal team che li mantiene. Registra quali pagine devono essere equivalenti e quale componente pubblica attualmente quella relazione.

Esegui la modifica su una copia di staging di quella configurazione. Mantieni lo staging privato ed escluso dai motori di ricerca, prova i controlli su mappature e output e salva impostazioni e template precedenti. Concorda una finestra di passaggio e i passaggi di ripristino, poi verifica le pagine pubbliche dopo la distribuzione. I controlli in staging dimostrano la struttura; host finali di produzione e indicizzabilità vanno comunque verificati sulle pagine in produzione. Non pubblicare mai URL di staging nelle alternative o nelle sitemap di produzione.

Se routing multilingue, canonical e mappature delle alternative sono in conflitto, PrestaShop SEO Audit & Action Plan offre un'analisi e correzioni in ordine di priorità per il tuo sviluppatore; l'implementazione è separata.

Comprendi cosa fa hreflang

Hreflang identifica versioni linguistiche o regionali equivalenti di una pagina. Aiuta i motori di ricerca a scegliere una versione appropriata; non traduce i contenuti, non impone posizionamenti e non unisce le pagine tradotte in un'unica pagina canonica.

Il contenuto principale interamente tradotto non è contenuto duplicato solo perché tradotto. Il testo copiato nella lingua sorgente e le duplicazioni regionali nella stessa lingua richiedono una propria revisione di contenuti e canonical. Usa URL linguistici separati e consenti alle persone di cambiare lingua esplicitamente. Consulta le indicazioni Google sui siti multilingue.

Hreflang è consigliato quando devi esprimere quella relazione, non è obbligatorio per ogni negozio multilingue. Google può scoprire le versioni linguistiche anche senza. Contenuti scadenti, traduzioni mancanti, URL bloccati e routing confuso sono problemi separati.

Esamina prima l'output nativo di PrestaShop

Il PrestaShop moderno crea una mappa di URL linguistici alternativi per le lingue attive nel negozio corrente. In PrestaShop 9, la mappa usa come chiave language_code e utilizza Link::getLanguageLink(). Il tema deve effettivamente renderla nell'head. Un parziale head sovrascritto può rimuoverla o duplicarla.

Classic e Hummingbird forniscono integrazioni moderne del tema, ma verifica le versioni installate. Classic è rimasto il predefinito nella 9.0; Hummingbird lo è diventato nella 9.1. L'header di default-bootstrap in PrestaShop 1.6 non fornisce lo stesso blocco moderno delle alternative. Non presumere un output identico tra queste generazioni.

Il codice ISO della lingua partecipa al routing degli URL, mentre language_code fornisce la chiave della mappa nativa delle alternative. Locale è un campo separato. Correggi i valori errati nella loro configurazione effettiva, poi controlla l'output renderizzato; modificare uno non garantisce che l'altro sia corretto.

Gli URL del negozio appartengono ai negozi, non alle singole lingue. Le sottocartelle possono usare il routing multilingue nativo. Domini o sottodomini linguistici separati richiedono un multinegozio o routing personalizzato adatti. I link linguistici nativi di un singolo negozio non scoprono automaticamente prodotti equivalenti su domini di negozi non correlati.

Nelle versioni che usano queste etichette di menu, controlla Internazionale → Localizzazione → Lingue per i campi linguistici e Parametri negozio → Traffico & SEO → SEO & URL per le impostazioni URL. Imposta URL negozio riguarda l'indirizzo del negozio. Registra contesto del negozio e valori correnti prima di modificarli; cambiare un percorso linguistico consolidato richiede anche un piano per reindirizzamenti e link interni.

Crea gruppi di pagine con collegamenti reciproci

Usa codici lingua validi, eventualmente con una regione supportata: en-GB, non en-UK; cs per il ceco, non cz. Punta alla pagina effettivamente equivalente usando il suo URL completo. Ogni versione partecipante deve identificare sé stessa e rimandare alle altre. Google può elaborare sottoinsiemi reciproci; un'annotazione mancante altrove non invalida ogni coppia funzionante. Consulta le regole Google sulle versioni alternative.

Per un gruppo di pagine prodotto in inglese, tedesco e francese, lo stesso insieme partecipante deve essere nell'head di ogni pagina:

<link rel="alternate" hreflang="en" href="https://store.example/en/product">
<link rel="alternate" hreflang="de" href="https://store.example/de/produkt">
<link rel="alternate" hreflang="fr" href="https://store.example/fr/produit">

x-default è un fallback facoltativo, per esempio un selettore di lingua o una versione generale scelta. La sua assenza non rende invalido l'insieme linguistico. Se lo usi, mantieni la destinazione adatta e accessibile. Consulta la spiegazione Google di x-default.

<link rel="alternate" hreflang="x-default" href="https://store.example/en/product">

Mantieni il consueto canonical per ogni versione realmente tradotta in quella lingua. Risolvi reindirizzamenti inattesi, noindex, errori o canonical in conflitto prima di affidarti al gruppo. Hreflang non rende indicizzabile una destinazione non idonea.

Per i negozi regionali, mappa esplicitamente le entità equivalenti. ID numerici coincidenti tra negozi sono sicuri solo se rappresentano lo stesso articolo o contenuto. Decidi quale destinazione gestisce ogni codice lingua/regione se più negozi lo offrono. Non mappare mai un prodotto non tradotto a una homepage solo per riempire uno spazio.

Tag nell'head HTML e annotazioni nella sitemap XML possono esprimere queste relazioni. Se usi entrambi, mantieni coerenti le mappature. Una voce della sitemap deve includere l'URL corrente e i riferimenti alternativi pertinenti con i namespace XML richiesti; esamina tutte le voci partecipanti anziché aggiungere soltanto un link estero a senso unico.

Un esempio di errore nella mappatura regionale

I tuoi negozi britannico e statunitense vendono la stessa lampada in inglese, ma le importazioni del catalogo hanno creato record prodotto diversi. Una mappatura basata sulla corrispondenza degli ID numerici collega la lampada britannica a un paralume statunitense. I codici en-GB e en-US possono essere validi anche se la relazione è errata.

Conferma l'equivalenza usando un riferimento stabile del catalogo e il contenuto effettivo del prodotto, correggi la mappatura, poi esamina entrambe le destinazioni e i rispettivi link di ritorno. Se la lampada statunitense non è pubblicata, rimuovi la sua voce alternativa dalle pagine partecipanti e dalle annotazioni sitemap abilitate finché non è pronta. Aggiungi questo caso ai controlli successivi alle importazioni del catalogo: un crawler può segnalare relazioni non funzionanti senza riconoscere che due pagine valide vendono articoli diversi.

Scegli una sola implementazione e mantieni la configurazione nella guida del modulo

Scegli un solo responsabile per l'insieme delle alternative di ogni pagina e verifica la sua integrazione con l'output effettivo del tema.

Per collegamenti multinegozio automatici, gruppi manuali Local/Shared, righe origine/destinazione, esclusioni, anteprime delle bozze, proprietà e requisiti di licenza, segui la pagina di aiuto di Hreflang Tags Manager.

Per impostazioni hreflang, schemi URL, anteprime, reindirizzamenti della cronologia URL e sitemap linguistiche generate, segui la pagina di aiuto di SEO Revolution.

Hreflang Tags Manager copre le pagine delle entità supportate e omette i propri insiemi generati per ricerca, risultati filtrati e pagine di elenco successive alla prima. Nelle risposte riuscite, le pagine account, checkout e moduli mantengono le alternative fornite dai propri controller e dal tema. Le assegnazioni manuali hanno precedenza sui collegamenti automatici. Destinazioni URL personalizzate e mappature dinamiche richiedono comunque controlli dei link di ritorno. La gestione dei canonical resta una questione separata.

Quando SEO Revolution gestisce l'output hreflang, il gestore autonomo non produce output. La suite richiede almeno due alternative idonee, inclusa la pagina corrente; l'output x-default dipende dal fatto che l'URL predefinito selezionato resti idoneo. Il codice preferisce language_code e può ripiegare sul locale. Le funzionalità header e sitemap hanno controlli e verifiche di idoneità propri. Ripeti i controlli sull'output dopo modifiche al tema, perché i tag generati dal modulo dipendono comunque dall'integrazione del tema.

Valida le pagine effettive dopo le modifiche

1. Scegli un prodotto reale con traduzioni completate. Recupera la risposta HTML o usa Visualizza sorgente, poi esamina l'head alla ricerca dei link alternativi. Verifica quale componente li fornisce.
2. Apri ogni destinazione. Conferma URL finale, lingua visibile, stato della risposta, direttiva robots e canonical. Verifica il codice lingua/regione effettivo rispetto al pubblico previsto.
3. Confronta gli insiemi. Verifica autoreferenze e link di ritorno delle pagine partecipanti. Considera x-default facoltativo e validane la destinazione quando presente.
4. Ripeti per homepage, categorie, CMS, marchi e fornitori dove partecipano. I tipi di pagina intenzionalmente non supportati da un modulo non richiedono mappature inventate.
5. Esamina l'XML generato se le annotazioni sitemap sono abilitate. Confrontane gli URL con tag nell'head e destinazioni del selettore lingua.
6. Usa un crawler sull'inventario URL previsto per individuare codici non validi, reindirizzamenti, coppie a senso unico, output duplicato e destinazioni non idonee. Registra le eccezioni anziché presumere che ogni pagina debba partecipare.
7. Ripeti dopo aver modificato domini, impostazioni linguistiche, slug, template head del tema, responsabilità SEO o generazione della sitemap.

Le annotazioni mancanti o inutilizzabili possono essere ignorate o non riuscire a stabilire una relazione. Verifica quali mappature sono interessate e correggi le annotazioni inutilizzabili.

Se una vecchia destinazione rimane dopo una correzione, confronta una risposta aggiornata con l'HTML in cache e individua il livello di cache prima di modificare altre mappature. Svuotare la cache del browser non svuota l'HTML sul server o sulla CDN. Se mancano tag, confronta lo stesso tipo di pagina nel tema installato e nel suo override dell'head prima di presumere che manchino i dati linguistici.

Per la preparazione di contenuti e valute alla base di questi URL, usa la guida alle traduzioni e alla vendita internazionale.

Pianifica il passaggio e la consegna

1. Salva HTML prima e dopo e impostazioni delle mappature per le pagine di test concordate, inclusa un'esclusione intenzionale. Tieni pronta la configurazione precedente dell'output per il ripristino.
2. Distribuisci insieme impostazioni approvate e modifiche ai template, aggiorna le cache interessate e rigenera le sitemap abilitate. Ripeti la validazione descritta sopra sugli URL pubblici prima dell'approvazione finale.
3. Fornisci a chi mantiene il negozio il responsabile dell'output, le regole di mappatura, le esclusioni, gli URL di test e le istruzioni di ripristino. Ripeti i controlli pertinenti quando questa persona modifica una lingua o importa dati del catalogo.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Come vengono associati i record equivalenti tra negozi e cosa succede quando una traduzione non è pubblicata o un'importazione sostituisce un record?
• Quale override del tema o modulo controlla l'head e quali impostazioni controllano le annotazioni sitemap?
• Chi verifica le nuove lingue e le modifiche ai domini e quali riscontri faranno scattare il ripristino?

Domande dei gestori dei negozi

Devo passare a domini separati per correggere hreflang?

No. Una configurazione funzionante con sottocartelle può esprimere le alternative linguistiche. Scegli i domini in base al mercato e all'architettura del negozio; spostare URL consolidati aggiunge un lavoro di migrazione che una correzione dei tag potrebbe non richiedere.

Hreflang può sostituire il selettore di lingua o reindirizzare i visitatori?

No. Mantieni un selettore utilizzabile che colleghi alla pagina equivalente. I reindirizzamenti automatici per lingua o posizione richiedono una valutazione separata: possono impedire a visitatori e crawler di raggiungere l'URL richiesto.

Quando Google mostrerà la versione corretta?

Non esiste una tempistica fissa. Conserva l'HTML corretto e i risultati della scansione come evidenze tecniche; i risultati di ricerca dipendono da una nuova scansione e dalla scelta di Google. Un posizionamento invariato non dimostra da solo se un'annotazione sia valida.