Hreflang PrestaShop : correspondances linguistiques et validation

Notre approche

Nous identifierions la cause d'une alternative erronée ou manquante avant de choisir un module. La méthode dépend de votre thème actuel, des modules SEO, des intégrations qui importent des traductions ou modifient les URL, des correspondances du catalogue, des marchés et de l'équipe qui les entretient. Consignez les pages qui doivent être équivalentes et le composant qui publie actuellement cette relation.

Effectuez la modification sur une copie de préproduction de cet environnement. Gardez-la privée et exclue des moteurs de recherche, répétez les contrôles des correspondances et de la sortie, et sauvegardez les réglages et modèles précédents. Convenez d'un créneau de bascule et des étapes de retour arrière, puis vérifiez les pages publiques après le déploiement. Les contrôles en préproduction valident la structure ; les hôtes définitifs et l'indexabilité doivent encore être vérifiés sur les pages en production. Ne publiez jamais d'URL de préproduction dans les alternatives ou sitemaps de production.

Si le routage multilingue, les canoniques et les correspondances des alternatives sont en conflit, le service PrestaShop SEO Audit & Action Plan fournit une analyse et des corrections hiérarchisées pour votre développeur ; la mise en œuvre est distincte.

Comprendre le rôle de hreflang

Hreflang identifie les versions linguistiques ou régionales équivalentes d’une page. Il aide les moteurs à choisir la version adaptée ; il ne traduit pas, n’impose pas de classement et ne regroupe pas les traductions en une seule page canonique.

Un contenu principal entièrement traduit n’est pas dupliqué du seul fait de sa traduction. Les textes copiés dans la langue source et les doublons régionaux de même langue nécessitent leur propre examen de contenu et de canonique. Utilisez des URL linguistiques distinctes et laissez les personnes changer explicitement de langue. Consultez les consignes Google sur les sites multilingues.

Hreflang est recommandé lorsque vous voulez exprimer cette relation, pas obligatoire pour toute boutique multilingue. Google peut découvrir les versions sans lui. Contenu médiocre, traductions manquantes, URL bloquées et routage confus sont des problèmes distincts.

Inspecter d’abord la sortie native PrestaShop

PrestaShop moderne construit une carte d’URL alternatives pour les langues actives de la boutique actuelle. Dans PrestaShop 9, la carte est indexée par language_code et utilise Link::getLanguageLink(). Le thème doit réellement la rendre dans l’en-tête HTML. Un template partiel d’en-tête surchargé peut la supprimer ou la dupliquer.

Classic et Hummingbird proposent des intégrations modernes, mais vérifiez les versions installées. Classic est resté le thème par défaut en 9.0 ; Hummingbird l’est devenu en 9.1. L’en-tête default-bootstrap de PrestaShop 1.6 ne fournit pas le même bloc moderne d’alternatives. Ne supposez pas une sortie identique entre ces générations.

Le code ISO de la langue participe au routage des URL, tandis que language_code fournit la clé native de la carte des alternatives. La locale est un champ distinct. Corrigez les mauvaises valeurs dans leur configuration réelle, puis vérifiez la sortie ; changer l’une ne garantit pas l’exactitude de l’autre.

Les URL de boutique appartiennent aux boutiques, pas aux langues individuelles. Les sous-dossiers peuvent utiliser le routage multilingue natif. Des domaines ou sous-domaines linguistiques distincts exigent un multiboutique ou routage personnalisé adapté. Les liens natifs d’une boutique unique ne découvrent pas automatiquement les produits équivalents sur des domaines de boutiques sans rapport.

Dans les versions utilisant ces intitulés de menu, examinez International → Localisation → Langues pour les champs linguistiques et Paramètres de la boutique → Trafic & SEO → SEO & URL pour les réglages d'URL. Définir l'URL de la boutique concerne l'adresse de la boutique. Consignez le contexte de boutique et les valeurs actuels avant toute modification ; changer un chemin linguistique établi nécessite aussi un plan de redirection et de mise à jour des liens internes.

Construire des groupes de pages réciproques

