76% des gens sont plus susceptibles d'acheter un produit si la description est dans leur langue maternelle — ce sont les données de CSA Research. Donc la traduction n'est pas seulement une « courtoisie », mais un travail direct sur la conversion.
Le client demande une version anglaise du site. Vous ouvrez Tilda et réalisez : il n'y a pas de moyen intégré de créer un site multilingue. Il n'y a que quelques solutions de contournement, et la plupart d'entre elles créent des problèmes au début ou plus tard.
Option 1 : Projet séparé dans Tilda
La solution la plus évidente : vous dupliquez le projet, traduisez tout manuellement, publiez sur un autre domaine ou sous-domaine.
Dès que le client modifie quelque chose sur le site principal, vous allez dans la copie et faites la même chose. Si le client gère activement un blog ou met à jour un catalogue, cela se transforme en une synchronisation manuelle sans fin. De plus, le contenu doit toujours être traduit et mis en page à nouveau dans l'éditeur Tilda, car les éléments peuvent se déplacer.
Un autre problème : le SEO. Tilda n'a pas de mécanisme intégré pour hreflang entre deux projets distincts. Sans hreflang, Google ne comprend pas que deux sites sont liés et peut percevoir la version anglaise comme du contenu dupliqué.
Convient aux pages de destination uniques avec des mises à jour rares, qui ne sont pas destinées à être promues dans les moteurs de recherche.
Option 2 : Zero Block avec un sélecteur de langue
Ceci est utilisé par les agences qui veulent tout faire au sein d'un seul projet Tilda. La logique : un bloc en russe est caché via CSS, l'autre est affiché. La langue est changée par un bouton.
Cela ressemble à une solution, mais les moteurs de recherche ne comprennent pas une telle page. Google voit un contenu mixte des deux langues à la fois : il ne sait pas que le texte russe est pour certains utilisateurs et l'anglais pour d'autres. Pas de hreflang, pas de séparation par langue. Pour le référencement, cela peut être pire que deux sites distincts.
De plus, les formulaires et le contenu dynamique ne sont pas traduits avec cette approche : les boutons du catalogue, les champs de formulaire, les messages d'erreur, — tout cela reste dans la langue d'origine.
Option 3 : Services de traduction avec script JS
Weglot, Linguise et des solutions similaires fonctionnent avec Tilda via un script JS sur la page : le navigateur charge le contenu original, le script le remplace par la version traduite.
Visuellement, cette approche fonctionne : l'utilisateur voit le texte traduit, bien que pas immédiatement après le chargement de la page, mais après un certain temps. Cependant, il n'y a aucun avantage pour le SEO : les robots d'exploration n'indexent que la version originale du site, car ils voient le contenu avant que le script JS n'ait eu le temps de le remplacer.
Les robots d'exploration indexent ce qu'ils voient lors du rendu initial. Ils peuvent ne pas voir le contenu JS ou le voir avec un délai. Cela signifie que votre version anglaise dans la recherche sera moins bien indexée que souhaité, ou pas indexée du tout.
Option 4 : Proxy avec traduction côté serveur
Fonctionnement : un serveur proxy se place entre l'utilisateur et votre site web, traduisant tout le contenu côté serveur. Le navigateur reçoit alors un HTML déjà traduit.
Ce que cela apporte :
- Les moteurs de recherche voient le contenu entièrement traduit, et non un brouillon avec JS
- hreflang est généré automatiquement (dans les métabalises de chaque page et dans les sitemaps)
- Tout le contenu dynamique est traduit : catalogue, formulaires, boutons, textes d'erreur
- La gestion du contenu se fait uniquement sur le site source, le nombre de langues n'augmente pas la charge de travail
C'est ainsi que Multify fonctionne. Vous connectez la version anglaise via un sous-domaine (par exemple, en.votresite.ru) ou un domaine séparé, tout le reste se passe au niveau du serveur.
Ce qu'il faut prendre en compte lors de la création d'une version anglaise
Structure du domaine
Deux options : un sous-domaine (en.site.ru) ou un domaine séparé (site.com). Pour la plupart des projets, un sous-domaine est plus simple à configurer et fonctionne bien du point de vue du SEO. Un domaine séparé a du sens si vous prévoyez de construire une marque distincte pour le marché occidental.
Les dossiers (site.ru/en/) ne sont pas nativement pris en charge par Tilda. Sans proxy, cela ne peut pas être mis en œuvre, bien que cette option soit plus avantageuse : la réputation d'un seul domaine augmente, et il n'est pas nécessaire de se disperser pour promouvoir plusieurs sites à la fois.
Contenu à adapter
La traduction mécanique du texte n'est que la moitié du travail. Pour un public anglophone, il est souvent nécessaire de :
- Remplacer les exemples et les cas par des exemples compréhensibles pour le lecteur occidental
- Changer les méthodes de paiement : certains systèmes de paiement qui fonctionnent en Russie peuvent ne pas fonctionner à l'étranger
- Ajuster les appels à l'action : ce qui fonctionne pour un public russophone peut sembler étrange en anglais
- Vérifier les images : contiennent-elles du texte qui doit également être traduit ?
Hreflang et plan du site
Sans un hreflang correctement configuré, Google peut afficher la version anglaise aux utilisateurs russophones, et vice versa. La configuration manuelle de hreflang dans Tilda n'est pas triviale : la plateforme propose d'insérer le code manuellement dans le HEAD de chaque page — il n'y a pas d'interface automatique.
Lors de l'utilisation d'une solution proxy, hreflang est généralement généré automatiquement pour chaque page. Le plan du site est également mis à jour automatiquement.
Formulaires sur la version anglaise
C'est une histoire à part. Un formulaire sur Tilda, traduit mécaniquement, envoie toujours les données au système de notification en russe, si cela n'est pas configuré séparément. Les champs, les astuces à l'intérieur des champs, les messages après l'envoi, les textes d'erreur lors de la validation — tout cela doit être traduit séparément.
Erreurs typiques lors du lancement d'une version anglaise sur Tilda
Publier sans hreflang. Les moteurs de recherche verront deux sites sans lien entre eux. Le trafic pourrait ne pas aller là où il le faut.
Traduire uniquement le texte, ignorer la dynamique. Catalogue en anglais, boutons « Ajouter au panier » en russe. La conversion sera en conséquence.
Créer un projet séparé et ne pas penser à la synchronisation. Les deux premiers mois, tout va bien. Ensuite, le client commence à apporter des modifications, et l'un des sites "prend du retard".
Ignorer les systèmes de paiement. YuKassa et Robokassa n'acceptent pas les cartes étrangères. Si la version anglaise est destinée à un public occidental, Stripe ou PayPal est nécessaire.
Comment prendre une décision
Si le site est simple (landing page, carte de visite) et que la version anglaise est nécessaire une fois pour toutes sans mises à jour, un projet séparé dans Tilda est le plus simple. Si le site est vivant, avec des mises à jour régulières, un catalogue ou des formulaires, une solution proxy est nécessaire. Tout le reste crée une dette qu'il faudra rembourser plus tard.
