An agency connects Weglot to a Tilda website. The plugin is installed, the language switcher button appears. Then it turns out that the product catalog remains in Russian, the feedback form too, and some content doesn't load at all. This is not an installation error. This is a fundamental architectural limitation: Weglot only translates static content, of which there is little in Tilda, while all dynamic content remains untranslated.
Weglot works not just as a JS-script, but as a reverse proxy via DNS. The problem is that it doesn't account for the specifics of Tilda's architecture, which leads to difficulties in translating content.
How Weglot Works in General
Reverse proxy works well on static sites with a simple HTML structure: a regular blog, a landing page without dynamic blocks. Weglot handles WordPress, Shopify, Webflow excellently — there, the content is predictable and accessible to the script immediately upon loading.
Tilda is structured differently: it has specific functionality and a lot of dynamic content that requires a special approach.
Why Tilda is a Different Case
Tilda generates pages in blocks. Most of the content loads standardly, but a number of blocks work through their own mechanisms: AJAX requests, separate API requests.
These blocks include:
- Product Catalog (Tilda Store) — product data is loaded by a separate request to the Tilda server, and is not present in the original HTML. The Weglot JS script runs before this data appears in the DOM.
- Forms (Tilda Forms) — field names, captions, error messages, and button texts are partially rendered dynamically. Weglot does not intercept everything.
- Widgets and third-party embeds — TravelLine, Calendly, booking widgets are loaded in iframes from another domain. Weglot's JS simply does not have access there: this is a browser limitation, not Weglot's.
In total: on a typical commercial Tilda website with a catalog and forms, Weglot translates approximately half of the content. The rest remains in the original language.
What This Means for SEO
This is a separate problem, and it's more serious than it appears at first glance.
Weglot, through DNS integration (Reverse Proxy), successfully translates static content on the server side. However, for dynamic elements loaded via JS, this method does not work: Googlebot may index the page before the script performs text replacement, causing the original version to be indexed.
For dynamic blocks, Weglot attempts to translate content after the page loads, which causes delays and visual jumps. In contrast, Multify integrates directly into the Tilda API and translates data before the response reaches the browser: for the user, the content appears translated immediately, as if it originally came from the Tilda server.
This directly affects positions for key queries in foreign languages: the page exists, the translation exists, but the search engine does not see it as translated. Weglot itself confirms: JS integration does not provide SEO benefits because translations do not get into the source HTML.
Nuances with hreflang
Weglot adds hreflang tags statically. While this allows search engines to discover language versions, there is a technical nuance: Weglot does not add the x-default tag. Whereas Multify correctly implements x-default in accordance with Google's recommendations, which helps search engines better determine the default language version.
What to do about it
Weglot is a good product; it works where content is static and predictable. But on Tilda with a catalog and forms, it works partially. This is not a matter of settings or pricing plan, but an architectural limitation. Weglot is originally designed for WordPress and Shopify.
Multify is designed for Tilda: it translates dynamic content, forms, and catalogs, and also converts currencies on the server side. Metatags for proper SEO are generated directly in HTML.
The proxy approach is fundamentally different: translation happens on the server, and the browser receives an already translated page. Google sees the same thing the user sees.
FAQ
Does Weglot not work with Tilda at all?
It works, but partially. Weglot will translate static content (headings, text blocks, regular pages). Problems begin with the product catalog, forms, and everything that loads dynamically.
If I have a simple landing page without a catalog, will Weglot work?
For a landing page without dynamic blocks, Weglot will most likely work. There will be no problems with pop-ups, difficulties will only arise with forms: Tilda simply will not accept applications, as there is no integration. It is not suitable for a commercial website with a store.
Why might Google not see the translation from Weglot?
Google may not see the translation if it is connected via JavaScript. In this mode, search engine crawlers (such as Googlebot) index the page asynchronously: they may record the original HTML before the script has had a chance to execute. As a result, the original language remains in the index, as this is a feature of client-side JS translation.
Does Weglot have an official integration with Tilda?
Weglot can be connected to Tilda by adding a special script to the site settings. This is not an official integration, but simply a way to embed code on pages.