SEO international Shopify : Markets, hreflang et pages par langue

Décidez d’abord s’il vous faut une autre langue, une autre offre, ou les deux.

N’ajoutez pas un second système de balisage avant d’avoir examiné celui qui est déjà en place. Pour une boutique gérée par Shopify, vérifiez d’abord la configuration native des marchés et des langues, ainsi que ce qu’elle génère. Un guide hébergé séparément relève d’une autre surface de publication : être sous le même domaine n’en fait pas une page du thème Shopify.

Ce guide s’adresse aux équipes qui lancent ou corrigent des boutiques régionales et des contenus éditoriaux. Il ne traite pas en profondeur l’héritage des marchés B2B. Dans la suite, « marché » désigne l’expérience régionale dont il est question, sans prétendre que chaque marché Shopify se réduit à une liste de pays.

Avant de commander une traduction, faites valider par le marchand : les pays desservis, les produits proposés, les restrictions de livraison, les consignes de retour et la personne qui répondra aux clients. Ce sont des données d’entrée de la mise en ligne, pas du texte SEO à inventer. Si la réponse manque, réduisez le périmètre de la mise en ligne plutôt que de promettre une couverture mondiale.

Consignez les URL publiques avant de modifier les paramètres de langue.

Conservez les adresses existantes et stables, sauf raison opérationnelle de migrer. Un changement de route génère du travail sur la navigation, les redirections, l’analytics et les liens éditoriaux, même quand le nouveau chemin paraît plus propre. Shopify prend en charge les sous-dossiers, les sous-domaines et les domaines distincts ; la documentation sur les domaines internationaux distingue, sur le marché principal, les dossiers de langue seule des suffixes propres aux marchés secondaires. Ne recopiez pas un chemin hypothétique /fr/ dans une boutique qui sert en réalité /fr-ca/.

Dans le parcours actuel de configuration des marchés, examinez les langues ajoutées à la boutique et les paramètres Domain / language du marché cible. Consignez l’URL produite par cette configuration, et non un chemin deviné à partir du nom de la langue. Traduisez le contenu retenu et testez une page représentative publiée avant d’élargir l’ensemble.

Votre fiche de mise en ligne doit comporter une ligne par relation entre pages : identité de la ressource, langue, périmètre de marché, URL publique actuelle, URL précédente le cas échéant, responsable de la publication et ressource équivalente. Des slugs traduits différents peuvent tout à fait désigner la même ressource. Un simple remplacement de chaîne, comme l’ajout de /fr à chaque URL, ne permet pas d’établir cette relation.

Choisissez la stratégie d’URL en pensant à l’exploitation : qui contrôle le DNS et les certificats, comment les mises en ligne sont coordonnées, comment les changements de politique atteignent chaque langue et quel système a la main sur les redirections. Aucun de ces choix ne dispense d’un contenu utile.

Vous hésitez encore entre sous-dossier, sous-domaine et domaine national ? Shopify Markets : sous-dossier, sous-domaine ou domaine présente les règles propres à Shopify, quatre questions à se poser par marché et les contrôles de lancement.

Identifiez qui génère les balises avant de supprimer quoi que ce soit.

La documentation des thèmes de Shopify décrit la sortie hreflang native via content_for_header, ainsi que les cas qui exigent une implémentation personnalisée. Cela ne signifie pas qu’une route servie par un CMS externe reçoive la même sortie.

1. Relevez le code source actuel des pages. Enregistrez une fiche produit, une page de collection et un article dans chaque langue concernée. Notez chaque URL alternative, la canonical et la réponse observée.
2. Trouvez qui produit les balises. Demandez à l’intégrateur d’identifier la sortie native, les personnalisations du thème, les apps de traduction et ce que génèrent l’edge ou le CMS. Deux occurrences sont un indice à examiner, pas une autorisation de supprimer une source en particulier.
3. Désignez un responsable pour chaque surface. Pour une boutique native, conservez l’implémentation native, sauf exigence documentée imposant un autre responsable. Pour un ensemble réparti sur plusieurs boutiques, démontrez que l’implémentation retenue couvre les deux boutiques.
4. Testez la solution de remplacement avant de basculer. Vérifiez les URL propres à chaque ressource et la réciprocité des relations dans un aperçu sans risque. Ne modifiez la source écartée qu’une fois la source retenue validée ; gardez une copie pour le retour arrière. Ne désactivez pas d’abord les balises natives en espérant qu’une app comble le vide.