Utilisez des codes de langue valides, éventuellement avec une région prise en charge : en-GB, pas en-UK ; cs pour le tchèque, pas cz. Pointez vers la page réellement équivalente avec son URL complète. Chaque version participante doit se référencer et renvoyer vers ses partenaires. Google peut traiter des sous-ensembles réciproques ; une annotation manquante ailleurs n’invalide pas toutes les paires fonctionnelles. Consultez les règles Google sur les versions alternatives.

Pour un produit en anglais, allemand et français, le même ensemble participant doit figurer dans l’en-tête de chaque page :

<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 est un repli facultatif, par exemple un sélecteur de langue ou une version générale choisie. Son absence n’invalide pas l’ensemble linguistique. Si vous l’utilisez, gardez sa destination adaptée et accessible. Consultez l’explication de x-default par Google.

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

Gardez la canonique habituelle de chaque vraie traduction dans sa langue. Résolvez redirections inattendues, noindex, erreurs ou canoniques contradictoires avant de vous fier au groupe. Hreflang ne rend pas indexable une destination inéligible.

Pour les boutiques régionales, associez explicitement les entités équivalentes. Des identifiants numériques identiques entre boutiques ne sont sûrs que s’ils représentent le même article ou contenu. Déterminez la destination de chaque code langue/région si plusieurs boutiques le proposent. Ne reliez jamais un produit non traduit à l’accueil pour simplement remplir une case.

Les balises d’en-tête HTML et annotations de sitemap XML peuvent exprimer ces relations. Si vous utilisez les deux, gardez leurs correspondances cohérentes. Une entrée de sitemap doit inclure l’URL actuelle et les alternatives pertinentes avec les espaces de noms XML requis ; inspectez toutes les entrées participantes plutôt que d’ajouter un seul lien étranger unidirectionnel.

Exemple : une erreur de correspondance régionale

Vos boutiques britannique et américaine vendent la même lampe en anglais, mais les imports du catalogue ont créé des fiches produit différentes. Une correspondance fondée sur l'égalité des identifiants numériques relie la lampe britannique à un abat-jour américain. Les codes en-GB et en-US peuvent être valides alors que la relation est erronée.

Confirmez l'équivalence à l'aide d'une référence stable du catalogue et du contenu réel du produit, corrigez la correspondance, puis examinez les deux destinations et leurs liens retour. Si la lampe américaine n'est pas publiée, retirez son entrée alternative des pages participantes et des annotations de sitemap activées jusqu'à ce qu'elle soit prête. Ajoutez ce cas aux contrôles après import du catalogue : un robot peut signaler des relations rompues sans reconnaître que deux pages valides vendent des articles différents.

Choisir une implémentation et réserver la configuration à l’aide du module

Désignez un seul responsable de l'ensemble d'alternatives de chaque page et vérifiez son intégration avec la sortie réelle du thème.

Pour les connexions multiboutiques automatiques, groupes manuels Local/Shared, lignes source/destination, exclusions, aperçus de brouillon, propriété et exigences de licence, suivez la page d’aide Hreflang Tags Manager.

Pour les réglages hreflang, motifs d’URL, aperçus, redirections d’historique d’URL et sitemaps linguistiques générés, suivez la page d’aide SEO Revolution.

Hreflang Tags Manager couvre les pages d’entités prises en charge et omet ses ensembles générés pour la recherche, les résultats filtrés et les pages de liste après la première. Dans les réponses réussies, les pages de compte, de passage de commande et de modules conservent les alternatives fournies par leurs propres contrôleurs et par le thème. Les attributions manuelles priment sur les connexions automatiques. Destinations personnalisées et correspondances dynamiques exigent toujours des contrôles de liens retour. Les canoniques restent un sujet distinct.

Lorsque SEO Revolution gère la sortie hreflang, le gestionnaire autonome reste silencieux. La suite exige au moins deux alternatives éligibles, dont la page actuelle ; sa sortie x-default dépend de l'éligibilité persistante de l'URL par défaut choisie. Son code privilégie language_code et peut se rabattre sur la locale. Les fonctions d'en-tête et de sitemap possèdent leurs propres contrôles et critères d'éligibilité. Répétez les contrôles de sortie après les changements de thème, car les balises générées par le module dépendent toujours de l'intégration du thème.

