Une agence connecte Weglot à un site Tilda. Le plugin est installé, le bouton de changement de langue apparaît. Puis il s'avère que le catalogue de produits est resté en russe, le formulaire de contact aussi, et qu'une partie du contenu ne se charge pas du tout. Ce n'est pas une erreur d'installation. C'est une limitation fondamentale de l'architecture : Weglot ne traduit que le contenu statique, qui est peu présent sur Tilda, tandis que tout le contenu dynamique reste non traduit.
Weglot ne fonctionne pas simplement comme un script JS, mais comme un proxy inverse via DNS. Le problème est qu'il ne prend pas en compte les spécificités de l'architecture de Tilda, ce qui entraîne des difficultés pour traduire le contenu.
Comment Weglot fonctionne en général
Cela fonctionne bien sur les sites statiques avec une structure HTML simple : un blog ordinaire, une page de destination sans blocs dynamiques. Weglot gère parfaitement WordPress, Shopify, Webflow — là, le contenu est prévisible et immédiatement accessible au script lors du chargement.
Tilda est structuré différemment : il a des fonctionnalités spécifiques et beaucoup de contenu dynamique qui nécessite une approche particulière.
Pourquoi Tilda est un cas différent
Tilda génère des pages par blocs. La majeure partie du contenu est chargée de manière standard, mais un certain nombre de blocs fonctionnent via leurs propres mécanismes : requêtes AJAX, appels API distincts.
Ces blocs incluent :
- Catalogue de produits (Tilda Store) — les données sur les produits sont chargées par une requête distincte vers le serveur Tilda, et ne sont pas présentes dans le HTML source. Le script JS de Weglot s'exécute avant que ces données n'apparaissent dans le DOM.
- Formulaires (Tilda Forms) — les noms de champs, les étiquettes, les messages d'erreur et les textes des boutons sont partiellement rendus dynamiquement. Weglot n'intercepte pas tout.
- Widgets et insertions tierces — TravelLine, Calendly, les widgets de réservation sont chargés dans un iframe depuis un autre domaine. Le JS de Weglot n'y a tout simplement pas accès : c'est une restriction du navigateur, pas de Weglot.
En résumé : sur un site commercial typique sur Tilda avec un catalogue et des formulaires, Weglot traduit environ la moitié du contenu. Le reste reste dans la langue d'origine.
Qu'est-ce que cela signifie pour le SEO
C'est un problème distinct, et il est plus grave qu'il n'y paraît à première vue.
Weglot, via l'intégration DNS (Reverse Proxy), traduit avec succès le contenu statique côté serveur. Cependant, pour les éléments dynamiques chargés via JS, cette méthode ne fonctionne pas : Googlebot peut indexer la page avant que le script n'effectue le remplacement de texte, ce qui fait que la version originale est indexée.
Pour les blocs dynamiques, Weglot tente de traduire le contenu après le chargement de la page, ce qui entraîne des retards et des sauts visuels. Contrairement à lui, Multify s'intègre directement à l'API Tilda et traduit les données avant que la réponse n'arrive dans le navigateur : pour l'utilisateur, le contenu apparaît traduit immédiatement, comme s'il provenait initialement du serveur Tilda.
Cela affecte directement le classement pour les mots-clés étrangers : la page existe, la traduction existe, mais le moteur de recherche ne la voit pas comme traduite. Weglot confirme lui-même: l'intégration JS n'offre pas d'avantages SEO, car les traductions ne sont pas incluses dans le HTML source.
Nuances avec hreflang
Weglot ajoute des balises hreflang de manière statique. Bien que cela permette aux moteurs de recherche de détecter les versions linguistiques, il y a une nuance technique : Weglot n'ajoute pas la balise x-default. Contrairement à lui, Multify implémente correctement x-default conformément aux recommandations de Google, ce qui aide les moteurs de recherche à mieux déterminer la version linguistique par défaut.
Que faire à ce sujet
Weglot est un bon produit, il fonctionne bien là où le contenu est statique et prévisible. Sur Tilda avec un catalogue et des formulaires, il fonctionne partiellement. Ce n'est pas une question de configuration ou de tarif, mais une limitation architecturale. À l'origine, Weglot est conçu pour WordPress et Shopify.
Multify est conçu pour Tilda : il traduit le contenu dynamique, les formulaires et le catalogue, et convertit les devises côté serveur. Les balises meta pour un bon SEO sont générées directement dans le HTML.
L'approche par proxy est fondamentalement différente : la traduction a lieu sur le serveur, et la page déjà traduite est envoyée au navigateur. Google voit la même chose que l'utilisateur.
FAQ
Weglot ne fonctionne pas du tout sur Tilda ?
Il fonctionne, mais partiellement. Le contenu statique — titres, blocs de texte, pages ordinaires — sera traduit par Weglot. Les problèmes commencent avec le catalogue de produits, les formulaires et tout ce qui est chargé dynamiquement.
Si j'ai une simple page de destination sans catalogue, Weglot conviendra-t-il ?
Pour une page de destination sans blocs dynamiques, Weglot fera probablement l'affaire. Il n'y aura pas de problèmes avec les pop-ups, mais des difficultés surgiront avec les formulaires : Tilda n'acceptera tout simplement pas les demandes, car il n'y a pas d'intégration. Pour un site commercial avec une boutique, cela ne convient pas.
Pourquoi Google pourrait ne pas voir la traduction de Weglot ?
Google peut ne pas voir la traduction si elle est connectée via JavaScript. Dans ce mode, les robots d'exploration (par exemple, Googlebot) indexent la page de manière asynchrone : ils peuvent enregistrer le HTML original avant que le script n'ait eu le temps de s'exécuter. En conséquence, la langue originale reste dans l'index, car c'est une particularité du fonctionnement de la traduction JS côté client.
Existe-t-il une intégration officielle de Weglot avec Tilda ?
Weglot peut être connecté à Tilda en ajoutant un script spécial dans les paramètres du site. Ce n'est pas une intégration officielle, mais simplement un moyen d'implémenter du code sur les pages.
