Tout ce que les marchands Shopify font de travers avec Translate & Adapt (et la seule chose importante qu’ils réussissent)
La vraie force de l'application, c'est un domaine, plusieurs langues. La plupart des boutiques multilingues qui échouent ne le doivent pas à l'outil. Elles échouent sur les présupposés qu'il vous laisse discrètement conserver.
- L'application fait une chose à merveille : plusieurs langues sur un seul domaine, au lieu d'extensions nationales fragmentées.
- La plupart des échecs viennent de la configuration, pas de l'outil : handles non traduits, trop de variantes linguistiques, hreflang cassé.
- La traduction des handles existe, mais les boutiques créées avant 2023 ne l'ont jamais remarquée. Corrigez le tout en masse avec un import CSV.
- Dépasser les limites de l'application est bon signe. Sachez où se situe son plafond avant de l'atteindre.
Commençons par la seule chose que Translate & Adapt réussit vraiment, car c’est la raison même de l’utiliser. L’application sert plusieurs langues depuis un domaine unique. Pas d’extensions .be, .nl et .de fragmentées qui se disputent chacune leur propre autorité, pas de boutiques dupliquées à maintenir synchronisées. Un seul domaine, des sous-dossiers par marché, et toute la valeur des liens qui se concentre au même endroit.
Shopify fixe les règles, vous jouez à l’intérieur
C’est l’architecture correcte pour l’immense majorité des boutiques, et Shopify en fait le comportement par défaut. Le revers, c’est que Shopify décide aussi comment cette architecture se comporte, et vous ne pouvez jouer qu’à l’intérieur de ces règles. La plupart des problèmes qu’on me demande de corriger commencent quand quelqu’un pense qu’installer l’application équivalait à terminer le travail.
Les échecs que je constate réellement
Quand une boutique Shopify multilingue sous-performe, ce n’est presque jamais le moteur. C’est la configuration posée par-dessus. Trois problèmes expliquent presque tout :
Des handles d’URL non traduits. Le texte visible est traduit, mais le slug de l’URL est toujours en anglais, ou pire, c’est encore un handle Shopify aléatoire. Pour un moteur de recherche, la page paraît à moitié localisée, et le marché qu’elle est censée servir ne lui fait jamais pleinement confiance.
Trop de variantes linguistiques. C’est le gros problème, et il mérite sa propre section plus bas. Les boutiques ajoutent chaque locale plausible « au cas où », et se cannibalisent en silence.
Des pointeurs hreflang cassés. Les variantes se référencent mal entre elles, ou pointent vers des pages qui n’existent plus. Google ne peut pas construire un cluster propre, alors il choisit un gagnant à votre place, et ce n’est presque jamais celui que vous vouliez.
Corriger les handles : c’est bien là, mais ça ne l’a pas toujours été
Voici ce que la plupart des gens ignorent : la traduction des handles existe dans Translate & Adapt. Vous pouvez localiser le slug par marché. Si tant de boutiques ne le font jamais, c’est une question de calendrier, pas de capacité.
Les boutiques créées avant début 2023 sont antérieures au moment où la fonctionnalité est devenue évidente, l’habitude ne s’est donc jamais prise. Le handle anglais est devenu le handle définitif, et personne n’y est revenu. Si c’est votre cas, la solution n’est pas de modifier page par page. Exportez votre contenu, traduisez les handles en masse et réimportez avec un CSV. C’est la différence entre un après-midi et un trimestre.
Ce n’est pas l’outil qui casse. C’est l’idée qu’en l’installant, le travail était terminé.
Le piège des langues, en détail
Passons à l’erreur coûteuse. Face à une audience néerlandophone aux Pays-Bas, en Belgique et dans le reste de l’UE, le réflexe est de créer une variante pour chacun : nl, nl-BE, nl-EU. Cela donne l’impression d’être exhaustif. En réalité, ce sont trois pages presque identiques qui se disputent les mêmes requêtes, divisent les signaux et empêchent Google de savoir laquelle positionner.
N’ajoutez une variante que lorsqu’elle mérite sa place, avec un contenu, des prix ou des conditions de livraison réellement différenciés. Sinon, vous ne couvrez pas plus de terrain, vous diluez celui que vous possédez déjà.
| Variante | Différenciée ? | Verdict |
|---|---|---|
| nl | Marché principal, catalogue complet | Garder |
| nl-BE | Prix, livraison et TVA propres | Garder, si c’est réel |
| nl-EU | Doublon de nl | Supprimer |
Une bonne variante vaut mieux que trois variantes créées par précaution. À chaque fois.
Là où l’application atteint son plafond
Pour être juste avec l’outil, il arrive un moment où le problème n’est plus votre configuration mais les limites de l’application. Translate & Adapt gère bien le contenu principal, mais s’essouffle sur les bords : le contenu des applications tierces, les filtres de collections et les métadonnées d’images passent souvent à travers les mailles sans être traduits.
Si vous vous heurtez à ces murs, ce n’est pas un échec. Cela signifie généralement que vous avez dépassé le stade du plug-in et que vous entrez dans un véritable processus de localisation, avec une mémoire de traduction digne de ce nom et une couverture de tout ce que l’application ne peut pas atteindre.
Alors, on garde ou on abandonne ?
Gardez-la, pour presque tout le monde. Pour une boutique qui veut plusieurs langues sur un seul domaine sans gérer une infrastructure de localisation, Translate & Adapt est le bon choix par défaut et fait bien le plus difficile. Considérez simplement son installation comme le début du travail : traduisez vos handles, soyez impitoyable sur les variantes et vérifiez que votre cluster hreflang est réellement propre.
Ne l’abandonnez que lorsque vous l’avez vraiment dépassée, quand le contenu tiers, les filtres et les métadonnées comptent au point que ce plafond vous coûte du chiffre d’affaires réel. Arriver à ce stade n’est pas un échec de l’outil. C’est le signe que vous êtes en train de gagner.
