Pourquoi Weglot ne fonctionne pas sur Tilda : une analyse détaillée

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 de traduction du contenu.

Le proxy inverse 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 — où le contenu est prévisible et disponible pour le script dès le 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.

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, requêtes API distinctes.

Ces blocs incluent :

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.

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 entraîne l'indexation de la version originale.

Pour les blocs dynamiques, Weglot tente de traduire le contenu après le chargement de la page, ce qui provoque des retards et des sauts visuels. Contrairement à cela, 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 des requêtes clés dans les langues étrangères : 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 aucun avantage SEO, car les traductions ne sont pas incluses dans le HTML source.

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. Alors que 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.

Weglot est un bon produit, il fonctionne là où le contenu est statique et prévisible. Mais sur Tilda avec un catalogue et des formulaires, il ne fonctionne que partiellement. Ce n'est pas une question de configuration ou de tarif, mais une limitation architecturale. Weglot est initialement 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 méta pour un bon référencement 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.

Cela fonctionne, mais partiellement. Weglot traduira le contenu statique (titres, blocs de texte, pages ordinaires). Les problèmes commencent avec le catalogue de produits, les formulaires et tout ce qui est chargé dynamiquement.

Pour une page de destination sans blocs dynamiques, Weglot conviendra probablement. Il n'y aura pas de problèmes avec les pop-ups, les difficultés n'apparaîtront qu'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.

Google peut ne pas voir la traduction si elle est connectée via JavaScript. Dans ce mode, les robots des moteurs de recherche (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.

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.