Boutique en Ligne Multilingue sur Tilda : Liste de Contrôle pour le Lancement
Dans cet article : ce qu'il faut traduire dans une boutique en ligne sur Tilda en plus du texte des pages, pourquoi le catalogue et le panier nécessitent une approche particulière, comment configurer les devises pour différents marchés, ce qui est important pour le référencement d'une boutique multilingue et une liste de contrôle complète avant le lancement.
Vous avez créé un site sur Tilda, ajouté un catalogue, configuré le processus de commande. Maintenant, vous devez lancer des versions en anglais et en allemand. Il semble qu'il suffise de traduire le texte.
Selon CSA Research, 76% des acheteurs préfèrent acheter dans leur langue maternelle, et 40% n'achèteront pas du tout dans une autre langue. Mais ajouter une version linguistique et la rendre fonctionnelle sont deux tâches différentes.
En pratique, un magasin multilingue est plus complexe qu'un site web multilingue ordinaire. Il y a un catalogue dynamique, un panier, un processus de commande, des notifications de paiement, des messages d'erreur. Chacun de ces éléments nécessite une attention particulière. Si quelque chose est manqué, un acheteur allemand verra une vitrine en allemand avec un panier en russe.
Ce qu'il faut traduire dans une boutique
Dans une boutique en ligne sur Tilda, il existe plusieurs catégories de contenu qui se comportent différemment. Le texte statique des pages est la moindre partie du problème.
Contenu statique
Description du magasin, textes sur l'entreprise, conditions de livraison, blocs statiques sur la page d'accueil. Cela se traduit de manière standard, n'importe quel traducteur proxy peut le gérer.
Catalogue de produits
Tilda charge les fiches produits dynamiquement via JavaScript. Les noms, descriptions, caractéristiques et prix sont générés après le chargement de la page. La plupart des traducteurs ne voient que la structure HTML, et non ce qui est chargé après.
Résultat : le produit s'appelle « Leather wallet » sur la vitrine, mais en cliquant sur la fiche, il est de nouveau en russe. Ou tout le catalogue reste non traduit, alors que la vitrine est déjà en anglais.
Panier et Commande
Tilda Store est un module distinct avec sa propre logique. Le panier, la page de commande, les champs d'adresse de livraison, le choix du mode de paiement, le bouton «Payer» — tout cela sont des composants distincts. La plupart des services ne les traduisent pas.
Messages Système
«Article ajouté au panier», «stock insuffisant», notifications d'erreur — tout cela est généré dynamiquement. Cela reste souvent dans la langue du site d'origine, même lorsque tout le reste est traduit.
E-mails et notifications
La confirmation de commande par e-mail est une autre histoire. Tilda envoie des e-mails via son propre mécanisme, et Multify n'a aucune influence sur ce processus. Ce n'est pas un bug ni une limitation d'un service spécifique : les e-mails vivent en dehors de la zone de responsabilité du proxy.
Techniquement, cela peut être résolu via une automatisation externe. Multify transmet les champs de langue, de pays et de domaine d'où la demande a été envoyée dans les données du formulaire. Si vous connectez n8n, Make ou un équivalent, vous pouvez configurer la logique : si une demande provient de la version allemande, envoyez un e-mail en utilisant le modèle allemand. Mais c'est une intégration distincte que vous devez configurer vous-même.
Pourquoi les solutions standard ne fonctionnent pas
Weglot et Linguise traduisent le HTML statique. Le contenu dynamique — catalogue, panier, messages — ils ne le voient pas ou le traduisent de manière instable.
Le problème spécifique : lorsqu'un utilisateur ajoute un article au panier, Tilda contacte ses serveurs et reçoit des données en temps réel. À ce moment-là, le traducteur côté client a déjà terminé le traitement de la page. Il ne voit pas les nouvelles données.
La solution est la traduction côté serveur. Lorsque toutes les requêtes vers Tilda passent par le proxy, chaque réponse (y compris les données du catalogue et l'état du panier) est traduite sur le serveur, et le résultat final est déjà livré au navigateur. L'utilisateur voit toujours le contenu traduit, quelle que soit la manière dont il est arrivé sur la page.
Un magasin multilingue nécessite presque toujours une prise en charge de plusieurs devises. Pour un acheteur allemand, les prix doivent être en euros, pour un acheteur britannique, en livres sterling. Il existe trois approches, chacune ayant des conséquences différentes pour le référencement.
Conversion JavaScript
La méthode la plus courante : un script sur la page prend le prix en roubles et le convertit dans la devise souhaitée directement dans le navigateur. L'utilisateur voit des euros, mais le HTML contient toujours des roubles.
C'est mauvais pour le référencement. Googlebot scanne la page et voit les prix en roubles. Si votre site est destiné au marché allemand, il enregistre une divergence entre ce qu'il indexe et ce que l'utilisateur voit. Cela affecte le classement pour les requêtes allemandes.
Gestion manuelle de plusieurs catalogues
Un catalogue séparé avec des prix en euros pour la version allemande. Cela fonctionne, mais nécessite une mise à jour manuelle à chaque changement de prix. C'est acceptable pour un petit catalogue, mais pas pour plus de 200 produits.
Conversion côté serveur
Les prix sont recalculés sur le serveur, et l'utilisateur reçoit une page prête avec la devise souhaitée. Googlebot voit exactement la même chose qu'un acheteur allemand : les prix en euros. Le référencement est correct, les données sont à jour.
Vous pouvez choisir la source des taux de change : une source pour le marché rouble, la BCE pour le marché européen, ou un taux spécifié manuellement – si vous ne voulez pas que les prix changent tous les jours avec le taux de change.
SEO : ce qu'il faut configurer pour chaque version linguistique
Une boutique multilingue sans une bonne base SEO sera invisible dans les moteurs de recherche des marchés cibles.
hreflang
Les balises hreflang indiquent à Google que vous avez plusieurs versions linguistiques d'une même page. Sans elles, le moteur de recherche ne comprend pas quelle version afficher aux utilisateurs de chaque pays et peut considérer les versions linguistiques comme du contenu dupliqué.
Ceci est particulièrement important pour un magasin : chaque produit, chaque catégorie et chaque page de paiement doit avoir un hreflang correct. La documentation officielle de Google décrit en détail les règles de mise en œuvre.
Sitemap pour chaque langue
Le sitemap doit contenir toutes les versions linguistiques de toutes les pages. 300 produits et trois langues, cela représente 900 pages dans le sitemap, chacune avec l'indication de sa langue.
Meta tags pour chaque version
Le titre et la description dans les résultats de recherche doivent être dans la langue de l'utilisateur. Un acheteur allemand voit la description du produit en allemand, un acheteur français en français.
Structure d'URL
Deux modèles principaux : les sous-domaines (de.yourshop.com) et les dossiers (yourshop.com/de/). Pour la plupart des boutiques en ligne sur Tilda, les dossiers sont plus simples à mettre en œuvre et ne nécessitent pas de configurations DNS supplémentaires.
Localisation : ce qui va au-delà de la traduction
Techniquement, la traduction peut être configurée en une journée. Mais pour que le magasin fonctionne pour les acheteurs d'un pays spécifique, plusieurs éléments supplémentaires doivent être pris en compte.
Formats de dates et de nombres. En Allemagne, le prix est écrit « 19,99 € », aux États-Unis — « 19,99 $ ». Le séparateur de milliers, la position du symbole monétaire, le format de la date. Des détails qui sont immédiatement perceptibles par l'acheteur local.
Modes de paiement. L'acheteur russe est habitué à YuKassa ou SBP. L'Européen s'attend à Stripe, PayPal ou un virement SEPA. Afficher tous les modes de paiement à tous les utilisateurs n'a pas de sens, cela crée de la confusion. Il est préférable de n'afficher que ceux qui fonctionnent dans la région spécifique.
Conditions de livraison. Pour chaque marché, il y a des délais différents, des transporteurs différents, des coûts de livraison différents. Cela ne se traduit pas automatiquement, le contenu doit être adapté à chaque marché.
Exigences légales. Pour le marché européen, une bannière de cookies est nécessaire conformément au RGPD, politique de confidentialité dans la langue de l'utilisateur, parfois des informations obligatoires sur le vendeur (Impressum pour l'Allemagne).
Lancez-vous votre boutique sur plusieurs marchés ?
Nous vous montrerons à quoi ressembleront votre catalogue et votre panier dans les langues souhaitées, avec les prix corrects pour chaque marché.
Check-list pour le lancement d'une boutique multilingue sur Tilda
Utilisez cette liste avant de lancer une version linguistique et de l'ouvrir au trafic.
Traduction du contenu
Toutes les pages du site sont traduites, y compris la page d'accueil, la page À propos, les contacts
Catalogue de produits : noms, descriptions, caractéristiques dans la langue cible
Fiches produits, y compris les descriptions étendues et les onglets
Panier : tous les éléments de l'interface sont traduits
Page de commande : champs, boutons, astuces
Messages d'erreur lors du remplissage des formulaires
Confirmation de commande à l'écran
Email de confirmation de commande (la localisation nécessite une intégration séparée via n8n / Make)
Prix et devises
Les prix sont affichés dans la devise du marché cible
La conversion a lieu côté serveur (pas via JS)
Source des taux de change sélectionnée : live currency exchange rate / ECB / manually specified rate
Le format de prix est conforme aux normes du pays (séparateur, symbole monétaire)
Les prix dans la recherche (Google Shopping, si utilisé) correspondent aux prix sur le site
SEO
Les balises hreflang sont définies sur toutes les pages, y compris les fiches produits
Le Sitemap contient toutes les versions linguistiques de toutes les pages
Titre et description de chaque page dans la langue de la version
La structure d'URL des versions linguistiques est cohérente (sous-domaines ou dossiers)
Les balises canoniques sont correctement configurées, il n'y a pas de duplication
Fonctionnalité
Le sélecteur de langue fonctionne sur toutes les pages, y compris les pages de commande
L'ajout d'un produit au panier ne change pas la langue de l'interface
La langue est conservée lors du retour sur le site
La détection automatique de la langue par géolocalisation est configurée (si nécessaire)
La recherche dans le catalogue fonctionne dans la langue cible
Modes de paiement
Les modes de paiement disponibles correspondent au marché
Une commande test a été effectuée avec succès sur chaque version linguistique
L'e-mail de confirmation est envoyé dans la langue de l'acheteur
Exigences légales
La politique de confidentialité est traduite
Les conditions d'utilisation sont traduites
La bannière de cookies est configurée (obligatoire pour le marché européen)
Restrictions d'âge ou autres prises en compte pour le marché spécifique
Vérification finale
Parcours d'achat complet testé : de la vitrine à la confirmation de commande
Affichage mobile vérifié sur la version linguistique
Vitesse de chargement de la version linguistique acceptable
Le trafic vers la version linguistique est suivi séparément dans l'analyse
Erreurs typiques au lancement
Lancement de la traduction sans vérifier le panier. La situation la plus fréquente : la vitrine est traduite, le catalogue semble bon, mais le panier et le paiement sont restés en russe. L'acheteur est arrivé à la commande et a vu une interface non traduite. Parcourez toujours le chemin d'achat complet avant le lancement.
Les prix sont traduits via JS. Visuellement, tout semble correct, mais Googlebot voit les prix en roubles sur la page en allemand. Cela affecte le classement dans les recherches allemandes et l'apparence des fiches produits dans Google Shopping.
Pas de hreflang sur les pages produits. Vous l'avez configuré sur la page d'accueil, sur les pages de catégories aussi, mais vous avez oublié les fiches produits. Google ne comprend pas que /de/product/leather-wallet est la version allemande de /product/leather-wallet, et peut montrer la version russe aux utilisateurs allemands.
Vous avez oublié les e-mails. Le client a passé une commande en allemand, mais la lettre de confirmation est arrivée en russe. Tilda envoie des e-mails via son propre mécanisme, et cela n'est pas résolu automatiquement. Si vous souhaitez des e-mails traduits, une intégration séparée via n8n ou Make est nécessaire — Multify transmet la langue et le domaine d'où provient la commande dans les données du formulaire, et vous pouvez construire la logique de sélection de modèle sur cette base.
FAQ
Faut-il un domaine séparé pour chaque version linguistique du magasin ?
Non. Un seul domaine avec des dossiers (yourshop.com/de/) est la solution standard pour la plupart des magasins. Un domaine ou un sous-domaine séparé n'a de sens que si vous créez un produit entièrement localisé pour un pays spécifique avec une marque distincte. Pour lancer plusieurs langues sans refonte radicale, les dossiers sont plus simples.
Comment Multify gère-t-il le catalogue si les produits sont chargés dynamiquement ?
Multify fonctionne comme un proxy au niveau du serveur. Toutes les requêtes vers Tilda, y compris les requêtes de données de catalogue, passent par lui. La réponse avec les produits est traduite sur le serveur, et le contenu traduit est déjà envoyé au navigateur. Cela fonctionne à la fois pour les blocs Tilda Store standard et pour Zero Block.
Est-il possible d'afficher des prix différents pour différents pays, et pas seulement des devises différentes ?
Oui. En plus de la conversion de devises, vous pouvez définir des prix fixes pour des versions linguistiques spécifiques. Par exemple, pour la version allemande, vous pouvez définir un prix de 29 €, non lié au taux de change du rouble. C'est pratique si vous avez des politiques de prix différentes sur différents marchés.
Comment mettre à jour les traductions lorsque le contenu du magasin change ?
Lorsque de nouveaux produits sont ajoutés ou que des descriptions sont modifiées, les traductions sont automatiquement mises à jour lors de la prochaine requête. Il n'est pas nécessaire de mettre à jour manuellement les traductions dans l'interface à chaque fois : la couche proxy traite le nouveau contenu de la même manière que l'original.
Faut-il configurer quelque chose dans Tilda même pour un magasin multilingue ?
Du côté de Tilda, aucune configuration supplémentaire n'est généralement nécessaire. Vous travaillez dans l'éditeur comme d'habitude : vous ajoutez des produits, modifiez des descriptions, mettez à jour des prix. Tout le reste est pris en charge par Multify au niveau du proxy.
Lancer un magasin multilingue sur Tilda, ce n'est pas seulement ajouter une traduction. Vous devez vous assurer que chaque étape du parcours d'achat fonctionne dans la langue de votre client : de la fiche produit à l'e-mail de confirmation. La checklist ci-dessus vous aidera à ne rien oublier avant le lancement.
Prêt à lancer votre magasin sur de nouveaux marchés ?
Nous connecterons Multify, vérifierons le catalogue, le panier et le processus de commande, et vous montrerons à quoi cela ressemble dans les langues souhaitées.