Eine Agentur verbindet Weglot mit einer Tilda-Website. Das Plugin wird installiert, der Sprachumschalter erscheint. Dann stellt sich heraus, dass der Produktkatalog auf Russisch geblieben ist, das Kontaktformular ebenfalls, und ein Teil des Inhalts überhaupt nicht geladen wird. Dies ist kein Installationsfehler. Es ist eine grundlegende architektonische Einschränkung: Weglot übersetzt nur statischen Inhalt, von dem es in Tilda wenig gibt, während der gesamte dynamische Inhalt unübersetzt bleibt.
Weglot funktioniert nicht nur als JS-Skript, sondern als Reverse Proxy über DNS. Das Problem ist, dass es die Besonderheiten der Tilda-Architektur nicht berücksichtigt, was zu Schwierigkeiten bei der Übersetzung von Inhalten führt.
Wie Weglot im Allgemeinen funktioniert
Reverse Proxys funktionieren gut auf statischen Websites mit einer einfachen HTML-Struktur: ein gewöhnlicher Blog, eine Landingpage ohne dynamische Blöcke. Weglot kommt hervorragend mit WordPress, Shopify, Webflow zurecht – dort ist der Inhalt vorhersehbar und für das Skript sofort beim Laden verfügbar.
Tilda ist anders aufgebaut: Es hat spezifische Funktionen und viele dynamische Inhalte, die einen besonderen Ansatz erfordern.
Warum Tilda ein Sonderfall ist
Tilda generiert Seiten in Blöcken. Der Großteil des Inhalts wird standardmäßig geladen, aber eine Reihe von Blöcken funktioniert über eigene Mechanismen: AJAX-Anfragen, separate API-Anfragen.
Zu diesen Blöcken gehören:
- Produktkatalog (Tilda Store) – Produktdaten werden durch eine separate Anfrage an den Tilda-Server geladen und sind nicht im ursprünglichen HTML enthalten. Das JS-Skript von Weglot wird ausgeführt, bevor diese Daten im DOM erscheinen.
- Formulare (Tilda Forms) – Feldnamen, Beschriftungen, Fehlermeldungen und Schaltflächentexte werden teilweise dynamisch gerendert. Weglot fängt nicht alles ab.
- Widgets und Drittanbieter-Einbettungen – TravelLine, Calendly, Buchungs-Widgets werden in einem iframe von einer anderen Domain geladen. Das JS von Weglot hat dort einfach keinen Zugriff: Dies ist eine Browserbeschränkung, nicht die von Weglot.
Fazit: Auf einer typischen kommerziellen Tilda-Website mit Katalog und Formularen übersetzt Weglot etwa die Hälfte des Inhalts. Der Rest bleibt in der Originalsprache.
Was das für SEO bedeutet
Dies ist ein separates Problem, und es ist ernster, als es auf den ersten Blick scheint.
Weglot übersetzt über die DNS-Integration (Reverse Proxy) statische Inhalte serverseitig erfolgreich. Für dynamische Elemente, die über JS geladen werden, funktioniert diese Methode jedoch nicht: Googlebot kann die Seite indexieren, bevor das Skript den Text ersetzt, wodurch die Originalversion in den Index gelangt.
Für dynamische Blöcke versucht Weglot, den Inhalt erst nach dem Laden der Seite zu übersetzen, was zu Verzögerungen und visuellen Sprüngen führt. Im Gegensatz dazu integriert sich Multify direkt in die Tilda-API und übersetzt die Daten, bevor die Antwort im Browser ankommt: Für den Benutzer erscheint der Inhalt sofort übersetzt, als ob er ursprünglich vom Tilda-Server gekommen wäre.
Dies wirkt sich direkt auf die Positionen für Schlüsselanfragen in Fremdsprachen aus: Die Seite existiert, die Übersetzung existiert, aber die Suchmaschine erkennt sie nicht als übersetzt. Weglot selbst bestätigt: Die JS-Integration bietet keine SEO-Vorteile, da Übersetzungen nicht im Quell-HTML landen.
Nuancen mit hreflang
Weglot fügt hreflang-Tags statisch hinzu. Obwohl dies Suchmaschinen ermöglicht, Sprachversionen zu erkennen, gibt es eine technische Nuance: Weglot fügt das x-default-Tag nicht hinzu. Multify hingegen implementiert x-default korrekt gemäß den Google-Empfehlungen, was Suchmaschinen hilft, die Standard-Sprachversion besser zu bestimmen.
Was tun damit?
Weglot ist ein gutes Produkt, es funktioniert dort, wo der Inhalt statisch und vorhersehbar ist. Aber auf Tilda mit Katalog und Formularen funktioniert es nur teilweise. Dies ist keine Frage der Einstellung oder des Tarifs, sondern eine architektonische Einschränkung. Weglot ist ursprünglich für WordPress und Shopify konzipiert.
Multify ist auf Tilda zugeschnitten: Es übersetzt dynamische Inhalte, Formulare und den Katalog und konvertiert Währungen serverseitig. Metatags für die richtige SEO werden direkt im HTML generiert.
Der Proxy-Ansatz ist grundlegend anders: Die Übersetzung erfolgt auf dem Server, und die bereits übersetzte Seite wird an den Browser gesendet. Google sieht dasselbe, was der Benutzer sieht.
FAQ
Funktioniert Weglot überhaupt nicht mit Tilda?
Es funktioniert, aber nur teilweise. Statische Inhalte (Überschriften, Textblöcke, normale Seiten) werden von Weglot übersetzt. Probleme treten bei Produktkatalogen, Formularen und allem, was dynamisch geladen wird, auf.
Wenn ich eine einfache Landingpage ohne Katalog habe – ist Weglot geeignet?
Für eine Landingpage ohne dynamische Blöcke ist Weglot wahrscheinlich geeignet. Bei Pop-ups wird es keine Probleme geben, Schwierigkeiten treten nur bei Formularen auf: Tilda wird Anfragen einfach nicht annehmen, da keine Integration besteht. Für eine kommerzielle Website mit Shop ist es nicht geeignet.
Warum kann Google die Weglot-Übersetzung möglicherweise nicht sehen?
Google kann die Übersetzung möglicherweise nicht sehen, wenn sie über JavaScript verbunden ist. In diesem Modus indizieren Suchmaschinen-Bots (z. B. Googlebot) die Seite asynchron: Sie können den ursprünglichen HTML-Code erfassen, bevor das Skript ausgeführt werden konnte. Infolgedessen bleibt die Originalsprache im Index, da dies eine Besonderheit der clientseitigen JS-Übersetzung ist.
Gibt es eine offizielle Integration von Weglot mit Tilda?
Weglot kann mit Tilda verbunden werden, indem ein spezielles Skript in die Website-Einstellungen eingefügt wird. Dies ist keine offizielle Integration, sondern lediglich eine Methode zur Code-Implementierung auf den Seiten.