Ne supprimez jamais content_for_header pour neutraliser le hreflang. Si une implémentation personnalisée se justifie, utilisez le paramètre prévu et décrit par Shopify, puis testez l’ensemble du thème. Cet article ne vous invite pas à modifier automatiquement votre boutique en production.

Testez une vraie paire de pages, dans les deux sens.

Les consignes de Google sur les pages localisées exigent des références alternatives réciproques, avec des URL complètes, y compris vers la page elle-même. Elles décrivent des variantes ; elles ne traduisent pas le contenu et ne garantissent pas l’indexation. Un chemin d’URL n’est pas un code de langue.

Exemple pédagogique, et non un résultat client : à l’adresse https://example.com/guides/lamp-care se trouve un guide anglais sur l’entretien d’une lampe, dont l’équivalent français est publié à l’adresse https://example.com/fr/guides/entretien-lampe. Les handles diffèrent, mais les deux pages expliquent l’entretien de la même famille de produits. Associez-les par ressource éditoriale, pas par slugs identiques. Ne reliez pas le guide anglais à la page d’accueil de la boutique française en guise de « traduction ».

1. Ouvrez les deux URL directement, en étant déconnecté. Notez l’adresse finale, la langue affichée, le titre et la tâche à laquelle la page répond. Si l’une des deux affiche un écran de connexion, une erreur ou une page de repli sans rapport, arrêtez le test de la paire.
2. Lisez la canonical et la liste des alternatives de chaque page. Dans cet exemple, la canonical visée est l’URL publique du guide lui-même ; les deux pages doivent déclarer les deux mêmes alternatives. Une destination par défaut, facultative, doit avoir une véritable fonction de repli.
3. Utilisez le sélecteur de langue visible depuis le milieu de l’article. Il doit mener au guide correspondant, sans interrompre la lecture. Testez aussi le sens inverse.
4. Vérifiez séparément la canonical sélectionnée par Google. Un head HTML techniquement cohérent constitue votre preuve de mise en ligne, pas la preuve que Google l’a traité.

Pour des pages régionales dans la même langue qui se recoupent largement, définissez la stratégie de canonical visée avant d’imposer une règle d’auto-canonical généralisée. Les consignes de Google sur les sites multirégionaux traitent des doublons régionaux. Les exigences de langue et de marché et la canonicalisation doivent être examinées ensemble.

Un domaine partagé exige tout de même deux responsables de publication.

Une boutique Shopify et un CMS éditorial distinct peuvent partager un domaine public tout en servant des chemins différents. La frontière entre les deux devient alors une responsabilité de mise en ligne, pas une fonction de traduction automatique. Shopify natif reste un choix judicieux quand son flux éditorial suffit.

Par exemple, le guide français indépendant pourrait utiliser /resources/fr/… tandis que la fiche produit en français canadien de la boutique utilise /fr-ca/products/…. Le lien doit provenir d’une table de correspondance validée. Le fait que le guide soit en français ne prouve pas, à lui seul, que le lecteur peut acheter ce produit en France ou au Canada. Proposez le choix du marché quand la destination commerciale est ambiguë.

Avant le déploiement, suivez un parcours guide → produit → page d’assistance dans les deux langues. Testez sans préférences enregistrées, puis avec un choix de langue délibéré. Tenez les réponses du panier et du compte à l’écart de la mise en cache du contenu public. Ce sont des tests de recette techniques ; aucune architecture CMS n’est présentée ici comme un avantage de positionnement.