Valider les pages réelles après modification

1. Choisissez un vrai produit entièrement traduit. Récupérez la réponse HTML ou affichez le code source, puis inspectez les liens alternatifs de l’en-tête. Vérifiez le composant qui les fournit.
2. Ouvrez chaque cible. Confirmez URL finale, langue visible, statut de réponse, directive robots et canonique. Vérifiez le code langue/région réel face au public visé.
3. Comparez les ensembles. Vérifiez autoréférences et liens retour des pages participantes. Considérez x-default comme facultatif et validez sa cible s’il existe.
4. Recommencez pour accueil, catégories, CMS, marques et fournisseurs participants. Les types de page volontairement non pris en charge par un module n’exigent pas de correspondances inventées.
5. Inspectez le XML généré si les annotations de sitemap sont activées. Comparez ses URL aux balises d’en-tête et aux destinations du sélecteur de langue.
6. Utilisez un robot sur l’inventaire d’URL prévu pour repérer codes invalides, redirections, paires unidirectionnelles, sorties dupliquées et cibles inéligibles. Consignez les exceptions plutôt que de supposer que chaque page doit participer.
7. Répétez après changement de domaines, réglages linguistiques, slugs, templates d’en-tête, responsabilité SEO ou génération du sitemap.

Des annotations absentes ou inutilisables peuvent être ignorées ou ne pas établir de relation. Vérifiez les correspondances affectées et corrigez les annotations inutilisables.

Si une ancienne destination subsiste après une correction, comparez une réponse actualisée au HTML en cache et identifiez la couche de cache avant de modifier d'autres correspondances. Vider le cache de votre navigateur ne vide pas le HTML du serveur ou du CDN. Si des balises manquent, comparez le même type de page dans le thème installé et sa surcharge d'en-tête avant de supposer que les données linguistiques sont absentes.

Pour préparer les contenus et devises derrière ces URL, consultez le guide des traductions et de la vente internationale.

Planifier la bascule et la transmission

1. Conservez le HTML et les réglages de correspondance avant et après pour les pages de test convenues, y compris une exclusion volontaire. Gardez la configuration de sortie précédente prête à restaurer.
2. Déployez ensemble les réglages approuvés et les modifications des modèles, actualisez les caches concernés et régénérez les sitemaps activés. Répétez la validation ci-dessus sur les URL publiques avant de donner votre accord.
3. Transmettez à la personne qui entretient la boutique le responsable de la sortie, les règles de correspondance, les exclusions, les URL de test et les consignes de retour arrière. Répétez les contrôles pertinents lorsqu'elle modifie une langue ou importe des données du catalogue.

Questions à poser à votre développeur ou agence

• Comment les fiches équivalentes sont-elles associées entre boutiques, et que se passe-t-il lorsqu'une traduction est dépubliée ou qu'un import remplace une fiche ?
• Quelle surcharge de thème ou quel module contrôle l'en-tête, et quels réglages contrôlent les annotations de sitemap ?
• Qui vérifie les ajouts de langues et les changements de domaines, et quels constats déclencheront un retour arrière ?

Questions des propriétaires de boutiques

Dois-je passer à des domaines distincts pour corriger hreflang ?

Non. Une configuration fonctionnelle en sous-dossiers peut exprimer les alternatives linguistiques. Choisissez les domaines selon votre marché et l'architecture de la boutique ; déplacer des URL établies ajoute un travail de migration qu'une correction des balises ne nécessite pas forcément.

Hreflang peut-il remplacer le sélecteur de langue ou rediriger les visiteurs ?

Non. Conservez un sélecteur utilisable qui mène à la page équivalente. Les redirections automatiques selon la langue ou la localisation nécessitent un examen distinct : elles peuvent empêcher les visiteurs et les robots d'atteindre l'URL demandée.

Quand Google affichera-t-il la version corrigée ?

Il n'existe pas de délai fixe. Conservez le HTML corrigé et les résultats d'exploration comme preuves techniques ; les résultats de recherche dépendent d'une nouvelle exploration et du choix de Google. Un classement inchangé ne suffit pas à établir la validité d'une annotation.