Diagnostiquez la défaillance observée, pas une pénalité SEO supposée.

La documentation SEO de Markets actuelle de Shopify distingue la redirection native des clients de l’accès des robots d’exploration connus. N’assimilez pas ce comportement à une redirection arbitraire par IP dans un proxy. Si vous exploitez un routage personnalisé, vérifiez son comportement séparément ; un test dans un navigateur ne se fait pas passer pour Googlebot.

En cas d’écart sur la canonical, suivez la procédure de dépannage des URL canoniques de Google. Le statut seul n’établit pas une cause unique et ne prouve pas qu’une traduction manque de mots.

Demandez à un relecteur d’accomplir la tâche, pas de noter la traduction.

Pour un guide d’entretien de lampe, remettez la page publiée au relecteur et demandez-lui : à quel produit s’applique-t-elle ; faut-il couper l’alimentation ; quel matériel de nettoyage est autorisé ; qu’est-ce qui ne doit pas être mouillé ; et à quel moment le lecteur doit-il s’arrêter et contacter l’assistance ? Procurez-vous les instructions réelles du produit avant de fournir ces réponses. Ce sont des questions de relecture, pas des conseils universels d’entretien électrique.

Suivez ensuite le lien vers l’assistance ou le produit. La destination décrit-elle le même modèle et les mêmes conditions pertinentes ? Une phrase fluide associée au mauvais produit reste un défaut de contenu. Notez les faits manquants à part des formulations maladroites, pour que le rédacteur ne fasse pas « disparaître à la traduction » une question de sécurité ou commerciale non résolue.

Relisez le contenu visible, le titre, la description, le texte des images, les liens vers les politiques et les messages d’erreur. Tenez un article non traduit hors de toute relation d’équivalence linguistique tant qu’il ne sert pas réellement ce lecteur. Publier toutes les langues n’est pas le critère d’achèvement.

Clôturez la mise en ligne avec des preuves ; jugez les résultats de recherche plus tard.

Une passation utile contient les URL exactes testées, le marché et la langue, le code source avant/après, la chaîne de réponses, le responsable des balises, les décisions du relecteur et l’emplacement de la copie de retour arrière. Testez une fiche produit, une page de collection et un guide, car ils peuvent être générés par des systèmes différents. Revérifiez après le déploiement plutôt que de vous fier au résultat d’un aperçu.

Distinguez trois résultats : page utilisable (le lecteur peut aller au bout), relation technique (routes et annotations cohérentes) et état observé chez Google (inspection et données de recherche). Aucun ne remplace les autres. Consultez la checklist technique (EN) pour constituer un relevé de preuves.

Quand des URL changent, conservez les métriques par page des anciennes et des nouvelles, et notez la date de migration. Comparez des périodes complètes de 28 jours avec les mêmes filtres pays/appareil et les requêtes pertinentes ; signalez honnêtement les faibles volumes. Ne comptez pas l’URL redirigée comme un second article, et ne qualifiez pas de perte de trafic un rapport d’URL nouvellement vide sans vérifier l’URL qui la précédait. Un changement dans la répartition des requêtes peut faire varier le CTR sans aucune amélioration de la page.

Sources, périmètre et changements apportés par cette révision

Les références officielles ont été vérifiées le 8 octobre 2026 et sont liées à côté des décisions qu’elles étayent. Cette révision supprime des sections de planification en double et remplace les conseils généraux de suppression ou de redirection par des vérifications propres à chaque source de balises. Les exemples sont des scénarios pédagogiques, pas des résultats clients audités. La lecture de ce guide ne modifie aucune configuration de boutique.

Pour la répartition des responsabilités de mise en œuvre, consultez la page Architecture Shopify et couche de contenu. Pour une passation propre à votre boutique, apportez la correspondance des URL et les vérifications en échec — pas vos identifiants — lors d’un échange sur votre projet.